Don't Use Mobile Management to Build BlackBerry all Over Again

Learn from Lego -- to users, everything is awesome.

BlackBerry, Lego
Credit: Brickset via Flickr

Turning off device features is the fastest way to get users looking for alternatives the company can't control.

IT departments want to be Lego master builders, like Emmett in the gloriously silly Lego Movie. The double decker couch with built-in beer kegs might look stupid to the IT team busily gluing systems together with their Kragle glue to make a beautiful, orderly, secure cityscape in the basement -- but if it makes users more productive (or helps them survive when the submarine gets sunk by Lord Business and Bad Cop), you should be giving them boxes of Lego blocks and seeing what they come up with.

Mobile device management (MDM) vendors are starting to get that message. For instance, AccessData is adding iOS and Android support to its ResolutionOne system. Unusually, this isn't actually about device management -- the agents you put on users' mobile devices are doing endpoint monitoring rather than setting policies on what they're allowed to do.

That's a mix of checking if users are visiting malicious IP addresses or domains known to host malware (which would mean they've installed a malicious app) and showing you details of what they're doing on the phones by periodically collecting running processes and network traffic (and location). It should be useful for spotting data leakage and for going back and tracking down what happened if a compromised mobile device means you lose data.

It's a similar idea to the security reports in Microsoft's Azure Active Directory Premium service. You can see if any of the IP addresses users are connecting from have been found to be part of a botnet, or if their devices are making impossible journeys -- logging on from home then an hour later logging on from a country that takes eight hours to fly to, for instance. It's managing security by looking at what devices are doing, not by stopping them from doing things.

Learning from BlackBerry's mistakes

The kneejerk IT admin practice of turning things off because you can is one of the reasons BlackBerry isn't a major handset maker any more. Yes, BlackBerry handsets fell behind the iOS experience, but BES admins who turned off the camera and BBM messaging and the browser made them look even further behind.

Alan Panezic, the then-VP of software of BlackBerry, told me in 2012 that creating all those policy settings in BES when customers asked for them hadn't necessarily been the right idea.

"We really set the bar on security on all these devices -- but we set the bar in such a way that people tend to look at the security of solutions in terms of 'how many things I can turn off'. It's better to think in terms of how many things you can turn on. It's not about having 700 different ways to turn things off."

Turn off too many things and you turn users away. As Panezic put it, "Security done wrong puts you against human nature. Humans are fundamentally problem solvers; give me a problem and I'll find a way to fix it. If it's too complicated to share files [in the company approved way], I'll use Box."

Microsoft discovered the same fundamental truth a while ago. Dan Plastina runs the Azure Rights Management service these days but his experience in the early days of Group Policy showed him exactly why you shouldn't just lock everything down.

"I created Group Policy and everyone went nuts, and before you knew it there were cables running across hallways because users were installing their own network hubs so people could be productive."

Microsoft's app compatibility expert Chris Jackson saw that happen too. "Some security guys believe they are paid by the number of group policies they modify. If you don't need to change the default, don't change the defaults."

He once added up the Group Policy options for Internet Explorer. "The combination of possible Internet Explorer policies is somewhat larger than the number of molecules in the observable universe," he says drily. And those combinations of policies made IE compatibility problems far worse over the years; "When a site works on vanilla IE but doesn't work when it gets to my particular set of IE policies&"

To prevent overkill, Plastina suggests offering as as possible for classifying information: Make it internal, confidential, public, or unprotected (using tools like RMS-enabled Secuda to make sure data coming out of a system like SAP is always encrypted) and leave it at that. "I want to keep it simple because I want normal people to use it," he pleads now.

Don't stop the builders

Normal people don't build giant Lego models of the Millennium Falcon, or MetalBeard's Sea Cow (2,741 pieces, including the anchors). They might build their own version of the double-decker couch, or they might just stick a couple of Lego minifigures on the edge of their desk to use as cable grips.

Instead of trying to stop that impulse by gluing all the blocks together with inhuman MDM security that turns off everything on their devices, concentrate on making sure they have the blocks they need -- whether that's email that's secure for employees and customers, sharing files that's secure but also easy, a secure enterprise social network, business intelligence tools, ways to find and lock lost devices, or secure but simple systems for accessing whatever else would be useful to them -- on the devices they want to use.

Equally important, make it easy for employees to get your help with their Lego systems. Jackson suggests, "If someone says 'here's an Access database we use, I'd like to submit it to be managed so you can help us keep it running,' find a way to have that be friction-free. Don't complain about it being in Access. Support it, and look at how to help them build a long term solution that works, and where you can share the cost."

That doesn't mean anything goes. As Panezic put it, "You can end up with something perfectly secure and you can't use it, or something that's perfectly insecure and perfectly useful -- and both ends of the spectrum are awful."

But remember: If you try too hard to glue everything down you'll get the perfectly secure end, but all your employees will be down at the other end, using the useful, insecure stuff they built and bought that you know nothing about.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies