Android Marshmallow and iOS 9 add new tricks to the MDM arsenal, especially for app management

By Galen Gruman

InfoWorld |Oct 6, 2015 5:17 AM PT

Apple’s iPhone and iPad long ago pushed out the BlackBerry as the corporate standard for mobile devices, in all but the highest-security environments. Earlier this year, Google — whose Android platform reigns outside the corporate world — got serious about mobile management with a new effort called Android for Work. And Samsung upped its the game with a new version of its Android security suite, Knox.

Now we have Android 6.0 Marshmallow and iOS 9, both of which offer refinements to their respective existing mobile management capabilities, particularly in the areas of app management.

What’s new in iOS 9

Released in mid-September, Apple’s iOS 9 has very few new policies for managing iPhones, iPads, and iPod Touches. But there are a handful: Using an mobile device management (MDM) tool, IT admins can now force iOS updates as well as stage their deployment across supervised devices — corporate-issued devices under full IT control.

There are also new policies in iOS 9 to control whether devices can roam on cellular networks, to enable or disable screen recording, and to control whether they can use Apple’s Mail Drop feature to send large attachments. (Mail Drop stores the documents in iCloud and sends the recipient not using an Apple device a link instead to download the attachment from; Apple device users see the normal attachment in their email, even if it exceeds their email server’s attachment-size limits, because Apple Mail reattaches the file automatically behind the scenes.)

For supervised devices only, there are new controls over Apple Watch pairing, the use of iCloud Photo Library, keyboard shortcuts, automatic app downloads, and News app setup, as well as over the users’ ability to change the device name, password, and wallpaper. Those supervised policies are designed mainly for shared-use devices, such as in schools or retailers.

Apple’s major changes in iOS 9 management focus on its Device Enrollment Program and Volume Purchase Program services. DEP is the service to manage fleets of supervised iOS devices and in-house apps, and VPP is the program to manage corporate apps from the App Store across that fleet of devices.

iOS 9 adopts the OS X approach to app management, whereby IT can associate a specific app to any number of devices and/or users, rather than managing each device’s or user’s apps independently. Apple has also simplified how DEP catalogs apps, so IT can build an app library without having to poll all devices each time. Apps can now be installed on supervised devices even if the App Store is disabled on those devices, and in-house apps can be installed silently, without user confirmation.

What’s new in Android 6.0 Marshmallow

The big change in Android Marshmallow is that its adopts iOS’s approach to app permissions. That means users can now change the permissions that apps have whenever they want, not simply choose those permissions at app installation. Many users didn’t know what all those requested permissions meant; plus, they had to accept all or none. Now, users can go to the Settings app to see what permissions each app uses and revoke or enable each permission independently.

Better, IT can also manage these app permissions as granularly for apps that reside in Android for Work or other managed container (for BYOD deployments) or on fully managed (supervised) corporate-issued devices, notes Imran Ansari, Android product manager at MDM provider Soti.

Android Marshmallow’s other policy refinements are similar in their incremental nature to iOS 9’s. For example, new policies let IT force a device’s screen to stay on or a Wi-Fi connection to remain active while the device is plugged in. Ansari says this feature will appeal to IT for public-facing deployments, such as for kiosks, payment terminals, ordering systems, and lobby sign-in systems.

Android Marshmallow also lets admins disable the use of a smartwatch as an authentication token, so a smartwatch cannot be used to bypass a password requirement. And it lets IT force installation of OS updates as they become available, as well as delay those updates for as long as 30 days, so IT can test apps on a new OS version first.

Finally, Android Marshmallow offers new policies to control whether users can safe-boot their device (booting into safe mode can bypass MDM controls) and whether notification details can appear on a paired smartwatch’s screen, to keep company information secret.

What Android for Work does and doesn’t do

The biggest change in Android management, however, came last February with the release of Android for Work as part of an Android 5 Lollipop update. That technology added new security and management capabilities, plus the ability to do corporate deployments of Android apps from the Play Store.

Android for Work containers — which run business apps in a separately managed workspace on your device — are part of the Android 5 Lollipop and Android 6 Marshmallow OSes and support any Google Play store apps. But Android 3.0 Ice Cream Sandwich through 4.4 KitKat require users to install the Android for Work app, which can run only apps that have the Android for Work APIs implemented.

