Key Take-aways
- Web browsers are dual-persona: they are both a “super app” for enterprise services and a gateway to external resources you can never fully trust
- Remote Browser Isolation (RBI) and dedicated Enterprise Browsers offer limited security benefits and create “walled gardens” that degrade user experience and compromise productivity.
- Seraphic fills significant gaps left by other approaches by providing unique visibility, ability to enforce policy, and context-sharing capabilities for every browser and a wide range of popular digital workplace apps without negative impacts to performance or user experience.
Introduction
Seraphic Security has been recognized as a Sample Vendor for Enterprise Browsers in the Gartner® Hype Cycle™ for Zero Trust Networking, 2023. According to the same report “Several technologies are on the Slope of Enlightenment, having achieved a state of maturity in terms of enterprise adoption. They include remote browser isolation (RBI), container security, microsegmentation, OpenID Connect and zero trust network access (ZTNA).”1 The report further states that Gartner “expect[s] microsegmentation, container security and RBI to achieve mainstream adoption within the next two years, as many enterprises are already showing interest in, and adopting, these technologies.”2 The inclusion of both Enterprise Browsers and RBI speaks to companies’ need to secure browsers as they continue to manage hybrid workforces, move critical work to the cloud, and develop their Zero Trust strategies. With multiple technologies, both new and existing, that ostensibly address the same problems where do Enterprise Browsers fit in a Zero Trust architecture?
The heart of Zero Trust: authentication and authorization
It bears repeating that what Zero Trust really means is Zero Implicit Trust: no assumptions should be made about the trustworthiness of anything, whether it is a user, an endpoint, an application, or even individual network flows. It follows, then, that access should be denied by default and granted only after strong authentication and—more importantly—contextual authorization (i.e., authorization that includes more than just static attributes such as group membership, device type, or application version). Since the authorization is contextual, it must also be temporary. If the context of an entity changes, its authorization should be re-evaluated and, if necessary, changed or revoked.
There’s a common misconception—with more than a little misleading marketing behind it—that strong user authentication coupled with microsegmentation represents the full extent of Zero Trust. While it is true that both are great starting points and essential elements, they are not the whole story. Zero Trust demands that all the participants in a network session be authenticated and authorized including—and perhaps especially—the app (or user agent). Web browsers are critically important both because they are the de facto user agent for the plurality of enterprise apps and because they can help inform trust decisions about upstream and downstream entities (such as endpoints and network flows, respectively).
NIST SP 800-207 defines several logical components of a Zero Trust Architecture, including the Policy Definition Point (PDP) which is composed of the Policy Engine (PE) and Policy Administrator (PA), Policy Enforcement Points (PEPs), and data sources which—had the naming convention remained consistent—probably should have been called Policy Information Points (PIPs). Browsers are ideal PEPs because of their ability to, in the words of NIST, “enable, monitor, and eventually terminate connections between a subject and an enterprise resource” and because they can be “a single portal component that acts as a gatekeeper for communication paths” to certain types of resources. Like other NIST-defined data sources such as Continuous Diagnostics and Mitigation (CDM) or Security Information and Event Management (SIEM) systems, browsers are also a rich source of contextual information that can be fed back to the PDP to assist its administration of policy on other types of PEPs. To fulfill these roles, it is necessary to trust the browser and that trust must be established through authentication and authorization. However, since browsers are primarily consumer applications that lack integration with enterprise tech stacks, additional capabilities are necessary.
The function of Remote Browser Isolation
One approach to establishing browser trust has been to abandon the idea of trusting it all by using server infrastructure to completely isolate browser execution from the endpoint. Remote Browser Isolation (RBI), therefore, is best thought of as a form of microsegmentation. Although it does not enforce policy in the same sense as conventional network access control lists, it does prevent direct communication between enterprise resources and external resources. The benefit of this approach is that it doesn’t require an organization to make a trust decision about external resources at all: RBI sessions are ephemeral and, in theory, it does not matter if an individual session is compromised since nothing executes directly on an enterprise endpoint and nothing persists between sessions.
In practice, however, there are very significant limitations to the protection RBI offers. RBI does not promise to protect against successful delivery and execution of malware so much as it promises to limit malware’s reach. While it can stop malware from directly impacting an endpoint, it falls short if the target of the attack is something inside the browser session such as authentication tokens, session cookies, or cached data which may be just as—if not more—valuable to attackers than a compromised endpoint. It also offers virtually no protection from techniques like phishing, which remains a leading cause of compromise according to analyses by Comcast Business, Mandiant, and Verizon Business.
There are drawbacks besides lack of adequate protection, as well. As we have described, RBI creates cost and complexity for IT departments due to the amount of infrastructure it requires and it can seriously degrade the user experience due to issues such as network performance and problems with web site/application compatibility.
Lastly, the role of RBI in a Zero Trust architecture is limited unless it is augmented by capabilities from additional infrastructure. Although it meets some of the criteria for PEP, it also depends on secondary technologies like Secure Web Gateways (SWGs) and Cloud Access Security Brokers (CASBs) to ensure comprehensive protection and policy enforcement. RBI also offers very little in terms of context sharing so ultimately—without other tools—RBI only keeps you from trusting an endpoint less, it doesn’t help you trust it more.
Enterprise Browsers: the newest arrival in the Zero Trust landscape
Despite its perceived maturity, the limitations of RBI leave a clear opening for technology alternatives. The Gartner report further states “Enterprise browsers and extensions deliver security services for policy enforcement, visibility, and productivity through a managed web browser or plug-in extensions. Many products in this category provide lightweight features and benefits similar to those found in SWG, CASB, ZTNA, RBI, VDI, and VPN products.”3 It is worth highlighting that this definition encompasses two distinct implementations and there are different implications for each in the context of Zero Trust.
Dedicated enterprise browsers are similar to RBI in the sense that both represent “walled gardens”. The idea is that, by restricting user activity to a single, specific application, both the user and the application are easier to protect and control. But the history of cybersecurity is littered with the failures of this approach precisely because it is difficult to implement and maintain such restrictions. Deploying a dedicated browser creates friction by forcing users to change and giving IT teams another application to manage and maintain. Also, like RBI, they are of limited utility for Zero Trust because they may not be the only “gatekeeper of communication paths” if they are not the only browser on the system and because, by definition, the only context is from within the confines of a single browser meaning that the picture they provide is incomplete.
Extensions, on the other hand, enhance existing commercial browsers with enterprise-grade security and governance capabilities. The primary benefit of extensions is that they do not change the user experience and their capabilities work across every browser, so they can perform policy enforcement and collect context even if there are multiple browsers on the system. This important difference makes this implementation method the superior option in a Zero Trust Architecture.
It should be noted, however, that there is a subtle difference between the Gartner definition of browser extensions and the more widely-used definition which refers to a software module that alters browser behavior through the use of a specific API. Most Enterprise Browser extensions meet the criteria for both definitions. The potential drawback of “pure extensions” is that the capabilities exposed by the API are controlled by browser vendors and their behavior changes—usually growing more restrictive—over time, so there is a real risk that the delivery of specific security capabilities may be curtailed.
Seraphic is unique in that our browser agent is executed directly by the browser engine and supports multiple delivery methods, so it maintains cross-browser compatibility without the constraints of “pure extensions”. Because of this unique approach, its capabilities can also be extended to the desktop clients of digital workplace apps such as Microsoft Teams, Slack, Asana, Notion, and Trello which should also play a role in an organization’s Zero Trust strategy because, just like browsers, they are “gatekeepers for communication paths” and because they are becoming the new targets for old techniques like phishing.
By using Seraphic, you can transform enterprise productivity tools into powerful delivery vehicles for enterprise security and leverage those capabilities to support and improve your Zero Trust strategy. For more information on our capabilities, visit our Use-cases page or schedule a demo.
1 Source: Gartner, Hype Cycle™ for Zero Trust Networking, Andrew Lerner, John Watts, Dan Ayoub, et al., 18 July 2023. Gartner and Hype Cycle are registered trademarks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.
2 Ibid.
3 Ibid.
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
