What Enterprise Mobile Management Strategy Should You Adopt for BYOD?

The current BYOD (bring your own device) trend for enterprise mobile applications has its pros and cons. The author walks the reader through the problems faced by systems admins when implementing strategies for enterprise mobile management (EMM), drawing from his own experiences in this field, and talks about the strategies that have evolved recently.

Developers or product managers of enterprise grade mobile apps often wish their apps could be managed by enterprise IT admins using popular Enterprise Mobile Management (EMM) solutions. Similarly, IT admins are on the lookout for the ideal mobile strategy to manage and secure business apps, with data residing on the user’s personal mobile device.

Over the course of my work in this domain, I found solutions to address both these important requirements. It happened while working on an assignment to define an extensible mobile strategy for a popular workforce management (WFM) mobile product. The task was to enable it to be managed by IT admins using popular EMM solutions in the market, whether Air-watch (AW), MobileIron (MI), SOTI or SAP Afaria. The major requirement was to enable the IT admin to dynamically configure WFM to set key properties like the server URL from the EMM admin console.

This article is based on my experience from that exercise. It will provide insights to help you decide the best mobile management strategy for your needs. Additionally, it will help you understand the new, standard EMM integration approach by highlighting the pros and cons of each of the legacy EMM integration approaches normally used.

BYOD: Benefits and trends
The use of mobile devices for work operations has become quite common. In fact, with BYOD (bring your own device), it has become a basic need nowadays.

According to Wikipedia, BYOD refers to the policy of permitting employees to bring personally owned devices (smartphones, tablets, etc) to their workplace, and to use those devices to access privileged company information and applications.

BYOD has resulted in a lot of benefits like:
1. Increased productivity of employees when they work from devices they are familiar with as it helps them complete tasks faster. A survey carried out by Dell and Intel confirms this.
2. Employee satisfaction.
3. Cost reduction—no hardware/COPE (corporate owned personally enabled) device procurement.

Owing to the benefits mentioned, there has been substantial adoption of BYOD in enterprises in the past few years and this is expected to grow even more in the future. According to Gartner, half the employers around the world were operating on the basis of BYOD by the end of 2016, and 90 per cent of organisations will support some aspect of BYOD through 2017.

The need for MDM alternatives for BYOD
Mobile device usage for work has led to IT admins searching for technology solutions to secure these devices and safeguard company/business data.

In the past, mobile device management (MDM) solutions worked well, giving IT admins the management capabilities to manage COPE devices. The usual MDM solution enables IT admins to manage and govern the complete mobile device. MDM allows IT admins to wipe all data, locate devices, apply policies and generally govern COPE devices.
The rise in BYOD opens up the need for alternate mobile management strategies as MDM isn’t a fit for BYOD. Let us briefly understand the rationale behind the need for alternatives.

Along with benefits, BYOD comes with challenges. With BYOD, the chances are high that enterprise data on the user’s personal device can be compromised. For example, if an employee uses a smartphone to access the data on the company network and then loses that phone, untrusted parties could retrieve any unsecured data from the phone. Such risks call for an appropriate mobile strategy to secure enterprise apps and data.

MDM does not mesh well with BYOD users as they would like to keep their privacy intact while they use their smartphones for work. Users may not like MDM solutions to completely govern their personal devices, which may have their personal files along with business apps and data. Users will be reluctant to use their devices for work if the governing MDM solution is always keeping an eye on their geo location or if there is a chance that their personal files may get accidentally wiped by the IT (MDM) admin.

On the other hand, IT admins may like to at least have basic mobile management capabilities, even for BYOD, so as to effectively do the following:

• Distribute business applications (in-house or third party) from one place.
• Secure data on the move. Company employees will run business apps on their mobile devices and may fetch business data over public/open Wi-Fi or 2G/3G networks. This confidential data getting transferred over networks while users are on the move is termed as data on the move. It becomes important to take measures to safeguard this data as it can be sniffed and compromised on open networks.
• Secure data at rest. Company employees may save business data/files locally on their mobile devices while using business apps. These confidential data files stored locally can be extracted by anyone who gets access to the mobile device. Thus it becomes important to safeguard these data files.
• Protect data leaks. There could be a few business mobile apps serving very sensitive data to the end user, like the price quotations of a product. IT admins may want to restrict the screen capture or copy/paste of such sensitive pieces of information from the application.
• Configure the application. IT admins may want to set up business apps for their employees by dynamically configuring key parameters like the enterprise backend server URL and port, where the application should connect or fetch data from.

