Remote Browser Isolation; Complementing the SDP Story
Our digital environment has been transformed significantly. Unlike earlier times, we now have a bunch of different devices, access methods and types of users accessing applications from a variety of locations. This makes it more difficult to know which communications can be trusted.
The perimeter-based approach to security can no longer be limited to just the physical location of the enterprise. In this modern world, the perimeter is becoming increasingly difficult to enforce as organizations adopt mobile and cloud technologies.
Under these circumstances, the perimeter is more likely to be breached; it’s just a matter of time. A bad actor would then be relatively free to move laterally, potentially accessing the privileged intranet and corporate data, both on-premises and in the cloud. Therefore, we must operate under the assumption that users and resources on internal networks are as untrustworthy as those on the public internet, and design enterprise application security with this in mind.
What within the perimeter leads us to assume that it can no longer be trusted?
Security becomes less and less tenable once there are many categories of users, device types and locations. The very fact that users are diverse means that it is not possible, for example, to slot all vendors into one user segment with uniform permissions. As a result, access to applications should be based on contextual parameters such as who and where the user is. And sessions should be continuously assessed to ensure they’re legit.
We need to find ways to decouple security from the physical network and more importantly, to decouple application access from the network. In short, we need a new approach to providing access to applications that is cloud, network, and device agnostic. This is where Software Defined Perimeter (SDP) comes into the picture.
What is Software-Defined Perimeter (SDP)?
SDP complements zero trust, which considers both internal and external networks and actors to be completely untrusted. The network topology is divorced from trust. There simply is no concept of inside or outside of the network. This may result in users not automatically being granted broad access to resources, simply by virtue of their being inside the perimeter.
Primarily, security pros must focus on solutions where they can set and enforce discrete access policies and protections for those requesting to use an application. SDP lays the foundation and secures the access architecture, which enables an authenticated and trusted connection between the entity and the application.
Unlike security based solely on IP, SDP does not grant access to network resources based on a user’s location. Access policies are rather based on device, location, state, and associated user information, along with other contextual elements. The applications are considered in the abstract, so whether they run on-premise or in the cloud is irrelevant to the security policy.
Periodic Security Checking
Clients and their interactions are periodically checked to make sure they are complying with the security policy. Periodic security checking protects against any additional actions or requests that are not allowed while the connection is open.
Let’s say, you have a connection open to a financial application and users are accessing the recording software to record the session. In this case, the SDP management platform can check if the software has been started or not. If so, it employs protective mechanisms to ensure smooth and secure operation.
Front end authentication and periodic checking is one part of the picture. However, we not only need to go a layer deeper to secure the front door to the application but also must secure the numerous doors within, which can potentially create additional access paths. Primarily, this is the job of microsegmentation.
It’s not sufficient just to provide network access. We must enable granular application access for dynamic segments of 1. In this scenario, a microsegment is created for every request that comes in. Microsegmentation creates the minimal accessible network required to get specific tasks done smoothly and securely. This is accomplished by subdividing larger networks into small secure and flexible micro-perimeters.
Introducing Remote Browser Isolation (RBI)
SDP provides mechanisms to prevent the possibility of lateral movement once users are inside the network. However, we also need to address how external resources located on the internet and public clouds can be accessed while protecting end-users, their devices and the networks to which they connect. This is where remote browser isolation (RBI) comes into the picture.
Initially, we started with browser isolation, which protects the user from external sessions by isolating the interaction. Essentially, it generates complete browsers within a virtual machine on the endpoint, providing a proactive approach to isolate user’s sessions from, for example, malicious websites, emails, and links. But these solutions do not reliably isolate the web content from the end-user’s device, which is of course, on the network.
Remote browser isolation takes local browser isolation to the next level by enabling the rendering process to take place remote from the user’s device, in the cloud. Because only a clean data stream touches the endpoint, users can securely access untrusted websites from within the perimeter of the protected area.
SDP along with RBI
In many important ways, remote browser isolation complements the SDP approach. When you access a corporate asset, you operate within the SDP. But when you need to access external assets, RBI is needed to keep you safe.
Zero trust and SDP are about authentication, authorization, and accounting (AAA) for internal resources, but there must be secure ways to get to external resources as well. For this, RBI secures browsing elsewhere on your behalf.
No SDP solution can be complete without including rules to secure external connectivity. RBI takes the essence of zero trust to the next level by securing the internet browsing perspective. If access is to an internal corporate asset we create a dynamic tunnel of one individualized for the connection. For external access, RBI allows information to be transferred without full, risky connectivity.
This is particularly crucial when it comes to email attacks, like phishing. Malicious actors use social engineering tactics to convince recipients to trust them enough to click on embedded links. Quality RBI solutions protect users by “knowing” when to allow user access while preventing malware from entering endpoints; entirely block malicious sites; or protect users from entering confidential credentials by enabling read-only access.
The RBI Components
To understand just how RBI works, let’s look under the hood of Ericom Shield. With RBI, for every tab that a user opens on his or her device, the solutions spins up a virtual browser in its own dedicated Linux container in a remote cloud location. For example, if the user is actively browsing 19 open tabs on his Chrome browser, each will have a corresponding browser in its own remote container. This sounds like it takes a lot of computing power but enterprise-class RBI solutions do a lot of optimizations to ensure that it is not eating up too much of the endpoint resources.
If a tab is unused for a period of time, the associated container is automatically terminated and destroyed. This frees up computing resources and also eliminates the possibility of persistence. As a result, whatever malware may have resided on the external site being browsed is destroyed, and cannot accidentally infect the endpoint, server or cloud location.
When the user shifts back to the tab, he is reconnected in a fraction of a second to the same location but with a fresh container, creating a secure enclave for internet browsing.
Website rendering is carried out in real-time from the remote browser. The web page is translated into a media stream, which then gets streamed back to the end-user via HTML5 protocol. In reality, the browsing experience is made out of images. When you look at the source code on the endpoint browser, you will find that the HTML code consists solely of a block of Ericom-generated code. This block manages sending and receiving of images via the media stream.
Regardless of whether the user is accessing the Wall Street Journal or YouTube, they are always going to get the same source code from Ericom Shield. This is ample proof that no local download, drive-by download, or any other contact that may try to hook up into your endpoint is ever going to get there, as it does not come into contact with the endpoint. It runs only remotely, in a container located outside of the local LAN.
The browser farm does all the heavy — and dangerous — lifting via container-bound browsers that read and execute the uniform resource locator (URL) requests coming from the user.
SDP vendors have figured out device user authentication and how to continuously secure sessions. However, vendors are now looking for a way to secure the tunnel through to external resource access.
If you use your desktop to access a cloud application, the session can be hacked or compromised. But with RBI, you can maintain one-to-one secure tunneling. With a dedicated container for each specific app, you are ensured of an end-to-end zero-trust environment.
RBI based on hardened containers, and with a rigorous process to eliminate malware through limited persistence, forms a critical component of the SDP story. The power of RBI is that it stops both known and unknown threats, making it a natural evolution from the zero trust perspective.