Government Android Should Concern You

Android exploits present a problem for enterprise and Gov’t adoption of Android

Android is a great mobile computing platform. It’s extensible, fairly easy-to-use (considering its plethora of features), has a great application store with hundreds of thousands of applications, and connects back with everything in Google so that all of Google’s information and services are at the users fingertip. For developers, it’s a very extendable platform which is able to integrate code from a variety of languages, run C programs, and deploy applications easily to users.

This combination of versatility, extendability, usability, and many features are a few reasons why Android has a significant market share in the mobile computing industry. These great features are also the things attracting enterprise users, including the government.

But something is becoming increasingly clear to security researchers. There are some very serious security issues with this platform. They are so serious the government should think twice before rushing to Android as a most favored mobile platform. In fact, a case can be built that it should be excluded from government use unless guidelines are followed in order to mitigate the issues.

Bottom line up front: If you are going to use Android, use it with a well thought out Mobile Risk Management solution.

Here is more to ponder:

Android is supposedly secure from the ground up, running a Linux kernel (with many adaptations), a walled-garden application model, system architecture to increase security (DEP, ASLR), application permissions, and more. Unfortunately, holes or bypasses have been found in nearly all of these security features. Some, like the application permissions model, may require significant overhauls in order to maintain security. For more on Android security, please use the Crucialpoint contact form in “Contact Us” to request access to the “Current State of Android Security” whitepaper.

The security of the platform in question is not just notable for what has been broken or evaded, it’s notable for what it does’t include: fine-grain enterprise management and mature management tools. Android from its inception has been primarily a consumer device and its somewhat meager corporate tools reflect this path. As the operating system grows, it has been adding new management/control features in order to allow its use in corporate infrastructure, but these features are still growing. Enterprise adoption of the platform has thus been low and slow. It doesn’t yet provide the myriad of options that blackberry does, and it doesn’t have the level of integration with existing corporate services either. These features need to be built into the core of the operating system and its management tools.

Android devices have also had a notoriously difficult update process, with devices waiting months or years to receive critical patches or version upgrades from service providers and/or manufacturers. Government devices need to be kept to a higher security standard and as such should receive patches at-pace. Android devices are computers, and they should be treated as such.

Government adoption of Android should meet these requirements in order to securely implement Android:

• Hardware that will be able to run next-generation Android versions
• Ability to push patches and upgrades
• Require vendors to have a quick patch turnaround (a few weeks instead of months, like Google Nexus devices)
• Management and Policy deployment platforms (such as Fixmo Sentinel)
• Support contracts from vendors or in-house Android support
• Release of patches back into Android Open Source Project
• Disablement of the Android Debug Bridge
• Encryption or Encryption Services (such as SafeZone)

Admittedly, most of the infection vectors for android require the ability to install malicious applications, a feature which can be easily disabled with simple policy, but some common application exploits are available for Android as well. Physical access to a device can also give other attack vectors to motivated criminals or state actors, and given the ease with which phones are lost, it isn’t beyond the realm of possibility that phone would get misplaced or stolen, hacked, and then returned to the user.

Android may be the most common, most easily extendable platform, but with its security concerns, very careful planning is recommended so that mistakes aren’t made in its deployment.

A concluding caution: There are issues in closed approaches to mobile as well. And some of those might even be harder to fix. With this article we wanted to focus a bit more on Android because the Government seems to be rushing there. The key point is that any mobile system will require the right planning and systems to be put in place. When it comes to Android, the versatility and ability to modify Android will prove to be an asset to the Government — so long as it is properly managed and as long as security is part of your architecture.