The Relevance of RBI
Remote browser isolation (RBI) has slowly moved from the shadows of information security products as something with potential, to a member of product stacks for Zero Trust and Secure Access Service Edge (SASE) in some of the largest companies in the space since its first enterprise adoption in the late 2000’s.
RThe early days of RBI were plagued by poor user experience because of technologies that were not resource-efficient. RBI has come a long way in just a few years with the capability to support thousands of concurrent people. RBI moves the execution of web page code from the browser installed on the local machine to a server in a data center that is physically located outside of your local network. Malicious code, like what is found in malvertising, does not make it to the local machine because it stays in the server, then the malicious code is destroyed when you log out of your browser isolation session.
Attackers have a few options when they use malvertising.
After reading the malvertising strategies, you might have asked yourself how RBI keeps malicious code that is downloaded through a file from infecting the local machine. The answer is that RBI employs many of the same mitigating techniques that you find on an endpoint. Web filtering blocks known bad pages, file download blocking prevents its namesake, DNS filtering prevents people from visiting known bad domains, and virus scanning for downloaded files. RBI prevents browser lock because the only action that can open a new tab or window is the person logged into the browser isolation session.
Exploit kits give attackers the capability to choose which web page visitors they want to engage based on a system profile. RBI makes you a less attractive target because attackers are unable to enumerate installed applications and browser extensions, the operating system isn’t a typical target, and the browser fingerprint is unique. Browser fingerprinting includes characteristics like screen resolution or the number of pixels used to display the web page, browser publisher, browser version, and machine characteristics like how pixels are rendered based on graphics hardware and the driver, processor cores, system memory, and installed fonts.
Any information security program worth its salt is going to have Transport Layer Security (TLS) inspection at the edge, and possibly at the endpoint depending on the endpoint protection vendor. TLS inspection increases CPU load significantly on edge devices like unified threat management and secure web gateways because decryption, threat scanning, then encryption to send the data to the client takes time and resources. TLS inspection also increases administrative overhead because not all web servers play nice with edge devices getting between it and the client to scan payloads. Broken connections result in broken web pages, and broken web pages require exceptions. Scanning exceptions mean that payloads are not scanned, and extra work for administrators to create regular expressions, sources that will use the exception, testing, and several other things that might need adjustment or configuration.
RBI reduces the volume of data that edge devices scan because only code that styles and maintains the interactive portions of the web page are sent to the client, not the entire web page. The average size of a web page is just over two megabytes. RBI reduces the data transmitted to under one megabyte in most cases. Administrative overhead from creating scanning exceptions is reduced because you’re scanning content from the RBI vendor, a single source, and the RBI vendor infrastructure *should* be compatible with the customer’s TLS inspection.
RBI is not a silver bullet. You should have serialized controls in the case that a control fails, you have secondary controls for prevention or containment. Endpoint Detection and Response with continuous monitoring and employee education are still needed. Keeping web page, browser, and web app threats off of the endpoint reduces the probability that a threat will materialize through the browser.
If you would like a fact finding conversation click here to schedule a video or phone call with us.