Android in the Enterprise: A Roadmap: Phase 1

There has been a lot of discussion recently regarding Google's Nexus One and whether or not it is a suitable device for enterprise use. Instead of answering that question directly, I will discuss the broad requirements that most enterprises must satisfy before allowing mobile devices to connect to IT services.

Mobile devices must be able to connect to enterprise messaging systems. Though the best mobile platforms have moved beyond being just messaging tools, email is still the killer application for mobile devices and support for enterprise messaging systems should be a core part of any enterprise grade mobile platform. To be specific, deep support for Exchange ActiveSync (EAS) is required. EAS is becoming the de-facto standard for syncing email and personal information manager (PIM) data to mobile devices, and is supported by Lotus Domino, Google Sync, and others in addition to Microsoft Exchange. The EAS protocol even supports pushing security policies to the device over the air.

Many of the articles and blogs around the topic of Android in the enterprise have focused on the inherit ability of the phone to be secured and managed by enterprise IT. Google has designed a security architecture for Android that is focused on ensuring that applications running on the platform adhere to specific security policies that govern access to private user data, data owned by other applications, and device resources such as network access, Bluetooth access, etc. You can read more about the Android security model here.

This security model, however necessary, solves a qualitatively different problem than the security burden placed on IT personnel charged with implementing a mobility solution for their organizations.

Enterprise IT's primary mobile related security threat is physical loss of the device. Therefore a robust device loss protection (DLP) solution is required to address this problem. At minimum, most sophisticated IT organizations require that mobile device platforms provide the following capabilities before being allowed to access enterprise resources:

• Device Lock, i.e. a PIN or alphanumeric password is required to unlock the device

• Data-at-rest encryption for all sensitive corporate data and in some cases personal data

• Remote wipe capability, i.e. a remote wipe command sent via an IT administrative console to destroy data in the event of device loss

• Local wipe policies, to destroy data after a given number of failed unlock attempts--i.e. Enter a PIN five times, the device automatically wipes all data

• A mechanism to ingest a security policy configurations from a mobility management system

Here I'll propose a simplified hypothetical Phase 1 roadmap for the Nexus One, and Android writ large, to become an enterprise class mobile platform.

Support for Exchange ActiveSync

Exchange ActiveSync is supported by most major mobile OS platforms, including iPhone OS, Windows Mobile, Symbian, and the Palm's webOS. Some Android handsets do support EAS, but those have tended to be handset vendor specific implementations, namely from HTC and Motorola. The Android platform itself is behind the curve here and should accelerate investment in EAS as a core platform capability.

• Exchange ActiveSync 2.5 and 12.1 and later

• Email Sync

• Contacts Sync

• Calendar Sync

◦ Ability to accept meetings

◦ Ability to Schedule meetings and send invites

• Security Policies: PIN, Encryption, Remote and Local Wipe

Device Loss Protection

Device loss is, at this time, the top mobile computing security threat faced by enterprise IT organizations. Therefore device loss protection mechanisms should be a core component of a comprehensive security model built into enterprise class mobile computing platforms.

• A robust PIN and/or alphanumeric device lock facility to prevent unauthorized access to the device itself

• Robust and transparent data-at-rest encryption

◦ Fast, seamless

◦ Multiple entropy, e.g. user's PIN as entropy, with PIN caching to allow for background sync while the device is locked

• Remote wipe: respond to remote wipe commands

• Local wipe capabilities

◦ Based on number of failed password attempts

In a follow on post, I'll propose an extension to the roadmap to include device management, and enterprise integration.