The Benefits and Pitfalls of Using Sandboxing Techniques in SSL VPN, Part 1

Posted: August 7, 2012 in Industry Commentary, Mobile, SSL
Tags: , , , ,

By Dr. Matthias St. Pierre, Senior Developer at NCP engineering

When connecting to your company network with an SSL VPN, you are using your standard web browser to access an SSL-secured website, which the company provides.  After logging in, typically, a graphical user interface appears in the browser that gives you limited access to company resources, like your business e-mails or other confidential documents.

Because modern browsers and applications cache all downloaded data for performance and convenience purposes, most of the sensitive information that you access via an SSL VPN is written on the computer’s file system where others could potentially access it. This happens — not when you explicitly press ‘Download’ or ‘Save as’ — but also, implicitly whenever you follow a link or view file contents.  Even if you clear the browser cache when terminating the session, the deleted files can easily be recovered using standard tools. This can be problematic if the computer you are using is not owned by your company and not subject to minimal endpoint policies.

This is where sandboxing comes in. At NCP, one of our main goals when it comes to sandboxing is to protect confidential data by ensuring that all write operations to the file system are transparently redirected to a secure location, where the file contents are secured on-the-fly using AES encryption.  A thin client program, which is downloaded at the beginning of the SSL VPN session and acts as a guardian process, helps to achieve this. The thin client injects a DLL into a newly created browser instance and all of its descendant processes, in order to monitor and modify the Windows file system API calls. All further browsing occurs in the sandboxed browser. Moreover, the thin client starts the new browser instance on a different Windows™ desktop, in order to isolate the sandboxed processes from the other processes running on the original Windows desktop.

This way, write access to files can either be prohibited or virtualized by transparently redirecting it to a shadow folder, depending on the location of the file and the policies given by the administrator. Registry access is sandboxed in a similar fashion. It’s important to note, the thin client program requires no installation and no administrative rights in order to operate.

Learn more about the side effects of taking this approach in part two.

Comments
  1. […] The Benefits and Pitfalls of Using Sandboxing Techniques in SSL VPN, Part 1 […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s