Mobile Device Management Solutions Don’t Always Work.

What IT Decision Makers Need To Know.

IT departments use Mobile Device Management (MDM) software to monitor, manage and secure employee’s mobile devices that are used for work purposes.  MDM encompasses a range of products and services that are used and to enforce security policies and protect IT data across multiple platforms.

The widespread increase in use of MDM software is due to the increasing acceptance of BYOD (bring your own device) policies in the workplace. Employees are being allowed to bring their personal computing devices to and from work to enhance flexibility in the workplace and increase employee satisfaction with the company they work for. MDM products also support business-owned devices as well.

MDM Solutions comes with inherent risks.

Because mobile devices are portable they are at greater risk of being lost or stolen; and the information they contain is as well.  Because they can connect to the Internet over cellular networks, transmissions can take place that a business can’t be detected or filter via firewalls or proxies. Mobile devices are usually equipped with many more physical sensors than a typical personal computer, including cameras, microphones, GPS (global positioning service) receivers, accelerometers, etc., and have the ability to pick up information, as well as malicious software from places other than the Internet.

Because of this, a number of risk scenarios could occur:

• Malicious software or hardware may be introduced in a brief physical encounter with the device, such as from a hotel maid when the device is left unattended.
• Sensitive data can be recovered from an unattended, lost or stolen device.
• If the device is powered on when the adversary uses it, information can be recovered from RAM as well as from permanent storage.
• A remote attacker can exploit a software’s vulnerability and gain access to the device, bypassing the operating system’s security.
• Spyware or Trojan horses can invade the device and collect sensitive information, as well as send it to adversaries without exploiting any vulnerability in the OS.
• If the device is connected to an unsecured network, its communications could be intercepted either passively or actively, compromising sensitive information.
• Sensitive information can accidentally be leaked via non-malicious applications such as advertising or social software that detects a user’s location, contact lists or web browsing history.

Although an MDM solution can prevent some of these risks, it won’t prevent all of them.   

MDM Architecture—Apples and Oranges

MDM software enhances the security of a mobile device—it doesn’t change it. The MDM software totally depends on the particular interface of the mobile device’s operating system, and even when the software is similar to the OS platform there are considerable differences between the enterprise management capabilities for each platform.

Furthermore, IT managers can’t carry out arbitrary modifications to the underlying mobile OS platform with their MDM products, nor any commercially supported third-party software. This is different than when managing desktops, where third-party software can run highly privileged code similar to the OS.

MDM products typically come with an on-device agent that is used by an organization’s administrative personnel and an intermediary service operated by the platform vendor. The on-device agent may be hidden in the mobile OS itself, or it may take the form of a third-party application. The platform vendor’s intermediary typically maintains a continuous connection to the devices to facilitate on-demand queries and commands from the organization. If a product includes additional major architectural components in addition to these, they can impact the architecture of the MDM system. In this case IT Decision Makers should ask:

• What happens if this component is compromised by an attacker?

• What happens if it fails and goes offline?

• Who’s responsible for and has insight into this component’s security and reliability—the organization or a third party?

When evaluating an MDM solution, decision-makers must understand its overall network architecture. They should ask:

• How many servers should be deployed on the enterprise network, and what kind of access is needed for services like mail, calendars, and corporate directories?
• What connections from the Internet should servers be able to accept?

MDM servers should be deployed within a network’s firewalls to ensure they have access to the Internet and the organization’s Intranet. IT Decision Makers must understand the product’s components before making a decision to deploy the software. Key questions they should ask include:

• Which product components have access to which cryptographic keys?

• Can the product be configured to increase convenience and still expose the cryptographic keys?

• Do servers use strong, mutual cryptographic authentication, or can messages be spoofed?
• If a client is compromised, what kind of access to the server can command protocols exploit?