Either way, you need a compatible mobile management server to handle the policies applied to apps running in the container, such as enforced VPN use or copy-and-paste restrictions. Mobile management vendors supporting Android for Work include BlackBerry, Citrix Systems, Google, IBM, MobileIron, SAP, Soti, and VMware AirWatch.

What Android for Work only partially addresses is the malware problem among Android apps, both due to the high incidence of malware residing in the Google Play Store and to the common file system in Android that lets malware infect apps via data files. For example, the feds have said that industrial-class spyware used in advanced persistent threats has entered the Google Play market. With Android for Work, IT admins can prevent users from installing unapproved apps from the Play Store in the business workspace to better protect the corporate environment.

By contrast, iOS uses rigid sandboxing to keep apps from accessing other apps, and it severely restricts document sharing to block malware. BlackBerry and Windows Phone have small app libraries and a semiporous approach to sandboxing, so malware has not been an issue for them to date — though there have been outbreaks of BlackBerry malware in the past.

Android for Work also does not make encryption the default on existing Android devices. (Many models, especially the cheap ones, lack the horsepower to handle encryption.)

Google promised last October that Android 5 Lollipop would enable encryption by default on all new devices. (Upgraded devices’ encryption state is unchanged.) But there’s no requirement that the devices use a crypto chip, so users could see major performance hits. InfoWorld’s sister publication Greenbot found that Google’s own Nexus 6 slows to a crawl with encryption on, for example.

Of particular concern to IT, Google has quietly backtracked on its promise that new Lollipop devices would be encrypted by default. In fact, several new Lollipop devices are not. The new Android Marshmallow also does not enforce this promised encryption.

By contrast, iOS devices have been encrypted by default (with no disable option) since 2010, and BlackBerry devices have been encrypted for at least a decade — both have the needed crypto chip to avoid performance hits. But Windows Phone 8.1 devices come with encryption disabled by default, and an admin must enable it. (Windows 8.1 is the first version of Microsoft’s mobile platform to support device encryption.) It’s unclear whether the forthcoming Windows Phone 10 will enable encryption by default.

Knox aims for corporate-issued Android users

Announced two years ago, Samsung’s Knox has had a difficult rollout and now competes with Google’s Android for Work. But the company has stuck to the product, quietly unveiling Knox 2.4 in February and following up with smaller updates this spring.

Knox works only with selected smartphones and tablets from Samsung because it integrates directly with the hardware in a way similar to how BlackBerry does for its own smartphones and BES management server. Thus, Knox is a realistic option only for companies that issue compatible Samsung devices to employees.

For such companies, Knox 2.4 and later provide Active Directory password integration for its secure workspace, bulk enrollment of devices over the air, and the ability to track users’ business and personal data usage.

Mobile device management has essentially stabilized

Google’s Android for Work move came on the heels of the efforts of Microsoft to improve the security of Windows Phone, which historically has had weak security and management capabilities. Windows Phone 8.1, released last fall, finally gave the Microsoft smartphone platform a reasonable level of basic capabilities, though well behind what other mobile platforms provide.

BlackBerry devices have long offered mobile device management (MDM) controls in the operating system and key bundled apps to manage user permissions. iOS added such capabilities in 2010. Android followed a few years later, and in fall 2014, Windows 8.1 was the last major mobile OS to provide a strong set of device-management APIs. (BlackBerry devices also provide a secure network and chip-level antidevice spoofing, which competitors don’t have and are key reasons that high-security environments rely on BlackBerry still.)

With the market for BlackBerry devices fading fast, BlackBerry has focused on reshaping its formerly BlackBerry-only BES tool into a unified mobile management tool, BlackBerry Enterprise Service (BES) 12, for managing iOS, Android, and Windows Phone 8 devices — all widely supported by other MDM tools — in addition to its current BlackBerry 10 and legacy BlackBerry 5 and 7 devices. But BES12 has failed in the marketplace, leading BlackBerry to buy longtime MDM provider Good Technology instead.

