Everything to this point has been about prevention, the part you configure and then largely leave alone. Operations is the other half, and it is the half that separates an organization that owns its mail security from one that merely licensed it. Prevention is a purchase. Operations is a practice. The instruments in Plan 2, the ones the anchor called an operations purchase, are worthless without someone to read them, and the discipline of reading them is what this piece is about.
The loop from a suspicious user to a verdict
The most valuable signal in mail security is not generated by the platform. It is generated by your users, when one of them looks at a message, distrusts it, and reports it. The whole reporting apparatus exists to turn that instinct into something actionable, and it has consolidated in a way worth understanding. The old Report Message and Report Phishing add-ins that people installed for years are now in maintenance, on their way to retirement without a fixed date, and the button built directly into Outlook has taken their place across every platform. A reported message goes where you tell it, to Microsoft for analysis, to a mailbox your security team watches, or both, and the choice has real consequences for how the loop closes.
When a report reaches Microsoft, it comes back with a verdict, and the platform will now let your team dispute that verdict when they believe it is wrong, sending the item back for reevaluation with its full history attached. This matters more than it sounds, because the alternative, a verdict you disagree with and cannot challenge, is how a reporting program loses the trust of the people who feed it. A user who reports a genuine threat and watches it come back marked clean stops reporting. The loop only works if the people in it believe their reports are read, and the operational job is as much about maintaining that belief as it is about the mechanics.
Quarantine is a retention decision, not a bucket
Quarantine looks like a holding pen and behaves like one, but the decisions inside it are about time and permission, and both are more consequential than they appear. The first is retention, and it hides a trap. The common belief is that quarantined mail is held for thirty days, and for some categories it is, but the default anti-spam retention is fifteen, not thirty, and a message that ages out is deleted permanently with no recovery. An organization that assumes it has thirty days to review a quarantined message, on a default policy, has half that, and finds out the hard way when someone goes looking for a message that is already gone.
The second decision is permission, meaning what your users are allowed to do with their own quarantined mail. The presets wire this in a fixed and reasonable way, but it is the single most common reason to reach for a custom policy. The choice is between a quarantine your users never see, where everything waits for an administrator, and a quarantine that notifies them and lets them request release, which lightens the load on your team at the cost of putting judgment in users’ hands. The release-request workflow is the dial between those two postures, and where you set it is a real decision about how much of the triage burden your security team is willing to carry directly. Set it too tight and you drown in release requests. Set it too loose and you have handed the verdict back to the people least equipped to make it.
The queue, and the automation you have to ask for
Threat Explorer and the investigation tools are the instruments the operations team lives in, and they impose a thirty-day discipline. The data window for hunting and for Explorer is thirty days, which means an investigation that reaches back further has to draw on data streamed elsewhere, into a longer-retention store. That thirty-day horizon is not a limitation to complain about so much as a forcing function to design around. The investigations you can do live are recent ones, and anything historical requires that you planned for it in advance.
Automated investigation and response is where the platform offers to work the queue for you, and here Defender for Office 365 behaves differently from its endpoint sibling, in a way worth knowing. On endpoints, the automation runs at full tilt by default, remediating on its own. In mail, it does not. Automated investigation produces recommendations and then waits for a human to approve the action, which is the safe default for a system that can delete people’s mail. There is one deliberate exception, added recently, where you can opt the platform in to remediating clusters of clearly-related malicious messages on its own, the copies of one attack scattered across many mailboxes, without waiting for approval. That opt-in is off until you choose it, and choosing it is a judgment about how much you trust the platform to act unattended against the messages it is most confident about. The point is that the automation is there, that it is conservative by default, and that the more aggressive posture is available but never assumed.
On endpoints the automation acts on its own. In mail it waits for a human, because a system that can delete people’s mail should.
Rehearsing the attack, and the agent that reads the queue
The last instrument is attack simulation training, and its purpose is routinely misunderstood. The point is not the simulated phish. The point is the training that follows for the people who fall for it, because the phish is only a way of finding out who needs the training and of measuring whether it worked. Run as a scoring exercise, it breeds resentment and teaches people to distrust their own mail tools. Run as a way to target education where it is actually needed, it is one of the few security controls that improves the humans rather than the machines. The reporting that comes with it, who is repeatedly caught and whether the population is getting better over time, is the part that matters, and it is worth reading as a measure of your program rather than a stick for your people.
There is a newer instrument worth naming briefly, because it points at where this is going. Microsoft has begun offering an agent, built on its security assistant, that triages the phishing your users report before a human sees it, pre-classifying the queue so that an analyst’s time goes to the reports that warrant it. It requires the higher plan and the assistant’s paid capacity, and the depth of it belongs to the capstone piece on the fabric that ties this whole suite together. I raise it here only to mark that the operational surface is itself beginning to be automated, and the reporting loop that starts with a suspicious user may increasingly be read first by something other than a person.
That is the doctrine of this pillar: a layered platform whose tuning Microsoft owns, whose floor rose under everyone, whose overrides are a discipline, and whose real work is operational. What remains is to build it. The two pieces that follow are the reproducible companions to all of this, the first standing up the policy baseline and the impersonation lists by hand, the second configuring the protection stack and closing the doors this pillar has pointed at. The argument is made. The build is next.
Defender XDR
‹ Previous: [D 4.2.1] Build Sheet: Configuring the Protection Stack
Next: [D 5] Defender for Cloud Apps: Seeing and Governing the SaaS Estate ›
