This article can also be found in the Premium Editorial Download "Information Security magazine: New security strategies for the bring-your-own-device era."
Download it now to read this article plus other related content.
Multi-platform mobile device management systems are gaining a foothold in enterprises anxious to meet the needs of today's expanding mobile workforce. While no silver
In a recent study by Ponemon Institute, most organizations agreed that mobile devices created business risk but were important to achieving business objectives. However, just 39 percent had deployed security controls needed to address that risk; fewer than half of those could enforce mobile security policies.
Unfortunately, this lax governance has already resulted in non-compliance and data breaches. In Ponemon’s survey, 59 percent said employees disengaged fundamental measures such as passwords; another 12 percent were unsure. It should therefore come as no surprise that half of those organizations had experienced mobile data loss during the past year.
Given the rash of employee-owned smartphones and tablets now finding their way into the workplace, IT simply must find a way to manage mobile application and system access while keeping corporate data secure. Fortunately, a new crop of multi-platform MDM products and services stand ready to help IT achieve these objectives and mitigate BYOD risks. However, organizations need to understand the benefits, nuances and limitations of this emerging technology before taking the plunge.
The rise of multi-platform MDM
Mobile device management systems are not a recent phenomenon. Enterprises have long managed company-issued BlackBerries and Windows Mobiles via BlackBerry Enterprise Server and Microsoft Exchange Active Sync (EAS). But yesterday’s narrowly focused MDMs could not handle the consumer smartphones and tablets that flooded the workplace following Apple’s iPhone release in 2007. As handset procurement rapidly shifted from employer to employee, driven by budget cuts and workforce demands, IT groups were left scrambling for more extensible tools.
Initially, IT had little choice but to reduce iPhone risk by applying EAS policies to prevent corporate email access by non-passcoded phones and remotely wipe those that were lost. But these basic measures fell short of governance needs. Certainly, they did not satisfy compliance mandates to encrypt data at rest, nor could they deliver proof of continuous enforcement or meet access tracking and audit requirements. Although EAS support in newer devices continues to expand, this messaging-centric approach is plagued by inconsistency and cannot meet broader mobility management requirements.
By early 2010, iPhones had been joined by iPads and Androids, fueling growth of the multi-platform MDM market. Niche multi-platform MDMs previously used by cellular companies and highly mobile verticals such as retail quickly expanded to embrace iOS 4, followed by Android 2.2. Today, multi-platform MDMs are viable alternatives to BES or EAS, giving enterprises a “single pane of glass” through which to monitor and manage an increasingly diverse array of corporate and bring-your-own phones and tablets.
MDM breadth and depth
Unlike BES, which uses a proprietary approach to manage only RIM devices running the BlackBerry OS, multi-platform MDMs are third-party products that use open APIs to tap the native interfaces and capabilities offered by many different devices. Today, it is common for MDMs to manage Apple devices running iOS 4+, Samsung/Motorola/HTC/LG devices running Android 2.2+, and an array of handheld and embedded devices running WinCE and Windows Mobile. Limited MDM support can also be found for Windows Phone and WebOS devices. However, the degree of monitoring and control delivered for each managed device varies by make/model and OS version.
For example, MDMs can usually enforce device-level access controls on iOS and Android devices. On iOS, IT may require alphanumeric passcodes with minimum length and special characters and limit passcode age, reuse, idle time, or failed entry attempts. On Android 3+, IT can enforce all of this, plus require upper/lowercase letters, digits, and symbols. Every MDM that supports iOS and Android exhibits this difference because it reflects native OS capabilities. However, the extent to which each MDM tries to hide such differences under unified consoles with a consistent look and feel varies widely.
In other cases, mobile device management systems can do little to mask underlying diversity. For example, IT can use any MDM on the market to request a full-device wipe. Because all Apple iPhones and iPads now support full-device encryption, remote wipe easily renders data inaccessible. However, wiping most Android phones simply resets them to factory default, leaving cleartext behind on removable storage. MDMs cannot eliminate this native shortcoming -- doing so falls to device manufacturers. But MDMs can provide tools to centrally invoke remote wipe, confirm a requested wipe has been completed, report on all wiped devices (including ownership and last known location), and clearly describe the consequences for each wiped device.
This is where MDM depth comes into play. Some MDMs stick to managing hardware, software and policies. Other MDMs pile on value-added security measures. For example, some MDMs create their own authenticated, encrypted data containers on managed devices. Any enterprise data stored in those containers can be reliably wiped, even on phones and tablets that do not support native full-device encryption. Moreover, this approach lets IT wipe data consistently across all MDM-supported platforms. However, MDMs that include these value-adds tend to have more device-specific dependencies and limitations than MDMs that focus on management.
Enterprises flocking to multi-platform MDM technology to gain IT visibility and control over personally owned devices may find it hard to directly compare products. Heritage plays a role: Some MDMs historically focused on mobile expense management, others started with mobile application management and still others specialized in mobile security. Yet most of these MDMs deliver foundational capabilities such as inventory and policy management that cause them to appear superficially similar. Drilling beyond functional comparison can also reveal significant differences in automation, usability, scalability and integration.
One way to reduce confusion is to preface MDM product selection with an inventory of business mobility needs and use cases. When IDC surveyed businesses about their ability to support consumer devices in the workplace, four out of five respondents identified policy compliance and data security/access as top concerns. However, nearly the same percentage cited ensuring IT support and resource availability, readying mobile applications and setting employees up with multiple devices as major issues. In other words, choosing an MDM based on its ability to meet security needs alone may be shortsighted.
Instead, begin with lifecycle management. Even if the employer does not own an employee’s mobile device, it owns the business data and applications stored on that device. Start by establishing a process for tracking and managing those assets through each device’s lifetime. Doing so creates an essential foundation for not just security management, but expense tracking, user assistance, application and data deployment and more.
MDMs can enable lifecycle management by automating device enrollment, monitoring and de-enrollment, independent of ownership. Most MDMs support IT-initiated enrollment; some also offer user-initiated enrollment. Either way, users follow links to a self-help enrollment portal where they are prompted to enter credentials. Behind the scenes, the MDM typically authenticates the user and compares user and device to IT-defined policies. If this user is permitted to enroll this device, based on make/model, OS, ownership and group membership, access may be authorized. MDMs may display an acceptable use policy and issue a device certificate before continuing on to provision the device over-the-air, applying device settings, security policies and applications.
By automating enrollment, IT can deliver scalable support for many personally owned devices while placing well-defined limits on acceptable use. Devices that pass muster can be outfitted for safe productive business use, leaving IT well-positioned to continually monitor activity and enforce security policy compliance. If an enrolled device should be lost or stolen or become non-compliant, IT can use MDM to remotely find, lock or wipe it.
In addition, MDM may be used to invoke temporary stop-loss actions such as removing settings that permit corporate email, VPN or application access. Eventually, when the employee leaves the company or the device is replaced, MDM can easily de-enroll it while wiping corporate assets. Many MDMs can now differentiate between full-device and enterprise wipe, letting IT decommission an employee’s device without harming personal data.
Mitigating BYOD risks
With MDM in place to shepherd every corporate and personal smartphone and tablet used for business, IT can deploy, audit and enforce appropriate security controls.
Typically, IT can use MDM to remotely configure native device settings to reflect security policies, including: requiring a PIN or password; enabling auto-lock and auto-wipe features; encrypting data at rest on the device, removable media or in the cloud; protecting data-in-motion over email, VPN or Wi-Fi; and selectively disabling hardware and OS features such as integrated cameras. When properly configured, these native settings deliver most (but not all) mobile security best practices for personal smartphones and tablets.
As previously noted, supported policies do vary by device make/model and OS. However, mobile device management systems generally try to maximize IT access to native settings. For example, any MDM that supports iOS device management lets IT set every Apple-supported Configuration Profile attribute. MDM-configured controls for Android are more varied because the devices themselves are more diverse. Notably, manufacturers such as Samsung and Motorola have extended native APIs with proprietary attributes to give IT greater visibility, control and flexibility.
Ultimately, mobile security management requires careful analysis of native device and OS features needed to implement policies and confirmation that any MDM under consideration can deliver visibility and control over those features. Where native capabilities are insufficient, MDMs can also help by deploying, configuring and enforcing third-party security measures.
For example, health care organizations often use MDM to centrally deploy two-factor authentication, VPN clients and virtual desktop applications. Enterprises concerned about mobile malware can use MDM to push sandboxed browsers and antimalware. To an MDM, these are simply applications that must be installed and maintained. For this reason, organizations focused on MDM to enable security should also evaluate each product’s application management capabilities.
For small mobile workforces, IT could enroll devices one by one, manually installing required security and business applications, but that does not scale nor does it enable continuous monitoring and enforcement. This is where MDM technology can yield return on investment through logging, auditing and compliance enforcement.
Mobile device management systems can capitalize on their over-the-air access to enrolled smartphones and tablets. Even if devices never return to the office, MDMs can poll them to verify settings and detect events such as PIN disablement or blacklisted application installation. Some mobile devices and settings can be monitored from afar using nothing more than native APIs -- notably Apple iPads and iPhones. Deeper than EAS insight on other devices (e.g., Android, Windows Mobile) usually requires installing a device-resident MDM agent.
Today, MDM vendors publish their agents at the Google Android Market or the Apple AppStore where users can freely download them. Upon installation, agents connect to a corporate MDM server that may be installed on-premises, hosted by a managed service provider, or operated as a cloud service. Thereafter, MDM agents can serve as IT’s “eyes and ears,” logging activities, reporting on events, and carrying out MDM requests that go beyond native capabilities.
For example, it has become common for MDM agents to offer jailbreak or root detection. Jailbreaking or rooting pose business risks because they render the underlying OS unreliable and raise concerns about device integrity. Jailbroken Apple devices are vulnerable to mobile malware downloaded from non-Apple websites. Rooted Android devices are even more vulnerable because applications can access normally privileged features.
By immediately detecting such activity, MDM agents can notify administrators and users. IT can even install enforcement policies that automatically take actions such as disabling email or VPN access or removing enterprise applications or even wiping an offending device. Although available actions are limited by the mobile OS, they can still go a long way towards reducing business risk and encouraging voluntary compliance.
Test drive before buying
Like any other technology designed to assist IT with security enforcement, MDM is a means to an end. Organizations should not expect MDMs to magically keep a mobile workforce secure any more than a firewall can be expected to keep a corporate network safe. MDMs require careful selection, based on ability to meet business needs, implement desired policies, integrate with existing infrastructure and support workflows.
Those workflows and related IT processes should not be left as a post-deployment exercise. Diversity within the multi-platform MDM market becomes most apparent when organizations begin to use products to manage real-world devices. For best results, pilot a few MDM products by attempting to assert and enforce an acceptable use policy on various devices of importance to your workforce.
About the author:
Lisa Phifer owns Core Competence, a consulting firm specializing in business use of emerging network and security technology. She has been involved in the design, implementation and evaluation of internetworking, security and management products for 30 years. Send comments on this article to firstname.lastname@example.org.
This was first published in April 2012