Also, iOS, Android, Windows Phone 8, and BlackBerry 10 all support Microsoft Exchange ActiveSync (EAS) policies, which provide basic but common cross-platform management for less-rigorous security environments that IT can administer from an Exchange server, Office 365, Google at Work, Lotus Notes, or Microsoft System Center, as well as from any MDM server. Table 1 shows which policies are supported by each major mobile platform.

Content and app management is where mobile security is now focused

These days, the mobile management vendors’ focus is on content and application security since device management is all but settled. Apple’s iOS 7 APIs were the first to address the issue at a platform level, providing standard APIs for apps to use to manage their content and usage.

Apple last made a big leap in mobile security and management in 2013, when iOS 7 pushed Apple’s management and security into new areas, including application management and licensing management. The recent iOS 8 and iOS 9 have only a few additions.

Apple’s approach is to handle apps and their contents directly, which means app developers must implement the APIs for a management server to be able to work with them. Furthermore, iOS allows only one instance of an app on a device, so users can’t install a personal copy free of restricts and a business copy managed by IT.

Apple didn’t invent the API-managed apps notion; in 2011 several startups offered mobile application management technology that required app developers to implement proprietary APIs and proprietary management tools. They went nowhere. Apple’s approach in iOS 7 makes the technology available to all apps and all management servers, eliminating the lock-in barrier.

Since then, most vendors have taken the containerization approach, which essentially partitions IT-managed apps and the data they work on, into a separate workspace not accessible by the user’s personal apps. Users have to switch between the two workspaces, as if they were using two devices.

For years, several providers such as Divide have offered such containers for iOS and Android, but they required that the apps running in them be tied to their proprietary APIs, which in turn were tied to a specific vendor’s mobile management server. Thus, they’ve gained little adoption.

In 2013, Samsung announced a container technology called Knox that was available for a handful of its Galaxy smartphones and supported by few mobile management servers; it too has gained very little adoption. But the company is renewing its Knox effort with the 2.4 version released on April 10, 2015.

Also in 2013, BlackBerry introduced BlackBerry Balance, the first platform-level containerization approach, for BlackBerry 10 devices. It also has a Balance container app, called Secure Work Space, for iOS and Android.

In spring 2014, Google purchased containerization vendor Divide and later said it would make containerization part of Android — now the Android for Work technology that became available in February 2015.

Container policies differ widely from container to container, which can make management difficult. However, now that popular mobile management servers support both iOS’s APIs and Android’s containers, IT admins should be able to create consistent policies that are largely compatible across the two platforms — much as they can when using the extended device management APIs in iOS and Android.

Note that BlackBerry’s BES12 supports some of the iOS 7 app-management APIs, few than those from, for example, Citrix, MobileIron, and VMware AirWatch. Among the iOS 7 app policies supported by BES12 are per-app VPN, single-app mode, single sign-on, and Apple Volume Purchase Plan (its corporate app store).

BES12 supports some app-management APIs for BlackBerry devices, but the policies available vary widely based on the type of app managed: Java, recompiled or Fire OS-compatible Android, BlackBerry 5- or 7-native, or BlackBerry 10-native. Frankly, it’s a mess.

Native security and management API capabilities compared

As noted previously, the platform APIs vary widely across the major mobile OSes, and each requires a management tool. Most MDM tools support multiple mobile OSes, providing a single console for IT admins.

Some also offer client apps — basically, a proprietary container with proprietary business and communications apps — that add capabilities not found in the native APIs. Table 2 shows some of the more commonly requested management features typically implemented through APIs.

iOS API tour. Apple, for example, has several dozen APIs for device management that use remotely installed configuration profiles not only to configure various iOS settings (such as preconfiguring VPN or allowed access points) but also to manage app behavior (such as disallowing the forwarding of corporate messages via personal accounts in Mail). App-related policies include the ability to prevent app removal, lock a user to a specific app (such as for kiosk or retail usage), and prevent paid apps from being purchased. All are part of what iOS calls a supervised environment, in which the iPhone or iPad is treated as an appliance.