Containerisation and MAM – the MDM alternate strategy best suited for BYOD
The need for the earlier mentioned mobile management capabilities and the partial mismatch between what MDM does and BYOD users want, have resulted in containerisation. This is a new methodology which separates business data from personal data on the user’s device. This methodology creates a separate and secure storage space on the device to store business apps and data, away from personal data. This space can be thought of as a separate container/box which keeps business apps and data secure in silos, away from intruders.

Mobile application management (MAM) is also gaining popularity with containerisation. MAM is about managing just the business apps used for business operations instead of managing the entire device. MAM and containerisation go hand in hand, and have become the mobile management strategy for BYOD.

The older EMM integration methodologies for containerisation and MAM
Initially, EMM (enterprise mobility management) vendors devised diverse integration methodologies to achieve containerisation and MAM. These had some benefits as well as quite a few downsides.

Let me highlight a couple of old methodologies along with their pros and cons, which I experienced while doing some WFM MAM work for iOS and Android.

1. MAM (EMM) SDK integration methodology: In this methodology, the developer needs to integrate the EMM propriety mobile MAM SDK code into the mobile application code. Each EMM propriety MAM SDK library code will be different, and will provide varying mobile management feature sets. There are several EMM solutions in the market and, with this approach, MAM SDK code for each of these EMMs has to be plugged in with the mobile application to support them all. The following are the pros and cons of this approach.

Pros

• Full blown MAM feature support.
• Fine grain management and control.
• Possibility of extended/custom management and security features.

Cons

• Can only support internal mobile apps with MAM SDK. Chances of managing public mobile apps from third party ISVs are less as the app may not have EMM SDK code in it.
• EMM vendor lock-in, if the mobile application is integrated with the MAM SDK code of just one EMM. To support the new EMM, MAM SDK code of the new EMM has to be plugged in within the app code.
• Multiple EMM MAM SDK codes in a single mobile application will increase the following:
  a. Code complexity;
  b. Application binary—the key consideration is to look at the mobile device storage capacity;
  c. Side effects owing to code conflicts, as more or less all MAM SDK codes will be leveraging similar events within the application;
  d. Performance degradation of the application.
• Maintenance overheads with constant upgrades for the latest MAM SDK library updates.
• Unavailability of the SDK can become a bottleneck. While working on WFM, initially (Q1, 2015) we integrated an iOS variant with MI’s App connect library. For Android, the MI MAM SDK/library wasn’t available.

2. App wrapping methodology: In this methodology, the already compiled and packaged mobile app is wrapped with MAM (EMM) vendor dynamic libraries, and this is called app wrapping. MAM libraries are layered over the already built mobile application binary and then the complete set is recompiled, repackaged and resigned with the EMM app signing certificate to generate a new MAM capable mobile app binary. Post wrapping, standard system calls from the original mobile app are routed through the MAM API library to ensure that the calls are secured and managed. This methodology does not require any development work, that is, no code change is required to hook the MAM SDK. There are several EMM solutions in the market and, with this approach, the mobile application needs to be wrapped with the MAM SDK of all EMMs. The following are the pros and cons of this approach.

Pros

• No development/code change is required.
• Public mobile apps from third party ISVs/developers can be covered as well.

Cons

