Can Web Browsers be “Secure” as Required by Federal Cybersecurity Guidelines?

This blog was originally published by Ericom Software here.

Written by Gerry Grealish, Ericom Software Chief Marketing Officer.

The National Institute of Standards and Technology (NIST) issued its “Definition of Critical Software Under Executive Order,” one of the first items to be delivered in response to President Biden’s May 12 Executive Order on Improving the Nation’s Cybersecurity. The executive order laid out the Administration’s plan to modernize Federal government cybersecurity by, in part, adopting Zero Trust architectures.

The NIST document comprises a list of software categories and products that require high levels of “privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.” The products include operating systems, web browsers, hypervisors, and endpoint security tools, among others.

The issuance of these definitions triggers a cascade of further activity. NIST, CISA and OMB now have 60 days to jointly publish guidelines for securing these products by “outlining security measures for critical software… including applying practices of least privilege, network segmentation, and proper configuration.”

But here is the challenge: Among the software products listed in the NIST definitions, there is one that is, by its nature, the very antithesis of Zero Trust. That, in fact, has great “potential for harm” even when not compromised. Whose very functioning depends on the “implicit trust” that Zero Trust security firmly rejects.

Web Browsers: Just Doing Their Jobs

That product is the web browser. While some web browsers offer more security features than others, the basic function of a web browser is to bring internet content to users’ computing devices. And as we all know too well given the sophisticated nature of advanced threats, internet content can never be verified as being completely safe.

Recent research indicates that in the first quarter of 2021, 74% of malware was zero-day – that is, “polymorphic, evasive malware that bypasses signature-based protections on day ‘zero’ of its release.” The volume of malware threats detected per minute hit a new high of 688 during that period as well. Of course, “detected” doesn’t necessarily mean “new.” Most threats are out there, on the web, for some time before they are recognized and detected. Now think about this – even if it takes just 12 hours for security companies to pick up on new malware signatures or strains and update their threat intelligence networks and secure web gateways to block them, there is a lot of malware that is side-stepping legacy detection-based web security approaches and making its way onto endpoint devices.

Beyond malware, cybercriminals automatically spin up millions of phishing URLs that they quickly take down before they can be identified as malicious – but not before phishing victims have the opportunity to click. If a federal employee clicks on a phishing mail that slips through an email gateway, their web browser will allow any malware on that site onto the endpoint or enable unsuspecting users to enter credentials – regardless of how many security features that web browser may have.

Finally, vulnerabilities in web browser software itself are also being targeted. Recently, Google announced the seventh zero-day vulnerability found in Chrome since the turn of the year and the second in a week. These zero-day exploits allow malware to compromise endpoints via weaknesses that bad actors have discovered in Chrome. Frequently, these vulnerabilities exist in the “wild” for some time until they are discovered by researchers or security analysts. Once discovered, Google engineers a fix and issues a new version or a patch. Unfortunately, organizations remain exposed until they can roll out the patch across their user base, which can take weeks.

Securing Endpoints from Inherently Insecure Browsers

While web browsers themselves unfortunately cannot be completely secure, it is possible to protect endpoints and systems from malicious web content. Historically, some government agencies and enterprises in high-risk fields have done so by strictly limiting employees’ ability to access the web, or entirely ruling it out. Of course, this approach is no longer tenable, since so much work depends on web and cloud apps and general web use.

A more modern and pragmatic approach is Remote Browser Isolation (RBI), an approach mandated for specific sectors by some governments, including Singapore and Israel. With RBI, website content is executed by a virtual browser located in an isolated container in the cloud. Safe rendering data is sent to the user’s regular browser, providing an interactive browsing experience that feels no different than what they are used to. Attachments are opened in the container, examined for malware and if necessary, sanitized before being downloaded to endpoints.

Suspected phishing sites may be opened in read-only mode to prevent credential theft. Likewise, policy-based controls can prevent exfiltration of sensitive data by limiting user activity on cloud storage sites, social media platforms and other specified sites.

Given its unique approach, many organizations have adopted RBI as the means to achieve Zero Trust web browsing.

Conclusion

The NIST document is an excellent first step toward orderly and comprehensive implementation of a Zero Trust security approach for US Government agencies. But it is important to identify the proper measures to secure each solution, regardless of whether they can be built into the product or require external protection such as RBI.

This white paper, “Browsers are the Target: Protect Them with Zero Trust Browser Isolation,” offers useful insights into browser vulnerabilities and how remote browser isolation protects against zero-day threats.