If the communications between an MDM’s various components are carried over simple, industry-standard protocols, then the organization’s IT analysts should independently verify vendor claims about the MDM’s trust relationships; this can be done using off-the-shelf inspection tools. If, on the other hand, the product relies on undocumented protocols that are proprietary to the MDM vendor, independently verifying these claims becomes too time-consuming and expensive, and can decrease the product’s interoperability.

MDM software can be used to activate the following capabilities:

Data-at-Rest Protection. Mobile device platforms have a passcode-lock feature that’s used to prevent unauthorized access and encrypt data stored on it.  This protects against improper disclosure of confidential information if the device is lost or stolen.

MDM solutions can ensure that the platform’s encryption capabilities are activated and used in a manner consistent with the organization’s security policies, and that individual users don’t disable them. But these are not the only important factors to consider when encrypting mobile devices. Equally important are to know what data is encrypted and how the encryption keys are created and stored. Key questions include for IT Decision Makers to ask include:

• Is the entire device encrypted, or just specific partitions?

• Are different files and per-application storage areas encrypted individually?

• How are encryption keys derived from the user’s passcode?

• How costly could an offline brute-force attack be?

• Is there a recovery or key-escrow mechanism enabled, and can it be disabled?

• Are encryption keys cleared from RAM when they’re no longer needed?

Whether the entire device, per-application storage areas, or separate storage partitions are encrypted, depends on the mobile OS; managing the platform’s built-in encryption is also dependent upon the particular mobile OS.  In addition to this, some MDM products may encrypt the MDM application’s own data as well. IT Decision Makers should be cautious, because this can’t protect the MDM agent from malicious software running on the device. An MDM agent application is one item among many on the OS, and it can be completely controlled by an attacker who compromises a bug in the OS.

A Remote Wipe.

MDM software provides the ability for administrators to remotely erase a device. This prevents the risk of sensitive data being improperly disclosed; but its effectiveness depends on whether the device is accessible via the network after it’s lost.  Key questions for IT Decision Makers to ask regarding remote wipe features include:

• How thorough is the wipe and how long will it take to complete?

• Is all data on the device erased or just the data associated with specific applications?

• Is the erased data overwritten with zeros, cryptographically made unavailable by erasing a decryption key, or simply unlinked from the file system?

• Is the wipe command restricted to administrators, or can users deploy a remote wipe as soon as they notice a device is missing?

• Can the MDM software be configured to automatically initiate a wipe under certain circumstances, e.g. a large number of failed-authentication attempts?

• Can the MDM software verify that the wipe has occurred?

Application Policies.

MDM solutions allow administrators to create policies that govern which applications

are installed on the mobile device. Decision makers evaluating an MDM product should understand the application-installation policies that the product supports, and if they meet their organization’s mobile security goals.

Key questions for them to ask include:

• To prohibit the installation of unapproved applications, does the product support whitelisting or only blacklisting?

• Can the product also ensure that certain required applications are installed on all managed devices?

• Does the policy identify applications by name only, or can it permit or deny applications through other characteristics like the version, developer ID or certificate, or use of security- sensitive OS services?

It might be desirable for an organization to forbid the installation of any unapproved applications on mobile devices that can track a user’s location or record audio, but still allow applications that don’t use those services. 

Enterprise Application Deployment

Although application deployment isn’t always related to MDM products, some can deploy in-house or approved applications over the organization’s distribution channels. IT Decision Makers should understand the infrastructure involved in setting up application distribution and its impact on their network-attack surface. Key questions to ask should include:

• Is application deployment handled by a separate server on the enterprise network that must be maintained and secured?

• Does this server need to accept requests directly from the Internet, or can the managed devices connect to the network over a Virtual Private Network (VPN)?

It’s also important for administrators to know how much control they have over the cryptographic signing of applications deployed through an MDM product.

Key questions include:

• Does the MDM product sign applications or does it simply distribute pre-signed application packages.

• Does the MDM product verify application signatures before deployment?

• If the MDM signs applications, does it sign them with a dedicated enterprise‑provided certificate that can be revoked without impacting other MDM features?

