Advanced Zero Trust: The Minutes Automation Gives Back
In this article
Summary
As in past articles, it's important to add context to complex strategies. This time, "INC-4417" started as five separate alerts that nobody would have escalated on their own. An unfamiliar sign-in, a suspicious inbox rule, a blocked script, a burst of file access, and a download spike, spread across five products and roughly 40 minutes. Defender XDR joined them into a single incident with an attack story attached, and that is the part of this module that is not oversold. Correlation genuinely does turn five shrugs into one investigation. Automation collapses one part of the response and leaves the rest where it was, the fastest mechanism in the platform is not the one most teams configure, and the scorecard only becomes honest once you split it up.
What Correlation Needs First
An incident is a join. Five alerts become one story because the platform found keys they share: the same user principal, the same device identifier, the same session, a plausible time window. Understanding it that way explains both why correlation is powerful and where it quietly degrades.
That last point is the one to carry into a design review. If Defender for Cloud Apps is not connected, the mass file access branch never exists, "INC-4417" still forms from the remaining four alerts, and it presents with the same confident narrative and one fewer piece of evidence. Nothing in the incident says a branch is missing. Coverage gaps do not announce themselves as gaps, they show up as slightly thinner stories.
| Source | What it adds to the story | What is thinner without it |
|---|---|---|
| Entra ID Protection | How the account was reached, and whether risk was already raised | You get the actions and lose the entry point, which is the part the report needs. |
| Defender for Endpoint | Process lineage, and the device to contain | No containment target, and no way to tell one machine from a fleet. |
| Defender for Office 365 | The delivery mechanism, and who else received it | The blast radius question stays open, and it is usually the first one asked. |
| Defender for Cloud Apps | What was reached in SaaS after the fact | The story stops at the endpoint, which is rarely where the damage was. |
| Purview Insider Risk | Whether the behaviour was anomalous for this person | Everything looks equally suspicious, which is the same as nothing being suspicious. |
Table 1 – Describes the different Defender suites and how it adds context to a risk, helping to develop decision making faster.
The Fastest Thing Is Not a Playbook
Automatic attack disruption is the one worth knowing properly, because it behaves unlike anything else in the stack. It acts on Microsoft's own cross-product correlation, and Microsoft holds it to a confidence level of 99 percent or higher before it will contain or disable anything. It uses the remediation capability in Defender for Identity to disable an account, and the Contain User action needs a recent enough Sense agent on the endpoint to work. There is no playbook to write. There is, however, an exclusion list to maintain.
The exclusion list is where this connects back to Module 3. Break-glass accounts and the service identities propping up critical business processes need excluding, or a genuine attack will disable them at the moment you most need them. Microsoft's guidance is that excluding assets is not recommended because it reduces effectiveness, and that is correct in general and wrong for the two or three identities whose whole purpose is to survive a bad day. Decide those deliberately, write down why, and review the list when the emergency access accounts change.
Automated investigation and response sits a level down and is yours to configure. Automation levels are set per device group, ranging from full remediation without approval to semi-automated modes where an analyst approves each action. Microsoft's own data has customers on full automation removing around 40 percent more high-confidence malware than those on lower levels, which is the strongest available argument for turning it up on the device groups where you can tolerate it. Playbooks are the third layer, and they are the only one that can reach outside the Microsoft estate to a ticketing system or a firewall.
Disintegrating the Scorecard
Response is at least five distinct phases, and automation does not touch them equally.
Read that shape carefully, because the conclusion is better than the headline rather than worse. Total response time falls by under a fifth, which is not the collapse from days to minutes the slide suggests. What does collapse is the window in which an attacker is still operating, from three quarters of an hour to almost nothing, and that window is the one that determines how much damage gets done. Eradication and recovery are unchanged because they are human judgement and human work: deciding what else was touched, rebuilding, telling people. Selling automation on total MTTR invites a finance conversation you will lose. Selling it on the containment window is both more accurate and more persuasive.
There is a failure mode worth naming too. Aggressive containment can lengthen eradication, because an isolated device and a disabled account stop generating the evidence an investigator needs. The fix is not less automation. It is making sure the containment action captures state before it acts, which is a playbook design decision nobody makes until the first time it costs them.
Measuring this properly takes one query rather than a dashboard. Percentiles matter more than means here, because a single incident that sat over a weekend will drag an average somewhere unhelpful.
Where Security Copilot Helps, and What It Costs
Security Copilot earns its place on this article for the work nobody enjoys and everybody needs: summarising an incident for someone who was not in it, drafting the report, turning a half-formed question into a hunting query. It runs both standalone and embedded across Defender, Sentinel, Intune, Entra and Purview, and promptbooks let a recurring investigation be run the same way twice. What it does not do is decide. The containment decision belongs to attack disruption or to a person, and the value of a summary depends entirely on the evidence underneath it, which takes us back to Figure 1.
The commercial model is worth understanding before anyone builds a habit around it. Capacity is measured in security compute units, provisioned as a baseline and billed by the hour, and the allocation refreshes on fixed clock-hour blocks rather than rolling ones. Overage capacity can be set anywhere from zero to 999 units and is billed only when used. The practical consequence is that a burst of investigation at ten to the hour draws from that hour's allocation and not the next one, so the capacity question is about peaks rather than totals. During an incident like "INC-4417" everyone reaches for it at once, which is precisely the shape that exhausts a baseline.
Conclusion
Operations is the last module for a reason. Every control in the previous six eventually resolves into a minute here, either saved or unaccounted for, and an incident is where the design gets marked.
"INC-4417" formed correctly because five products were onboarded, and it would have formed just as confidently with four. Automation took the containment window from 45 minutes to almost nothing and left eradication and recovery exactly where they were, which is a smaller headline and a better argument. Check that attack disruption is on, that your break-glass accounts are excluded from it, and that you can produce the percentile query above without asking anyone for help. If those three things are true, the other six modules have somewhere to prove themselves.