- May 11, 2012
- Lee Cocking
Buckle up for a bit of a long post here, but I feel it’s important that everyone understands the subtleties of mobile sandboxing, also known as containerization.
Once you get past the standard MDM (Mobile Device Management) discussions, talk often turns to sandboxing or containerization as a method to securely embrace BYOD (Bring Your Own Device, also known as Employee Owned Devices). There’s a lot of confusion in the market over sandboxing technologies and I wanted to provide an overview of the various technologies, clear some of the misconceptions, and discuss which ones you should be concerned about.
Let’s start with the basic premise. A sandbox (or container) in it’s strictest sense is a security mechanism for separating running programs (thanks Wikipedia), essentially isolating code and the impact that code can have in a runtime environment like a mobile device. Under the covers, sandboxing technologies typically provide an abstraction layer so one application can’t step on another applications toes, or generally corrupt the operating system. Think of it like a hotel, where each person has their own room and set of amenities, rather than sharing with every guest staying there.
So at this point, you may have a couple questions, like “don’t some devices have sandboxing built in?”, or “why should I care?”. All good questions. First, you’re right, some devices like the Apple iPhone have inherent sandboxing of each application, though it can be relatively easy to jailbreak an iOS devices and start doing pretty much whatever you want from a programmatic standpoint. This leads to the why you should care part, and you should care if you’ve got corporate applications or corporate data (like emails or documents) being stored on newer consumer devices including Apple or Android platforms, particularly if those devices are employee owned.
We need to step up the sandboxing security to another level. It needs to be more than just simple application abstraction and should also include increased encryption for data-at-rest and data-in-transit, with enhanced policy control that goes above and beyond the standard application level control (which is usually nothing).
This is probably a good time to talk about the myriad of sandboxing techniques that are currently at various levels of maturity in the industry. I’m going to lump these technologies into three main categories; Type 1, Type 2 and Type 3 (I’m taking a bit of liberty here, there really is no type 3, but I’ll explain).
Type 1 sandboxing is often referred to as “bare metal” sandboxing, and provides a hypervisor that typically lives at the firmware level. Above this firmware-based hypervisor rests one or more virtualized operating systems that are completely sandboxed from each other. Type 1 is usually considered the most secure approach to sandboxing, however requires significant work by device manufacturers, and the technology has not really made it into consumer smartphones and tablets.
Type 2 sandboxing is one step above Type 1, and can be equated to the typical VMWare style of virtualization, which runs on top of an existing operating system such as Microsoft Windows. This type of sandboxing requires less work from device manufacturer, usually requiring some tweaks to the operating system load out and no modification at the firmware level. The downside here is more resources are burned up by the “host” operating system, which runs one or more virtual operating systems on top of it. Again, there hasn’t been much traction for Type 2 in smartphones or tablet devices.
Lastly, we’ve got Type 3 sandboxing. This is my own term, and I use it to describe application level sandboxing. This is where a standard application, which uses the native OS environment and API’s, is used to provide a sandboxed environment for data or applications and introduces additional security mechanisms like encryption and advanced policy control.
This type of sandboxing is currently very important for the mobile industry since there are no standards with Type 1 and Type 2 sandboxing. If an organization needs to support BYOD devices, including any iOS or Android devices available on the market, Type 3 is the best way to provide sandboxing. Over time this will change, but it will take some time for any Type 1 or Type 2 standards to materialize and pervade the mobile ecosystem.
Type 3 sandboxing is confusing in it’s own right, as the market is seeing various solutions which are all similar, but provide solutions to different problems. Type 3 sandboxing can typically be broken down into the following categories:
1. Application wrappers
2. Content wrappers
3. Work space wrappers
Let’s review each of these techniques:
1. Application wrappers take the approach of providing an additional security layer, usually in the form of an SDK, that developers can integrate into their application and not have to worry about implementing their own data-at-rest / data-in-transit encryption. Typically this technology provides additional policy control mechanisms which allow wrapped applications to be individually wiped out without touching the rest of the mobile device.
2. Content wrappers are sandboxes usually focused on providing a secure container for enterprise documents. Many flavors of content wrappers are popping up on the market and are often directly aimed at stemming the document-sharing problem that organizations are facing right now. Many consumer services exist to share content between all of your devices, and employees use these to be more productive, but organizations have no control over distributed documents, which presents increased risk of a data breach if mobile devices are lost or compromised.
3. Work space wrappers are aimed at providing a full work space environment for enterprises, including email, calendar, PIM, secure browsing, document editing, PDF annotation and more. The best work space sandboxes are now allowing organizations to embed their own home grown and enterprise applications inside the sandbox, ensuring that there is one common entry point to access any enterprise application or data.
All three of these approaches are good ways to minimize the risk of embracing BYOD in your organization.
Fixmo’s approach to sandboxing rests firmly in Type 3, and covers all three sub-types. We provide a secure application wrapper (SafeGuard SDK) as well as a full work space (SafeZone) in which additional enterprise applications, such as secure document stores, can be embedded in the sandbox. The up side here is you have one single area on a mobile devices for all enterprise applications and data, with a unified set of authentication and policy controls for access. In addition, Fixmo also leverages its Device Integrity capabilities, based on NSA technology, to determine if devices are compromised before allowing employees into the secure work space.
I hope you’ve got a better mental model now for the various sandboxing techniques available. If your organization is embracing BYOD, or you require additional security on consumer-grade devices, please include sandboxing requirements when looking at your mobile security and mobile risk management needs.