Android invades the enterprise: How to handle it

Android-based devices account for nearly half (44 percent) of the smartphones in use, says research firm ComScore, followed by Apple’s iPhone at 27 percent and Research in Motion’s BlackBerry at 20 percent. But in the business world, the iPhone is the leader, accounting for 45 percent of smartphones in use, according to ComScore, followed by the BlackBerry at 32 percent and Android at 21 percent.

I believe that by July 2012 the Android percentage in business use will exceed that of the BlackBerry and could topple the iPhone for first place by 2013. Whatever the adoption rates, it’s clear that Android will be a big percentage of the devices accessing corporate networks and data — posing a huge risk for the business and a huge challenge for IT.

[ Learn about consumerization of IT in person March 4-6, 2012, at IDG’s CITE conference in San Francisco. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld’s 29-page “Mobile and BYOD Deep Dive” PDF special report. | Keep up on key mobile developments and insights with the Mobilize newsletter. ]

For much of 2008 through 2010, IT worried about iPhones coming into the enterprise. But after Apple adopted Exchange ActiveSync (EAS) security policies in iOS 4 and provided API hooks for device management through third-party MDM tools, it became clear that for the vast majority of businesses, an iPhone was a safe device. Business adoption soared.

Why Android is a nightmare for IT But Android is a very different story. It too is propelled by individuals asserting their technology preferences. But from a security and management point of view, Android is a dangerous operating system. Androids in business pose real security risks, worse even than what IT is used to dealing with for Windows. Here’s why:

Android is a malware magnet. The Android Market is full of malware apps masquerading as legitimate apps, stealing information and running up huge SMS and phone bills on behalf of criminals. It’s so easy to develop effective malware for Android that security firm McAfee reports all new mobile malware is for Android; the criminals aren’t bothering with iOS, despite its larger market share, or with the longer-established BlackBerry OS. But don’t confuse malware with viruses (apps that infect other devices and PCs) — Android’s risk here very small, despite the scaremongering carried out by Kapersky Lab, McAfee, Symantec, and other highly self-interested vendors.

Android is highly fragmented. The Android universe is unmanaged, with multiple versions of the OS in use. Smartphones sold today could run Android”Froyo” 2.2, “Gingerbread” 2.3, or — starting this month — “Ice Cream Sandwich” 4.0. Tablets could run Android 2.2 or 2.3 or “Honeycomb” 3.0, 3.1, or 3.2, with Android 4.0 added to the mix soon. Android is less a platform than a collection of one-off products. By contrast, Apple sells only one iOS version at any time, and RIM generally does the same with BlackBerry OS.

Android is unpatched. Worse, those inconsistent versions are even more inconsistently patched — you can have different patches (or none at all) applied from one carrier/manufacturer/model combination to the next. By contrast, Apple releases OS updates and patches to all devices across all carriers at the same time, typically covering every model released in the previous two years. RIM’s product portfolio is in between, with different OSes for different hardware generations and variable patching schedules, but not as bad as for Android.

The bottom line for IT is that there is no “Android platform” to manage. Although Windows is as susceptible to malware as Android, IT at least knows that OS patches from Microsoft apply to all PCs from all hardware makers — and IT has the power to roll out the patches at once. It’s not the case with Android, leaving IT with no control or even consistency.

But none of that matters to users, and as the BYOD phenomenon has become the norm at most companies, saying no to Androids while saying yes to iPhones and BlackBerrys is a losing strategy. (And saying yes to iPhones and BlackBerrys is a rational strategy that you can’t undo.)

What IT can do to reduce the pain Given the situation, here’s what I advise IT to do:

