Organising alert and incident triage in Defender XDR

Alerts and incidents: working at the right level

Each product in the Defender family generates alerts. Defender XDR groups them into incidents when they involve the same entities (user, device, mailbox, IP address) or belong to the same attack. A successful phishing attempt can therefore produce, within a single incident, an email alert, a suspicious sign-in and abnormal activity on a device.

The first organisational rule follows from this: triage incidents, not individual alerts. Working alert by alert multiplies the effort and loses the bigger picture. The incident carries the status, assignment, classification and analyst comments; it is the record of how the case was handled.

Prioritising: severity, assets and context

The severity Microsoft suggests (informational, low, medium, high) is a starting point, not a decision. A medium alert on a Global Administrator account deserves more attention than a high alert on an isolated test machine. To prioritise properly:

• identify your critical assets: privileged accounts, executive accounts, sensitive servers; tags and critical asset management help them stand out in the queue;
• look at the scope of the incident: how many users, devices and mailboxes are involved;
• take into account actions already taken automatically, such as attack disruption having already disabled an account.

Automated investigation and response

Defender XDR can run automated investigations that examine entities, reach verdicts and propose or carry out remediation actions: isolating a device, quarantining a file, removing a message from every mailbox that received it. The automation level is set per device group for endpoints, and depends on the Defender for Office 365 capabilities available for email.

Two pitfalls are common. The first is an automation level kept at the minimum for fear of false positives, which turns every action into an approval request. The second is an Action centre where pending actions pile up with nobody approving them. An action left pending for three weeks provides no protection at all.

Reducing noise without going blind

A queue that is too noisy ends up being ignored. Alert tuning is therefore essential, but it must stay under control:

1. start by analysing incidents closed as false positives or expected activity to identify recurring sources;
2. create alert tuning rules that are as specific as possible: a given process on a given device group, rather than a whole alert type;
3. document every suppression rule and review them periodically;
4. add custom detections based on advanced hunting when you identify a need specific to your environment.

Classifying incidents correctly when closing them (true positive, false positive, informational expected activity) is not a formality: that information is what allows tuning to improve and, on Microsoft's side, detection quality.

Who does what

Technology is not enough without organisation. The points to formalise:

• who checks the queue, how often, and who takes over outside business hours;
• expected response times by severity;
• email notifications for incidents, sent to a monitored distribution list rather than to a single person;
• procedures for frequent cases: compromised account, reported phishing, malware on a device;
• the threshold for escalating to an incident response provider.

If an external provider handles monitoring, these points belong in the contract, and the permissions it holds in the tenant must be reviewed like those of any administrator.

What an audit checks

• The number of active incidents, their age and their breakdown by severity.
• Assignment and classification of closed incidents.
• The configured automation level and pending actions in the Action centre.
• Alert tuning and suppression rules, how specific they are and how they are justified.
• Roles assigned in Defender XDR and the separation between viewing and responding.
• Configured notifications and the out-of-hours procedure.