The Deployment Sequence

Introduction

The controls in this course are not difficult to configure and the order they go in decides whether the deployment finishes at all.

This section is that order and the reasoning behind it. It is built on gates rather than dates: each step has a condition that has to be true before the next one starts, because a calendar promises something you cannot deliver and a condition tells you honestly where you are.

You will finish able to say why visibility comes before enforcement, name the difference between the three enforcement modes as instructions rather than as settings, choose between a per-rule and a global exclusion correctly, and recognize the four resequencing mistakes by what each one costs.

The scenario is not a technical failure. Every rule enabled that Monday was a rule the estate should be running, the engineer's assessment was correct, and if the same eighteen rules had gone on in a different order most of them would still be on today. What was lost was not a configuration, it was permission to make configuration changes, and that is much harder to get back.

// Which rule is quietest, and therefore which to promote next
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType endswith "Audited"
| summarize Events = count(),
            Devices = dcount(DeviceName),
            Apps = dcount(InitiatingProcessFileName)
            by ActionType
| sort by Devices asc

Sort ascending, not descending. The rule at the top of that result is the next one to promote, because it is the one whose promotion produces the fewest tickets and therefore the most evidence per unit of disruption.

That is the resource the sequence protects. An endpoint program spends organizational trust with every change and earns it back with every change that causes no incident. Run the cheap, quiet changes first and you accumulate a balance you can spend on the disruptive ones later. Run the disruptive one first and there is no balance, so the revert is total rather than partial and the next proposal starts from behind.

The difference between those two outcomes is not competence and it is not risk appetite. Order A produces one indistinguishable failure, so the only available response is total. Order B produces attributable failures, and an attributable failure is a ticket rather than an outage.

It is worth being precise about who holds that permission, because it is rarely the person who thinks they do. The security engineer proposes; the change board or the IT operations lead approves; and the people who decide whether the next proposal is heard are the business owners whose Tuesday was ruined. That last group keeps no register and takes no minutes, and their memory of the endpoint program is a single event.

Which means the sequence has a second purpose beyond avoiding outages. Each successful step is evidence you can cite the next time: three rules enforcing for a quarter with no tickets raised is an argument, and it is a considerably better argument than a vendor's recommendation. Build that record deliberately, because you will need it at gate five and there is no way to acquire it retrospectively.

Read the dashed arrow. Microsoft's own guidance is explicit that an exclusion is preferable to switching a noisy rule off or back to audit, and the reason is that both of those responses treat a narrow problem with a fleet-wide answer. One application misbehaving is one exclusion; it is not a reason to stop protecting 865 machines from the technique.

The first gate produces no protection at all, which is why it gets skipped. Onboarding devices and confirming they report gives you no blocked techniques and nothing to show a steering group, and every instinct says to enable something instead.

The reason it comes first is that every step after it consumes its output. Audit mode produces events, and events from devices that are not reporting do not exist, so a rule audited across an estate where a quarter of machines are silent produces a clean-looking result that describes three quarters of the population. Promoting on that evidence is how the missing quarter becomes the incident.

The same logic applies to the population rather than only to the count. Audit events tell you which legitimate applications trip a rule, and the applications most likely to trip one are specialist: the CAD helper, the finance macro host, the plotter driver, the ancient line-of-business tool one department depends on. Those live on the machines least likely to be in an early ring, so an audit window covering only the pilot group produces a confident, clean, and completely unrepresentative answer.

There is a second reason this gate comes first and it is about what you can prove. Onboarding is the only step here that is visible to somebody outside the security team without explanation: a device count going up is legible to anybody. Starting with the step that produces a legible number, before asking for permission to change anything, is not presentation, it is how you establish that the program measures itself.

One practical note on getting through this gate rather than stalling in it. Onboarding rarely fails uniformly; it fails in populations, and the populations are the ones from ES0.6: a site that joined late, an image built before the sensor was in it, a group of machines that are powered on rarely. Chasing individual devices is endless and chasing populations is finite, so group the non-reporting machines by build, by site and by last sign-in before opening a single ticket.

What each state gives you, and what it costs

  NOT ONBOARDED     a policy can apply and you cannot see the
                    result. every promotion is a guess.
                    cost: nothing. risk: everything downstream.

  ONBOARDED         events arrive. no protection yet.
    AUDIT ONLY      cost: storage and patience.
                    risk: the techniques still succeed.

  ONBOARDED         events arrive and techniques stop.
    BLOCK           cost: the ones you got wrong.
                    risk: bounded by the ring you chose.

The middle state is the one estates get stuck in, and ES0.3 showed what that looks like as data: audit counts rising, block counts at zero, every event a technique that ran. The gate out of it is not more audit data, it is the exclusion work in gate four, and recognizing that the middle row is a waypoint rather than a destination is most of what this section is for.

Microsoft names a small standard protection set that can go straight to block or warn without an audit cycle: blocking abuse of exploited vulnerable signed drivers, blocking credential theft from the local security authority subsystem, and blocking persistence through WMI event subscription. None of them constrains anything an ordinary business process does, which is why the testing requirement does not apply.

