Google and Samsung have both made real strides lately in turning Android into a safer mobile option for businesses. But safer is not necessarily safe.
The Android platform still has a ways to go to match the security capabilities of Apple’s iOS-based iPhones and iPads, never mind BlackBerrys.
Due to its fractured capabilities, Android has long been difficult to manage. Coupled with Android’s fewer security and management functions, most organizations have limited Android use to basic email access. iPhones and iPads, by contrast, have emerged as the standard devices at most organizations, supplanting BlackBerry for most users.
The good news: There’s now a common Android management model
There is good news for Android: The new Android for Work technology available in Android Lollipop and, to a lesser extent in earlier Android versions, brings a common security and management model to Android devices from any manufacturer.
Android for Work provides a secure container that IT can manage via a mobile management server, similar to how IT manages iOS devices to go beyond the basic security that Apple provides through Exchange ActiveSync policies. (Google also supports many of the same EAS policies as iOS.)
Google is also experimenting with a variety of password surrogates, such a facial recognition and swipe patterns, meant to make it easier for users to actually lock their devices. Ironically, the password policies in EAS and mobile management servers often prevent users from those approaches, forcing the usual password approach. At least you can enforce the use of a password, even if one is likely to frustrate users.
Samsung is trying to make its Android devices the BlackBerrys of the Android world, with extra hardware security such as kernel and file-system integrity inspection, plus its Knox technology built in to some high-end Galaxy devices such as the new Galaxy S6 and S6 Edge.
Knox 2.4 (but not Android for Work) also now supports bulk enrollment over the air, which the iOS world got in fall 2013, along with a large set of content-management APIs the Android world is only starting to get via Android for Work and Knox.
Android encryption remains a major Achilles’ heel
Android Lollipop was supposed to enable device encryption by default on new devices, but as far as I can tell, no manufacturer is doing that — not even Samsung. Encryption on Android has long been an afterthought, and even in Lollipop it remains both an optional, uninstallable feature and requires a separate sign-in from the device unlock. Since 2010, encryption in iOS has been on by default, integrated with device unlock, and it can’t be disabled.
Encryption in Android — including Lollipop — is also slow, even on high-end devices like the Galaxy S6. On low-end Android devices, it can cripple performance. By contrast, in iOS it’s essentially invisible to users. No wonder Android makers don’t enable encryption by default — their device hardware and the Android OS can’t handle encryption in the invisible way users need.
Yes, you can block access to unencrypted Android devices through EAS or MDM policies, but you can’t prevent users from decrypting their devices. The use of containers such as those in Android for Work and Knox can reduce the encryption penalty, as you can encrypt only those partitions on the device, as well as prevent users from disabling that encryption.
Android apps continue to be a big malware risk
Apple is often strongly criticized for its heavy-handed curation of apps in its App Store, but that has led to a tiny number of malware apps getting into users’ devices. In addition, iOS’s lack of a shared file system, coupled with its sandboxed approach to apps, has contained rogue apps, preventing them from acting on other apps and other apps’ data.
Thus, the risk of malware on iOS centers on apps that use websites and third-party services to capture user data or run up bills — essentially phishing-style attacks that use an app rather than a website to conduct the scam. But these apps are extremely rare. Contrast that with Google’s Play Store, where researchers regularly find oodles of such phishing apps.
Android’s permissions model is insufficient
iOS also has a very strong permissions model for apps, which users can easily check and update each permission for each app. Users can see the permissions used for each app, as well as all apps that use specific permissions, and change those permissions directly.
The permissions are discrete, so users can, for example, allow an app to track their location but not use the microphone. Some sensitive permissions also require periodic reauthorization enforced by the operating system.
Although Google has strengthened disclosure of the permissions apps use, Android provides no permission-management tool for users. Once you agree to give an app a permission, you’re stuck with that set unless you uninstall and reinstall the app. And finding the permissions you’ve granted an app is both difficult and not available for every app.
Inconsistent Android core apps hinder workflow cohesion
One of the advantages of Android is that device makers get to differentiate their products through not only visual skins but also custom app versions.
For example, Google’s Gmail app on its Nexus devices works with Exchange accounts to provide a unified email tool like Apple’s Mail on iOS, but on Samsung, HTC, and other manufacturers’ devices, Gmail does only Gmail, POP, and IMAP email; you have to use the separate Email app for Exchange email. And the Email app varies from manufacturer to manufacturer, with different capabilities.
It’s not Android makers alone that create such variances. Microsoft has two different email apps for both Android and iOS — Outlook and OWA — that work differently from each other, as well as from their counterparts on other platforms.
None of that is bad in and of itself, but it means that email (or calendars or contacts) works differently from device to device. That makes it harder to know what individuals can do and how they can do it. Granted, this is more about consistent workflows that strict security, but the uneven capabilities make it harder to understand security and compliance implications of these “standard” tools that aren’t.
The same situation can exist in iOS, since there are plenty of third-party apps available. But the reality is that every iOS device has Apple’s clients, and those quickly become the workflow standards for that platform, just as Microsoft’s Outlook app is in Windows.
It’s the variations among the “same” apps in the Android ecosystem that cause the difficulty. If, say, Gmail or Email worked the same (and well) on every Android device, then those other apps would not matter — the workflow and support complexity would be no greater than exists in iOS or Windows.