iOS’s APIs for application management include managed Open In, per-app VPNs, managed copy and paste across apps, and single sign-on, as well as true license management and profile-based app installation. iOS 8 also has APIs to disable the Handoff capability, iCloud sync for managed apps, backup of enterprise books, and annotation to enterprise books. Supervised devices also get the ability to disable erasure of all content and settings, restriction configuration, and presentation of Web results in a Spotlight search.

iOS 8 supported per-message S/MIME and both IKEv2 and always-on VPNs. iOS 9 adds several features, as previously described, such as control over cellular roaming, use of MailDrop, and iOS updates.

Android API tour. Although Google hasn’t published details of its Android at Work APIs on its Android developer or IT admin sites, Alexander Romero, an Android engineer at MobileIron, walked me through them.

To address the Android malware problem, Android at Work can let IT restrict the provisioning of apps in the business workspace to only those approved by IT. That means users can’t install apps themselves in the secured workspace if IT enables this policy. IT can also install, update, and remove apps in the business workspace without user involvement.

There are policies to disable copy and paste from the business workspace into the personal one (but not vice versa) and to prevent screenshots being taken in the business workspace. IT can also determine which IT-managed apps use a VPN for access, as well as retract personal apps’ communication from the corporate VPN.

Android Marshmallow adds, a previously noted, a few policies, such as to deploy OS updates to managed devices and to manage app permissions.

Google also says the Google Play app store can now provision apps to Android devices through volume business licenses, similar to Apple’s volume licensing approach introduced in iOS 7. Called Google Play for Work, the revised app store supports free apps already and will “soon” support paid apps.

Samsung had its own set of device APIs for Android 4 called SAFE APIs, which allow IT admins to disable cameras, Bluetooth, tethering, voice recording, SD cards, and Wi-Fi. You have to use a SAFE-compatible device and management server to access those extra policies. The SAFE APIs were replaced with its similar Knox APIs in Android 5.

Windows Phone API tour. In Windows Phone 8, Microsoft supports the ability to revoke applications, restrict email forwarding, remotely enroll or unenroll devices, and remotely update business-provisioned apps.

One capability in Windows Phone 8 not available to other mobile OSes is its integration with Active Directory. This means that compatible MDM tools can access the Active Directory groups, then assign policies to those groups rather than maintain a separate set of groups in the MDM tool from the set in Active Directory. The feature reduces the risk of employees not being in the correct groups for the policies that should apply or falling through the cracks when terminated in, say, Active Directory but not in the MDM tool’s user database.

Microsoft uses a central manager in Windows Phone 8 called DM Client that contains all the relevant user and corporate profiles (like the Windows Registry, in effect), rather than rely on a set of separate installed configuration profiles (like the OS X System Folder, in effect).

How to think about mobile device management

No matter what platforms you support, there are three bands of management requirements for IT to think about, advises Ojas Rege, vice president of strategy at MDM provider MobileIron.

The first set of requirements is around configuration and protection of lost or compromised devices. That typically requires password enforcement, encryption enforcement, remote lock and wipe, remote email configuration, certificates for identity, remote connectivity configuration (such as for Wi-Fi and VPNs, though Rege says this configuration capability is not essential if usage is only for email and over cellular networks), and detection of compromised OSes (whether jailbroken, rooted, or malware-infected).

The second set of requirements is around data loss prevention (DLP), which covers privacy controls (such as for user location), cloud-usage controls (such as for iCloud, OneDrive, and Google Docs), and email DLP controls (such as the ability to restrict email forwarding and to protect attachments). “More regulated environments may require No. 2, and these policies are still TBD for Windows Phone,” Rege notes. By contrast, iOS, BlackBerry, and Android have supported most of these needs since (respectively) iOS 4, BES 5, and Android 3, though a few — for example, managing email forwards — are handled outside the OS by MDM client apps such as MobileIron’s.

The third set of requirements is around apps, such as their provisioning and data security. Both Apple and Microsoft have mechanisms to do at least basic app management — iOS can essentially hide an app so that it’s no longer available to a user, and Windows Phone 8 can update corporate apps remotely — and both Google and Samsung now offer this capability within their secured containers.

But mobile application management (MAM) capabilities are mostly still up to the mobile management vendors to deploy and can vary widely across MDM tools, Rege says.

• Download the PDF: Mobile security Deep Dive