2.3.2. Security Policies and Attack Surface Reduction Rules
💡 First Principle: Many attacks rely on behaviors that legitimate users rarely need: Office spawning a child process, scripts launching obfuscated code, a process reading LSASS memory. Attack surface reduction (ASR) rules forbid those behaviors outright, removing the technique instead of waiting to detect it. Because a few legitimate tools do need these behaviors, ASR rules are rolled out carefully, with measurement before enforcement.
Security policies for MDE-protected devices are managed as endpoint security policies: antivirus, firewall, endpoint detection and response, and attack surface reduction profiles. They can be authored in the Defender portal (through MDE security settings management) or in Microsoft Intune, and ASR rules can also be deployed through Configuration Manager, Group Policy, or PowerShell for individual devices. Whatever the tool, each ASR rule runs in a mode:
| Mode | Behavior | When to use |
|---|---|---|
| Not configured / Disabled | Rule inactive | Rules you've decided not to use |
| Audit | Logs what would have been blocked; user unaffected | First deployment stage; measure impact |
| Warn | Blocks but lets the user bypass after a warning | Rules with occasional legitimate use (not supported by every rule) |
| Block | Prevents the behavior | Final state once exclusions are tuned |
The rollout pattern is a favorite drag-drop sequence: deploy in audit to a pilot ring, review audit events in the ASR rules report and advanced hunting (the DeviceEvents table records action types such as AsrOfficeChildProcessAudited and AsrOfficeChildProcessBlocked), add narrowly scoped exclusions for confirmed legitimate files or folders, then move to block or warn, expanding ring by ring.
Some rules are special. Microsoft groups three as standard protection rules that are low-risk to enable broadly: blocking abuse of exploited vulnerable signed drivers, blocking credential stealing from the Windows local security authority subsystem (LSASS), and blocking persistence through WMI event subscription. Two rules don't support warn mode: the LSASS credential-stealing rule and the rule blocking Office applications from injecting code into other processes. Every ASR rule depends on Microsoft Defender Antivirus, and several also need cloud-delivered protection.
⚠️ Exam Trap: "Minimize user disruption while evaluating ASR rules" means audit mode, not warn mode. Warn still interrupts the user. And exclusions should be specific (a file path or hash), because a broad folder exclusion reopens the attack surface the rule was meant to close.
Reflection Question: A pilot shows the "Block Office applications from creating child processes" rule would block a finance macro that launches a reporting tool. What evidence would you gather, what exclusion would you create, and why not simply leave the rule in audit forever?
