Device Control Polices with Microsoft Defender for Endpoint and Endpoint Manager

Device Control is one of the core components of any Device Management solution. This identifies what devices the user can install in their system or plug and play. While there are devices that need to be installed on user computers such as printers, specific computer peripherals, and USB keys, you don’t want to allow the user to plug in just any device and use it. Chances are they are plugging a device with malware that can sneak through the network until it gains access to critical systems and maybe keys to the kingdom.

Controlling devices will predominantly lower your attack surface and this is a complete set of settings that comes under Microsoft Endpoint Manager’s Attack Surface Reduction policies.

This can be done in a few different ways. You can use GPOs or OMA-URI profiles within Endpoint Manager or simply can use the Endpoint Manager UI to set up the policies. For this to work with MEM, the device should be connected to the Endpoint Manager and must be onboarded to MDE so the services will be talking hand in hand.

Table of Contents

What can you Block/ Allow?

Plug and Play devices by specifying the Device IDs
Plug and Play devices by specifying the Instance IDs
Plug and Play devices by specifying Setup Classes
Removable Storage Devices
Bluetooth Connections

Required Licenses

Microsoft Defender for Endpoint Plan 1
Microsoft Defender for Endpoint Plan 2

Multiple Device or User Groups

Depending on the requirement and the business need create the groups accordingly. Chances are you have different set of devices or groups that you need to push the polices without hindering their daily tasks and maybe the call center users that you need to block all device types, but not the Keyboard, Mouse and Headset

Required Setup

Enabling Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria

This policy setting will change the evaluation order in which Allow and Prevent policy settings are applied when more than one install policy setting is applicable for a given device. Enable this policy setting to ensure that overlapping device match criteria is applied based on an established hierarchy where more specific match criteria supersede less specific match criteria. The hierarchical order of evaluation for policy settings that specify device match criteria is as follows:

Device instance IDs > Device IDs > Device setup class > Removable devices

Enable this via MEM Administrative Templates

Endpoint Manager Portal > Devices > Configuration Profiles > Create Profile >

Platform: Windows 10 and later
Profile type: Templates
Template type: Administrative Templates

Assignment: Preferred Device group/s that you planning to implement device control

Now that we have the control policy setup, we can look at the device settings now.

While you can use the standard GPOs, OMA-URI profiles to accomplish this task, I will be using Endpoint Manager as all the required policies are now in the UI.

Endpoint Manager Configuration

Endpoinr Manager > Endpoint Security > Attack surface reduction> Create Policy >

Platform: Windows 10 and later
Profile: Device Control
Provide a policy name

According to your requirement, provide the IDs Or move on to the next section of

Block or Allow Connected Devices

If you check the policy closely, there are 3 options where you can Block or Allow devices.

Block or allow installation by device identifiers (Hardware ID or Compatible ID)

This policy setting allows you to specify a list of plug-and-play hardware IDs and compatible IDs for devices that Windows is allowed to install

Check this doc about Hardware IDs

Block or allow installation by setup classes

This policy setting allows you to specify a list of device setup class globally unique identifiers (GUIDs) for driver packages that Windows is allowed to install

Check this doc to identify the GUIDs

Block or allow installation by device instance identifiers

This policy setting allows you to specify a list of Plug and Play device instance IDs for devices that Windows is allowed to install

Check this doc to read more

Block Direct Memory Access and Enumeration of external incompatible with Kernel DMA Protection

From Microsoft Text

Block direct memory access
This policy setting allows you to block direct memory access (DMA) for all hot-pluggable PCI downstream ports until a user logs into Windows. Once a user logs in, Windows will enumerate the PCI devices connected to the host plug PCI ports. Every time the user locks the machine, DMA will be blocked on hot plug PCI ports with no children devices until the user logs in again. Devices which were already enumerated when the machine was unlocked will continue to function until unplugged. This policy setting is only enforced when BitLocker or device encryption is enabled.

Enumeration of external devices incompatible with Kernel DMA Protection
This policy is intended to provide additional security against external DMA capable devices. It allows for more control over the enumeration of external DMA capable devices incompatible with DMA Remapping/device memory isolation and sandboxing. This policy only takes effect when Kernel DMA Protection is supported and enabled by the system firmware. Kernel DMA Protection is a platform feature that cannot be controlled via policy or by end user. It has to be supported by the system at the time of manufacturing. To check if the system supports Kernel DMA Protection, please check the Kernel DMA Protection field in the Summary page of MSINFO32.exe.

Block Removable Storage or Allow Read Only

As the policy says this will block all removable storage devices both Read/ Write

Below policy will block Write access from the removable storage

Bluetooth Settings

This will simply block Bluetooth connections in the device

However you can still allow the Bluetooth service by the Universally Unique IDentifier (UUID).

Set a list of allowable services and profiles. String hex formatted array of Bluetooth service UUIDs in canonical format, delimited by semicolons. For example, {782AFCFC-7CAA-436C-8BF0-78CD0FFBD4AF}.

Use KQL Over Device Control

Once the policies have been activated, depending on their behaviour, the events will start recording in Microsoft Defender for Endpoint and you can use KQL to see reports and perform threat hunting tasks. I have discussed about threat hunting in this previous article so you can read more about it.

For this, DeviceEvents table can be used and start writing your queries.
Action types: PnpDeviceConnected, PnpDeviceBlocked, PnpDeviceAllowed

Final Thoughts

Device Control is vital task in a controlled environment and for better security and compliance posture. Sure there can be some noise from the end users at first, but at the end of the day this is all about protecting them, organizational data, apps and making sure the doors are secure. Hope this post was useful and until I see you in my next post, cheers!