Mobile Device Management: Is it the Answer ... or is it the Question?
I was at a big AirWatch mobile device management (MDM) pan-European pow-wow last week. At it were CEOs, MDs and reps from Multinationals whose brand names are the stuff of the daily papers. In amongst them all were small firms, AirWatch’s channel partners and consultants like me who had some spare time on their hands.
Personally I like AirWatch: for their product, for their management style and especially for their in-house pre-sales and professional services team. I have used the software extensively and I have a lot of time for it. However, I think there is a problem specifically with MDM and the whole mindset that drives its adoption. I am not alone in this, and it is from a presentation at the conference by Chris Marsh of the Yankee Group that my current train of thought left the station.
The basic ambition of a pure MDM implementation, and in the rush to go mobile this is all that many firms have in mind, is that you can remotely control the mobile device from a console on a corporate server over the wireless networks. For Apple products, the server sends an Apple Push Notification Message to an MDM enrolled device which says “call home”. The device does and receives, by return message, an OS interpretable instruction such as “lock screen”, “clear password”, “install this app” or “reset the device to pre-enrolment status”. The device does what is requested if and when it can. Generally it reports success or failure back to the server but, say with reset message, executing the message necessarily involves clearing all of the enrolment server information including knowledge about where to report back.
What MDM can do is determined by what the list of message types the OS supports. Some MDM vendors provide an “agent” to augment the over-the-wireless services but given modern OS sandboxing and security models, the additional services are fairly circumscribed. Android supports a vaguely similar model and has a slightly larger set of controls.
The problems with MDM aren’t about its aims or implementation but, as with so much off-the-shelf software, the devil that lies within the detail of the operational manual that you must write for your L1 and L2 support teams. You can use your corporate console in the IT lair to do location tracking of all of your enrolled devices. It works and is an extremely powerful feature of MDM’s abilities. You can wipe clean the contents of the device’s storage with a press of a button. But when can you use these features, and their raft of companions, once you have implemented them? The examples below are not drawn from dreaming about a brochure-ware MDM implementation but from war stories from those who have done it.
Tracking employees’ location generates very large volumes of discontent. I cannot think of any organisation in which I have worked where employees would or did accept it. I can name even more organisations in which I have not worked that also have not accepted it. Apple’s micro-location service for devices that are never meant to leave the building would be acceptable probably because the feature confines its benefits for the business to within the geographic bounds of the business.
Wiping a device, especially a corporate owned device, when it is stolen seems a bit less contentious but on closer inspection it too has problems. Can you guarantee that, just because you press “wipe”, that the radio message will traverse the radio networks and the device will actually get the signal and complete the execution of the command?
If the fact that you cannot guarantee this doesn’t really bother you, and I can accept any number of reasons why, I imagine you don’t have any of your clients’ data on there about which you have critical business agreements to the effect that you won’t lose it.
For many businesses, losing client data to random third parties through loss or opportunistic theft might be acceptable provided there is a passcode and data encryption in place. At some point you need to do a risk assessment, set a budget for insurance and a plan for mitigation then act accordingly. However, what if the employee has personal or business data on the device, the continued existence of which is legally required by the courts and, although the device remains in the employee’s custody, it is wiped anyway? It may seem like a fringe case but I know of two large and extremely reputable companies that will not wipe a device without the express consent of the device’s owner because the devices can hold data relevant to regulators or to disclosure/discovery pre-trial phases of court cases (99.99% of the time they don’t, but these companies operate in industries that are unsympathetic to these kinds of errors).
The fact is people who work in a mobile way have data of real value on their devices and as, over time, the true internal/external business value of that work style develops, this data simply must not be wiped without due diligence.
My point isn’t that these fabulous features of MDM (as well as being able to set a password policy, black list apps etc) aren’t useful because they are. They should be thought of as small dots in the bigger picture of the policies and procedures you need to put in place around them. As the mobile picture continues to get bigger these dots will continue to get smaller. Or to use another analogy, MDM presents a range of tools that make every mobile problem look solvable in exactly the same way that a person given the use of a hammer sees every problem as a variety of nail.
So how do you develop a mobile strategy that is robust, encourages employees to get the full benefits of the technology, can be managed by the L1 team and will work in the general and fringe cases?
The trick is to have extremely strong business-led procedures around the devices. You can’t setup operating rules around using the device that are unreasonable to the employee because you can’t place any unreasonable restrictions on employees. Even if you have a clear idea of what is reasonable and unreasonable, make sure that your HR department agrees with you. Employment law (which is what this boils down too along with unfair or constructive dismissal) is not always sympathetic with headline features in the MDM tool set. You also can’t write L1 operations procedures which are too “reasonable” (aka nuanced) if your L1 team, along with a large percentage of your company, has English as a second or third language.
So rest assured that it can be done.
The most important step is to follow Chris Marsh’s advice and break the task down into two parts: device management is asset management; data management is best handled through encapsulation.
I mostly consider MDM a solution for corporately owned devices. Some non-corporate devices that need to access the corporate network, such as those owned franchise holders or sub-contractors, will possibly have their own MDM solutions already in place. Even employee owned mobile devices enrolled in personal MDMs will probably start to show up in work places before too long. You can’t enrol a device into two MDM systems concurrently. Asset management isn’t just about ownership of a device. Many of the asset management facilities of MDM can be still be implemented if you think your way around them hard enough and your vendor’s product supports what you are trying to do.
Anyway, for asset management try a two-pronged approach. Most importantly, use relatively few of the traditional mobile OS supported remote management features MDM supports. Choose your set based 100% around how your service desk team can be asked to use them. Maybe write your L1 and L2 manual around your use cases and then track backwards – whatever works for you.
In parallel, work out how to tie MDM into your asset management systems and configuration management database. It doesn’t hurt to read all of the L1 and L2 tickets every week and see if requests are coming in from employees that are being misinterpreted, escalated to L2 or L3 or related to functions you elected to leave out. It may save the service desk group quite a bit of money, in light of these reviews, to rewrite the knowledge base, adjust the MDM functions available and move some roles around if you find out you were wrong in your early analysis.
Next, if you can arrange a feed into your MDM setup from your asset ordering system, you can use MDM to send out mobile device enrolment information to staff as their corporate owned devices are delivered to them and then make sure the serial numbers match when they enrol. In jurisdictions where it is important that communications originating from corporately owned are fully managed (one of the deal breaking issues in the US in certain industry sectors) this can ease a lot of conversations with mobile skeptics.
Even better, if you can use MDM to dynamically update your CMDB with any company software that is installed (a good MDM system will be able to tell the difference between company managed and privately installed software) , then you can track licences using your company’s normal tool. There is no need to extend your general IT licence management processes to handle yet another exception, in this case for mobile devices, because MDM becomes merely an information source for your system of record. Essentially you can use MDM as a hub that incorporates mobile devices into your standard asset management toolset. The API of systems like AirWatch (using REST) are getting stronger all the time and this sort of integration is part of their product plan. I am sure that MobileIron, Mass360 and SAP’s Afaria (among all of the rest) are developing along similar lines.
How to manage encapsulation as a way of managing data is another step up in sophistication. Its benefits and techniques are useful equally on corporate owned devices as on BYOD.
Thus it deserves its own article, so stay tuned.
