ES0.8 The Blast Radius Problem
Figure ES0.8 — Blast radius categorisation for endpoint security controls. Deploy low-blast-radius controls first for immediate security improvement with minimal risk. High-blast-radius controls require weeks of audit data and stakeholder preparation.
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 behaviour 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. An AV cloud protection level change affects nobody visibly (occasional 10-second file analysis delays). The affected population determines the scale of potential disruption.
What is the failure mode? When a legitimate action is blocked by the security control, what does the user experience? A blocked application (ASR, WDAC) is high-severity — the user cannot perform their job function. A blocked USB device (device control) is medium-severity — the user has alternative methods. A delayed file open (cloud protection) is low-severity — the user waits 10 seconds. The failure mode severity determines the urgency of the support response.
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 in minutes and takes effect within the next policy sync (typically 1-8 hours). A WDAC supplemental policy requires creating, signing, and deploying a new policy — potentially 24-48 hours. A compliance-driven CA lockout requires the user to remediate their device, which may require IT assistance. The recovery time determines the business impact duration.
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), justified (the business reason why the exclusion is needed), documented (which control, which application, which path, which users), approved (by the security team), deployed, and reviewed (quarterly or annually — is the exclusion still needed? has the application been updated to eliminate the need? has the business process changed?).
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 is now protecting an empty directory while the backup directory on the new path has no exclusion (and may be causing performance issues because the AV is scanning backup files during backup windows). The exclusion register solves this: every exclusion has an owner, a justification, and a review date.
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. Do you apply the exclusion? No — or at least, not as requested. A directory-level exclusion means the AV will not scan ANY file in that directory, including malware that an attacker places there knowing it will not be scanned. The correct approach: identify the specific files causing performance issues (typically database files, high-IO log files, or large temporary files) and exclude only those specific file extensions or paths. If the vendor insists on a directory exclusion, request the specific file types that need exclusion and create extension-based exclusions within the directory rather than excluding the entire path. Document the vendor’s recommendation, your actual implementation, and the security rationale for the narrower exclusion.
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 phase includes: what is being deployed (specific control, in plain language), who might be affected (specific user groups), what the failure mode looks like (what the user will experience if a false positive occurs), how quickly you can fix it (recovery time), what the security benefit is (what attack technique this control prevents), and what happens if you do not deploy it (the risk of inaction). 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.”
Try it: write a blast radius assessment for your highest-priority control
Choose the first control you plan to deploy from your gap assessment. Write the assessment:
Control: (name and description) Audit data summary: (X events per day across Y applications and Z users) Affected population: (which users/groups/device types) Failure mode: (what happens when a legitimate action is blocked) Failure severity: (high = cannot work / medium = workaround available / low = minor inconvenience) Recovery path: (exclusion deployment time, policy sync delay, user remediation steps) Mitigation plan: (exclusions to create before enforcement, pilot group, expansion criteria) Security benefit: (ATT&CK technique prevented, attack scenarios interrupted) Risk of inaction: (what attack scenarios succeed if this control is not deployed)
Present this assessment to IT operations before deploying the control. The structured format demonstrates that you have thought through the impact and have a plan. It transforms the conversation from “security wants to break things” to “security has a deployment plan with rollback procedures.”
The myth: Business operations take priority over security controls. If a security control blocks a legitimate application, the control must be disabled until the conflict is resolved.
The reality: The correct response to a conflict between a security control and a business application is not “disable the control” — it is “create a targeted exclusion that preserves the control’s protection for all other scenarios.” Disabling an entire ASR rule because one application conflicts with it removes protection for 864 endpoints to accommodate 12 users. Creating an exclusion for that specific application preserves protection for 864 endpoints while allowing the 12 users to continue working. If the business requirement genuinely cannot coexist with any form of the security control, that is a risk acceptance decision that should be documented, approved by the appropriate risk owner, and reviewed periodically. “The business requirement wins” is valid — but it must be an explicit, documented decision, not a default response that silently removes security controls.
Troubleshooting
“We deployed an ASR rule in block mode and it is causing help desk tickets. How do we respond?” First, identify the specific application and the specific rule causing the block (the MDE portal shows ASR block events with the application path and rule name). Create a targeted exclusion for that application. Deploy the exclusion via Intune. Communicate to the affected users that the issue is resolved and the fix will take effect within the next policy sync (up to 8 hours, or force a sync via Intune). Do NOT disable the entire rule — the rule is protecting the other 850+ devices that are not affected.
“Our CFO’s assistant says the new policy broke their workflow and wants it reversed immediately.” Triage the specific issue. Is it actually caused by the security control? (Check the MDE portal for block events on the user’s device.) If yes, create the exclusion for the specific application. If not, the issue is unrelated to the security deployment. In either case, respond within 30 minutes — executive-adjacent users generate disproportionate escalation pressure. A fast response to the specific issue prevents a blanket “roll back everything” directive.
Blast radius assessment in practice: the NE ASR deployment
The ASR deployment at NE illustrates blast radius assessment across all three categories. Consider the ASR 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. These macros stop working when the ASR rule moves to block mode. The direct blast radius: 3 workbooks used by approximately 15 finance users.
Indirect blast radius: The finance team cannot process their month-end reports without these macros. The month-end close is delayed by 2 days while IT creates ASR exclusions for the specific workbooks. The indirect blast radius: the finance team’s monthly close timeline, which affects the CFO’s reporting to the board.
Reputational blast radius: The CISO deployed a security control that broke the finance team’s critical workflow. The CFO questions whether the security team understands the business impact of their changes. 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 security improvements.
The blast radius assessment that prevents this: before moving the ASR rule from audit to block, query the audit data for block-would-have-occurred events. Identify the 3 finance workbooks. Create the ASR exclusions for those specific files before enabling block mode. The finance workflow continues uninterrupted. The ASR rule blocks malicious Office child processes on all other devices. The blast radius is assessed and mitigated before the control takes effect.
You're reading the free modules of this course
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.