Android invades the enterprise: How to handle it

IT pros worried about the iPhone will soon have a real problem: The malware-ridden, unpatched Android universe

1 2 3 Page 3
Page 3 of 3

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 Read more of Galen Gruman's Mobile Edge blog and follow the latest developments in mobile technology at Follow Galen's mobile musings on Twitter at MobileGalen. For the latest business technology news, follow on Twitter.

Copyright © 2011 IDG Communications, Inc.

1 2 3 Page 3
Page 3 of 3
How to choose a low-code development platform