Security Manager's Journal: Android panic
- 29 July, 2013 12:07
A couple of years ago, I implemented a technology that makes iPhones, iPads and Android smartphones and tablets more secure by giving us access control, encryption, passwords and remote-wipe capability. Since then, at a time when smartphone usage at my company was booming, we haven't had any data security breaches related to smartphones and tablets. Although some of those devices have been lost or stolen, such occurrences have never led to a breach, thanks to the ability to remotely wipe those devices. I've loved the peace of mind that has given me.
But now my peace of mind has been shattered.
As the use of mobile devices has grown at my company, our smartphones and tablets of choice have been Android-based phones. They are so much cheaper than Apple products, it has been hard to justify spending a lot more for iPads and iPhones. And our security record with the Android devices has been so good that there was no reason to second-guess that decision.
Lately, the Android platform has come under attack. Serious vulnerabilities have been found in the Android operating system that can compromise devices and the data on them, regardless of any security software that may be running. For example, Google recently released a security update to fix a vulnerability in the Android security model that can be used to plant Trojan horse malware in regular applications, which an attacker can use to break into the device and steal data. Known as the "master key" vulnerability, this particular security hole has been lurking around undetected for the last four years. Google's fix isn't permanent, though. And now a second master key vulnerability has been discovered.
If the underlying operating system isn't secure, the security software running on it can be bypassed or compromised, so there's no longer any guarantee that data on Android-based smartphones can be protected. This comes as some surprise, because open-source operating systems like Linux, FreeBSD and OpenBSD have historically been more secure than proprietary operating systems like those made by Apple, because there is a significant amount of review that happens for every line of code in the operating system, as well as the entire architecture and security model. But this doesn't seem to be the case with Android. And the apps themselves are not controlled or tracked, so attackers can put malware-laced software on the Android Market with impunity. And I don't have a very effective way to control what apps my users download. If people download malicious apps from the Android Market, my company's data might be put at risk.
In addition to the risks posed by the attack surface of the Android operating system and the apps that can be downloaded from the Android Market, we have to worry about malware as well. Malware attacks on Android devices are on the rise. As a result, antivirus software is now a necessity on Android devices. And my experience with antivirus software has not been good. On many occasions, I have experienced zero-day infections on Windows systems on my company's network that the antivirus software was not able to contain. So I've built a complex array of network-based and host-based security products for a multilayered defensive strategy to compensate for the shortcomings of antivirus software. I don't have the same options on Android platforms.
So what do I do now? My company has already invested a substantial amount of money in Android-based smartphones, so I have to decide what position to take on those pre-existing devices. And as each day passes and more security problems are found with the Android platform, I'm beginning to think my position is going to have to be against Android. If that turns out to be the case, then not only will I lose face by reversing my earlier position supporting the use of Android smartphones and tablets on my company's network, but I'll also incur a significant cost to replace those Android devices by switching to Apple. And that's a real dilemma.
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at email@example.com.
To join in the discussions about security, go to blogs.computerworld.com/security.
Read more about security in Computerworld's Security Topic Center.