Sandboxing could be used to allow risky code and applications to be run without impacting other parts of the underlying host.

Control Type: Technical

Control Function: Preventive

Some organizations find themselves needing to review, test, and utilize high risk software and code in various aspects of work. For example, an organization may need to run a legacy, vulnerable Java application as part of a service. Or an organization’s IT team may want to review forensic malware artefacts regarding a recent incident. In such cases, organizations need to employ methods to isolate the risky software from production environments. Concepts such as VLANs and DMZs already address this on a network level, but what about at the OS level? How do organizations run high risk software on a machine without it impacting the rest of the underlying OS?

Sandboxing is one of the most common ways to handle this. Sandboxing has two forms:

  1. Physical Sandboxing: a physically isolated network segment completely closed off from any contact with the production network. Cables, networking devices, and endpoints are all isolated from any contact with other network segments. This is basically the same thing as an “airgapped” network.
  2. Logical Sandboxing: this is the more applicable setup for this documentation. Logical sandboxing involves setting aside isolated memory spaces for code to run in isolation from the rest of the system. This prevents malicious code from spilling over into other processes.

Logical sandboxing is generally used in the context of running/testing individual pieces of code. The term Application Virtualization is used for running entire programs in isolated spaces. Generally, you can refer to each of these techniques as “sandboxes” since they are aiming for the same goal: running risky software in isolated spaces.

There are many different programs that accomplish various sandboxing needs. Linux offers WINE, which is an application virtualization program that allows Windows native programs to be run on Linux. WINE creates a fake Windows kernel that allows the applications to call the necessary functions and processes as they would on a normal Windows system. Meanwhile, the program does not understand that it is being virtualized on a Linux host. WINE is useful for organizations that want to test old, potentially unstable Windows programs. It can also be used for more than just sandboxing. Organizations that run Linux systems and need to implement a Windows program for daily operations could implement WINE to accomplish this.

Sandboxie is a program that can sandbox a system’s web browser and other programs, indicated by a classic yellow square outlining the program window. Sandboxie uses the classic logical sandboxing approach: when websites and programs running in the Sandboxie session try to make changes to the system, Sandboxie seizes those requests and redirects them to an isolated sandbox folder rather than the actual system resources. If risky behavior is in fact detected in the Sandboxie session, the end user can simply delete the sandbox when finished with the session. Sandboxie could be a recommended sandboxing solution for organizations that frequently access uncharted territories on the web for tasks such as OSINT and criminal or journalistic investigations.

More advanced sandboxing/application virtualization platforms also exist for traditional business use. Microsoft App-V allows organizations to run traditional everyday Windows applications in a virtual environment, giving a layer of host security to Windows systems without changing the overall user experience. Citrix XenApp allows organizations to host Windows apps on centralized cloud virtual desktops for client access. This is useful for organizations that want to restrict use of specific applications to one hosted location, preventing any of the application operations from spilling into individual endpoints.

Sandboxes also exist for organizations and individuals that want to analyze a potentially malicious program’s activity in real time. The attractive part of these malware sandboxing services is that they are used in the form of interactive online platforms that provide an OS experience to end users. There is no need for dedicated, on-site sandboxing capabilities, everything is provided to users via the web, and all they have to do is provide the application files of the program they want to analyze. Popular examples of this solution include ANY.RUN and Joe Sandbox.

It is easy to see how sandboxing is a variable term that can be used in a variety of situations. There is no dedicated single purpose for using a sandbox. Regardless of whether it’s used for software testing, malware analysis, or making legacy apps compatible, the underlying approach remains the same: isolating a program to a dedicated, virtualized memory space  to allow it to run in isolation from other programs and services on the same host.