NAC and Endpoint Security Management
Securing Android devices with a mobile device security policy
This tip is part of SearchSecurity.com's Integration of Networking and Security School lesson, Strengthening policies for endpoint controls. For more learning resources, visit either the lesson page or the Integration of Networking and Security School main page.
Just as security teams start to get a grip on bring-your-own (BYO) iPhones and iPads, along comes Android devices challenging you to find new ways to enable productive business use without acceptable risk. In this tip, we will look at techniques for securing Andorid devices, including using a workable mobile device security policy and tools that enterprises can use to discover, enroll, protect and monitor employee-liable Android smartphones and tablets. Learn what can and cannot be done to enable safe business use of today's top selling, but less-than-security-friendly mobile devices.
According to Canalys, nearly half of all smartphones shipped in Q2 2011 were powered by Android, making it the most popular mobile operating system (OS) in the world. For enterprises, battling this device surge requires workable security policies and tools to discover, enroll, protect and monitor Android endpoints.
Securing Android: Discovering Android devices
Android runs on various platforms, from handsets and e-readers to embedded devices and home automation systems. But, few Android devices are enterprise-purchased. Rather, most are employee-purchased consumer smartphones and tablets made by HTC, Samsung, Motorola and others. Discovering bring-your-own Android devices is a prerequisite for securing them.
Enterprises that have deployed network access control (NAC) may be able to use that platform’s fingerprinting features to classify device manufacturer and OS version whenever a new Android tries to connect to a LAN or VPN.
Alternatively, enterprises using WLAN infrastructure from vendors such as Aerohive, Aruba, Meraki and others can use those platforms to fingerprint devices that associate via Wi-Fi, supported by most Android smartphones and tablets.
For devices that never connect to the corporate network, enterprise server logs can be searched for unknown Android devices, classified by HTTP or Exchange ActiveSync (EAS) user agent.
Upon discovery, Android devices can be inventoried by MAC address and Android Device_ID (GSM IMEI or CDMA MEID), laying a foundation for policy enforcement.
Securing Android: Enrolling Android devices
Device inventories can be used to block or compartmentalize BYO Androids endpoints – for example, disallowing email synchronization or letting them use an Internet-only guest wireless LAN. Starting with this binary policy is a good way to get a handle on Android usage.
But ensuring safe, productive use of BYO Androids requires enrolling devices that satisfy defined criteria so IT can provision and enforce security measures. One increasingly popular way to accomplish this is with a Mobile Device Manager (MDM).
Using an MDM, administrators can “bulk enroll” inventoried devices, sending email or SMS invitations to affected users. Some MDMs offer a self-enrollment portal that users can visit to generate invitations to themselves. Either way, users end up following a URL to an enrollment page, where they are prompted to log in.
Authenticated users should be mapped to group policies that determine the applications they require, the device types they can enroll, and the conditions that must be satisfied. For example, a sales rep could be permitted to use enterprise apps on his corporate BlackBerry but not on his personal Android tablet. However, his Android tablet might be configured for enterprise email access – but only if the tablet has Android 3.0 data encryption.
Devices that pass muster should be issued credentials (e.g., using the Simple Certificate Enrollment Protocol) and then configured with security settings and applications. MDMs can automate Android provisioning, but users must first download and install an MDM agent from the Android Market.
Securing Android devices: Protection
Early Android devices offered little native security. However, on devices running Android 2.2 or later, IT can require pattern locks, PINs or passwords to deter unauthorized use. IT can also initiate remote lock and wipe commands to reduce risk associated with lost, stolen or retired devices. Unfortunately, an Android remote wipe merely resets the device to factory default – it does not overwrite stored data, nor does it remove data from the SD card.
Android 3.0 offers more granular control over password policies, such as setting minimum complexity or preventing reuse. Android 3.0 also provides remote admin control over data encryption – but only when the device is itself capable. In fact, some employers may choose to severely restrict use of pre-3.0 Android devices.
For some users, even Android 3.0 is not sufficient. In such cases, IT may remotely install third-party security apps – for example, self-encrypting apps. While employees could be instructed to install and configure such applications, automation is more efficient and effective. Enterprise apps can be pushed over-the-air and installed transparently, without user involvement. Public apps can be installed from the Android Market by presenting users with a list of required or recommended apps.
In short, by harnessing the native security capabilities built into Android, combined with third-party apps that support security and business tasks, IT can prepare even a BYO Android device for safe productive use.
Securing Android: Monitoring Android devices
Once a BYO Android device has been provisioned, it is important for IT to keep an eye on the device. Users can still change settings, remove security apps or install their own personal apps, endangering business data and accounts that reside on that device.
To prevent drift, device settings can be checked whenever an Android device attempts to access corporate email or the company VPN. Alternatively, Android devices can be continuously monitored by MDM agents. For example, agents can detect when an Android gets “rooted,” when a blacklisted app gets installed or when a required setting is altered. Agents can not only report these policy violations, but take predefined actions such as removing email and VPN accounts or previously installed enterprise apps.
These techniques can help IT reduce business risk without resorting to wiping (factory resetting) BYO Androids. However, there are limitations – most notably, users can always disable Android MDM agents by removing their “device admin” privileges.
While it might not be possible or practical to eliminate all business risk on a BYO Android device, much can be done to enable safe business use of today's top selling, but less-than-IT-friendly mobile devices.
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.
17 Oct 2011
Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.