Taking those three first changes the character of the whole program. You have three rules enforcing before you have asked anybody for anything, you have a result to report at the first review, and the audit cycle for the remaining fifteen now runs in the background of a project that has already delivered something. That sequencing is worth more than the three rules are individually.

It also settles an argument that otherwise runs for weeks. The usual objection to any ASR proposal is that it needs testing first, and that objection is correct for fifteen of the eighteen rules and wrong for three. Being able to say which three, and to cite the vendor's own position on them, moves the conversation from whether to test to what to test, which is a much shorter conversation.

Two of those three also happen to sit on the phase that decided the chain in ES0.2. Credential theft from the security authority was the hinge of that intrusion, and it is in the set that needs no audit cycle. The cheapest available change and the one that would have mattered most are, unusually, the same change.

There is a licensing and platform caveat behind all three that is worth checking once rather than assuming. These rules are a Windows client mechanism delivered through Defender Antivirus, so they need real-time protection running and the antivirus in its normal active mode. On a device where another product holds the active role and Defender is in passive mode, the rules are configured and not enforcing, and the configuration reads exactly the same either way.

One caveat travels with the third rule and it is worth carrying. Configuration Manager relies heavily on WMI, so an estate running it should audit the WMI persistence rule rather than take it on trust, and Microsoft says so directly. That is the shape of every exception in this course: not "this rule is risky" but "this rule interacts with a specific thing you may or may not have".

Turn the remaining rules on in audit together rather than one at a time. They do not interact, the events carry the rule that produced them, and running them serially multiplies the waiting by fifteen for no additional information.

The condition that opens the next gate is that the audit has covered a full business cycle, and that is a statement about the organization rather than about a number of days. If month end is when finance runs the macro workbook, an audit window that has not contained a month end has not seen the thing most likely to break. Quarter end, year end, the annual stock count and the payroll run are the same argument. Ask what the least frequent important process is and let that set the window.

// What audit produced: which rule, which process, how often, where
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType endswith "Audited"
| summarize Events = count(), Devices = dcount(DeviceName)
            by ActionType, InitiatingProcessFileName, FolderPath
| sort by Events asc

Sort ascending rather than descending, which is the opposite of instinct. The rule at the top of that result is the one with the fewest triggered events, and Microsoft's deployment guidance says to promote that one first. It is the smallest blast radius available, it produces a promotion you can report, and it teaches the organization that a promotion is a routine event rather than an outage.

Read the other two columns as well, because they separate two very different findings. A rule with many events across a handful of devices is a specialist application on a small population, which is an exclusion. A rule with many events across most of the fleet is a rule that conflicts with something everybody does, and that is either a much larger exclusion or a rule that stays in audit on this estate with a written reason.

The folder path column is what turns an event into an exclusion you can actually write. It gives you the executable rather than the process name, and the difference matters: excluding by name exempts anything with that name anywhere, which is a considerably wider grant than excluding the specific binary in its specific location.

One more property of this data is worth using. The same query grouped by device name rather than by process tells you whether a rule's events are concentrated or spread, and concentration is good news: a rule firing on four machines is four conversations, and a rule firing on four hundred is a policy question. Deciding which of those you have before writing the exclusion stops you writing a narrow exclusion for a broad problem.

Audit, block and warn are not degrees of the same setting. Audit records and permits. Block refuses. Warn is a block with a user-facing override, and its mechanics decide whether it is useful to you or a hole in your deployment.

Warn stops the action and offers the user an Unblock, and the scope of that override is narrower than people assume. It applies to one combination of device, user, file and process, it is held locally on that machine, and it lasts twenty-four hours. It is a suppression while somebody works out the right answer, not a way of permanently permitting anything.

PS C:\> $p = Get-MpPreference
PS C:\> 0..($p.AttackSurfaceReductionRules_Ids.Count-1) | ForEach-Object {
            [pscustomobject]@{
                Rule = $p.AttackSurfaceReductionRules_Ids[$_].Substring(0,8)
                Mode = switch ($p.AttackSurfaceReductionRules_Actions[$_]) {
                    0 {"Disabled"} 1 {"Block"} 2 {"Audit"} 6 {"Warn"} }
            } } | Group-Object Mode | Select-Object Name, Count

Name     Count
----     -----
Block        3
Audit       13
Disabled     1

Read Disabled separately from absent. A rule set to zero is a decision somebody took and a rule missing from the list was never configured, and a policy summary shows those two identically.

That fourth line under warn is recent and it changes how the mode behaves in practice. Administrator approval is now required to use the Unblock override, introduced at platform version 4.18.26060, and Microsoft states plainly that Unblock is for temporary suppression and is not a durable exclusion mechanism. An estate that adopted warn mode on the basis that users could self-serve their way past a false positive should re-read its rollout plan, because that is no longer what happens.

