Ever since sandboxing was implemented in the early 1990s, it has been a staple of defense-in-depth strategies that is still in use two decades later. But today, with the proliferation of browser-borne threats putting organizational endpoints and networks in jeopardy, are sandboxes able to provide the necessary protection? Can sandboxing safeguard our critical infrastructure against browser-executable malicious code?
Hackers are increasingly managing to outsmart sandboxes in order to unleash hordes of malware. Given today’s evasive threats, will sandboxing be considered an adequate form of security for much longer?
A Sandbox’s Tale
More than just child’s play, cybersecurity sandboxes are confined environments on a user device or server where incoming files are executed to assess whether or not they’re safe to use. While software may run indefinitely within sandboxes, they generally serve as a quarantined waystation for files en route to the endpoint or network.
Allowing all file activities to run to ascertain their safety is a time-consuming process and many users who need immediate access cannot wait until the evaluation is complete. In addition, many applications require access to processes, such as printing, that are outside of the sandbox.
When users grant permission to test those processes, as they usually do, the lid slides off the box – and malware can spread.
The upshot is that sandboxes’ “unsafe until proven safe” methodology had already begun to crumble like a sandcastle in a torrential downpour – and that was before hackers took aim.
Hackers Going Deep into Their Playbook
To overcome these limitations, cybersecurity innovators have amplified the sandboxing concept by leveraging analytics and artificial intelligence and integrating them with traditional sandbox solutions. This enables sandboxes to accelerate the detection process and reduce the human error factor when it comes to granting access permission and releasing files.
However there are skilled hackers who are very attentive to these developments, and have been hard at work creating sophisticated strains of malware that slyly detect the sandbox environment and hold their fire while within, only to activate malicious activity once released. Malware files remain undetected in a dormant stage for as long as they remain in the sandbox.
Once the benign-seeming files are deemed safe and released from the sandbox to the end-user device, the malware awakens, attacking vulnerable endpoint networks and systems.
Sandboxes will continue to be improved to detect files that are malicious. Hackers will likewise continue to work to perfect their game plan to outsmart sandboxes so they can successfully make their way to your network infrastructure.
Browser-Borne Threats Must Be Contained
While sandboxes remain an important, if not flawless, layer of defense against files and software, malicious agents are lazering in on browser-borne threats that sandboxes simply can’t touch.
Today’s browsers instantly execute millions of lines of website code as sites are rendered. Browser executable code brings outside activity directly from the internet to the endpoint, without first downloading files. This is what makes browsers so valuable and so powerful, and so seriously dangerous.
Browser-executable code starts running as soon as a user begins browsing a website, and continues to run as long as the website is open in a browser or tab. Because browser-executable code is never actually downloaded, these minute apps cannot be first placed in a sandbox to be observed.
Instead, they introduce malware and fileless exploit kits that can rapidly disperse from endpoint to server, and throughout the organizational network.
It’s Time to Get Proactive – Contain Browser-Borne Threats
How can organizations secure their endpoints and networks from browser-executable malware and the browsers that run it blindly?
The answer is simple: containers that are deployed for the sole purpose of isolating browsing away from the endpoints.
Containers may function similarly to sandboxes, but when used for remote browsing, they have a critical twist. While sandboxes serve as quarantined waystations for files en route to the endpoint or network, containers for remote browsing serve as a proverbial “dead end” for applications.
Executable code cannot be successfully sandboxed, but it can be contained, along with the browser that runs it. Remote Browser Isolation (RBI) creates virtual browsers within containers that are far from the endpoint, where browser-executable code runs. Each browser tab is executed in its own unique, single-use container.
Once a browsing session is inactive or exited, that container is destroyed along with the virtual browser and all content inside of it, including malware and illicit coin miners.
Like the sandboxing approach, containers may be built on endpoints or organizational networks. However, truly secure solutions, position virtual browsers remotely, in containers located in the cloud or network DMZ, so active code cannot inadvertently escape onto the endpoint or organizational network.
If sandboxing is the pioneer of the isolation technique, then virtual containers are an upgraded, much more polished, and fail-safe version. Utilizing the same core principles that made sandboxing effective for as long as it did – quarantining files that may contain malware threats – virtual containers have gone far beyond.
By applying this approach to applications in addition to files, full browser isolation and container destruction can be leveraged to safeguard organizational systems against all variations of browser-borne threats.