• Wrapping public apps from third party ISVs/developers or even private apps isn’t right and is not recommended. It violates app terms and copyright rules.
• Not a reliable methodology, as it creates a lot of issues and side effects. For WFM, initially (Q1, 2015) we used it for both Android and iOS variants. Post wrapping (with old wrapping engine versions from MI and AW), the app used to get stuck at the landing page with a blank blue screen. Later, after a couple of months with newer wrapping engine versions, the app was able to move ahead from the landing page but used to crash randomly in different modules. On detailed research on Android variants, we found that the MI wrapped library had issues with Implicit Intent handling within the resolveActivity method of the PackageManager class from the Android OS.
• It can interfere and obstruct certain functionalities of the app. For WFM Android wrapped with MI, we found that the MI MAM libraries were not allowing the app to fetch GZip data from the server, and there wasn’t any way to configure and allow it. This became a big bottleneck and we had to drop this approach eventually.
• Wrapped apps may not support full blown MAM feature sets and will not be able to provide fine grained control like in the SDK approach.
• For WFM Android, post wrapping with MI and AW, we ran into the blocker issue of reaching the 64k method count limit of Dalvik. Android apps run on Dalvik VM (DVM).
• Wrapping with multiple EMM (MAM) libraries created conflicts.
• For WFM, we had to add a different EMM specific code to receive dynamic app configuration from EMM.

Old methodologies could achieve varying levels of containerisation and MAM for small/medium mobile applications but had several downsides as mentioned above. Moreover, the rapidly changing market introduced several methodologies and thus fragmented the market. It created a lot of confusion and chaos amongst IT admins, product owners and app developers to identify the right way to achieve containerisation and MAM.

OS containerisation – standard and recommended EMM integration methods
In the past few years, Apple and Google realised the increasing use of personal mobile devices for work and the need for standardisation. So they took the initiative to bake in containerisation and MAM capabilities right into the mobile OS, that is, iOS and Android (AndroidforWork or AFW). Mobile OS native containerisation can be thought of as a new, standard, universal approach. I will term it as OS containerisation for the rest of this article.

The AppConfig community (a group of EMM providers, ISVs/developers and enterprises) has been formed to standardise and streamline the OS containerisation and integration process. It has come out with an EMM independent methodology to leverage OS containerisation features. As a result, many of the management and security features are automatically taken care of by the OS and will not require any development. For a few features, like app configuration, minimal but standard OS code changes can be made so as to receive dynamic app configuration values from any EMM. With OS containerisation, managed mobile applications can be governed by any app configuration member EMM without any EMM specific code. The following are the pros and cons of this approach.

Pros

• Reliable approach, as it is backed by mobile OS vendors (Apple/Google), EMMs, enterprises, ISVs/developers.
• No conflict, nor code redundancy via a single unified, standard mobile OS infrastructure, code for containerisation and MAM.
• No development/code changes are needed.
• Internal (system) apps and public mobile apps from third party ISVs/developers can be covered under this.
• No EMM vendor lock-in, as IT admin can change the existing EMM with another app configuration member EMM, and it will work seamlessly.
• No 64k method count problem on Android.

Cons

• May take some more time to mature, as OS containerisation is gradually evolving and a set of new features is getting introduced with every new OS version.
• AFW is complex to set up as it involves tie-ins with several Google consoles and EMM in use to set up the entire system. Examples of consoles are Google Admin Console, Google Play for Work, Work Profile on Android device, etc.
• AFW can be costly as it is powered by Google, which will levy charges on a per-user, per-month basis. These Google charges will be additional costs if your organisation is already paying and using some EMM tool.
• For AFW, GCDS or Google Cloud Directory (earlier known as GADS) may require to be set up to sync your organisation’s Active Directory user/group with it. This may not be acceptable as per the policies of many enterprises.

OS containerisation empowers IT admins with the following key mobile management and security capabilities for BYOD:
1. Securing data on the move via app tunnel/per app VPN.
2. Securing data at rest via complete encryption.
3. Mobile app level DLP (data leak protection) by disabling screen capture, disabling copy/paste, selective app wipe, and pin protection for business app access.
4. Single sign-on.
I strongly recommend the OS containerisation integration methodology as it is provisioned by mobile OS vendors Apple and Google and has become the standard, thanks to the participation of popular EMM vendors, ISVs, enterprises, etc. It enables coverage of a wide set of mobile applications in a standardised manner without getting locked with any single EMM vendor solution, and that too in a standardised manner.