The Blast Radius Problem

Introduction

Every enforcement decision breaks something for somebody, and the deployments that fail are the ones where nobody put a number on it beforehand.

This section is about producing that number, being honest about what it cannot include, and reading what actually happened afterwards from the four events Defender writes. The estimate matters less as a prediction than as a thing you can be held to: a number you produced before the change is what makes the conversation after it a review rather than an argument.

You will finish able to count devices, users and processes from audit data, explain why every such count is a floor, name the events that record a block and a user override, and put the trade in front of somebody who does not care about ASR and does care about month end.

Blast radius is not a severity and it is not a risk rating. It is a count of the specific things a change will touch, and the reason to insist on counts is that they can be wrong in a way a rating cannot. Somebody can check 47 and nobody can check moderate.

Three counts do the work. Devices, because that sizes the pilot and the support load. Users, because that is who raises tickets and who complains to somebody senior. And distinct processes, because that is the number that tells you how much exclusion work stands between you and enforcement. Those three answer different questions and reporting only the first is what makes a change look small.

Reports > Attack surface reduction > Detections, 30 days
filtered to one rule, grouped by triggering process

  ledger-macro-host.exe     31 devices    finance
  cad-export-helper.exe     12 devices    engineering
  reportbuilder.exe          4 devices    finance
  --------------------------------------------------
  3 processes, 2 owners, 47 devices

Read the process column and the owner column, not the device total. Three rows means three conversations and three exclusions to write; the 47 is the number that goes in the change request and the 3 is the number that predicts whether the change finishes this month.

The third is the one most often left out and the most useful. Forty-seven devices running one application is one exclusion and a short conversation with whoever owns it. Forty-seven devices running nine different applications is nine investigations, nine owners, and a rollout that will not finish this quarter. The device count is identical in both cases.

Read the last line. A percentage of the estate is the figure that gets quoted and it is the one that collapses the difference between those two changes. Quote all three counts, always, and quote the process count first when you are asking for a decision rather than reporting progress.

There is a fourth thing worth counting where you can get it, and it is the one that changes an approver's mind rather than informing them. Name the applications. Thirty-one users is an abstraction and the finance month-end workbook is not, and a room that recognizes the application will tell you within a minute whether your estimate has missed anything, because somebody present uses it.

The counts also need a denominator stated beside them rather than converted into a percentage. Forty-seven of 865 is a fact; 5.4 per cent is that fact with the denominator hidden, and the denominator is exactly the thing that turns out to be wrong later in this section. Report the pair and let whoever wants a percentage compute one.

The estimate comes out of the audit events the rule has already been generating, which is the whole reason gate three in ES0.7 exists. Every audit event names the rule, the device, the account and the process that triggered it, so the three counts are one summarize away.

// Blast radius for one rule, as three counts plus the work list
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "AsrOfficeChildProcessAudited"
| summarize Devices = dcount(DeviceName),
            Users = dcount(AccountName),
            Events = count()
            by InitiatingProcessFileName, FolderPath
| sort by Devices desc

Grouping by process and path rather than summarizing to three scalars is what makes the result a work list instead of a headline. Each row is a candidate exclusion with the exact executable and location you would write it against, ordered by how many machines depend on it, and the row count is the process number from the previous section.

Read the tail of that result as carefully as the head. A row on one device is usually a person with an unusual tool, which is a conversation rather than an exclusion, and a row on four hundred is a rule that conflicts with something the organization does everywhere. The head tells you the size of the change and the tail tells you whether an exclusion list can contain it at all.

One column is missing from that query on purpose. Account name gives you the user count but it does not give you the department, and the department is what tells you whether the affected population is one team or scattered across the estate. Forty-four users in one function is a single conversation with one manager; the same number spread across nine functions is nine conversations, and the query cannot tell you which without a join against your directory. Do that join by hand for the top few rows rather than building it into the query.

Run the estimate against thirty days rather than the fortnight the scenario used, and run it again the week before you promote. Audit data accumulates, so an estimate taken early is the weakest version of itself, and the second run costs one command.

Use the report to find the rows and the query to produce the counts. The report is faster to read and does not give you a number you can put on a form, and a change request carrying a screenshot rather than a figure is one nobody can check afterwards.

An audit count describes behavior that occurred, on devices that were reporting, during the window you looked at. Each of those three qualifiers removes something, and none of the removals is visible in the number that comes out.

The window is the one that produced the scenario. A process that runs monthly appears in a fortnight of audit data only if the fortnight happens to contain the day it runs, and the processes most likely to break a business are precisely the periodic ones: month end, quarter end, payroll, the annual return. An audit window shorter than the longest business cycle it needs to cover has not finished, whatever the counts look like.