Used correctly, warn is the middle rung on rules where you have finished the audit work but are not certain you have found every legitimate case. The user hits the block, somebody has to approve the override, and that approval is a signal arriving at a person rather than an event in a log nobody reads. It converts an unknown into a conversation, which is exactly what you want at that point in a rollout.

Where it does not belong is as a permanent state. A rule left in warn indefinitely is a rule whose exclusion work was never finished, and it carries a running cost in approvals that somebody is quietly absorbing. If a rule has been in warn for months, the question is not whether to promote it but why the audit never resolved into an exclusion, and the answer is usually that nobody owned the application involved.

Warn also does not exist on every rule, which catches people mid-plan. Where it is unavailable the ladder is audit then block with the exclusion work carrying the whole weight, so a rollout designed around warn as a universal middle step needs checking rule by rule before it is committed to a change board.

An exclusion tells a rule to ignore something, and where you put it decides how much you gave away. A per-rule exclusion exempts that path from that rule. A global attack surface reduction exclusion exempts it from every rule you have, including the ones you have not deployed yet.

That difference is the most expensive detail in this section. If the CAD helper application trips the Office child-process rule, the correct answer is an exclusion on that rule for that executable. Putting the same path in the global list also exempts it from credential theft blocking, from WMI persistence blocking, and from every rule added in future, and nothing anywhere reports that you have done so.

PS C:\> $p = Get-MpPreference
PS C:\> $p.AttackSurfaceReductionOnlyExclusions

C:\Finance\Reports\
C:\Program Files\Contoso\Ledger\ledger-macro-host.exe

PS C:\> $p.AttackSurfaceReductionRules_RuleSpecificExclusions

PS C:\>

Two findings in one reading. The second list is empty, so every exclusion on this device is global and applies to all eighteen rules. And the first entry is a directory rather than an executable, so anything written into that folder is exempt from every rule, which is a location an attacker would choose deliberately if they knew it existed.

Write the justification down at the moment you create the exclusion, with the condition that would let you remove it. An exclusion with no removal condition is permanent by default, because every future review is an argument about a decision nobody present made, and the safe answer in that argument is always to leave it alone.

The narrowness rule has a limit worth naming, because taken too far it produces exclusions that break on the next update. An exclusion pinned to a full path including a version number stops matching when the vendor ships a new build, and the application starts failing again with nobody remembering why. Exclude the executable at the path it installs to, not the path it currently happens to occupy, and expect to revisit anything that sits inside a versioned directory.

Keep the exclusion register somewhere other than the policy, and keep it in a form a person can read. The policy holds the exclusions and holds nothing about why they exist, so the register is where the justification, the owner and the removal condition live. Reviewing the policy tells you what is excluded; reviewing the register tells you which of those exclusions still has a reason, and only the second review can ever remove anything.

The four resequencing mistakes are worth knowing by their cost rather than their name, because that is how you will recognize one in a plan somebody hands you.

A deployment plan as submitted to a change board

  1  enable all ASR rules in block across the estate
  2  onboard remaining devices
  3  write custom detections for Office-to-PowerShell,
     LSASS access and WMI remote execution
  4  enable script block logging      [ no owner, no date ]

Three mistakes are in those four lines.

Step 1 precedes step 2, so the enforcement lands before the visibility that would show what it broke. Step 3 writes detections for three techniques that step 1 blocks outright, which is an ongoing cost bought to catch something already stopped. And step 4 carries neither an owner nor a date, which is how the only item that cannot be applied retrospectively becomes the one that never happens.

All four share a shape: each one is locally reasonable and produces a cost that lands somewhere else. Enforcing before onboarding is faster today and pays for it at every subsequent decision. Skipping audit is decisive and pays for it in permission. Detection before prevention is the more interesting engineering and pays for it in perpetual maintenance. Readiness last is invisible and pays for it exactly once, at the worst possible moment.

The third is the one that looks most defensible and is the most wasteful. Writing a detection for a technique that a prevention control blocks outright is paying an ongoing cost, a rule to maintain and an alert to triage each time it fires, for something a one-off configuration removes entirely. Prevention before detection is not a preference about which is better; it is about which of them keeps charging you.

The fourth is the one to argue hardest for, and the argument is unusual because it does not concern attacks at all. Readiness is the only item on this list where deferring the work destroys the option rather than delaying it. Every other gap on this page can be closed next quarter and be just as good. Logging that was not configured on the day of an incident cannot be configured retrospectively for that incident, so a decision to defer it is a decision to accept that the next investigation produces no conclusions.

The circumstance in which the sequence is correctly abandoned is worth naming, because it exists. During an active incident, containment outranks everything here: you enforce immediately, you accept the disruption, and you write down what you did so it can be reviewed afterwards. That is a deliberate exception with a defined end, and it is different in kind from skipping the sequence because the assessment felt urgent.

The next section takes the disruption this sequence exists to manage and looks at it directly: what a control actually breaks, how far the damage reaches, and how to size it before you deploy rather than afterwards.