According to market intelligence firm ABI Research, Android devices now exceed those running iOS 2.4-to-1 worldwide....
As a result, many employers are forced to enable business use of devices running what is a consumer-grade mobile OS. Fortunately, Android 4.0 shores up the platform’s native defenses. Here, we consider available methods to centrally assert and enforce security policies on Android smartphones and tablets.
Android malware has surged in the past year, with malware authors taking advantage of Google’s open Android Market and Android’s willingness to “side-load” apps from third-party sites.
Under the covers of Android security settings
Android employs many defenses expected of contemporary mobile operating systems, including sandboxing, code signing, OS-enforced permissions and (new in Android 4.0) address space layout randomization (ASLR). Passwords were added in Android 2.2. Hardware encryption was added in Android 3.0, but only used by tablets. Android 4.0 brings hardware encryption to smartphones as well.
To prevent a data breach via a lost or stolen device, enterprises can enforce password and encryption policies, block business use of non-compliant devices and remotely wipe data from any device that goes astray. These needs are addressed by Android’s Device Administration APIs, which can be used to query and set a number of Android security settings, including password controls (such as minimum length, alphanumeric requirements, symbol requirement, expiration timeout, history restriction, maximum failed password attempts, etc.)
Most of these controls were introduced in Android 3.0; the camera function was added in Android 4.0. As a result, IT may choose to only permit Android devices running 3.0 or later. However, IT must also check the exact device make and model, because even older phones upgraded to 4.0 still cannot encrypt data.
In addition, the Android API can lock a device, prompt for password change, or reset a device to factory default (wiping internal storage but not any removable media where music, photos, and email are stored). Resetting a device to factory default poses no risk on devices lacking removable media, this function may also be a criterion for business use.
Asserting IT control over Android devices
Three methods are available for asserting IT control over Android devices:
The user can directly set a few Android security policies – most notably turning on encryption, a once-and-done process that can take an hour. IT can recommend settings, but this method offers no IT enforcement.
Exchange Active Sync (EAS) attributes can be used to check and set some policies during enterprise mailbox synchronization. Android 4.0 upgrades EAS to v14, which expands policy breadth. However, device diversity hinders EAS control; results vary by make/model. In a typical case, EAS can require a PIN or password, enforce minimum length, set failed attempts and timeout, and reset to factory default.
Every policy in the Device Administration API can be enforced by mobile device management (MDM) agents or other security programs installed on the smartphone or tablet. Typically, the user downloads an MDM agent from the Google Android Market, following prompts to grant permission and visiting their corporate MDM enrollment portal. Thereafter, IT can use MDM to authenticate the user, issue a device certificate, provision the device, and enforce the organization’s policies.
Battling Android malware
Many MDM products offer more IT controls to supplement native Android controls, such as detecting and quarantining rooted Android devices, querying for blacklisted applications, and helping IT remotely install required or recommended applications. These can all help to deter Android malware and supplement Android enterprise security.
Android malware has surged in the past year, with malware authors taking advantage of Google’s open Android Market and Android’s willingness to “side-load” apps from third-party sites. IT’s first defense against malware is therefore visibility into applications installed on any device used for business. For example, MDM can be used to block enterprise access or wipe a device running malware.
IT may also install third-party Android security tools on Android devices, including antivirus scanners, SMS antispam filters, phishing URL checkers, high-risk application scanners, and remote lock/find/wipe utilities. It is common for these security programs to support several functions; however, most are designed for consumer use – only a few cater to IT control.
Creating your own sandbox
Given the diverse device capabilities and the risk of Android malware, IT may opt to create a secure (encrypted authenticated) business environment. For example, secure enterprise messaging applications can be installed to store email, contacts, schedules and tasks in a self-encrypted container. Program settings are usually controlled via EAS or MDM.
Ultimately, there is no shortage of methods and tools to help Android devices meet enterprise security expectations. While these may not fully satisfy every organization’s policies, Android 4.0 and MDM and other security products continue to close the gap.
About the author:
Lisa Phifer owns Core Competence Inc., a consulting firm specializing in network security and management technology. Lisa has been involved in the design, implementation and evaluation of data communications, internetworking, security and network management products for over 25 years. At Core Competence, she has advised large and small companies regarding security needs, product assessment and the use of emerging technologies and best practices. Before joining Core Competence, Lisa was a Member of Technical Staff at Bell Communications Research where she won a president's award for her work on ATM Network Management.