As webapps and other powerful websites become more fundamental to corporate and personal productivity, they need access to increasing amounts of data and privileges in both systems and endpoints. This poses a fundamental challenge in applying the principle of least privilege in zero trust network architecture (ZTNA) as required by ZTNA’s application and workloads pillar because, to put it simply, the web browser itself shouldn’t be treated as a homogenous application.

Browsers’ growing role as part of the workflow for business processes – including sharing and storing sensitive data, such as financial documentation or employee PII – puts them in constant interaction with other websites and applications. Applying the principle of least privilege on the browser would break these critical workflows and tank employee productivity, but today’s browsers provide no easy method to distinguish which websites and webapps require privileges. However, failing to secure the browser attack surface using zero trust principles opens businesses to multiple sources of risk. These include both common vulnerabilities and zero-days associated with the browser or the applications it interfaces with, as well as risks of data modification or exfiltration by malicious or negligent insiders.

The browser attack surface: Insecure by design?

Think about it this way: In an average day, a working professional may use the same web browser to access corporate data in Salesforce, Google Docs or Office365; to do research on news sites and business intelligence platforms; to check personal email on Yahoo or Gmail; to make dinner reservations on Resy or OpenTable; to check traffic and after school schedules on local news and school sites; and finally, to unwind with Netflix at the end of the day.

By default, in the current version of Chrome, all these sites will have access to run JavaScript, display images, run payment handlers, and access third-party SSO login mechanisms. Without these default privileges, most modern websites will simply break, or at the very least provide a poor user experience. The web browser imperative isn’t a security-first principle of least privilege; it’s a convenience-first least common denominator.

This “least common denominator” approach leaves a gaping hole in application-level zero trust. For business-critical applications like Salesforce to run alongside essential personal web traffic, administrators have to allow browsers to run dozens of open source components alongside Chromium’s own open source code and provide access to most of those open source components to any website whose code calls for them. Unless an organization aggressively blocks all websites whose DevSecOps practices haven’t been explicitly evaluated – an action that would be deleterious to both workplace productivity and workforce morale – this stands in direct violation of the Cybersecurity and Infrastructure Security Agency’s ZTNA Maturity Model’s Application and Workloads pillar’s Application Access and Application Security Testing aspirations, both of which call for dynamic monitoring, authorization and testing of deployed applications.

Fatal flaws in the solution space

To their credit, Google and other browser developers have recognized the fundamental differences amongst classes of websites and introduced more granular privacy and security controls to allow users and administrators to grant different levels of privilege to different websites. Enterprise browsers have gone a step further and implemented data loss prevention (DLP) and other features that protect sensitive corporate data from being dumped from one website – like a corporate Salesforce instance – to another, like a departing employee’s personal Gmail account. But while both developments are welcome indicators of a growing awareness of browser insecurity, neither provides a sufficient solution to the problem.

While the idea of altering Chrome’s enterprise defaults to remove attack vectors from websites that aren’t explicitly trusted may sound easy, it’s an incomplete solution that also creates an insurmountable hurdle for business operations. From a pure security standpoint, it’s nearly impossible to know which vectors will be targeted in the next attack so that website permissions can be restricted accordingly. For example, to have avoided 2023’s libwebp vulnerability, administrators would have had to disable images by default in the user’s browser for all but explicitly trusted sites – highlighting the business hurdle in doing so as well, since blocking images on most modern websites would render them nearly unusable. And the libwebp example isn’t an anomaly in its implications for usability: the first Chrome zero-day of 2024 was against the browser’s JavaScript engine. JavaScript is used in upwards of 95% of websites today, meaning that a disable by default policy toward JavaScript would be as deleterious to productivity as blocking the vast majority of websites from the organization!

Enterprise browsers, one of the latest additions to the security stack, provide a partial solution to the ZTNA problem posed by consumer browsers. Instead of focusing on defusing vulnerabilities from public-facing Internet sites, they aim to curb insider threats and risks to trusted sites like Salesforce and Office 365 by creating a hardened environment in which they can operate. By implementing controls around functions such as copying and pasting and by using AI-enabled DLP algorithms trained to detect malicious or negligent activity on users’ parts, enterprise browsers can effectively buy down the direct attack surface around trusted apps. But the larger problem remains: Because enterprise browsers focus so much effort on trusted websites, they provide little protection against zero-days from the 99% of public websites that companies don’t have the time to evaluate. A sophisticated, dedicated actor such as a nation-state or advanced cyber criminal could easily leverage this lack of attention or prioritization to gain system privileges on the endpoint, then conduct surveillance, pivot into trusted apps, or gain access to additional organizational systems using the endpoint.

Zero code, zero trust

It’s clear that ZTNA is imperative to prevent and mitigate business risks from cyber compromise and that allowing access to a slice of the public internet whose DevSecOps practices cannot be continually monitored is imperative to the health and productivity of the business. Thus, a paradox remains: The information on the public internet writ large must be available to the organization, but the code on those websites cannot be processed on the organization’s business systems.

While the idea of accessing information without processing the underlying code on business-connected systems seems contradictory, it’s been implemented in security-conscious sectors such as government, threat research and critical infrastructure for many years. From “old school” options like airgaps to newer technologies such as diodes, cross-domain access devices and browser isolation technologies, many solutions to this problem exist. Getting zero trust right requires that we bring them to bear in mainstream network architecture.

Adam Maruyama is a cybersecurity and national security professional and the field chief technology officer for Garrison Technology. He served more than 15 years in the Intelligence Community supporting cyber and counterterrorism operations, including numerous warzone tours and co-leading the drafting of the 2018 National Strategy for Counterterrorism.

Celina Stewart is the Head of Cyber Risk Management at Neuvik, a cybersecurity services company, where she specializes in designing and optimizing cybersecurity programs, with a risk-based approach to program strategy and technical controls.

Rob Clyde has decades of executive and cybersecurity experience and is credited with developing the first commercial intrusion detection system. He recently served as an ISACA Global board director and is on the board of directors of several cybersecurity companies.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.