The Blast Radius Problem

Quantifying blast radius before deployment

Blast radius is not binary — it exists on a spectrum from "affects nobody" to "locks out the entire company." The assessment methodology for any endpoint security control follows three questions.

Who is affected? Which users, groups, or device types will experience a behavior change when this control is enforced? An ASR rule that blocks Office macros from calling Win32 APIs affects users who rely on macro-heavy LOB applications — typically finance, operations, and legacy workflow teams. AV cloud protection raised to High+ affects nobody visibly — occasional 10-second file analysis delays that most users do not notice. The affected population determines the scale of potential disruption and the stakeholder communication required before deployment.

What is the failure mode? When a legitimate action is blocked, what does the user experience? A blocked application — ASR blocks an Office macro, WDAC blocks an unsigned executable — is high-severity because the user cannot perform their job function. A blocked USB device is medium-severity because the user has alternative file transfer methods. A delayed file open from cloud protection analysis is low-severity because the user waits a few seconds. The failure mode severity determines how fast the support response must be and whether a pilot deployment is mandatory or optional.

What is the recovery path? When a false positive occurs, how long does it take to restore normal operation? An ASR exclusion can be deployed via Intune within minutes and takes effect at the next policy sync — typically 1–8 hours, or immediately if a forced sync is triggered from the Intune portal or the Company Portal app on the device. A WDAC supplemental policy requires creating, signing, and deploying a new policy file, which can take 24–48 hours depending on the signing infrastructure and policy distribution mechanism. A compliance-driven CA lockout requires the user to remediate their device compliance issue, which may require IT assistance if the remediation involves an OS update or a configuration change the user cannot make themselves. The recovery time determines the business impact duration of each false positive, and it should be documented in the blast radius assessment before deployment — not discovered during the incident.

The exclusion lifecycle

Every exclusion to a security control is a hole in the defense. Necessary holes, often — but holes nonetheless. Exclusions must be managed with the same discipline as the controls themselves.

An exclusion has a lifecycle: it is requested by the affected team or identified during audit data analysis. It is justified with a specific business reason why the exclusion is needed. It is documented — which control, which application, which file path, which users. It is approved by the security team. It is deployed through Intune. And critically, it is reviewed on a schedule — quarterly or annually — to determine whether the exclusion is still needed. Has the application been updated to eliminate the conflict? Has the business process changed? Has the excluded application been decommissioned?

Exclusions without review dates become permanent security gaps. An AV exclusion created for a SQL Server backup directory in 2022 may still be excluding that directory from scanning in 2026 — even if the SQL Server has been migrated to a new path. The exclusion now protects an empty directory while the backup directory on the new path has no exclusion and may be causing AV performance impact during backup windows. The exclusion register solves this: every exclusion has an owner, a justification, a creation date, and a mandatory review date.

The most dangerous exclusion pattern is the vendor-requested directory exclusion. A vendor requests that you exclude their entire installation directory from AV scanning "for performance reasons." The directory contains 200+ executables, DLLs, and configuration files. A directory-level exclusion means AV will not scan any file placed in that directory — including malware that an attacker deposits there knowing it will not be scanned. Attackers actively target excluded directories: if they discover that C:\Program Files\VendorApp\ is excluded from AV scanning, they will write their implant to that directory. The correct approach: identify the specific files causing the performance issue — typically database files, high-IO log files, or large temporary files — and exclude only those specific file extensions or paths. Document the vendor's recommendation, your actual implementation, and the security rationale for the narrower exclusion.

Not all exclusions carry equal security risk. An exclusion that allows a finance Excel workbook to launch a specific PDF generator executable is low-risk — the exclusion permits a known binary at a known path from a known Office document. An attacker who wants to exploit this exclusion would need to modify the specific Excel workbook or replace the specific PDF generator binary, both of which require prior access to the file system. An exclusion that allows Outlook to launch PowerShell is high-risk — this is exactly the attack chain that phishing-to-execution campaigns use. The exclusion permits any PowerShell process spawned from Outlook, which means a malicious email that triggers PowerShell execution would bypass the ASR rule entirely. High-risk exclusions demand compensating controls: a custom detection rule that alerts on PowerShell launched from Outlook with suspicious command-line patterns, or a WDAC policy that restricts which PowerShell scripts can execute in that context.

The raw ASR audit event on the local endpoint shows exactly what the rule would have blocked — the evidence the analyst uses to classify each trigger as legitimate or suspicious.

Log Name:      Microsoft-Windows-Windows Defender/Operational
Source:        Microsoft-Windows-Windows Defender
Event ID:      1121
Task Category: None
Level:         Warning
Computer:      DESKTOP-FIN03.northgate.local
Description:
  Windows Defender Exploit Guard has blocked an operation
  that is not allowed by your IT administrator.
  ID:                56A863A9-875E-4185-98A7-B882C64B5CE5
  Detection Time:    2026-02-14T10:32:41.200Z
  User:              NORTHGATE\j.harper
  Path:              C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE
  Process Name:      C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  Target Commandline: powershell.exe -File "C:\Finance\MonthEnd\process-reports.ps1"

This Event ID 1121 is the ASR audit record that the KQL query aggregates at fleet scale. The GUID identifies the specific ASR rule (56A863A9 = "Block Office from creating child processes"). The Path shows EXCEL.EXE as the parent. The Process Name shows powershell.exe as the blocked child. The Target Commandline reveals the specific script — process-reports.ps1 in the Finance directory. This is a legitimate finance workflow, not an attack. The analyst adds the specific script path as an exclusion, and the rule can move to block mode knowing this workflow will continue to function.

