1.3.1. Microsoft Defender XDR
💡 First Principle: When the same vendor builds the sensor, the detection, and the response action, those three can be wired together natively. Defender XDR exploits that: each Defender product raises high-fidelity alerts from its own deep telemetry, a shared correlation engine joins them across domains, and response actions (isolate a device, disable a user, purge an email) execute directly in the product that owns the asset.
Defender XDR unifies the Microsoft Defender family, each covering one attack surface:
- Microsoft Defender for Endpoint (MDE) covers devices: process, file, network, and registry telemetry, endpoint detection and response, attack surface reduction, and device response actions such as isolation and live response.
- Microsoft Defender for Office 365 (MDO) covers email and collaboration: phishing and malware detection, Safe Links and Safe Attachments, and email remediation through Threat Explorer.
- Microsoft Defender for Identity (MDI) covers on-premises Active Directory: sensors on domain controllers and related servers detect attacks such as pass-the-hash and Kerberoasting.
- Microsoft Defender for Cloud Apps (MDCA) covers SaaS applications: activity monitoring, risky OAuth apps, and session controls.
Additional sources feed the same incident queue, including Microsoft Entra ID Protection (identity risk), Microsoft Defender for Cloud (cloud workload alerts), and Microsoft Purview (data loss prevention and insider risk alerts). Those integrations are why Phase 3's response objectives span so many products yet happen in one place.
The XDR advantage is depth plus speed. Because the platform understands its own telemetry, it can run automated investigation and response (AIR) to examine and remediate common threats, and automatic attack disruption to contain a compromised user or device mid-attack, both covered in Phase 2. Its advanced hunting data covers the last 30 days.
⚠️ Exam Trap: Know which product owns which surface. On-premises AD attacks such as Kerberoasting are Defender for Identity; risky cloud sign-ins are Entra ID Protection; malicious inbox rules and phishing campaigns are Defender for Office 365; risky OAuth app consents are Defender for Cloud Apps. Distractors routinely swap these.
Reflection Question: Why can Defender XDR isolate a device within seconds of a high-confidence detection, while a SIEM-only design usually needs a separately built and permissioned automation to do the same thing?
