- A TechNote on Wireless and Mobility
- Lisa Phifer, President
- Core Competence, Inc.
Many enterprises ban business use of Android, citing risks associated with consumer-grade smartphones and tablets. But Android has been making strides in both its market share and its range of capabilities. According to Google, more than 200 million Android devices have been activated worldwide, and there are 700,000 new activations every day. With November's Android 4 (Ice Cream Sandwich) release, the time may have come to carefully relax restrictions. Here's why.
Making Friends with IT
PIN/password lock, remote wipe and Exchange Active Sync (EAS) support have been around since Android 2.2. For some employers, these rudimentary security capabilities were enough - especially when paired with a self-encrypting messaging application such as Good for Enterprise or Nitrodesk Touchdown.
But Android has steadily expanded its Device Administration API, letting third-party applications - notably mobile device management (MDM) agents - set and query security policies from afar. Android 3 (Honeycomb) added more granular password policies and full device encryption, but these functions were supported by only a handful of new Android tablets. Android 4 brings these policies and others to new smartphones such as the Samsung Galaxy Nexus.
Android 4 also adds a new keychain API that applications can use to install and store user/device digital certificates and trusted enterprise certificate authorities. And it upgrades EAS to version 14, allowing IT to permit/deny Android Exchange Server access by certificate and device make/model and to disable potentially costly EAS synchronization while roaming.
Employers who want to move beyond secure messaging will appreciate Android 4's broader native IPsec and L2TP VPN clients, as well as its new VPN API, which supports third-party VPN clients (e.g., Authentec). To control ever-increasing mobile broadband usage, Android 4 can graph and alert or cap bandwidth consumption over defined periods.
Finally, employers wanting to develop enterprise applications will find Android relatively open, supporting IT-initiated local and over-the-air package installation ("side loading") independent of Google's Android Market. To deter malicious apps that might be installed from elsewhere, Android 4 adds Address Space Location Randomization (ASLR), which makes it harder for malware to successfully compromise Android devices.
Still Playing Catch-Up
While these administration and security improvements will increase enterprise tolerance for Android, the mobile OS platform still has a ways to go before catching up to Apple iOS, much less BlackBerry.
For starters, Android still lacks native MDM; users or IT personnel must install their chosen MDM agent before an Android smartphone or tablet can be centrally managed. And the user can always remove that agent - although doing so may trigger action to remove MDM-installed enterprise accounts and applications.
After installation, that MDM agent lets IT check for rooted devices, query/set policies (as of Android 4, including camera disablement) and query, install, update or remove applications. However, Android's permissions model requires that the user explicitly accept or cancel each application installed. This less-than- transparent experience results in users having to blindly accept everything - including potentially harmful public apps downloaded from the Android Market.
Why should this worry IT? Unlike Apple, with its tight-fisted control over its App Store, Google does not deeply vet Android Market apps, nor does it require that developers sign code with a Google-issued certificate. Instead, Google relies on the open-source community to raise red flags when malware appears on the Android Market. When risk warrants action, Google can remotely remove installed apps from infected devices, as it has done several times, starting with DroidDream Android trojans back in March 2011.
Closing the 'Trust Gap'
Due to this policing of the Android Market, most Android malware to date has been distributed through unofficial third-party markets. And alternative markets such as Amazon's and Verizon's are popping up to fill this "trust gap" with more rigorous reviews. Still, IT may be concerned about Market downloads and cautious about what's installed on Androids used for business.
To that end, requiring that new devices support full-device encryption, ASLR and no removable media can help limit Android malware's reach while avoiding data breaches due to lost or stolen devices. Some manufacturers, such as Samsung with its Samsung Approved for Enterprise (SAFE)-certified program, add proprietary device attributes to enable even more granular IT visibility and control.
Unfortunately, these advances don't yet apply to the vast majority of Android smartphones and tablets. It will take time for manufacturers and carriers to complete Android 4 upgrades for pre-2012 devices - and many will never be upgraded. For now, IT may be wise to more fully embrace the currently emerging generation of Android 4 devices, while still granting narrow or no business access by their older, less capable, higher-risk predecessors.
Making Friends with IT
PIN/password lock, remote wipe and Exchange Active Sync (EAS) support have been around since Android 2.2. For some employers, these rudimentary security capabilities were enough - especially when paired with a self-encrypting messaging application such as Good for Enterprise or Nitrodesk Touchdown.But Android has steadily expanded its Device Administration API, letting third-party applications - notably mobile device management (MDM) agents - set and query security policies from afar. Android 3 (Honeycomb) added more granular password policies and full device encryption, but these functions were supported by only a handful of new Android tablets. Android 4 brings these policies and others to new smartphones such as the Samsung Galaxy Nexus.
Android 4 also adds a new keychain API that applications can use to install and store user/device digital certificates and trusted enterprise certificate authorities. And it upgrades EAS to version 14, allowing IT to permit/deny Android Exchange Server access by certificate and device make/model and to disable potentially costly EAS synchronization while roaming.
Employers who want to move beyond secure messaging will appreciate Android 4's broader native IPsec and L2TP VPN clients, as well as its new VPN API, which supports third-party VPN clients (e.g., Authentec). To control ever-increasing mobile broadband usage, Android 4 can graph and alert or cap bandwidth consumption over defined periods.
Finally, employers wanting to develop enterprise applications will find Android relatively open, supporting IT-initiated local and over-the-air package installation ("side loading") independent of Google's Android Market. To deter malicious apps that might be installed from elsewhere, Android 4 adds Address Space Location Randomization (ASLR), which makes it harder for malware to successfully compromise Android devices.
Still Playing Catch-Up
While these administration and security improvements will increase enterprise tolerance for Android, the mobile OS platform still has a ways to go before catching up to Apple iOS, much less BlackBerry.
For starters, Android still lacks native MDM; users or IT personnel must install their chosen MDM agent before an Android smartphone or tablet can be centrally managed. And the user can always remove that agent - although doing so may trigger action to remove MDM-installed enterprise accounts and applications.
After installation, that MDM agent lets IT check for rooted devices, query/set policies (as of Android 4, including camera disablement) and query, install, update or remove applications. However, Android's permissions model requires that the user explicitly accept or cancel each application installed. This less-than- transparent experience results in users having to blindly accept everything - including potentially harmful public apps downloaded from the Android Market.
Why should this worry IT? Unlike Apple, with its tight-fisted control over its App Store, Google does not deeply vet Android Market apps, nor does it require that developers sign code with a Google-issued certificate. Instead, Google relies on the open-source community to raise red flags when malware appears on the Android Market. When risk warrants action, Google can remotely remove installed apps from infected devices, as it has done several times, starting with DroidDream Android trojans back in March 2011.
Closing the 'Trust Gap'
Due to this policing of the Android Market, most Android malware to date has been distributed through unofficial third-party markets. And alternative markets such as Amazon's and Verizon's are popping up to fill this "trust gap" with more rigorous reviews. Still, IT may be concerned about Market downloads and cautious about what's installed on Androids used for business.
To that end, requiring that new devices support full-device encryption, ASLR and no removable media can help limit Android malware's reach while avoiding data breaches due to lost or stolen devices. Some manufacturers, such as Samsung with its Samsung Approved for Enterprise (SAFE)-certified program, add proprietary device attributes to enable even more granular IT visibility and control.
Unfortunately, these advances don't yet apply to the vast majority of Android smartphones and tablets. It will take time for manufacturers and carriers to complete Android 4 upgrades for pre-2012 devices - and many will never be upgraded. For now, IT may be wise to more fully embrace the currently emerging generation of Android 4 devices, while still granting narrow or no business access by their older, less capable, higher-risk predecessors.
As the world moves closer and closer to a wireless residence and business universe, it will be interesting to see how much confidence the public can rely, that their data is safe. Hopefully, the new levels of security “built into” IPV6, will also bring added levels of genuine confidence to the consumer and business environment alike.