The exclusion register should categorize every exclusion by risk level — low (excludes a specific known-safe binary), medium (excludes a file type or path pattern that could be abused), or high (excludes an attack-relevant process chain). High-risk exclusions get reviewed quarterly. Low-risk exclusions get reviewed annually. All exclusions get an owner who is accountable for the review.

// ASR audit data analysis — identify applications that would be blocked
DeviceEvents
| where Timestamp > ago(14d)
| where ActionType == "AsrOfficeChildProcessAudited"
| summarize
    EventCount = count(),
    UniqueDevices = dcount(DeviceName),
    UniqueUsers = dcount(AccountName)
    by InitiatingProcessFileName, FileName
| sort by EventCount desc

This query shows every application that would be blocked if the "Block Office applications from creating child processes" ASR rule moved from audit to block mode. Each row is an application pair: the Office process (InitiatingProcessFileName) and the child process it spawns (FileName). High EventCount with a recognizable application name is a legitimate LOB application that needs an exclusion. Low EventCount with an unfamiliar process name warrants investigation — it may be a genuine attack attempt that the rule should block. The audit data is the evidence that drives every enforcement decision.

Blast radius in practice: the NE ASR deployment

The ASR deployment at NE illustrates blast radius at three levels for the rule "Block Office applications from creating child processes."

Direct blast radius. Any Office macro that spawns a child process — cmd.exe, PowerShell, wscript.exe — is blocked. At NE, 3 finance department Excel workbooks contain macros that launch PowerShell for data processing, and the engineering team has a Word template that launches an AutoCAD converter. The direct blast radius: 4 applications used by approximately 20 users across 2 departments.

Indirect blast radius. The finance team cannot process month-end reports without the macro workbooks. The month-end close is delayed by 2 days while IT creates ASR exclusions for the specific files. The indirect blast radius extends beyond the 15 directly affected users to the CFO's board reporting timeline, the accounts payable processing schedule, and the vendor payment cycle.

Reputational blast radius. The CISO deployed a security control that broke the finance team's critical workflow without warning. The CFO questions whether the security team understands business impact. Future security deployments face increased resistance from business units who remember the finance incident. The reputational blast radius — the security team's credibility and the organizational appetite for further improvements — is the hardest to recover from and the easiest to prevent.

The blast radius assessment that prevents all three levels: before moving the ASR rule from audit to block, run the KQL query above against 14 days of audit data. Identify the 4 affected applications. Create ASR exclusions for those specific file paths before enabling block mode. Test with one user per affected department. Confirm the exclusions work. Then deploy block mode fleet-wide. The finance workflow continues uninterrupted. The engineering template continues functioning. The ASR rule blocks malicious Office child processes on all other devices — and the audit data shows that the rule would have blocked 23 additional events from unknown processes during the audit period that are not attributable to any legitimate application. Those 23 events are either benign system noise or genuine attack attempts. Either way, the rule is providing value that the 4 exclusions do not diminish.

Total preparation time: 2 hours for exclusion creation and testing, on top of the 2–4 week audit data collection period that Phase 1 already completed. The alternative — deploying without the assessment — takes 5 minutes and produces 3–5 days of organizational disruption that may permanently damage the security program's credibility.

Communicating blast radius to stakeholders

The deployment conversation with IT operations, business unit leaders, and management follows a predictable pattern: "Will this break anything?" The answer is always "it might, and here is our plan for that."

The communication framework for each deployment includes what is being deployed in plain language, who might be affected, what the failure mode looks like if a false positive occurs, how quickly you can fix it, what the security benefit is, and what happens if you do not deploy it. The last point is often omitted and is the most important: every undeployed security control has a blast radius too — the blast radius of a successful attack. The ASR rule that blocks Office from spawning PowerShell has a blast radius of "some macro-dependent applications may need exclusions." The absence of that ASR rule has a blast radius of "every phishing email with a malicious macro succeeds and the attacker has code execution on the endpoint."

Framing the conversation as a comparison of blast radii — the blast radius of deploying with exclusions versus the blast radius of not deploying — transforms the discussion from "security wants to break things" to "which risk is the organization accepting?" Module ES4 includes the communication templates for each ASR rule deployment, with the specific security benefit and risk-of-inaction framing.

The executive escalation response is the critical test of blast radius preparation. When the CFO's assistant reports that a security control broke their workflow, the response time and specificity determine whether the security program retains organizational support. Triage the specific issue within 30 minutes — check MDE for ASR block events on the user's device, confirm the specific rule and specific application, create the targeted exclusion, and communicate the resolution with an estimated time to effect. A fast, specific response to the individual issue prevents a blanket "roll back everything" directive. Executive-adjacent users generate disproportionate escalation pressure — not because their workflows are more important, but because their escalation path is shorter. The blast radius assessment anticipates these users specifically and pre-creates exclusions for their known applications before enforcement day.

The worst outcome is not a false positive that causes a support ticket. The worst outcome is a false positive that causes an executive escalation that results in the entire security control being disabled permanently. The blast radius assessment and the exclusion preparation exist to prevent that outcome by ensuring that the first week of enforcement is uneventful — because every known conflict was identified during the audit period and mitigated before block mode was enabled.