The reporting population is the quieter one. Devices powered off, unenrolled or running a failed sensor generate no events and appear as unaffected while remaining in the denominator, so the numerator comes from the reporting population and the denominator from the whole fleet. The percentage is understated by an amount nobody has measured, and the machines in that gap are the ones from ES0.6: the site that joined late, the image built before the sensor.

The second bar is the correctable one. You cannot know how many devices run a monthly process without waiting a month, and you can find out today how many devices were reporting at all, which turns the largest of the two unknowns into a number.

PS C:\> $win = (Get-Date).AddDays(-14)
PS C:\> [pscustomobject]@{
            Onboarded  = 865
            Reporting  = (Get-MgDeviceManagementManagedDevice |
                            Where-Object LastSyncDateTime -gt $win).Count
        } | Format-List

Onboarded : 865
Reporting : 779

Take that reading before quoting any percentage: it is the denominator correction and it costs one command. Eighty-six devices produced no audit events for reasons unrelated to the rule, and every one is counted as unaffected by an estimate that never saw them.

Quote the pair rather than the ratio when you write it up. Forty-seven devices out of 779 reporting, on an estate of 865, is three numbers a reader can check and reason about. The same fact as a single percentage hides which denominator was used, and the choice of denominator is the thing that made this assessment wrong.

That known direction of error is what makes the estimate usable despite being wrong. A number that could be wrong either way is a poor basis for a decision; a number you know is a floor, and say is a floor, lets you size a pilot that assumes more and tell an approver honestly what the figure covers.

A third qualifier is easy to forget because it sounds like a technicality. The count describes the behavior the rule watches, not the applications that would break. An application launching its helper forty times a day and one launching it once produce wildly different event counts and identical breakage. Count distinct devices and distinct processes, and treat the raw event count as a measure of noise rather than impact.

You will be handed more of these than you write, and the failure is never falsified numbers. It is a form where every figure is measured correctly and the conclusion drawn from them is not supported.

Reading one is a distinct skill from writing one and it uses three questions rather than a checklist. What period does each number cover, and does that period contain the thing most likely to break. What population does each number come from, and is it the same population as the denominator beside it. And what does the backout actually do, because a backout that undoes the whole change is a sign the author did not expect to be able to contain a failure.

Here is the change request from the scenario, as submitted and approved. Read it as the board should have: not to check the arithmetic, which is right, but to find what the assessment does not cover.

Classify it before deciding what to do about it, because the routing depends on the answer. An assessment with a wrong number goes back to whoever produced it. An assessment with correct numbers and a missing qualifier goes to whoever owns the change template, because the same form will produce the same gap next time and the person who filled it in did what the template asked.

That is the more useful outcome of reading one of these. The engineer who submitted it was not careless; the template has no field for the audit window's length against the business cycle, no field for the reporting population, and a backout that offers reverting the rule as though it were the only option. Three fields would have caught all three findings.

That is worth acting on rather than noting. If your organization uses a change template for security enforcement, the cheapest improvement available to you is not better assessments, it is three more fields on the form: the length of the audit window against the longest business cycle it needs to cover, the reporting population against the estate, and a backout expressed as an exclusion. Templates are how a practice scales past the person who invented it, and a missing field is a finding that recurs on every future change.

After a promotion, the estimate becomes checkable, and the check is four event IDs in the Windows Defender operational log rather than a count of tickets.

Microsoft-Windows-Windows Defender/Operational

  1121   an ASR rule BLOCKED an action
           the friction a user actually experienced
  1122   an ASR rule AUDITED an action
           what would have been blocked. the estimate's raw material
  1129   a user OVERRODE a block, in warn mode
           now requires administrator approval
  5007   a configuration change, including an exclusion added
           your change record, and an attacker technique

Tickets tell you who complained. These tell you what happened.

The relationship between the first two is the deployment's progress. Before promotion a rule produces only 1122 and after promotion only 1121, so a rule still producing 1122 on some devices is a rule that has not reached them, which is the assignment gap rather than a quiet rule. Counting both by device is how you tell a successful rollout from a partial one.

1129 is the number to watch in the days after a promotion, because it is the friction users hit expressed as a count rather than as complaints. It also behaves differently now that overriding requires administrator approval: every 1129 has a person's decision behind it, so a rising count is a support load landing on a named team rather than a silent self-service.

PS C:\> Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" |
            Where-Object Id -in 1121,1122,1129,5007 |
            Group-Object Id | Select-Object Name, Count

