Beyond the BES: New Strategies for Mobile Device Management
By Tim Williams
Ten years ago, mobile device management really only meant one thing: BlackBerry Enterprise Server. In many ways, that pioneering system still sets expectations for management capabilities of the ever-widening array of mobile devices available to today's workers. Yet unlike those early BlackBerrys, today's smartphones and tablets offer far more than portable e-mail and pose greater potential risks to corporate networks and data security. Beyond that, the growing trend of employee-owned devices in the enterprise means that IT departments tasked with supporting those devices will have far less control than they had in older, closed systems.
Both the company and its employees benefit from the new arrangements. Employees can choose devices that better fit their personal work and lifestyle, which results in greater productivity for the company. As a result, a best practices approach to managing mobile devices must consider the challenges from both the enterprise’s and the employee’s perspectives, as both will have to accept certain tradeoffs in order to support use of employee-liable devices without compromising security.
The employee needs to understand that accessing corporate networks and resources with a personally owned device necessarily means ceding a certain amount of control over the device’s settings; for example, violating company policies may mean loss of access. The company needs to understand that management no longer means control, as the device’s owner will always be able to claim ultimate control of the device and its functionality. Distilling these tradeoffs into a clearly articulated policy is the first step towards effective mobile device management.
Beyond that, IT administrators need to understand both the benefits and the limitations of mobile device management (MDM) software. Specifically, you should seek software that can effectively implement and automate your policies, but don’t expect the software to define the policies for you.
In a June 2010 paper, Gartner categorized four different scenarios to define the policy options for mobile device management, ranging from “control” to “hands off.” (Gartner, “New Approaches to Managing Mobile Users and Smartphones,” Nick Jones, 2010) http://www.gartner.com/DisplayDocument?doc_cd=200750
This is a useful framework for defining your own company’s policies, which should include elements covering each of the following:
For most organizations, this means integrating with an Exchange server. Microsoft’s Exchange ActiveSync (EAS) supports robust security protocols and policies. Because of this, EAS support should be an important consideration in selecting mobile devices your company will support. Unlike the old closed-system days of the BlackBerry, with EAS it is no longer necessary to build an additional mail server infrastructure on top of Exchange. It’s redundant and serves mostly to add greater support demands while adding little, if anything, in the way of enhanced security for the data involved. Rather, staying within the features of EAS to build your company policy will leverage that existing resource, and make it easier to find an MDM application to support and automate those policies.
Still, while strong EAS policies will be sufficient for organizations using Exchange, there are still many who use POP/IMAP or another e-mail system. In addition, today’s mobile devices have capabilities—and associated risks—well beyond e-mail. Because of this, if you rely only on EAS, you do not yet have true mobile device management.
MDM software should be able to apply e-mail settings through use of configuration profiles, to ensure standardization, security, and ease of re-provisioning. It should also support removing these profiles and associated data.
While the primary focus in the closed-system days began and ended with e-mail, calendar, and address book, the real power of modern mobile devices is the dizzying array of applications that users can install for productivity, information, and entertainment. While your policy can’t account for all possible apps, what it can do is define different categories of apps, to which individual apps will later be assigned on an ongoing basis. These categories should include:
· In-house apps: apps developed by and for the organization. The policy should define how and to whom these will be distributed. Automated MDM tools should accommodate delivery of the apps, and have the ability to restrict their use and distribution in order to protect proprietary information.
· Recommended/required apps: those publicly available apps identified as particularly useful to the organization. Automated tools should enable publishing to a self-service portal, or pushing the app to devices. In the case of required apps, there should be a mechanism for identifying non-compliant devices (those that do not have the app installed) and remediating.
· Prohibited apps: this is self-explanatory. Automated MDM tools should be able to identify noncompliant devices and take remedial action, such as restricting access to corporate networks and data or removing the app.
Probably the most important step in device security is choosing the devices your organization will support. Recommending devices is outside the scope of this article, but hardware encryption, EAS support, support for certificates, and VPN are some basic thresholds to consider, and your MDM software should be capable of managing these things, as well. Once you’ve got the devices, your first line of defense on the device will be the password.
Unfortunately, passwords rely on the weakest security link—the end user. A recent breach of user passwords at Gawker showed that "password" and "123456" were among the most common passwords chosen by end users. That's obviously not good enough. Clearly, your policy (and your MDM software) must enforce high password complexity standards, frequency of password changes, and even automated countermeasures, such as device wipes.
Again, it’s your policy that needs to define the level of password complexity, password expiration, and countermeasures. Consideration of MDM software should take into account its ability to automate these policies.
Where the devices are employee-owned, vendor warranties and replacements will be managed by the employees, as well. Additionally, as smartphone lifecycles continue to shorten and costs drop, repair of devices has become a less pressing concern in most organizations. As a result, support needs are often limited to quick replacement of devices. This makes the ability to quickly re-provision new devices over the air the most important support feature for your policy, and your MDM software should support this. In the case of employee-owned devices, a self-provisioning portal will be the most timely way to support new devices, since new device delivery schedules will be outside the company’s control.
Additional considerations for MDM software
Having developed a set of policies to fit your organization, the next step is to determine a mobile device management software solution that can best support those policies. In addition to the points discussed above, there are other elements that will make such a solution more effective in most organizations.
1. While querying devices for hardware, software, and configuration information is vital, much of the reporting you will need to provide will also require a great deal of information that is not discoverable from the device itself, such as cost centers, domains, user names, and much more. You should seek an MDM solution that is capable of attaching such additional data to device records. Ideally, you’d want to have these fields completely customizable; at a minimum, you’d want to be able to import items from your Active Directory, where much of the relevant information is likely already stored.
2. MDM software should support some kind of role-based administration, in which administrators or techs can be assigned to manage only specific devices and have permissions restricted to specific management functions that are most appropriate to the scope of their jobs.
3. While there may be general company policies pertaining to mobile devices, there will also be more specific guidelines, lists of recommended apps, access to resources, and device restrictions that must be applied only to certain devices and groups. MDM software should allow for dynamically assigning devices to groups, and policies to devices, based on criteria you specify. This will truly automate the actual execution of the policies you’ve devised, an otherwise inefficient and time-consuming set of tasks.
4. Although a best practices approach requires polices to be applied via configuration profiles, creation of these profiles can be very time-consuming due to the large amount of required information that differs from group to group, or even by individual user. (Think of usernames and e-mail addresses, for example.) One alternative is to allow end users to fill in the blanks, but this introduces more possibilities for error, demands on the help desk, and perceived lack of support for end users. An effective MDM solution will have a mechanism for dynamic creation of your standard profiles, looking up and inserting customized data into profiles automatically.
5. MDM software needs to include a messaging function. SMS messaging is available for phones, but not for other devices, such as tablets. A simple form of text messaging, to immediately communicate information related to device support, IT outages, or emergencies, is vital.
6. Geotracking ability can be a valuable feature. In addition to aiding recovery of lost or stolen devices, geotracking can be used in fleet or workforce management as well. Ideally, you’d want to have control over the check-in interval in order to conserve battery life, the ability to view historical location information rather than just current location, and some kind of privacy control, in consideration of employee ownership of the devices.
7. Finally, consider who will be responsible for managing mobile devices. Increasingly, this responsibility is falling to desktop support groups in the IT department. This makes logical sense, as tablets and smartphones clearly are more computer than phone, and policies created for laptop e-mail and security should not be viewed as entirely separate from those of tablet e-mail and security. It makes sense then, to consider whether there is a PC Lifecycle Management solution that can manage both computers and mobile devices. This will limit support infrastructure overhead, functional redundancy, and staff training requirements.
Special considerations for iOS devices
Finally, it's no secret that the employee-liable device movement has been driven largely by Apple’s iPhone, and, more recently, the iPad. It is therefore worthwhile to explore the particular constraints of iOS as it pertains to MDM.
The iOS system always leaves ultimate control in the hands of the end user. For example, there simply are no MDM software solutions that can actually remotely install or remove specific apps from iPhones or iPads. Both of these actions require end-user interaction. Similarly, no specific data can be removed from an iOS device remotely. No management software can prevent a user (or thief) from resetting the device, thus removing it from management, either. Finally, Apple removed the jailbreak detection API back in iOS 4.2.
Upon initial review, these constraints would appear to contradict some of the best practices outlined earlier in this article. However, it is possible to manage within them. A properly designed MDM solution will be able to detect prohibited apps, even if they can’t be removed, as well as to detect when required apps are missing. As for jailbroken devices, these present an unacceptable security risk, and although there is no longer a standard API for detection, MDM solutions that do not include their own methods to flag compromised devices are inadequate to basic security standards.
By establishing dynamic reporting groups, as outlined in the section on MDM software considerations above, admins can then use all of this information to create remedial policies, which may range from reminder messages to denial of access to company networks and data. That access is a privilege, and complying with policies if the employee’s trade-off. The company may not have ultimate control of the devices, but it must maintain control of its networks and data.
Obviously, MDM software is a vital component to proper mobile device management. Ultimately, though, you can’t look to the software to tell you how to manage devices. You must first develop appropriate polices for your organization. Second, offer support only to devices that meet your policies’ standards. Finally, select the software that will support both.