Version Reporting Capabilities

A basic feature offered by many MDMs is the ability to report which versions of the OS

and applications are installed on each of their mobile devices. Most products should allow administrators to manually query version information via automation and integration.

Key questions to ask include:

• Can the MDM product automatically send alerts to administrators or end-users when a device is behind on security patches?

• Can it automatically revoke the device’s credentials or initiate a wipe, if a device is left   unmanaged or in an unattended state for an extended period of time?

• Does the MDM product offer a scripting interface so that enterprise administrators can create automated reports, alerts, and actions that are customized to their organization’s needs?

User-Initiated Platform Modifications—Can They Be Detected?  

Some MDM products can perform inspections of the mobile OS to detect user‑installed “jailbreak” or “root” tools. Since MDM agents run with limited privileges, they’re unable to detect sophisticated malicious software, but they can sometimes detect user misbehavior that significantly weakens the mobile device’s security.

Virtual Private Network (VPN)

Mobile OSs often comes with built-in support that connects to VPNs; an MDM product can facilitate consistent VPN configuration to all managed devices. Decision makers should understand the capabilities of their mobile OS and whether their MDM product is the right solution for this purpose. Key questions include:

• Can the VPN be configured to connect automatically, or does the user need to manually initiate the connection?

• Once the device is connected to the VPN, does all traffic pass through the encrypted tunnel, or does some traffic still transmit in clear text?

• Can the MDM prevent the user from disabling the VPN?

The mobile OS used should support certificate‑based VPN authentication, so individuals have their own certificate. Questions to ask include:

• Does the MDM have the features needed to manage these certificates?

• Can it automatically revoke a user’s certificate if a security violation is detected, is reported as stolen, falls too far behind on critical security patches, or has unapproved applications installed?

WiFi and Cellular Network Restrictions

Another means of protecting sensitive network communications is to prevent a mobile device from connecting to unsecure networks. Some mobile OSs allow an MDM policy to restrict which WiFi networks or Access Point Names for cellular networks that a mobile device can connect to. Administrators should be able to whitelist specific WIFi networks.

Certificate Trust Management

The security of mobile devices depends on PKI (public key infrastructure) certificates that are used to authenticate VPN’s, websites, applications, and even MDM policies. The OS maintains a list of these trusted certificates that are accepted by the OS.   If an attacker acquires a fraudulent certificate signed by a trusted CA, or makes the OS trust a fraudulent CA, they can intercept, decrypt, and modify all of the device’s communications, and install malicious software.

It’s important that an organizations and IT Decision Makers know the set of trusted CAs. Most MDM products allow an organization to add an enterprise’s in-house CA to the list. Some products may also automatically add a CA associated with the MDM vendor when evaluating

a product.  It’s important to determine whether it can do this and what the impact is on mobile-device security and trusted relationships.  Administrators should also be able to use an MDM solution to remove unwanted CAs and query a device’s trusted CAs.

A Policy Is Needed for Connection to PCs.

Most mobile devices can be connected to a personal computer for transfer of data,

debugging, and for a software installation or update. But when a device is connected to a malicious or compromised PC, this can lead to the compromising of data on the

mobile device as well.  MDM policy should limit the attack surface a device is exposed to when connected to a PC.  This can be done via disabling debugging, requiring a passcode is entered for access, or by limiting which PCs can be connected to the device. Administrators should be able to query a log to determine which PCs a device has been connected to.

No Matter What MDM Solutions You Use, Risks Will Always Remain.

The use of a properly-configured MDM solution can ensure that the built-in security features of an organization’s mobile devices are consistently enabled and configured to meet the their security needs. An organization’s IT Decision Makers should consider MDM solutions when planning a mobile-device deployment. They should also understand that MDM doesn’t add new security features to a platform; it’s simply a way to automate the configuration of security features already provided by the platform. And above all they should understand that there will always be risks to evaluate and to overcome.

For more information about Mobile Device Management, contact our team of mobile computing experts.