Understanding MDM: Navigating device management jargon

Cybersecurity is awash with acronyms, which certainly saves lots of space in marketing material and adds a certain high-falutin aura to sales patter.

But this tendency comes without a mixture of complication and controversy.

Ironically, part of the controversy is that language purists insist that abbreviations are initialisms and not acronyms unless they can be pronounced as words, so that all acronyms are initalisms, but not all initialisms are acronyms.

The complication comes in the form of confusion, where the phrase that the letters stand for gets superseded or forgotten altogether, but the initialism nevertheless enters widespread usage as an item of vocabulary that is taken for granted, even though no one is really sure quite what it means any more.

Device management – for Mobiles

MDM, short for mobile device management, is a fascinating example.

When this terminology first became widespread, the word “mobile” generally implied the phrase “mobile phone”, in the sense of a smartphone of the iOS and Android sort.

Not merely a traditional cellphone or feature-phone, but a handheld computing device that could be used as a a phone, yet that was more of tiny, truly mobile computer with a broad choice of apps for consumers and companies alike.

By the time Apple and Google phones arrived on the market, the word “endpoint” was already in widespread use, typically as an umbrella term to describe regular computers that weren’t servers, thus avoiding the cumbersome phrase desktop, laptop or notebook.

And by the early years of the 2010s, cybersecurity software for these endpoints acquired its very own initialism EDR, short for endpoint detection and response.

Most vendors adopted the tag EDR very quickly, because any product that still billed itself as an “anti-malware” or “anti-virus” sounded pale in comparison, and didn’t match the fancier name now being used by analysts for software that, after all, did much more than merely scan for computer viruses.

There was a modest problem, however, in applying the name EDR to third-party security products designed for mobile phones and their tablet-sized counterparts.

Many mobile security toolkits could detect some malware, prevent some types of malevolent behaviour such as snooping on other apps, and delete rogue text messages before they could cause trouble…

…but both Apple and Google (and, briefly, Microsoft with its Windows Phone product, discontinued in 2015) exerted considerable control over third-party software vendors, notably making it somewhere between difficult and impossible for cybersecurity vendors to produce and maintain full-strength EDR tools for mobile phones.

Locked and limited

Apple notoriously, right from the first version of iOS, implemented rigid controls, not only locking down the operating system itself against modification or repurposing by anyone else, even the device’s owner, but also limiting the apps available for download to an App Store owned and operated by Apple itself.

Google’s own Android phones have generally been more flexible, in that most of the company’s own devices can be wiped and reflashed with an operating system of the owner’s choice, including a free, non-Google-branded build of Android such as LineageOS, and can be configured to accept “off-market” downloads that don’t come from the Google Play Store.

Nevertheless, Google Android itself doesn’t let independent cybersecurity software vendors do everything they might want or need: as in Apple’s iOS, there are strict built-in controls over how apps interact.

Notably, every app runs as a different user, so that apps can’t access each other’s data by default, or peek at each other’s on-screen data, or interact in any of the many ways we expect and find useful on desktop or laptop computers.

From a cybersecurity point of view, that’s great for privacy and safety, because even a buggy or deliberately rogue app can’t inevitably snoop on what you are doing in your other apps.

But that sort of blanket restriction also makes cybersecurity innovation hard, because writing a low-level threat-blocking program when one app can’t keep its eye on others, even for respectable and useful purposes, limits its range and effectiveness.

Indeed, many vendors who used to offer EDR-style tools for Apple and Google phones have largely given up doing so, for two main reasons:

• Both Apple and Google broadly insist that their own threat-blocking tools are all their users need in the way of EDR, even though malware shows up with surprising regularity in both the App Store and Google Play.
• Both Apple and Google have restricted, and may again further restrict, the already limited security programming features available to third parties. Cybersecurity tools that work today might suddenly stop working in the next release of iOS or Android unless the vendor is strongly focused on finding new techniques to deliver their protection.

Fortunately for companies who are concerned about mobile phone security, both Apple and Google do provide built-in support for mobile device management tools.

MDM tends to focus on reducing what’s known in the jargon as the attack surface of devices used for company work, rather than detecting and blocking rogue behaviour when it does happen, for example by:

• Enforcing safe app configurations for work-related activity in which corporate data is used.
• Ensuring suitable minimum standards for device lock codes and device lock times.
• Enabling remote device lock, or even a remote wipe of some or all data, if a phone is lost or stolen.
• Preventing thieves from factory-resetting phones to make them suitable for resale.
• Detecting unauthorised or risky modifications to the operating system.

The trendy terms you will hear for phones that have been hacked to reduce security right down at the operating system level are rooting on Android, because root is the official name for the administrator account used by Android itself, and jailbreaking on iOS, a nod to the act of escaping from Apple’s carefully regulated ‘walled garden.’

