Sunday, December 15, 2013

Android's actual security risks


If you're an Android user -- or want to be -- you've likely heard about all the security risks of Google's mobile operating system. But how real are these threats, and how much damage can they do? Despite the fears, are Android devices actually a safe bet for an enterprise mobility strategy?
These are key questions for any organization thinking about a broad Android rollout or even simple acceptance of Android devices in a BYOD context. The answers may not be what you expect.
Android's two fundamental risks
The Android ecosystem has two main security risks, according to mobile security experts:
  • The Google Play Store
  • The fragmentation of devices and OS versions
The Google Play Store's risks. Android is a truly open OS, and that makes it risky, says Andrew Borg, research director for enterprise mobility and collaboration at research firm Aberdeen. "Unlike Microsoft Windows Phone or Apple iOS, there is no walled garden, and this leads to potential security vulnerabilities when not managed coherently," Borg says.
Google Play (formerly called the Android Market), the digital distribution platform for applications for Android devices, is itself a source of potential security risks. "With Google Play, there is a higher percentage of apps that contain malware, or social engineering to connect to malware, than any other app store by an order of magnitude," Borg says. "It's not a well-policed environment, and these factors continue to create friction or resistance toward greater adoption of Android in the enterprise."
When users download apps from Google Play, they often don't pay attention to the extent of permissions an app can have on their device, says Chandra Sekar, senior director of the Mobile Platforms Group at Citrix Systems, a provider of cloud-based mobility and collaboration products. "They usually just accept the permission during installation," he says. "And more often than not, apps ask for more permissions than they really need."
The security vulnerabilities affecting Android devices can cause actual performance issues and data loss -- not just minor inconveniences.
Borg tells of a demonstration he saw at a conference that gave him the "willies." The demonstrator, a white hat hacker, took an out-of-the-box Android device and downloaded a game called Very Angry Birds, basically a clone of the popular Angry Birds game, from an app store. "The device had the latest McAfee and Symantec security for Android, but the game contained malware that neither solution flagged," Borg says.
Everything looked fine, and once the game opened nothing changed on the device. "Then the demonstrator took out a laptop and was able to bring up a control stream where he could see all the smartphones that had downloaded the game and could inspect them and see all the emails they had downloaded."
He then put the Android device to sleep and took a picture from the device remotely using the laptop. "Normally, you hear a shutter sound, but this [malware] had turned off the audio," Borg says. "It took pictures and video, and all along it looked like the device was asleep."
For Borg, such examples justify IT's strong aversion to Android, despite its huge popularity among users. "This is a clarion call that security cannot be taken for granted. I don't think these [Android security] issues are overblown."
The risks of Android's fragmentation. The Android platform also suffers the issue of fragmentation -- there are multiple versions of Android in the market, even on current devices. Manufacturers often make their own changes to Android, so they could be behind Google's current reference release. In addition, carriers and manufacturers may not update their devices' Android version when Google does, or they take months or even years to do so.
As a result, many people within the same organization might be using outdated versions that could be riddled with security vulnerabilities. "People focus on malware risks of Android, but arguably the greater risk is that fragmentation creates different user experiences," says Ojas Rege, vice president of strategy at MobileIron, a provider of enterprise mobility management products. "This variety of user experiences makes it hard to educate your employees about how to take security measures, because the experience on each device is different."
Research shows that a majority of Android device users worldwide have devices with noncurrent versions of the OS, says Bob Egan, chief analyst at consulting firm Sepharim Group. "Some of the phones and OSes have very public weaknesses on security," he says.
If users have older versions of Android, that could mean vulnerabilities are left unpatched and new features of the OS won't reach them. "Maybe you can address the security holes for the HTC One, for example, but that might not apply to an older Samsung device," Borg says. The fragmentation issue multiplies the attack surface; thus, there's no single security solution that will fit all of Android's variations, he says.
Some Android risks are overstated -- and others are underestimated
Experts note that some Android risks are overstated, while others don't get enough attention.
Although Citrix's Sekar says fragmentation doesn't receive enough focus in security assessments, he considers Android malware fears overblown. "Traditional antivirus software vendors often hype up the threat of Android malware," he says. While these threats exist in isolated scenarios where users access apps from untrusted, private stores, the threat to enterprises from malware is overstated, he says.
Another Android risk that's overstated is tapjacking -- when an invisible application on top of an app manipulates key gestures to make purchases without the user's knowledge, says Scott Kelley, Android product manager at AirWatch, a provider of mobile device management (MDM) products.
But one risk that's often overlooked, Kelley says, is users' willingness to tap the Accept button for whatever permissions an app requests. "This is compounded by developers' often overzealous permission requests, due to a lack of understanding of which permissions an app needs," he says. "Apps should request the least number of permissions possible to function appropriately, and users should be in the habit of not automatically granting permissions to apps whose functions wouldn't seem to need them.

@@published at InfoWorld.com


No comments:

Post a Comment