Contextual mobile management: How real is the promise?

Thanks to their native security and management capabilities, as well as a wide selection of mobile device management tools, most businesses now let employees choose among several smartphones — typically iPhones, Androids, and BlackBerrys — in addition to iPads and emerging Android tablets. IT concerns over locking or wiping stolen or lost devices, ensuring that data is ecrypted at rest, and requiring a password to use a device are addressed by iOS 4, Android 2.2 and 3.0, BlackBerry OS 5 and 6 (but not the tablet version), and WebOS 3, even if you use Microsoft Exchange instead of a more sophisticated mobile device management (MDM) tool.

So mobile management is now a checkoff item, right? Buy a tool, set a policy, and you’re done. Well, not quite.

One of the major shifts in the last year was the acceptance by businesses that mobile devices are both personal and work tools used for both purposes. That means more than running personal and business apps — an issue that has increased interest in so-called mobile application management tools.

That very shared-ownership nature can lead to awkward results when a business (rightfully) manages devices — whether owned by the company or the employee — that connect to its network, email, and so on. Take the case of the mobile camera; iOS, Android 3, and BlackBerry OS all let you disable the camera on a managed device,  so companies concerned about sensitive facilities or whiteboards being photographed can reduce the risk of that occuring. But once you turn off the camera, it’s out of operation — and the employee can’t take pictures of her kids at the park. IT has no worries about such photography, but it can’t distinguish that kind of innocent photography from worrisome spying.

Or can it?

The promise of contextual MDM
An emerging concept in MDM is the idea of contextual MDM. For example, rather than turn the camera off as a binary activity, an MDM tool could turn it off only when the user is in a sensitive facility and reenable it the rest of the time. That way, the camera is available for personal and nonsensitive work purposes, and employees will be happier — and the business will remain secure.

There are examples of such contextual MDM already in place. Zenprise, for example, acts on the concept of geofencing, which correlates current location information from a device to a database of proscribed locations. When the device enters a proscribed area, the camera is turned off. (To avoid user location privacy concerns, such detection does not record users’ locations but simply detects when the device is in range of a sensitive location, then applies the appropriate security policy.)

Another form of context that MDM could use is time: Access to certain enterprise resources, such as Wi-Fi access points or the VPN, could be turned off after an employee’s working hours. Zenprise’s MDM tool supports the notion today of app-specific VPN use, so only authorized apps can access the corporate VPN, which can help prevent phishing attacks from penetrating the corporate network from an infected mobile device.

Longer-term, contextual management could be more behavior-based, similar to how data loss prevention (DLP) tools work to protect corporate data from unusual access, says Ahmed Datoo, chief marketing officer at Zenprise. For example, an MDM tool could notice that an app not used for five months has suddenly begun communicating — a sign of a data-stealing malware infection, he says. “That’s behaviorally detectable.”

Why contextual MDM is trickier than it first appears
“We see lots of customer demand for contextual MDM,” says Raffi Tchakmakjian, VP of product management at MDM provider Trellia. It’s a notion familiar to government customers who have tools to manage user laptops based on contextual policies — such as time and location — to track, for example, whether a government employee is connected via a public network. But MDM tools don’t have the same luxury of a monoculure environment (Windows, in the case of computers), so replicating that approach in the heterogeneous world of mobile devices will be difficult, he says. “It’s hard to have the same result across users of different mobile OSes.”

It also turns out that the IT groups that manage mobile security and access are rarely the same ones who manage desktop security and access, Tchakmakjian says, which has led to separate tool sets and nonunified management. But he does expect that to change as enterprises become more reliant on mobile devices and realize they’re part of the basic IT infrastructure, no longer a peripheral activity.

Beyond the internal IT issues, a big challenge for implementing contextual MDM is the challenge of dealing with the contexts themselves. A common complaint about DLP tools in their heydey of the mid-2000s was their complexity. The heuristic approach of DLP, which requires anticipating all the permitted uses of data — not just in general terms but specific files and databases, then in the context of the user and recipient — proved to be an overwhelming task. Writing the rules for the tasks that IT could anticipate also was a massive undertaking. Many DLP users quickly realized it was no automated protection system but really a forensics tool for after-the-fact incidents and a tool for preventing the most foolish employee actions. After all, a determined thief would work around the DLP rules, rendering most policies ineffective.

Behavioral MDM could face a similar barrier. Datoo says that’s why successful contextual MDM tools will need to avoid heuristic approaches reliant on identifying and acting on patterns of behavior — which are prone to false positives unless you have the vast kind of behavioral data characteristic of a Google search engine to back you up — and instead use a deterministic approach based on rules that trigger tests to diagnose the symptoms. That’s exactly what happens when comparing the user’s current location to the locations of sensitive areas, as does mapping the current time or application to allowable permissions.

Not only is the deterministic approach simply more feasible in practice, the notion of remediation if you break a policy (like using the camera where you’re not supposed to) is more acceptable to users, says Jesse Lindeman, product manager at MDM provider MobileIron. It also helps IT, he says: “It lets IT manage the exceptions, not the endless details.”

But even a deterministic approach has a fundamental weakness, Lindeman says: The device has to be managed by the MDM tool in order to apply the policies to it, whether based on context or not. A company that has an MDM tool that turns off mobile devices’ cameras based on user location is easily spied on by a user who brings in a digital camera or simply a smartphone not known to the MDM tool; the same can be said of a smartphone known to the MDM but with the radios turned off to avoid detection. “A security guard who collects these devices before you enter the building is probably both cheaper and more effective,” he says.

The back end is where the action needs to be
Lindeman says for contextual MDM to have a strong chance of being effective, it must be more integrated with the back end. For example, wireless access points need to detect guest devices and block services to that device until the person validates by logging in (thus making the device manageable). Likewise, detecting traffic patterns: Where is the mobile device sending information? What services is it accessing in the network? Do those match the user’s rights? That’s a more proactive use of wireless LANs than most companies have today.

Ironically, where MDM today does integrate with the back end is through Microsoft Exchange, using Exchange ActiveSync policies and tapping into Active Directory for user role information to help determine appropriate policy sets. Apple has picked up that notion in Mac OS X Lion Server’s new Profile Manager. Of course, BlackBerry Enterprise Server (BES) has been doing that for years, using its own protocols.

But Exchange is essentially an edge server, with little or no role in other data management, network management, and user management systems. Thus, the context available to MDM tools today is partial at best. Tchakmakjian, Lindeman, and Datoo all see that as a legacy of where mobile began a decade ago: with the BlackBerry essentially as a communications tool. When the iPhone redefined mobile devices as a new form of computing, the mail server remained mobile devices’ primary conduit to enterprise systems.

It’s clear that at several levels — Microsoft’s and Apple’s extended support for mobile devices in their server OSes, in mobile savviness being added to network management tools such as those from Aruba Systems, and the increasing back-end integration efforts by MDM vendors — this is all changing. Coupled with smart approaches to context detection and policy application, contextual MDM could really happen in a way that reflects the vision. But give it a few years.