MDM to the rescue

Annoyingly, perhaps, Apple and Google have come up with rather different MDM systems and terminologies, so that users who switch from iPhone to Android or vice versa may find the other’s approach a little confusing at first.

Loosely speaking, Apple devices generally rely on a single copy of apps such as an email clients, accessing two different accounts, each with their own, separately managed data stores.

Google’s approach involves two separate profiles, each with their own full copy of every app required for work and personal use, each with their own apparently independent storage, almost as though you had two phones and kept swapping between them.

Google also allows more options for how much power the IT team or security operations center (SOC) have over individual devices.

If you haven’t come across these initialisms before, prepare to learn about:

• BYOD, or bring your own device. Google calls this a Work Profile, but the phone belongs to you. The IT team can wipe the apps and data in your work profile, but they can’t perform a full factory reset and claim ownership of the device, which would effectively lock you out of it.
• COPE, or company owned but personally enabled. Google calls this Work Profile (Company Owned), and your IT team get slightly more control over the phone than if it belongs to you, notably that although they can’t snoop on your personal data or monitor your activity closely, they can do a factory reset, wiping your data and asserting their ownership at the same time.
• COBO, or company owned and business operated. Google calls this Fully Managed. The IT staff still don’t get the power to snoop on everything you do, but they do get more intrusive rights than in COPE mode, given that the device is intended for business use only. Notably, they can extract general usage data to look out for unwanted activity, even if you were using the device for personal reasons at the time.

Interestingly, Google has an MDM mode even stricter than Fully Managed, known as Dedicated, which is designed for kiosk-style devices such as bus stop signs or advertising hoardings, which can be used to keep the device locked into in a single app, preventing access to any other apps or even the home screen.

Apple’s approach is less granular.

Apple allows iPhones to be set up for what’s known as Zero-touch Enrolment, where the devices are bought by the company, pre-configured by a device distributor, and delivered as if truly new.

Users get all the delight of taking the product out of the box and peeling off the protective packaging as if it were their own, but get few or no choices in the setup process.

Alternatively, for users who want to use their own devices, Apple supports User Enrolment, which gives up less control and information to the IT team

For example, under Apple’s User Enrolment process:

• The device is registered with a pseudo-anonymous identifier, not with its baked-into-the-hardware universally unique  identifier and its international mobile equipment identity, known respectively by their initialisms UUID and IMEI . Your IT team will know it’s your device for as long as you remain enrolled and authorized to access work data on it. But if you later factory-reset the device, to use it for something else or to sell it on, your IT team won’t be able to identify it online in the future.
• The IT team don’t get any remote lock-out or remote wipe powers on the device. But they can cut you off from the data associated with any work accounts, essentially returning it to its un-enrolled state with no corporate data recoverable from it.

MDM for other values of M

Before we finish, we need to point out that although MDM started life as an alternative sort of cybersecurity toolkit for devices that didn’t or couldn’t enjoy the same levels of EDR protection as your laptop…

…its remit now extends, in Microsoft’s vocabulary at least, to laptops, desktops and even servers.

As mentioned above, Microsoft killed off its Windows Phone product nearly a decade ago, but still offers a set of products and services dubbed MDM, with operating system enrolment identifiers all the way from PRODUCT_­HOME_­BASIC, through PRODUCT_­CONNECTED_­CAR, to PRODUCT_­ENTERPRISE_­SERVER.

MDM seems a curious name for a cybersecurity product intended for use on systems such as Windows servers that you are probably already be protecting and managing with more powerful, broqder-brush tools such as EDR, inventory tracking, and directory services.

But it’s worth remembering, in Microsoft’s vocabulary at least, that the initialism MDM is used to refer to device management in general, whether that device truly is mobile or not.

What to do?

Getting value out of MDM, instead of merely putting cost into it, generally requires compromise by both sides:

• Be prepared to meet your IT team half way if you want to use your own phone for work. A well-devised MDM policy doesn’t need your IT team to get total remote control over your device. In a company where users and the IT team have learned to co-exist in mutual respect and harmony, giving a bit more power to the IT team than you might normally consider can help you, too. If your phone gets lost, stolen or snatched, having someone else on your side who can remotely purge company data from it, or even zap the entire device, could be a lifeline.
• Be prepared to meet your users half way if you want to implement MDM in your business. A well-devised MDM policy doesn’t need every user to give up total remote control over every device. In a company where the IT team and the users have learned to co-exist in mutual respect and harmony, giving a bit of leeway to your users needn’t put your corporate data at risk. If their phone gets lost, stolen or snatched, teaching them how to wipe it promptly for themselves, including purging company data from it, could be a lifeline.

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!

Featured image of a mobile pbone by Ravi Sharma via Unsplash.