Defender XDR: Tune Your Alerts
A noisy SOC is an ineffective SOC. Learn how to configure email notifications for incidents and threat analytics, tune alert correlation, and create suppression rules in Microsoft Defender XDR.
Why alert tuning matters
Imagine a smoke detector that goes off every time you make toast. After a few weeks, you stop running to check. Thatβs alert fatigue β and itβs the number one enemy of a SOC.
Defender XDR generates alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and more. Without tuning, your analysts drown in noise and miss the real threats hiding in the flood.
Alert tuning has three parts: email notifications (who gets notified about what), suppression rules (silence known false positives), and correlation (group related alerts into a single incident instead of 15 separate ones).
Email notifications
Defender XDR sends three types of email notifications:
1. Incident notifications
Notify specific people or groups when new incidents are created.
| Configuration | Options |
|---|---|
| Recipients | Email addresses (individuals, distribution groups, mail-enabled security groups) |
| Severity filter | High, Medium, Low, Informational (select one or more) |
| Device group filter | Notify only for incidents involving specific device groups |
| Service source | Filter by product (MDE, MDO, MDI, MDCA) |
2. Action notifications
Notify when automated investigation and response (AIR) completes an action β remediation succeeded, pending approval, or failed.
3. Threat analytics notifications
Notify when Microsoft publishes new threat analytics reports β intelligence on emerging threats, campaigns, and vulnerabilities.
Scenario: James configures notifications for Pacific Meridian
James at Pacific Meridian sets up tiered notifications:
- SOC team (all analysts) β High-severity incidents from all products
- Security leads (James + Sarah) β High and Medium severity + all AIR actions needing approval
- CISO β Threat analytics reports only (strategic awareness, not operational noise)
- Server team β Incidents involving the βServersβ device group only
This ensures the right people see the right alerts without everyone getting everything.
Alert suppression rules
Suppression rules automatically handle alerts that are known false positives or expected behaviour. Instead of analysts manually closing the same alert 50 times a day, a suppression rule does it automatically.
What you can suppress on
| Criteria | Example |
|---|---|
| Alert title | Suppress βSuspicious PowerShell command lineβ when it matches a known admin script |
| MITRE ATT&CK technique | Suppress all T1059 (Command and Scripting Interpreter) alerts from a specific device group |
| Device group | Suppress certain alerts from the βBuild Serversβ group (expected CI/CD behaviour) |
| User | Suppress alerts from a service account that performs automated tasks |
| File hash/name | Suppress alerts triggered by a known-good executable |
Suppression actions
| Action | What Happens |
|---|---|
| Hide alert | Alert is created but hidden from the queue β still searchable in Advanced Hunting |
| Resolve alert | Alert is automatically marked as resolved with a chosen classification |
Exam tip: suppression vs tuning vs disabling
The exam distinguishes between:
- Suppression rules β auto-resolve or hide specific alerts matching criteria. The detection still runs; the alert is just handled automatically.
- Alert tuning (classification) β change the severity or classification of an alert type (true positive, false positive, benign true positive). Adjusts how analysts prioritise, not whether the alert fires.
- Disabling a detection β turns off the analytics rule or detection entirely. This is rarely the right answer because you lose visibility.
If a question asks βhow to reduce noise from a known-safe activity,β the answer is usually suppression rule, not disabling the detection.
Alert correlation
Defender XDR automatically correlates alerts into incidents. Multiple related alerts become a single incident instead of separate items in the queue.
How correlation works
Defender XDR groups alerts when they share:
- Entity overlap β same device, user, mailbox, or IP address
- Time proximity β alerts occurring within a defined window
- Attack chain logic β alerts that fit a known attack pattern (e.g., phishing email β credential compromise β lateral movement)
This correlation is platform-driven β Defender XDR handles it automatically based on its AI engine. You do not directly configure correlation rules or thresholds. However, you influence correlation indirectly through:
- Entity mapping in custom detections and analytics rules (better mapping = better correlation)
- Alert tuning (suppressing false positives means cleaner correlation)
- Automated investigation triggers β which alert severities automatically start an investigation
| Feature | Alert Suppression | Alert Correlation |
|---|---|---|
| Purpose | Remove known false positives from the queue | Group related alerts into a single incident |
| Reduces alert count? | Yes β alerts are hidden or auto-resolved | Yes β 15 related alerts become 1 incident |
| Detection still runs? | Yes β the detection fires, but the alert is handled | Yes β each alert still fires, they're just grouped |
| Configurable by | Alert title, MITRE technique, device group, user, file | Entity overlap, time window, attack chain logic |
| Who manages it | SOC analysts and leads create rules for known FPs | Mostly automatic; settings adjusted by SOC leads |
Scenario: Anika reduces alert volume for a client
One of Anikaβs MSSP clients at Sentinel Shield generates 200+ alerts per day. After analysis:
- 60 alerts/day are PowerShell script executions from a known admin tool β Anika creates a suppression rule matching the script hash
- 40 alerts/day are 15 related alerts from the same phishing campaign β already handled by correlation (grouped into ~3 incidents)
- 30 alerts/day are low-severity informational alerts β Anika adjusts email notifications to exclude Informational severity
Result: the analyst queue drops from 200+ to ~70 actionable items per day. Detection coverage is unchanged.
Anika's SOC team at Sentinel Shield receives 60 alerts per day from a known-safe admin PowerShell script. What is the best way to handle this?
James at Pacific Meridian wants his CISO to receive emails about emerging threat campaigns but NOT about individual incidents. Which notification type should he configure?
π¬ Video coming soon
Next up: Alerts are tuned. Now letβs automate the response β Automated Investigation and Response (AIR) handles the heavy lifting so your analysts can focus on what matters.