How to protect smartphones and tablets

Managing mobile devices entails a level of complexity unheard of in the traditional enterprise world of Windows desktops. MDM software needs to control devices from multiple manufacturers, running different versions of as many as five operating systems, tied to carrier networks with their own particular constraints.

This makes mobile device management a tough battle, but one that IT execs need to take on because mobile device users can lose important company data, potentially increase personal and organizational liability, and compromise systems security at levels that will frighten even the most jaded of IT administrators.

We set up a comprehensive test that included eight mobile devices, four operating systems, two service providers and five mobile management vendors (see How We Did It).

Fiberlink's MaaS360 is our Clear Choice Winner, based on its strong overall performance, particularly its ease of use. But the competition was tough. McAfee's Enterprise Mobility Manager delivered excellent security features. Tangoe's MDM displayed a strong methodology for managing fleets of devices. Sybase Afaria supported a huge list of devices, but was difficult to configure and use.

We tried WaveLink's MDM offering, but it was incomplete in most smartphone operating system coverage and still mostly in beta at deadline time (see sidebar).

We also invited MobileIron, Symantec, Novell and BoxTone, none of which could summon resources. Apple declined to "support the review,'' but we obtained our own Apple testing resources. We asked Verizon, T-Mobile and Research in Motion for assistance with the test, and RIM was the only vendor of the three that helped out.

MDM Basics

Mobile device management tools use agents to control end user devices in the classic client/server model. Agents can be specific to the operating system version (and vendor) or use Microsoft's ActiveSync or an API-compatible version, like NotifySync.

Since mobile devices can be cracked, via rooting (Android OS) or jailbreaking (Apple iOS), MDM tools should be able to detect whether that has occurred. In our testing, Fiberlink and McAfee were able to detect that a device had been cracked and then blocked the cracked device. Fiberlink's MaaS360 went one step further and tried to remediate the nature of the crack.

This is important since device administration is done by agent control, and with a cracked device the end user has gained control. You want to be able to thwart those efforts to change settings and policies.