Name Count
---- -----
1121    14
1122     0
1129     3
5007     2

Read that device as a deployment report. Fourteen blocks and no audits means the rule is enforcing here and reaching this machine. Three overrides means somebody hit it three times and got approval three times, which is either a missing exclusion or a user who needs a conversation. Two configuration changes means somebody altered the protection on this endpoint, and the next section is about why that line matters as much as the other three.

Take that reading on a sample rather than on the machine that complained, because the machine that complained is the least representative one in the estate. Twenty devices across the affected population, read the same way, turns a support ticket into a distribution: whether the friction is concentrated on a few users doing something unusual or spread evenly, and those two point at completely different responses.

Note also what these events do not tell you. None of them records an application that failed silently, without the user connecting it to anything, and that is the commonest form of breakage rather than the loudest. The events give you the friction people noticed; the estimate and the exclusion list are what cover the rest.

An exclusion has four stages and only the last one is usually missing. It is requested when something breaks, written as narrowly as somebody has time for, recorded wherever that organization records things, and reviewed never. The fourth stage is what turns a temporary accommodation into permanent estate.

The reason the fourth stage never happens is not laziness. A review asks whether a constraint still holds, that question needs the person who knew what the constraint was, and by the second year that person has moved on. So the only reviewable exclusion is one that was written with its own removal condition attached: the vendor version that fixes it, the application being retired, the test that would have to pass.

Now the part that makes this a security topic rather than a housekeeping one. Event 5007 records a configuration change including an exclusion being added, and adding an exclusion is a step in a real attack chain: an operator with sufficient rights excludes a path, drops a payload into it, and executes with no detection because the location is exempt. The event that records your legitimate change is the same event that records theirs.

Two 5007 events, and the only thing that separates them

  09:14  5007  exclusion added   C:\Program Files\CADTools\helper.exe
           preceded by   a change request and an audit event trail
           followed by   nothing unusual in that path

  02:41  5007  exclusion added   C:\ProgramData\svc\
           preceded by   nothing. no ticket, no change record
           followed by   a file written to that path at 02:43
                         and executed at 02:44

The event is identical. The context around it is the whole finding.

Which gives the exclusion register a second job. It is the thing that lets a review remove an exclusion, and it is also the list you reconcile 5007 events against, so an exclusion appearing on an endpoint that appears on no register is a finding rather than an untidiness. That reconciliation is cheap and almost nobody does it.

It gets cheaper if the register is machine-readable rather than a page in a wiki, and that is worth choosing early. Exclusion path, rule it applies to, owner, business justification, removal condition, date. Six columns, one row per exclusion, and reconciling a fleet's 5007 events against it becomes a comparison rather than an afternoon of reading.

The same file answers a question that comes up in every audit and that most estates cannot answer: why is this path excluded. Being able to answer it per exclusion, with a name and a date beside it, is a materially better position than a policy export showing that it is.

The person approving this does not want to hear about attack surface reduction and is not being obstructive. They are weighing a disruption they will be blamed for against a risk they will not, and the asymmetry is real rather than a failure of understanding.

So state both sides in the same units, which are people and time. Not "this rule reduces credential theft risk" but "this stops the technique that took every credential on a laptop in our last exercise, and it will interrupt three named applications used by thirty-one people, all three of which have an exclusion written and tested." The second sentence can be argued with, which is what makes it useful.

Two habits make that conversation go differently. Bring the exclusions already written and already tested rather than promising them, because an approver weighing an unquantified disruption against an abstract risk will defer, and one weighing a tested mitigation against a demonstrated technique will usually not. And name the date the rule goes back to audit if the exclusions fail, which converts an open-ended risk into a bounded one and costs you nothing you were not already prepared to do.

What does not work is severity language. A rule described as critical invites the question of why the estate has survived without it, and that question has no good answer, because the honest reply is that the technique has not been used against you yet or has not been noticed. Describe what it stops and what it costs, and let the person whose job it is weigh them.

The pilot follows from the same three counts rather than from a percentage. Pick the population that runs the most affected application, because that is where the exclusion will be proved or disproved fastest, and avoid picking the security team, which runs none of the software that breaks.

Size it from the process count too. Where one application dominates, a pilot of the population running it answers the question in a week. Where nine applications are spread across the estate, no small pilot is representative and the honest options are a longer audit, a staged promotion rule by rule, or warn mode as the middle rung, and choosing between those is a decision to take before the change request is written rather than after it is rejected.

The next section places all of this on a maturity model, so you can say which level your estate operates at and what specifically moves it to the next one.