Considerations when deploying MTD with Android Enterprise

Mobile Threat Defence (MTD) is an increasingly popular point of discussion for endpoint management, particularly with the ever increasing worry of corporate devices falling victim to potentially harmful applications, network attacks and more.

As Android Enterprise adoption continues to grow, an important question arises more and more frequently: how does MTD work with the various Android Enterprise deployment scenarios?

Compared to legacy Android management, where organisations leveraged the now deprecated device administrator APIs to gain control over a device and push corporate applications out alongside personal (preferably containerised), Android Enterprise with its stronger focus on user privacy and corporate data protection does pose an interesting challenge.

The goal for an MTD is full visibility over the whole device with the ability to interject when threats are detected. Visibility differs by MTD and what’s supported, but may include: 

  • System applications (apps pre-loaded from the OEM, mostly required for a functioning Android OS)
  • User-installed applications (Play or sideloaded)
  • Corporate applications
  • Information about the network the device connects to in order to detect man-in-the-middle attacks, SSL stripping, cert spoofing and more
  • Device details & posture (root detection, unknown sources, debugging, etc)
  • Detection of applications attempting to open links which may be dangerous

Here’s a breakdown of visibility per deployment scenario:

Work-managed (fully managed)

The simplest and therefore easiest to begin with. A fully managed (COBO) device for all intents and purposes acts similarly to a legacy-managed Android handset where MTD is concerned.

The organisation distributes the MTD agent to the device directly and, as the MTD resides within the only profile on the device, it detects:

  • System and corporate applications (technically user apps also, but permitting this would not be recommended)
  • Network information
  • Device details and posture
  • Malicious links opened from other applications on the device

As a fully managed device, there are no concerns over lack of visibility, and should the MTD make use of VPN, it will run system-wide.

COSU (dedicated device)

A COSU device is normally one utilising a kiosk, either natively (and particularly following improvements with Android Pie) or, more likely, via an EMM vendor kiosk/launcher.

Much like the fully managed device, deploying MTD to a COSU device will provide full access akin to a legacy enrolment, and can see:

  • System and corporate applications
  • Network information
  • Device details and posture
  • Malicious links opened from other applications on the device

There’s only one caveat; as most MTD solutions cannot auto-activate on Android devices today, an MTD application would need to be made visible within the kiosk environment in order to allow for the opening and activation of the service. Exceptions apply so do check this with the MTD vendor.

Work profile (BYOD)

NB: From Android 11 the below work profile considerations also apply to COPE!

Work profile is designed for Bring Your Own Device (BYOD) deployments, however in reality and unfortunately work profile is utilised on many, many corporately owned devices across the world, which in general is less than ideal, but in the case of MTD is definitely not a particularly good thing.

When a corporate application is deployed into a work profile, it is within an isolated, separately encrypted profile on the device with zero visibility of applications and limited visibility of actions outside. For a BYO device this is great as user privacy is fiercely protected, as it rightly should be.

As a result of the privacy protections in place, an MTD solution can only see the following:

  • System and corporate applications
  • Device details and posture
  • Network information
  • Malicious links opened from other applications within the profile

There is therefore no visibility of user-installed applications, which is arguably more important in an environment where users may install their own applications, compared to the approved-only approach offered with dedicated and fully managed devices.

Furthermore, unless links are opened within the work profile, the MTD will not be able to intercept any attempt to trick users into clicking a malicious URL; the MTD agent simply cannot see it.

Finally, should the MTD make use of a VPN, traffic will only be routed within the work profile; the VPN is not device-wide.

The less-than-ideal workaround for this would be to deploy the MTD into the parent (personal) profile of the device, however without corporate management of this profile, users would have to install and activate the application manually by fetching it from the Play Store.

Managed devices with work profiles (COPE)

NB: The below considerations should be applied only to Android 8.0-10. Android 11 utilises a BYOD style COPE implementation.

The COPE approach, on paper, technically has the capability to add the missing management aspect to the above BYOD deployment scenario.

In reality though it very much depends on how the EMM/UEM vendor has chosen to implement it; vendors who believe the managed parent (personal) profile should be left mostly unmanaged will offer fewer configuration options, whilst others may believe it is up to the organisation to define the boundaries of personal use and offer a level of management directly comparable to a fully managed (work-managed) device.

In terms of visibility as defined by the Android Enterprise APIs, the MTD should be able to see:

  • System, corporate and/or user applications
  • Network information
  • Device details and posture
  • Malicious links opened from other applications on the device

This could be expected if the MTD is deployed into the parent profile, what is more likely at the moment however is the MTD being deployed into the work profile of the COPE device and as such it will by default lose access to user application visibility and visibility of device-wide malicious links.

