SA0.8 Defender XDR Automation Architecture

Auto Investigation and Response (AIR)

When Defender for Endpoint detects malware on a device, AIR automatically investigates: it examines the process tree, checks related files, reviews network connections, and identifies other endpoints that may be affected. Based on the investigation findings, AIR recommends or executes remediation actions — quarantine the file, isolate the endpoint, disable the account.

AIR operates in two modes. In “full automation” mode, it investigates and remediates without human approval. In “semi-automation” mode, it investigates automatically but presents the remediation actions for analyst approval in the Action Center. The mode is configured per device group — you can set full automation for workstations (low blast radius) and semi-automation for servers (high blast radius).

The critical insight about AIR is that it operates entirely within Defender XDR’s product boundary. It cannot call external APIs, query Sentinel watchlists, post to Teams, or create ServiceNow tickets. It cannot check your VIP watchlist before disabling an account. It cannot correlate with Sentinel incidents from non-Microsoft data sources. AIR is powerful within its scope and blind outside it.

What AIR catches well: Known malware (signature-based), credential theft tools (Mimikatz patterns), lateral movement using known techniques (PsExec, WMI, RDP with pass-the-hash), and email threats (phishing with known indicators). These are high-confidence detections where AIR’s built-in investigation logic performs well.

What AIR misses: Custom attack tools, living-off-the-land techniques that blend with legitimate administration, attacks that span multiple products (identity compromise + email + endpoint), and attacks that require environmental context (is this user a VIP? Is this server critical?) to make correct response decisions.

Attack disruption

Attack disruption is Defender XDR’s highest-confidence automated response. It identifies in-progress attacks — ransomware encryption, BEC financial fraud, AiTM session hijacking — and automatically disrupts them by containing the compromised user and isolating the compromised device.

Attack disruption differs from AIR in two ways. First, it targets specific high-impact attack patterns (ransomware, BEC, AiTM) rather than generic alert types. Second, it acts faster — it is designed to disrupt an attack in progress, not investigate after the fact.

The limitation is scope. Attack disruption only fires on attack patterns that Defender’s ML models recognise. A novel attack technique, a custom malware family, or an attack chain that does not match a known pattern will not trigger attack disruption. This is where Sentinel automation fills the gap — custom detections with custom response logic for the threats that are specific to your environment and your threat model.

Custom detection rules with auto-actions

Defender XDR custom detection rules are KQL queries that run against the advanced hunting tables (DeviceProcessEvents, EmailEvents, IdentityLogonEvents, CloudAppEvents). When the query returns results, Defender creates an alert and can automatically execute response actions on the entities in the results — isolate the device, quarantine the file, disable the user, or force password reset.

This is the Defender equivalent of Sentinel’s automation rule + playbook combination. The advantage: the response action executes directly from the detection, with no Logic App overhead, no managed identity configuration, and no connector setup. The disadvantage: the response actions are limited to Defender’s built-in capabilities. You cannot call external APIs, query non-Microsoft data sources, or implement complex conditional logic.

When to use Defender custom detections: When the detection and the response are both within Defender’s product scope. A detection for “encoded PowerShell downloading from external URL” that auto-isolates the endpoint is a perfect Defender custom detection — the detection uses DeviceProcessEvents, the response uses MDE’s isolation API, and no external integration is needed.

When to use Sentinel instead: When the response requires cross-product action (revoke identity sessions AND isolate endpoint AND block IP at firewall), external integration (notify Teams, create ServiceNow ticket, query external TI), or conditional logic (check VIP watchlist, assess blast radius, route to approval).

The unified model — Defender XDR and Sentinel together

The correct architecture uses both platforms:

Defender XDR handles fast, single-product responses. AIR investigates and remediates within MDE, MDO, and MDI. Attack disruption contains in-progress attacks. Custom detections with auto-actions handle Defender-specific detection-response pairs.

Sentinel handles cross-product orchestration. Playbooks coordinate identity + endpoint + network containment. Logic Apps integrate with Teams, email, ticketing, and external TI. Watchlists provide environmental context (VIP lists, known-safe IPs, asset criticality). Workbooks monitor automation health across both platforms.

The platforms must not conflict. If Defender AIR auto-disables a user account and a Sentinel playbook also tries to disable the same account, the second action fails (the account is already disabled) and generates an error log. This is not harmful, but it is noise. Coordinate by: having the Sentinel playbook check the current account status before acting (if already disabled, skip and log “already contained by Defender”), and monitoring the Action Center to ensure Sentinel and Defender are not duplicating actions.