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.
And that is why I do not have a gov supplied cell phone or whatever. I don’t want to be tied to work after 4 pm and I don’t want the responsibility that goes with it. After all, it’s “government PROPERTY”, and anything that happens to that phone, YOU the user are responsible. Our organization turned in all our cell phones, even my supervisor turned in the blackberry. Not worth it. Besides, “wireless” at our installation is but a “dream”. (i.e. NOT HAPPENING). Why? Security reasons. So glad the GS5’s up in DC are cavelier about Uncle Sam providing them with “mobile” technology. DoD is overly “cautious” to the point that NO ONE is going get to upgraded technology, even at the office, even if their mission has absolutely nothing to do with Homeland Security. No Thank You, Uncle Sam, you can keep your phone.
Having worked in IT security for a number of years, the most secure offices are those that ban all computer use. Right. They might as well ban all work. Some risk is always involved. You just try to minimize it, otherwise the nay-sayers would prevent any progress from 1950 technology.
No Federal technology should be developed or implemented if it’s not Section 508-conformant and fully accessible to all persons with disabilities *at the time of development and distribution.* More and more, mobile applications have already been developed without Section 508 conformance or accessibility in mind. Developers and managers have jumped onto too many bandwagons already. It needs to stop until all IT has been re-mediated and no more IT is developed that isn’t inclusive of everyone.
@Ed, you’re preaching to the choir. Our mission requires us to utilized software that is no longer sent to us via CD. We have to “download” it. Not allowed here. Wireless is but a dream.
@Gary. Yes, I see your point. We had to have a fax machine that was 508 compliant. As a gov card holder, I am “required” to purchase or have purchased through the contracting dept., office machines that are 508 conformant. Cell phones in gov., good luck with that. They are handed out like Halloween candy to any gov worker that wants one, especially in DC. (which is ridiculas)
While I appreciate the message that taking time to secure your mobile platform is a worthwhile endeavor, I’m disturbed at the focus on this one platform. The insinuation seems to be “Android is dangerous,” but does that mean that somehow inherently (and magically) Apple or RIM offerings are somehow better?
All mobile platforms have intrinsic flaws. Yes, even RIM. As Ed mentions below, the pendulum of security necessitates an ability to cast a critical eye on what the actual risk to the organization is. And that risk cannot be judged in a vacuum, in my opinion, but must be compared across the spectrum. Because, even in the full prohibition mode, someone, somewhere will cross the line and use a personal device. What do you do then?
What we could be doing, and perhaps should be doing, is encouraging the government (maybe through NIST?) to encourage some standards. In the same way NIST has developed configurations and security parameters for operating systems, maybe they could say “This is how a mobile environment, built to government specifications, should do.”
And then, of course, the neat thing about Android would be, just possible, that someone would take the open source and do it.
I agree with most of what is said here. Android has a whole host of vulnerabilities and enterprise management of the devices, policies and software distribution are problematic. Also the Android phones are not Section 508 compatible (built in accessibility).
Apple with it’s iOS and devices (iPad2 and iPhone 4) are way ahead of anything Android has to offer at the moment. There is “talk” of the government building a hardened version of Android, but I think that would be a mistake.
An important note: This post was written by my friend and associate Bryan Halfpap at our blog at http://ctovision.com When our RSS feeds are consumed here posts by others are frequently attributed to me. I hope to fix that glitch in the near term, till then I wanted to underscore that the brains behind this piece is Bryan. See more of his writing at: http://ctovision.com/author/bryanhalfpap/