As a direct comparison:

MTD in parent profile

  • System and user applications
  • Network information
  • Device details and posture
  • Malicious links opened from other applications on the device

MTD in work profile

  • System and corporate applications
  • Network information
  • Device details and posture
  • Malicious links opened from applications within the work profile

Once again this will need to be validated with MTD and UEM vendors as it really can be a pick-and-mix of functionality which is yet to be widely adopted still.

Should the MTD be deployed in the parent profile, any VPN connectivity will be system-wide, otherwise if deployed in the work profile the VPN will again, like BYOD, only route traffic within the work profile itself.

Touching on VPN capabilities

Some MTD vendors offer VPN capabilities, or may possibly even entirely rely upon a persistent VPN connection to be remotely useful.

The problem with this approach, though valid and arguably potentially necessary for some traffic management capabilities prior to Android Pie (when APN configuration support was introduced), is as follows:

Android supports one active VPN session at a time.

This means if an organisation relies on VPN for traffic routing back into the corporate network, ad-hoc access to resources or anything else, these VPN networks will clash, and MTD protection will suffer.

Add in the option of enforcing an always-on VPN connection through the UEM against the VPN solution of choice for an organisation and MTD solutions which fundamentally rely on a VPN connection are basically useless.

On the flip-side, where no corporate VPN is in use, the same always-on VPN enforcement can be applied to the MTD, ensuring even if the user kills the VPN connection, it’ll start right back up again.

This limitation is very much worth consideration before making a decision on MTD vendors, as it can result in a lot of wasted time and effort when it becomes clear it isn’t suitable. Organisations reliant on an existing VPN solution should make this abundantly clear when engaging with MTD vendors.

Conclusion

Depending on the Android Enterprise deployment scenario in use, MTD protection can range from basic – protecting primarily corporate data within a work profile, to full – protecting the entire device with no visibility issues.

Considering under what deployment scenario an MTD would be used ahead of time will ensure there’s no confusion about the capabilities available, and with enough forward thinking, the need for an MTD could and should influence the deployment scenario chosen by the business to begin with.

That about covers Android Enterprise. For more information about MTD in general, I’d recommend the following BrianMadden.com articles on planning for and deploying an MTD solution.


Comments

  1. Hi Jason,

    thanks for the great overview of the ‘problem’ we run into when using MTD on a AE device. In the end I think that the ultimate solution would be if MTD providers would make it possible to activate their MTD client twice on a device, once in the work profile and onetime outside of the work profile. Currently when registering a device in MTD through an MDM connector there is no way to do this.

    Regards,
    Almar

  2. MTD vendor depending that’s not unheard of, so likely something you need to bring up with the vendor you work with directly; if you’re doing it through EMM connector it naturally can’t automatically do so outside of EMM control, however manual invitations or global activation codes would offer alternative means to manually activate.

    Should an EMM build the capability to push to both work and parent profile via managed Google Play accounts then you’ll be set, but BYOD will always struggle by comparison.

  3. says:

    Hello Jason,

    great overview on MTD in the Android space - as always.

    One question, I’m asking myself: your article focuses on the detection of threats. I wonder what capabilities a 3rd party MTD solution app can have on an Android device to actually protect (instead of only detecting).

    In the end it is just another app, isn’t it. Would it be able to trigger any consequences? E.g. prevent the installation of a PHA or prevent the connection to potentially rogue access point. Does it have the power to do so in Android Enterprise? Not being an EMM client… Especially when I think about the COPE changes coming with Android 11. What’s your view on that?

    Best regards,
    McT

  4. Typically MTD hooks into your EMM platform, and so yes although you’re 100% that they predominantly detect rather that protect, the protect comes from that communication with the server(s) that manage the device on the app side of things.

    If the MTD detects a known bad app, it can ping the EMM to put the device out of compliance, mark it as high risk and have it moved groups/folders, plenty more. It can do this in almost real-time given it’s on the device and monitoring app installation & changes. What happens to that device then is entirely down to the EMM admin and range from an email notification to an enterprise wipe.

    On active protection, that tends to be more on the network side of things. It can and will block a bad known URL, prevent phishing, and generally get in the way. It does this via traffic proxy or VPN, depending on the solution.

    With the COPE changes it makes things more difficult, but actually the network stack and device posture can still be monitored, it’s the visibility of parent profile apps - which could only happen in any case when the MTD is installed on the parent profile - that suffers, as now you’re entirely reliant on expecting users to install it themselves, like work profile deployments (BYOD).

Something to say?

Comment