Blog post

MDM products: Which one is best?

Created:  08 Mar 2017
Updated:  08 Mar 2017
Author:  Andrew A
Like a car, which MDM tool is best?

We often talk with people who are building IT for the public sector, and one of the questions we've been asked a lot in recent years is "which mobile device management (MDM) product is best?"

We recently had to confront this question directly whilst building our own IT system. It seems like an entirely sensible question — until you realise it’s a bit like asking which car is best:

  • A fast car... aerodynamic... two-seater with a big engine.
  • Five seats... big boot.. economic. I've got kids and shopping to ferry around!

What’s best for a speed demon is going to be different to what’s best for a family — and probably different again for a commuter, and so on.

No such thing as an all-rounder

Each MDM product we’ve come across tends to focus more on some platforms and use cases than others — Apple iOS rather than Android, or fully managed rather than bring your own device (BYOD). We’re yet to come across a single MDM product that does well with all platforms and use cases.

This highlights that the most important thing you can do when choosing an MDM product is to pick one that does what you need it to do. That decision will be different for everyone — which means it's not enough to pick a particular product just because another department or organisation did. After all, would you buy a Reliant Robin car just because your friendly neighbour did?

The 'S' word

You can see that 'best' is highly subjective. But the way in which an MDM product handles security must be one of the most important factors. The 'secure' accounts and managed devices that users rely on can only be trusted as such if the components that manage them are also secure. 

We hear a lot about how attackers will initially go after individual users and devices within an organisation (to defend against this, see our end user device (EUD) security guidance. Ultimately though, they use those devices as a stepping stone to attack the enterprise-level services they can access. The most effective way of doing that is to target management components such as MDM products, to get high-level privileges and the access they afford to the organisation’s systems and data.

At the risk of over-simplifying the situation, it's a bit like if a burglar gets into your house because you left a window open. Not only have you made it easy for them to burgle your house, they can also bypass the usual deterrents against stealing your car (such as alarms and immobilisers) by just taking your car key and driving off.

Oldies, but goodies

Many of the good practices that have helped to defend traditional networks equally apply to managing modern mobile devices through MDM products. Techniques such as protective monitoring, network segmentation and preventing privileged administrator accounts from accessing the Internet continue to apply to MDM products, including those hosted in the cloud.

How we chose an MDM product

We kept all these thoughts in mind as we set about choosing an MDM product for the NCSC's IT system. Here are some things we considered:

  1. Anecdotally, we found that some MDM products are difficult to patch — a worrying fact given that patching plays a very important role in cyber defence. We wanted a product that would automatically and reliably apply security patches to the server/service as soon as the vendor releases them. The product could be software as a service (SaaS) that has a robust and transparent patching policy, or more traditional software that has an automatic update mechanism.
     
  2. We wanted users to be able to install their choice of apps from an approved list — so the MDM product must include some sort of 'app store' functionality. As some apps would be handling enterprise data, we realised it was important that our chosen combination of MDM product, app store and devices must automatically patch apps whenever the apps were updated in the public app store. Updates can be more or less automated on most modern devices — our choice of MDM product would need to take advantage of this. That is, we wanted a product that would allow automatic device updates and provide useful reporting to help us spot devices that aren’t being updated promptly.
     
  3. As a general rule, security is aided by simplicity. We tend to worry when it’s necessary to use a separate agent or app on devices, as that brings the challenge of yet more patching. And, many of these agents hook into the platform in ways that can actually make device updates less reliable. So we wanted an MDM product that will use the management features already built into devices and hook into the existing app store.
     
  4. We were keen to show our partners how our EUD security guidance provides an appropriate security baseline without significant loss of device function or usability. So, the MDM product would have to support all of the usability and security policies that the guidance recommends.
     
  5. We chose to hand out fully managed devices that safely allow personal use — marketing people often call this 'corporately owned, personally enabled' (COPE). In brief, we think this protects our enterprise data better and simplifies support and troubleshooting. In practice this means we need to be able to enforce certain security settings, pre-configure users’ accounts and provide an app store. We don't need functionality such as container apps, or dual identity devices. Nor do we need custom versions of apps, such as email clients designed for BYOD. So, we wanted an MDM product that will support our chosen model and allow us to not install other features that we aren’t using.
     
  6. We had already decided we would build in the cloud. But before we could opt for any particular cloud services we needed to have a high level of confidence in the way our deployed MDM resources are separated from those of other customers. After all, MDM plays a critical role that demands particularly good security. We would use our own cloud security principles guidance to help us decide if we could have enough confidence in a software as a service (SaaS) provider, or if we would need to build and maintain a product ourselves on an infrastructure as a service (IaaS) platform.
     

This 'wish list' probably leaves you wondering which product we actually chose in the end...

And the winner is...

Well, you won't be surprised to hear that we couldn’t find a product that satisfied all our above wishes, never mind our more detailed functional requirements.

Unfortunately, we couldn't get enough information about any MDM SaaS offerings to satisfy our concerns. Instead, we focused on MDM product offerings to install on IaaS.

Ultimately, we decided to use two different products — one to manage our phones (including those running Apple iOS), and one to manage our Windows 10 devices through Group Policy.

We're likely to revisit these decisions in the future as MDM services, products and devices mature — along with our understanding of them.

I'll end by challenging MDM product vendors and service providers to do more to help with such decisions in future:

When you're approached about MDM products/services:

  • explain how your offering measures up against these sort of requirements
  • help us identify which bits of your offering specifically meet our needs
  • help us to feel confident that once your offering is deployed, you'll keep us current as devices and features evolve — we need to be up to date with developments, whether this means the latest and greatest features that users expect of their devices, or improvements to security

Andrew A
Cloud Security Research Lead - NCSC

5 comments

Martin - 10 Mar 2017
I'm still left wondering what products you chose in the end .... Interesting that the SaaS MDM product from the vendor who handles your email wasn't considered up to scratch.
Andrew A - 15 Mar 2017
Ah-ha I'd optimistically hoped I’d get away with quietly not mentioning any product names! It was intentional because there’s a couple of features that we really wanted that we haven’t been able to get working despite the product’s marketing claims. If that changes then I’ll be happier shouting out what we’ve actually deployed. Our choice of vendor/product(s) was mostly influenced by the features set and available skills within our organisation – rather than us deciding that other products/services weren’t secure enough. We found that many of the alternative products currently focus on BYOD which ruled out quite a few of the big names you may have come across. It just happened that our chosen vendor offered a self-install product and a managed service, which required the final IaaS vs. SaaS decision.
Android MDM - 14 Mar 2017
Thankfully with today’s technology, Mobile device management is a broad term used to define the administration of mobile devices such as smartphones, laptops and tablets.
Peter B - 16 Mar 2017
Hi Andrew A Did you select container technology or non-container? I would expect the first of the two would provide better segregation between personal and gov information? Also it would appear to generally provide more effective control as you don't have to cater for all the different OS and native apps? Peter B
Andrew A - 22 Mar 2017
Hi Peter. We chose to rely on the per-app separation that’s native to iOS, and so didn’t use a 3rd party container technology. As we fully manage the device, we can use controls such as requiring the use of our private app store. That allows us to control apps that try and access potentially sensitive data on the device such as the phone book, messages and e-mail. We think container apps are most useful for for Bring Your Own Device deployments where they can help to mitigate some of the issues we discuss in our BYOD guidance (https://www.ncsc.gov.uk/guidance/byod-executive-summary)

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No