We know that Android is popular, and recent polls show that Android is “winning” the race in sheer number of smartphones that are out there. Frequent readers will remember previous blog posts on Apple’s MDM solutions where David Schuetz dives into some of the security concerns.
But what about Android? It seems to be following the way of the iPhone in that it becomes super popular as a consumer device, and only then do we start thinking about using it in an enterprise environment. Android has supported mobile device management (MDM) solutions for a long time now (since 2.1). Yet Android, until recently, is often considered ill-prepared for an enterprise environment.
Here’s Your API. Good Luck
Android’s MDM support comes in the way of the DevicePolicyManagement API. This allows developers to control things like password complexity, lockout timing, remote wipe, and remote lock. Standard MDM features right? But what about things like tracking apps that are installed on a device, keeping track of serial numbers, being able to recover lost devices? Yeah, it can do that but just like all of the other Android decisions they’ve made, Google has given you the ability to do it yourself and then they stepped back to watch the carnage. This means that while no official Android MDM solution exists, third parties are picking up the slack and rolling their own.
The MDM Recipes
I categorize third party MDM solutions into three unscientific groups: Cross-platform Android clients that use ActiveSync, native Android solutions, and cloud based solutions. Native clients, such as Google Apps, have created a complete solution tailored to Android devices. They take advantage of the DeviceManagementPolicy APIs and then add in some other features such as asset tracking, GPS location tracking, app auditing, and permission controls. They are not building upon any pre-existing technologies so while this sounds like the best solution, not many MDM providers are going this route because it’s so specific to Android.
Cloud based MDM solutions (lets face it, it’s just Good Technologies), will give a user access to all of the cloud services, and then remove them when the device is no longer compliant with a device policy or an employee leaves the company. You can probably see how it would be easier to just stop granting access to your enterprise services rather than attempting to wipe a device when it leaves a company.
The most popular solution by far is the ActiveSync based solutions. This is an MDM app that relies on ActiveSync for device management policies, and then adds in their own bells and whistles. Airwatch, for instance, is an ActiveSync solution that has added in asset tracking, app auditing, and a lot of other features. In fact, the most popular solution that I’ve seen is just enabling ActiveSync and calling it a day.
As a stand alone solution, ActiveSync will push out device polices that control passwords, idle timeouts, and provide a remote wipe capability. But the bells and whistles that you’ll see with other solutions are nonexistent. The reason it’s so popular is that there’s minimal deployment time and for some environments it very low cost. Those organizations that have already implemented Exchange can enable ActiveSync services for smart phones and using using Android’s built in “Corporate Email Client,” it connects in and is ready to go.
MDM and ActiveSync
Why are we talking about ActiveSync when it comes to Google? The reason is that the Android Exchange client (AKA Corporiate Email Client) uses ActiveSync to pull down email, contacts, and calendar events from corporate networks since 2.1. But one of the features it has also implemented as part of ActiveSync protocol is password controls, remote wipe, and idle timeout.
So that’s great – you have an Exchange environment, you enable ActiveSync, and you now have a mobile device management solution for Android devices. But what about those other feature we talked about; app management, asset tracking, GPS tracking. None of those features are there. Well it turns out that a lot of organizations believe that’s enough. In talking with one of the local fortune 500 companies about how they manage their mobile policy, we found that they’re using a native ActiveSync to implement a Bring Your Own Device (BYOD) mobile policy. They had an Exchange environment, they wanted to allow employees to bring in their own devices to access corporate information, so they enabled ActiveSync and they were done.
Because this is such a popular implementation, it’s also become a target for clients that would like to evade this policy. In the next post I’ll talk about some specific problems that we’ll run into.
MDM Communication With C2DM
Cloud 2 Device Messaging (C2DM) is Google’s lightweight data push service. It’s Android’s answer to the Apple Push Notification Service or the Blackberry Push Service. These types of services are ways of pushing down information to an app as opposed to waiting for an app to pull data. A lot of the MDM providers use this solution to send down their device policies or remote commands. When a remote wipe command is issued from an organization, you don’t want to wait for the app to issue a schedule update, you want that command to be sent as soon as a device has connectivity to something.
A coworker of mine is looking into the security concerns with C2DM but in this scenario, we’re concerned that someone might be able to send a remote wipe to your phone without having administrative access.
Android’s MDM solutions are up in the air which may be why a lot of people say that Android isn’t really ready for the enterprise. With the latest Ice Cream Sandwich version of Android that supports policy controlled encryption, I think you can see Google pushing Android into enterprise environments much more.
This is a nice little info blurb about Android MDM and the underlying technologies but lets be honest, the real fun comes from attacking. The next Android MDM post will discuss some attack vectors and evasion techniques that may make you re-think how much you trust your MDM provider.
Both comments and trackbacks are currently closed.