Unlike the traditional desktop world, where agents are pushed to the end user from a management console, agent installation can take many forms. Some devices come with the agent already installed (example: a phone already has Microsoft's ActiveSync or equivalent); sometimes the end user has to go to an "app-store" and download the agent, and sometimes there's simply a link to an MDM management server URL.

Devices may also be connected via Wi-Fi, instead of a telecom carrier, and we tested both ways, where meaningful.

The installed agent then assesses the client mobile device and policies are enforced. The details are largely common to all mobile devices:

• Once an agent is installed, it performs an evaluation of the phone's state, software inventory, configuration settings, and other characteristics.

• The collected information is relayed to the MDM server, where controls are matched to desired settings for the specific device and its user.

• In turn, messages are sent (pushed) to the mobile device agent software to change the phone according to the MDM application policy settings.

• Periodic conversations with the MDM "mothership" server then update the phone, its policies, and fleet inventory as desired.

It sounds simple, but it's not because each MDM vendor must make sense of the variances among smartphones and other mobile devices, their operating systems, possible carrier-imposed constraints, plus react to ongoing user changes, as well as operating systems changes (including patches and fixes).

All of the products that we reviewed were able to test phone configuration data, lock down features from user manipulation, require PINs/passcodes, as well as remotely wipe phones or change PINs.

Digging into mobile device management

Some also allowed users to remotely change a phone's PIN — a handy but dicey feature if MDM server security is compromised. Most can lock out use of a smartphone's camera. Some have the ability to push applications to phones; this requires deeper capability, as applications are required to be digitally signed to make it to the Apple iOS and Android platforms.

Here are the individual product reviews:

McAfee Enterprise Mobility Management (EMM)

McAfee EMM was strong and cohesive, but doesn't support BlackBerry devices. Administrative access is performed through a Microsoft Silverlight GUI tied to Microsoft IIS, and clients use an agent that uses certificates to add in a layer of security.

We were impressed by McAfee's control of Apple's iOS devices. EMM uses an Apple Enterprise Push Certificate to send communications and applications to compatible Apple devices like other MDM applications we tested. (An update that arrived past our testing phase allows EMM to push certificate signed (aka "enterprise") applications to phones, allowing McAfee to serve as its own "application store.")

We hosted the McAfee EMM in our network operations center on Windows 2008 R2 Server virtual machines (along with Microsoft SQL Server 2008). In addition to iOS, McAfee EMM supports Windows Mobile (not WM7 as of our testing); Motorola Android 2.2+, Android 2.2, Android 2.1 (manually, no agent download) but not Android 3/Honeycomb; and doesn't have support directly for BlackBerry although third-party ActiveSync-compatible agents may work (not tested).

We had a choice of three security models, Basic, Enhanced, and Simplified Deployment. In the Basic model, the McAfee EMM IIS components are installed on a single server/VM, and this server must be connected to Microsoft Active Directory or Lotus Domino and be able to connect to the SQL Server. We used this model for testing.

The Enhanced security model uses two servers; one contains a device management gateway, EMM portal, compliance filter, and EAS proxy on the public-facing Windows IIS Web server, while the EMM hub is installed on an internal server on a private subnet; communications between the two uses SSL.

Operations

Users provision their phones by downloading an agent app from a URL. Apple iOS users download an app from Apple's app store, and Android 2.2 users download an app from Google's Android market. HP Palm/webOS users can use their ActiveSync account. Once we logged on, the agent added our Exchange account, imposed policies and let us download recommended apps.

We found and used basic Starter policy, the default policy applied to users who aren't in groups covered by other policies. We then examined EMM policies. Once installed, agents assume the role of administrator (a root role), then direct actions where policies are chosen. Policies can mandate configurations, such as whether a PIN/passcode is required. The choices are staggering; some are common to all mobile devices, while others are specific to an OS version or carrier feature payload.

In order for an EMM policy to be applied, one must click the Publish button. This must be done each time settings are changed and saved. We found that the policies only allow you to provision apps based on Active Directory (or Domino) user groups and then mobile device type. But there doesn't seem to be any way to provision apps, for example, to control only iPads vs. iPhones.

Mobile devices not meeting security policies can be blocked from communicating with the EMM server. This means that remediation has to occur outside of the EMM application's auspices. Our jailbroken devices were detected, but the rooted Android devices weren't blocked. Certain phones that don't support hardware encryption, like older Android phones, can also be blocked.

The admin console uses policy tabs for compliance, membership, passwords, restrictions (limited to iOS or WM5/6), VPN settings, and Wi-Fi constraints. Policies based on restrictions were easy to set, although many general restrictions were specific to iOS. Policies can be applied to one or more groups, so for example we could publish policies that controlled VPNs, restrictions, password requirements, etc., based on group membership.

EMM can push application payloads that users optionally accept. These might be line of business, or other apps that are organizationally-licensed. However, Android packages can only be delivered from the Android Market. IOS devices can get multiple package types, Mobileconfigs, App store apps, enterprise apps and Web clips.

WebOS users can choose from CAB files (standard WebOS app rollups) and third party apps are supported. EMM can also push and install PocketPC or smartphone editions for WM5 or WM6, with either third party app or CAB files for Windows Mobile users.

Operations

EMM also delegates administration to different user types, starting in rank with System Administrator, then Helpdesk and Policy Administrator, and Reports Viewer. The administrative GUI was easy for us to understand and use.

Reports were somewhat limited, although there's a lot of data that can be exported using tab-delimited format to be subsequently churned by external applications. We had no trouble doing this. The "canned" reports consist of an audit log, Compliance Status, Package Deployment, User List, Unregistered Devices, and Pending Actions report.

EMM also has a Help Desk section that shows excellent drill-down detail — but isn't a report generating mechanism. Unlike EMM reports, in this section you can actually search for users, models, phones. Also you can perform actions on each device, like wiping, locking, reset password, delete email and PIM data, uninstall, delete, etc.

Summary

McAfee EMM was quite easy to setup and use. It heavily favors iOS devices, and has a consistent and understandable user interface. Compared to other MDMs we tested, it had fewer policy options and had weaker support for Android overall. Reports were a bit weak, but from a day-to-day administrative perspective, it worked well with few unhappy surprises.

Tangoe MDM

Tangoe's MDM is a SaaS-based or self-hosted product, and we chose SaaS hosted by Tangoe. The time to usability was reduced by not having to provision our own servers, and link the pieces together. Tangoe uses LDAP and Active Directory to bridge a host network into a discrete instance of Tangoe's MDM application.

As with all SaaS applications, customers have to trust Tangoe's infrastructure to withstand outages, attacks and interruptions, but Tangoe apparently has several customers with fleets in excess of 10,000 users.

Support for mobile devices was broad, but did not include HP Palm although Tangoe says they can manage Palm through ActiveSync. Tangoe supports BlackBerry 4x-6.x, Android 2.1/2.2, Apple iOS 3.1.3, 4.0.x ,4.1.x, 4.2.x and Windows Mobile 6.1/6.5. Phones that use Exchange 2007/2010 or Good Mobile Messaging 6.1 for ActiveSync agent use are supported and indeed there are versions of iOS, Android, and Windows mobile that need this to work. Tangoe integrates with the BlackBerry Enterprise Server, which is required to implement policies for BlackBerry devices.

Despite the rapid link-up, there was still work to do to bring Tangoe up to speed. We installed a required Apple Push Network Certificate for communications to Apple iOS devices. We setup users via ActiveDirectory. We added Microsoft Exchange 2010 configuration. Tangoe can also manage BES, AD, and Exchange for you.

Provisioning

Users can provision their own phones through the Tangoe Web page portal, and it's also possible to reset the device or change their password remotely. We could also set the Tangoe-hosted Web pages that instruct the user how to install everything on their phone or mobile device.

This can be sent as a link or via SMS. Apple's iOS and Android require an app be installed whose instructions will be shown on the website that the user logs into. BlackBerry devices don't require an app because they're controlled by the BES server. All the Web-based instruction screens for each type of device can be modified by the admin (in case they want to have customized layout or instructions) in the configuration section of the management Web portal.

Tangoe Policies

The only policies that can actually be configured within the Tangoe MDM are the Apple iOS policies, as BlackBerry policies are a function of the BES server, and ActiveSync device policies control Android devices.

Policies can be applied to users based not only on LDAP criteria, but by device, carrier, free memory available, and many others.

Tangoe can block a specific version of an Apple iOS device, but there's no way for Tangoe to detect jailbroken iPhones or rooted Android phones. We're told that Tangoe will remedy this in future releases.

We successfully pushed apps to mobile devices, but it wasn't easy. Apple iOS apps need to be signed with an Enterprise Apple Push Notification Certificate. The instructions aren't clear, but we did find that the file extension is key to what can be downloaded to what kind of mobile device. For example, you can send Android ".apk" files to Android, but not to iPhones, where the extension is meaningless.

Reports and Audit