Sandboxing refers to the isolation of applications within an encrypted silo independent of the operating system. The sandboxed applications are either available by vendors or the MDM vendors provide SDKs or URLs to upload and wrap the applications. The wrapping process enables the app to only communicate to other wrapped applications, push configurations, encrypt the app and its communications and push MDM policies to restrict in-app behaviour.
It is only with the advent of corporate information residing on mobile devices that the need for sandboxing arose. This is because data using native apps and mail clients can potentially be exposed. The three main vectors are:
Data Leakage: A Q1 2016 Report by AppThority found that 48.2% of applications on iOS and 86.7% of applications on Android leak data.
Malware: Both iOS and Android have suffered their fair share of exploited vulnerabilities and malware. Not having a MDM to provide device management means that corporate data on the device is at risk.
Shadow IT: If IT don’t provide the tools to do business then users may default to using applications that synchronise corporate data. Once this has happened the data is outside the remit of IT’s control. This is called Shadow IT.
All the above threats mean that valuable corporate data can leak outside the control of IT. In addition, mobile devices do not provide an audit trail for potentially where the data has leaked. Sandboxed applications are designed to mitigate these threats. Although, it must be said that Android Enterprise (formally known as Android for Work) and iOS have matured and provided built-in, out-of-the-box separation of private and corporate data.
Third Party Sandbox Use Cases
In a BYOD environment whereby IT can’t restrict the functionality of the device then sandboxing can make sense. This means that IT only need to concern themselves with the in-app security. In contrast, if a device is company-owned and be restricted sufficiently then the native client would be a better option.
For additional security, as sandboxes often require an additional passcode in order to gain access to the corporate apps within over and above the device passcode, a sandbox can be used to further segregate data from the main OS and enable a second level of DLM (data lifecycle management) control, too.
For highly regulated industries, sandboxing will more-than-likely be mandated to pass audits or obtain certification.
Third Party Sandbox Pros
Below are some sandbox pros:
• Some sandboxed solutions open web links in a secure browser that can redirect traffic to an MDM gateway and then a proxy server, thereby mitigating Spear Phishing Although it must be said that there are some global proxy products to perform similar tasks on both cellular and WiFi for native browsers but this is an additional cost.
• Can provide an extra layer of authentication, ie: PIN to access the sandbox independent of a device passcode. This is useful in scenarios whereby a child gets hold of daddy’s or mummy’s phone.
• Can usually control what is displayed on notifications.
• Data Loss Prevention Policies are in-app, not on the device, and don’t hamper the native device experience. For example, if an administrator disables print screen on an iOS device using iOS Restrictions, then that affects all apps at device level. In contrast, a sandbox print screen restriction only affects the sandboxed apps whereby the policy applies.
• Functionality has matured significantly across the MDM vendors.
• Many sandboxed apps use per-app VPNs
Third Party Sandbox Cons
Below are some third party sandbox cons:
• Users may likely complain about the sandbox in-app experience.
• The sandbox can have bugs and limitations that can prevent functionality.
• Older or certain sandboxes may not allow contacts to be exported or read; this can cause an issue if a contact dials. Also, exporting contacts may risk duplicating them if they already exist on the native contacts.
• The app wrapping can be complex and require niche or vendor skills. Also, it is commonplace for apps to have to be frequently re-wrapped, for example, when a major release of iOS comes out.
• Certain Third party sandbox apps may be acquired, cease to be or change format/name.
• Potential for extra costs
• The app may not poll as frequently as a native email app. In the case of iOS this will require access to the Key Chain and, even then, it may not be as frequent as a native client.
• Limited integration with the notification system
One of the key push backs to sandboxing is the user experience. Users are creatures of habit and mainly prefer the native experience when contrasted with a third party alternative. This can vary from just the look and feel of day-to-day common tasks or the fact that built-in Office readers or PDF annotation is not up to task. Of course the sandbox can be opened up to third party apps that users prefer (ie: the native iOS Office apps) but that defeats the whole purpose of sandboxing. This causes a Catch 22 as the users don’t like the in-built readers or clients.
It is advisable to have a test group of users and additional training so users can adjust to the transition. There is a possibility that user experience concerns aren’t taken into consideration. However, if they aren’t taken into account then significant user resistance can halt a project.
iOS provides alternatives to using third party sandboxing and is often overlooked. As per Apple Security White Paper, iOS separates managed and unmanaged apps using isolated memory and storage silos. This in effect is a native sandbox, not requiring a third party sandbox. So how can it restrict?
In iOS 7 and higher there is a managed open in policy that prevents managed apps opening in unmanaged apps and vice versa. A managed app is any app installed via the MDM vendor’s AppStore or may be a native application, for example, the iOS Native Mail app.
On a device-level screenshots can be disabled, however, the advantage of a third party sandboxed app is that these restrictions are in-app only. A device-level restriction may cause some frustrations for the user.
The one key advantage of using the native iOS client is that the sandboxing is virtually invisible to the user and the user experience is consistent.
One of the big issues with sandboxing in Android was that applications could not be guaranteed to run or push configs reliably across a wide range of Android devices. This is because, unlike iOS where the hardware/software experience is consistent, Android is a fragmented market. This is why many corporates either veered away from Android or mandated specific devices like Samsung that use SAFE APIs, KNOX and consistently support third party sandboxed solutions. To make Android more Enterprise friendly, Google addressed these concerns by developing Android Enterprise (Android for Work).
Android Enterprise initially used to be a complex process but recently has been greatly simplified. For example, there is no more domain verification for non-GSuite customers. These proved stumbling blocks for Corporates and now the simplified setup removes these barriers and concerns.
Starting with Android version 5.0 and higher, Android Enterprise devices offer a user and work space separation aimed at BYOD. In contrast, there is also a device owner mode with no separate user space. The separation of user and work apps are marked by Android Enterprise briefcase icons. It also offered a reliable experience across a range of Android Enterprise compatible devices in contrast to deploying a sandboxed solution across a myriad of Android device/vendor/OS versions where some devices may have specific issues or may not work at all. Also, to make the solution more Enterprise friendly, Googled added Play for Work, a corporate version of the Play Store with only work-approved apps analogous to iOS Apps@Work. In addition, certain apps when added to the Play for Work Store have additional configuration or lockdown settings that can be pushed to the device. The logical separation, encryption of data and a dedicated Play for Work Store aims to steer Android Enterprise towards consideration for Enterprise. In an MDM solution it is possible to create search criteria to identify compatible Android Enterprise devices.
This article is just a brief summary but aims to demonstrate that there are some built-in alternatives to using third party sandboxed software for both Android and iOS. No single solution is a panacea. There is a time and place for each solution. What suits one organisation, may not suit another due to workflows, compliance, user feedback and so forth. Assessing new technologies to deploy is an iterative process that must be reviewed as the industry evolves and offers new options. This article aims to show there are some free, native and sandboxed solutions in contrast to the third-party sandboxed app story.