Managing Android Tablets, Smartphones

The Android mobile operating system has matured into a force to be reckoned with, but enterprise use poses significant management and security challenges.

Here comes a rapidly-expanding pack of Android smartphones and tablets, nipping at the heels of Apple’s iPhone and iPad. From Samsung Galaxy Nexus to Motorola Droid Razr, Android devices now dominate sales and are forcing their way into the workplace. Alas, while Android smartphones and tablets can boost productivity and job satisfaction, these unruly upstarts are far more diverse than Apple’s and much harder for IT to control.

But don't despair; help is on the way. IT pros can use nascent device management interfaces embedded in Android 2.2 (Froyo) and 2.3 (Gingerbread) to enforce basic policies today while preparing to leverage Android 3 (Honeycomb) and 4 (Ice Cream Sandwich) extensions. Let’s look at what Android’s native management and security can and cannot do – and how to backfill critical gaps.

Meeting Basic Enterprise Needs

The open source Android operating system was originally designed to appeal to consumers. It was not until Android 2.2 that basic enterprise requirements for managing risk associated with loss or theft were addressed.

Specifically, starting in 2.2, users and IT could configure device PINs, passwords and inactivity timeouts (Figure 1). Under the covers, IT could also set minimum password length, limit password failures and stop an unprovisioned phone from synchronizing with Exchange.

Additionally, either users or IT could reset an Android to factory default, rendering any data on the device inaccessible but leaving any SD card data intact. Although referred to as remote wipe, stored data is not over-written and email attachments, photos and other sensitive data may well be left on a “wiped” Android’s SD card.

For smartphones and tablets running Android 2.2 or later, IT can enforce these basic policies in two ways: by configuring Microsoft Exchange ActiveSync (EAS) mailbox policies or by installing an Android app that uses a native Device Administration API.

As explained in Part 1 of this series (Effectively Securing Mobile Devices), EAS is best viewed as an inherently limited starting point. This is doubly true for Android, where the small set of mailbox policies that can be accessed and their actual impact vary by device manufacturer and model. For a complete list, consult this Google Help document.

Fortunately, more comprehensive controls are available for those that need them.

Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. Since 1997, Lisa has reviewed, deployed and tested mobile policies and practices, ranging from wireless/VPN security to device/data defenses.