Controlling USB and removable storage with Defender device control and Intune

USB sticks are still the simplest way to walk data out of a building or malware into it. Defender for Endpoint device control lets you decide which removable devices work, what users can do with them and who gets to do it, with Intune as the management plane. In this post I'll explain the group, rule and entry model, build a block-with-exceptions policy using reusable settings, and show how to prove it works and why it sometimes doesn't.

Prerequisites#

• Windows devices onboarded to Defender for Endpoint (Plan 1, Plan 2 or Defender for Business) and enrolled in Intune. Device control is a Defender feature: a device that receives the policy but isn't onboarded enforces nothing and reports nothing.
• Intune permissions to create Attack surface reduction policies, such as Endpoint Security Manager.
• If Group Policy ever managed device control on the same devices, remove those settings first. Microsoft notes that the ControlPolicyConflict setting doesn't apply to the Defender CSP, so conflicting GPO settings aren't overridden.
• The Device Control profile isn't supported for Windows Server managed through security settings management, even though the profile lists Windows Server as a platform.

How it works#

Device control has three building blocks:

• Groups describe devices by their properties: a primary ID such as RemovableMediaDevices, CdRomDevices, WpdDevices or PrinterDevices, or specifics such as vendor and product ID, serial number, hardware ID, instance path or friendly name. In Intune, groups are reusable settings.
• Rules (each row in the Intune profile is one) apply when a device is in all of the included groups and none of the excluded groups. Intune does not honour rule order, so rules must not overlap.
• Entries inside a rule say what happens: Allow, Deny, AuditAllow or AuditDeny for a given access mask, with options for a user notification and an event.

Masks add up: 7 means device read, write and execute. The Intune interface offers options such as Read (1), Write (2), Execute (4) and Print (64); Microsoft notes that not every feature is exposed in the Intune UI, while the XML format supports all of them. If no rule matches, the default enforcement applies, and out of the box that is Allow. Audit entries are evaluated after the enforcement decision, so an audit-only policy inherits the default enforcement and blocks nothing.

Step-by-step: block removable storage, allow approved drives#

Step 1: Create the reusable settings groups#

In the Microsoft Intune admin center, go to Endpoint security › Attack surface reduction › Reusable settings and add two groups of type Removable storage:

• All removable storage: one entry with Primary ID set to RemovableMediaDevices.
• Approved drives: one entry per approved device, matched on serial number or vendor and product ID. Avoid friendly name alone; many devices share it.

To find the identifiers, open Device Manager, select the drive and read Device instance path on the Details tab. It has the shape USB\VID_xxxx&PID_xxxx\serial: bus, device ID and serial number in one string. Microsoft's Intune documentation still describes reusable settings groups for device control as public preview.

Step 2: Create the Device Control profile#

Go to Endpoint security › Attack surface reduction › Create policy, platform Windows, profile Device Control. In the Device Control section add two rules:

1. Deny write to unapproved drives: Included ID = All removable storage, Excluded ID = Approved drives, type Deny, access mask Write (add Execute if you also want to stop programs launching from the drive). Set the options to notify the user and generate an event.
2. Allow approved drives: Included ID = Approved drives, type Allow, access mask Read, Write and Execute.

Give rules descriptive names: the name appears in the user's toast notification, in advanced hunting and in the report. Assign the policy to a pilot device group.

Step 3: Audit before you block#

For the pilot, run the deny rule as AuditDeny first, or add an audit entry next to the enforcement entry, so you can see which devices would be hit and who uses them. Microsoft advises always pairing audit entries with an Allow or Deny entry, because audit alone inherits the default enforcement. Expect at most one toast per hour per denied device, and up to 300 device control events per device per day in advanced hunting.

Step 4: Decide on default enforcement and device types#

A deny rule covers only what its groups match. For a true default-deny posture, change the default enforcement to Deny and allow only approved devices. Microsoft's documentation says this default can't be changed in the Intune graphical interface; the documented routes are a custom profile with the OMA-URI ./Vendor/MSFT/Defender/Configuration/DefaultEnforcement (integer, 1 = Allow, 2 = Deny) or Group Policy. The same CSP area has DeviceControlEnabled (0 or 1) and SecuredDevicesConfiguration, a pipe-separated list of the device families to protect, such as RemovableMediaDevices|WpdDevices. Default-deny also blocks CD/DVD drives, portable devices and printers unless you add Allow rules for them.

Step 5: Printers, briefly#

Printer protection uses the same model with a Printer device reusable group: match on primary ID PrinterDevices, a PrinterConnectionId such as USB, Network, Corporate or Universal, or vendor and product ID, and use access mask 64 (Print). A common pattern is to deny printing to USB and file printers while allowing corporate print queues.

Verify#

On a pilot device, plug in an unapproved drive and try to copy a file to it. You should see the toast with the rule name and the copy should fail; an approved drive should behave normally. Then confirm from the portal with advanced hunting:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "RemovableStoragePolicyTriggered"
| extend f = parse_json(AdditionalFields)
| project Timestamp, DeviceName, InitiatingProcessAccountName,
    Policy  = tostring(f.RemovableStoragePolicy),
    Verdict = tostring(f.RemovableStoragePolicyVerdict),
    Access  = tostring(f.RemovableStorageAccess),
    Media   = tostring(f.MediaName), Serial = tostring(f.SerialNumber),
    VID     = tostring(f.VendorId),  PID    = tostring(f.ProductId)
| order by Timestamp desc

The verdict tells you whether the rule allowed, denied or only audited the access, and the media columns give you the exact identifiers to add to the approved group. Reports › Endpoints › Device control in the Defender portal shows the same media usage without the 300-event cap. In Intune, the policy's device status should show Succeeded.

Troubleshooting and gotchas#

• Policy shows Succeeded but nothing happens. Confirm the device is onboarded and its sensor is Active; device control needs Defender for Endpoint. Then check for a leftover Group Policy configuration.
• USB is still writable. Run the query above. No event means no rule matched: the group's identifier is wrong (compare it with the Media, Serial, VID and PID columns) or the drive sits in an excluded group. An Allow verdict means another rule allowed it; rules aren't ordered, so make the groups non-overlapping. An audit-only verdict means you forgot the enforcement entry.
• Everything got blocked. Default enforcement was set to Deny without Allow rules for printers, CD/DVD or portable devices.
• Phones still move files. Phones and cameras connect as WpdDevices, not removable media; add that primary ID to the group if you want them covered.
• Co-managed devices. Custom OMA-URI profiles only apply when the Device Configuration workload is on Intune.
• Defender portal option. You can create the same Device control policy under Endpoint security policies in the Defender portal, but it applies only to Intune-enrolled devices.

References#

• Device control policies in Microsoft Defender for Endpoint
• Configure device control in Microsoft Defender for Endpoint
• View device control events and information in Microsoft Defender for Endpoint