Rethinking Remote Browser Isolation (RBI)

While most enterprises perform continuous efforts focused on educating users to minimize risky behaviors, not even the best education can prevent all of today’s sophisticated threats. 

By their very nature, web browsers are built to run third-party code directly on the endpoint. The majority of these application engagements come without verification, creating fertile ground for attackers. 

Remote browser isolation is a method for protecting users against such attacks by augmenting existing proxy resources. 

What is Remote Browser Isolation?

Remote Browser Isolation (RBI) is a cybersecurity technology that isolates web browsing activity from the endpoint device to significantly reduce the attack surface for rogue links and files. It aims to physically isolate an internet user's browsing activity (and the associated cyber risks) away from their local networks and infrastructure.

The concept behind RBI is to force uncategorized or untrusted web traffic into a virtualized cloud environment for remote execution. As the user engages web content in this way, the site is rendered over a video stream (often HTML5) back to the user’s consumer browser. In principle, the user is protected from any harmful content.

How does Remote Browser Isolation work?

Protecting web usage typically starts with web gateway (proxy) infrastructure for many organizations. While these were practical approaches in years past, the growth of encrypted traffic (SSL) and sophisticated threats such as browser code injection leave existing proxies and SASE solutions unable to protect end-users adequately. These attacks and defenses leave the user’s consumer browser (which cannot defend itself from such techniques) subject to exploitation. 

RBI renders and executes web content in a remote, isolated environment rather than directly on the user's device. 

Typical isolated environments include cloud servers or virtual machines. This prevents malicious code from interacting with the user's device or local network.

The process in a nutshell:

1. User clicks on a link or opens a web page.
2. The link or web page is sent to a remote server.
3. The remote server renders and executes the web content.
4. The remote server sends a pixel-based stream of the webpage to the user's device.
5. The user sees the webpage and interacts with it as if it were running on their device.

Why do enterprises use Remote Browser Isolation?

Phishing, malware, ransomware, and many other threats often begin with a web-based engagement.  Since the consumer browser is an unwilling participant in these engagements,  enterprises need to layer control after control around these web browsers to insulate them from danger. 

RBI significantly reduces the risk of malware infections and data breaches by preventing malicious code from executing directly on the user's device. Additionally, it can protect against zero-day attacks while reducing IT burden and improving productivity.

However, the tactic comes with unique drawbacks.

The downside of remote browsers

On the surface, a remote vehicle to execute potentially dangerous web content for the user seems like a viable protection strategy. However, this approach is fraught with its own set of challenges. 

The UX is not great

To begin with, it is not palatable to force all users’ traffic through RBI. Why? Because the user experience and performance simply are not acceptable for everyday use. Rendering the content remotely and streaming it back to the user adds noticeable lag and visual imperfections. 

The scope of defense is limited

Because the experience is generally poor, RBI technologies are usually invoked only in specific situations. 

For example: RBI is often used where content must be isolated for potentially malicious web content on untrusted sites. This means that only a tiny subset of traffic (usually 1-2%) is passed through RBI technologies in the first place. By reducing the scope of where RBI is engaged, the organization can attempt to minimize the concern over end-user friction. 

The attack surface is surprisingly large

Of course, this leaves a significant gap for sites categorized as collaboration, file sharing, social media, and others. In these cases, the web traffic is never passed through an RBI solution, yet risky content still exists. Further, Single Page Applications (SPA) and HTML5 canvas rendering are meant to be executed locally and would not be candidates for passing through RBI solutions. Put simply; the attack surface is much larger than the exploitation footprint protected by RBI. These limitations call into question the value of the investment. 

Rethinking Remote Browser Isolation outcomes

The proliferation of threats leveraging the web has piqued interest in RBI technologies. However, RBI provides limited solutions solving only the symptoms like browser exploits and remote code injection. 

This pattern is all too frequent in cybersecurity, where vendors build solutions to address a handful of symptoms without addressing the core problem. The core problem: consumer browsers were never developed to accommodate the needs of the enterprise.  

Remote browsers still struggle with common browser-based attacks

RBI technologies are also quite limited where other types of common browser-related attack techniques might be employed, such as: 

• Sophisticated Phishing Attacks 
• Exfiltration Of Data 
• Man-in-the-Middle Attacks 
• Malicious Extension Exploitation 
• Embedded Malicious Document Content 
• Localized Browser Tampering
• Man-in-the-Browser Attacks 

In each of these cases above, RBI either has no role in protecting against the attack or cannot offer full protection because it’s only used for a fraction of the web traffic.

Use case limitations for Remote Browser Isolation

As previously mentioned, RBI is most often invoked for web traffic destined for suspicious sites that might cause remote browser code injection or attempts to phish users leveraging fake sites. However, this limited usage of RBI means that it cannot fulfill more valuable browser-based use cases that may be important to the organization, such as:

• SaaS and Internal Web Application Protection 
• Contractor and Third-Party Provisioning/Protection 
• Call-Center Worker Governance 
• Bring-Your-Own-Device Policies 
• Privileged User Protection

A web browsing experience is often central to the needs of such use cases. Yet it is essential to note that RBI offers little for these scenarios. To begin with, the necessary traffic for these needs usually isn’t routed to RBI. Further, RBI just isn’t built to solve these challenges and lacks the mechanics required to add value to these core browsing use-cases.

Self-protecting enterprise browsers: the RBI alternative

What if the browser was built for the enterprise? This is precisely what Island considered as we created the industry’s first enterprise browser. 

As the inventor of Remote Browser Isolation, Island co-founder and CTO Dan Amiga has extensive experience with browser technologies and a deep understanding of the pitfalls. From the beginning, Island put significant expertise and effort into delivering the advantages of browser isolation without the need for the “remote” part.

Enterprise browser capabilities deliver far more effective outcomes than clunky RBI solutions while doing so in a native browsing experience. This ensures that users have complete protection without the negative impacts on their experience. 

How an enterprise browser works

Island will detect potentially malicious javascript from untrusted web destinations and dynamically block execution across over a dozen APIs and modules, including WebRTC, WebGL, and others. Island also leverages several additional protective capabilities by enabling Arbitrary Code Guard, Control Flow Enforcement, and Control Flow Guard. Each of these capabilities ensures that arbitrary code cannot be injected directly in an attempt to manipulate the memory or execution flow of the Enterprise Browser.

By delivering Browser Isolation directly into the Enterprise Browser, Island removed the most significant areas of browser vulnerability and added capabilities to protect against exploits. As previously mentioned, this solves the core problem of advanced web threats rather than the symptoms. These alone negate the need for Remote Browser Isolation solutions by preventing malicious code execution directly within the browser.