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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
Source: National Cyber Security Centre
