A two-analyst SOC drowning in Defender XDR incidents while servers do not block and macOS is dark
Tailspin Toys licenses Microsoft 365 E5 for 1,500 users. Defender for Endpoint covers 1,500 Windows 11 laptops, 60 macOS devices, and 40 Windows Server 2019 file servers onboarded through Intune. The SOC is two analysts. After go-live the incident queue stabilised at roughly 300 incidents a day; about 90% are low-severity Defender for Office 365 'suspicious email' and user-reported detections raised per message rather than per campaign. Automated investigation and remediation is enabled tenant-wide and set to remediate automatically; last month it quarantined a genuine vendor invoice that finance needed and nobody noticed for three days. The 40 servers show Defender antivirus running in passive mode. The 60 macOS devices have shown no sensor data since onboarding.
1. Bring the daily incident volume down without blinding the SOC. What do you change, and in what order?
Read the worked answer
Diagnose before tuning. Suppression without evidence is how a real intrusion gets missed.
- Prove what is driving volume. In advanced hunting, group
AlertInfoandAlertEvidencebyTitleandServiceSourceover 30 days. If 270 incidents come from two email detections, the fix is those two, not a global change. - Fix correlation before detection. Defender XDR correlates alerts into incidents; per-message incidents usually mean each user report is being raised as its own incident. Configure Settings → Email & collaboration → User reported settings so reports land in the reporting mailbox, and confirm that related alerts group by campaign rather than by recipient.
- Downgrade before you suppress. Use tuning rules (Defender portal → Settings → Microsoft Defender XDR → Alert tuning) scoped narrowly - sender domain, policy name, recipient - and always with an expiry date. A tuning rule that never expires becomes a permanent blind spot nobody remembers creating.
- Keep the signal. Either convert the pattern into a custom detection that fires once per campaign and routes to a separate queue, or leave the alert on and route low-severity items to a daily digest instead of the live incident queue.
- Never disable the underlying protection policy to quiet the queue. You lose the alert and the ability to hunt the associated evidence.
Success measure: daily incidents fall to a volume two analysts can triage to closure, and nothing scoring High ever leaves the queue unworked. Measure that second condition weekly, not once.
2. Is 'remediate automatically' the right automated investigation and remediation setting here? Justify your answer separately for endpoints and for email.
Read the worked answer
No. Tenant-wide automatic remediation is not defensible for a two-analyst team with a recent false positive.
Endpoints. The automation level in Defender for Endpoint is set per device group, so use that granularity:
- Full – remediate threats automatically for a pilot ring of roughly 50 IT devices, where a false positive costs a reinstall and not a production stoppage.
- Semi – require approval for the general laptop population and for servers, so a quarantined line-of-business file waits for a human instead of silently breaking a shift.
Email and collaboration. Move automated investigation to a review-based model, or at minimum require approval for user-visible remediation: quarantine and soft delete. The vendor invoice case is exactly the failure mode - an irreversible action executed with no reviewer, and the Action center went unread for three days.
The process gap is the real finding. No setting fixes an unread Action center. Assign a daily ten-minute Action center review, enable action notifications to the SOC mailbox, and add a standing agenda item for any remediation reversed in the past week. If an action had to be undone, that is a tuning input, not just an apology.
Keep the automation where it is clearly safe: automated investigation triggered by user-reported phish, with auto-purge once a campaign is confirmed. That is the case where a human in the loop adds delay and nothing else.
Write the decision down per workload per device group. 'AIR is turned on' is not a configuration - the automation level and the approval model are.
3. Explain why the 40 servers are in passive mode and why the 60 macOS devices report no sensor data, and prioritise the fixes.
Read the worked answer
Two unrelated root causes that look like one onboarding failure.
Servers in passive mode. Defender antivirus switches to passive for two reasons: a supported third-party AV is registered on the machine, or a policy deliberately set passive mode - common when servers were onboarded for EDR telemetry only. Passive means it never blocks, so you get detections after the fact and file-share ransomware runs to completion.
- If a third-party AV is present and staying, enable EDR in block mode now. That gives blocking with no AV conflict and no reboot.
- If no third-party AV exists, switch the Defender AV policy to active mode through the Intune/GPO policy already applied to the server group - but do the exclusions review first, or you will quarantine a business file in week one.
macOS with no sensor data. The Intune device object exists, so the device looks onboarded while the sensor never reported. Typical causes: the MDE for macOS system extension was never approved, full disk access was not granted, or the network extension is blocked. Re-apply the MDM configuration profile, approve the extensions on one test device, confirm healthy status in the device inventory, and verify the device is licensed.
Prioritisation: servers first if they host file shares - an unblocked server is both a ransomware target and a lateral-movement platform. macOS second, because those devices still receive email and cloud protection even while the endpoint sensor is dark.
Do not declare the rollout complete until sensor health and AV mode are reported metrics on a dashboard someone reads weekly.