Insist on basic EAS support. Android 3.x tablets and 4.0 devices (both smartphones and tablets) support EAS policies relating to passwords and on-device encryption that is close to what iOS provides, as do the 2011-model Android 2.3-based smartphones from Motorola Mobility and the Samsung Galaxy II S and Galaxy Note smartphones. Tell your users to favor these devices. Also, help them understand that some devices running Android 4.0 will still not support encryption due to hardware limits, so they need to be sure the hardware they choose support your requirements, which you should post. (It’s also good to provide a list of recommended, vetted devices.) Deny access to those that don’t support your EAS policies. MDM server tools like the new MobileIron 4.5 can manage the various flavors of Android devices from a common set of EAS and additional policies (which also apply to iOS), detecting noncompliant devices and regulating their access accordingly.

If your primary use case is email, you can tell users of other Android devices to opt for NitroDesk’s TouchDown app, which creates sandboxed container for corporate email, contacts, and calendars that supports EAS password and encryption policies similar to Android 3.x and 4.0. Some MDM clients, such as those from AirWatch, MobileIron, and Sybase, offer similar sandboxes for corporate services, as does the forthcoming Divide app from Enterproid.

Insist on antimalware sofware usage — when you can. Buying antimalware software for iOS is a waste of money — but not for Android devices. Given how malware-ridden the Android Market is and how big a target it is for criminals, I don’t believe you have a choice other than to require the use of antimalware software. But there’s a caveat: There’s little actual antimalware software to deploy; of the major vendors, only McAfee offers a client app. Symantec has no antimalware software for Android yet, but is working on it.

Another issue is how to enforce its use. That’s a bit tricky. McAfee says its antimalware software can be managed only by its MDM tool, for example. Symantec says when its antimalware software becomes available for Android, you should be able to use a third-party, application-aware MDM server to see if a device has it installed and decide what access to grant it based on that status; Symantec’s own MDM tool can only manage Android’s EAS policies, which don’t include application detection. You also should be able to use an application-aware MDM tool with McAfee’s client, but the company declined to comment on compatibility with other products, which tells me you should look elsewhere for serious mobile security.

Some application-aware MDM tools, such as MobileIron’s, let you go further and set policies based on the permissions that apps may have for accessing devicewide capabilities such as location information, VPN, phone dialer, and so forth. That can help prevent malware from causing harm, though it could also restrict legitimate apps’ appropriate access.

If you don’t use an application-aware MDM tool, all you can really do is tell users to install antimalware software — and revoke access privileges for those who repeatedly allow malware to get on their Androids in the first place. You always — or should — have the ability to treat outliers and offenders indvidually.

Bolster in-network defenses. You should do this anyway, as the notion of a network perimeter is nonsense today. You should invest in traffic analyzers, data loss prevention (DLP), and discrete access validation so that you can monitor and enforce policies for any user on any device connected to your network. This is not a mobile issue but a universal one, and the good news is that the networking vendors — Aruba, Cisco Systems, Juniper, and so on — have realized this and are rethinking their products accordingly. So should you.

Share the pain with users. One of the tenets of the consumerization of IT is the notion of shared responsibility. Or to put it in a way you can tell users: With freedom comes responsibility. If they choose Android devices and those devices come with extra costs compared to iOS and BlackBerry, they should bear those extra costs. Thus, users (or their business units) should pay for the antimalware client licenses and their share of any antimalware server tools. However, they should not pay for a share of MDM and network tools, unless all users do.

And users should know that their access may be limited based on their devices’ securability: The more a device and user are trusted, the more access and capability they get. IT will open up as much as it reasonably can, but not beyond a certain risk level that IT and the business jointly agree to. The key is that the decisions need to be risk-based, not endpoint-based. The result may be that some devices are given fewer or no access privileges, but the decision is never about the device itself; the access granted (and costs charged) to any specific device is simply a consequence of the global policies — this keeps the focus on the business risks and avoids the “technology wars” problem of “we don’t support x.”

This article, “Android invades the enterprise: How to handle it,” was originally published at InfoWorld.com. Read more of Galen Gruman’s Mobile Edge blog and follow the latest developments in mobile technology at InfoWorld.com. Follow Galen’s mobile musings on Twitter at MobileGalen. For the latest business technology news, follow InfoWorld.com on Twitter.