7.9 Integrating Defender XDR with Sentinel

Integrating Defender XDR with Sentinel

Introduction

Modules 1-5 covered Defender XDR — the detection and response platform for endpoints, email, identity, cloud apps, and cloud workloads. This module covers Sentinel — the SIEM and SOAR platform. The unified security operations platform merges both into a single operational experience in the Microsoft Defender portal, where Sentinel’s SIEM capabilities (analytics rules, automation, hunting, workbooks) and Defender XDR’s detection capabilities (product-specific alerts, automated investigation and response) work as one integrated system.

This subsection covers the integration architecture, the bi-directional data flow between Defender XDR and Sentinel, incident synchronisation, and the operational model for SOC teams using both platforms together.

The unified security operations platform

The unified platform moves Sentinel’s core capabilities into the Defender portal (security.microsoft.com). Instead of switching between the Azure portal (for Sentinel) and the Defender portal (for XDR), the SOC analyst works in one portal for both.

What moves to the Defender portal: Sentinel incident queue (merged with Defender XDR incidents into a single queue), advanced hunting (Sentinel tables available alongside Defender XDR tables in the same query editor), automation rules and playbooks, and Sentinel analytics rules. The analyst sees one incident queue, writes one KQL query surface, and manages one set of automation rules.

What stays in the Azure portal: Workspace configuration (the settings from subsections 7.2-7.5), data connector management, Content Hub, watchlist management, and workspace health monitoring. These are administrative tasks that the SOC analyst performs infrequently — the day-to-day investigation and detection work happens in the Defender portal.

Connecting Defender XDR to Sentinel

The Microsoft Defender XDR data connector is the primary integration point. Navigate to Microsoft Sentinel → Data connectors → Microsoft Defender XDR → Open connector page → Connect incidents & alerts.

What the connector enables:

Incident synchronisation: Defender XDR incidents appear in the Sentinel incident queue. Status changes, severity changes, and assignments synchronise bi-directionally — close an incident in Defender, it closes in Sentinel, and vice versa.

Alert data: All Defender product alerts (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps) flow into the SecurityAlert table in Sentinel. Analytics rules can evaluate these alerts alongside alerts from other Sentinel data sources.

Advanced hunting data: Defender XDR advanced hunting tables (DeviceProcessEvents, EmailEvents, IdentityLogonEvents, CloudAppEvents, and others) become available in the Sentinel workspace for KQL queries and analytics rules. This is the integration that makes cross-product investigation work — you query Defender XDR data and Sentinel-native data in the same KQL query.

Table selection: The connector allows you to select which Defender XDR tables to ingest into Sentinel. By default, all tables are selected. For cost optimisation, you can deselect tables that are not needed for Sentinel analytics rules or cross-product queries. However, be cautious: deselecting a table means it is not available for Sentinel analytics rules or cross-workspace queries — it remains available only in the Defender portal’s advanced hunting.

Bi-directional incident synchronisation

The synchronisation between Defender XDR and Sentinel incidents is a critical operational feature.

Defender XDR → Sentinel: When Defender XDR creates an incident (from product-specific alerts), it appears in the Sentinel incident queue. The Sentinel incident includes all Defender XDR alerts, affected entities, and evidence. Sentinel analytics rules can also fire against Defender XDR data, creating Sentinel-native alerts that are grouped into the same incident if they share entities.

Sentinel → Defender XDR: When Sentinel creates an incident (from Sentinel-native analytics rules that detect threats in non-Defender data sources — firewall logs, custom applications, third-party security tools), it appears in the unified incident queue in the Defender portal. Defender XDR automated investigation cannot run against Sentinel-only incidents, but the SOC analyst sees all incidents in one queue regardless of origin.

Status synchronisation: Closing an incident in either portal closes it in both. Changing severity in either portal changes it in both. Assigning an analyst in either portal assigns in both. This prevents the split-brain problem where an incident is closed in one portal but remains open in the other.

When synchronisation matters most: During a multi-stage attack that generates both Defender XDR alerts (endpoint detection, email detection) and Sentinel analytics rule alerts (firewall anomaly, custom application alert), the unified incident queue groups all alerts into a single incident. The analyst sees the complete attack picture in one place — not scattered across two separate incident queues.

The advanced hunting unified experience

With the Defender XDR connector enabled, the advanced hunting experience in the Defender portal provides access to both Defender XDR native tables and Sentinel workspace tables in the same query editor.

Defender XDR tables (prefixed with Device*, Email*, Identity*, Cloud*, Alert*) — these are the tables you queried in Modules 1-5.

Sentinel workspace tables (SecurityAlert, SecurityIncident, SigninLogs, AuditLogs, AzureActivity, Syslog, CommonSecurityLog, ThreatIntelligenceIndicator, custom tables) — these are the additional data sources that only exist in the Sentinel workspace.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Cross-platform query: Defender XDR endpoint data + Sentinel TI data
let MaliciousIPs = ThreatIntelligenceIndicator
    | where Active == true and ExpirationDateTime > now()
    | where IndicatorType == "ipv4-addr"
    | project MaliciousIP = NetworkIP, ThreatType, ConfidenceScore;
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| join kind=inner MaliciousIPs on $left.RemoteIP == $right.MaliciousIP
| project TimeGenerated, DeviceName, RemoteIP, RemoteUrl,
    ThreatType, ConfidenceScore, InitiatingProcessFileName

This query joins Defender for Endpoint network events with Sentinel threat intelligence indicators — combining XDR detection data with SIEM enrichment data in a single query. This cross-platform query is only possible with the Defender XDR connector enabled and advanced hunting tables ingested into the Sentinel workspace.

Operational model: when to use which portal

The practical workflow: The SOC analyst starts the day in the Defender portal — checking the unified incident queue, triaging new incidents, and investigating with advanced hunting. The Sentinel administrator visits the Azure portal periodically for workspace maintenance — checking connector health, deploying new Content Hub solutions, updating watchlists, reviewing workspace cost.

Selecting which Defender XDR tables to ingest

The Defender XDR connector allows you to select which Advanced Hunting tables are ingested into Sentinel. Not all tables are equally valuable for Sentinel use cases — some are high-volume with limited security value in the SIEM context.

Always ingest: DeviceProcessEvents (essential for endpoint investigation and detection rules), DeviceNetworkEvents (essential for C2 detection and network correlation), DeviceLogonEvents (essential for lateral movement detection), DeviceFileEvents (essential for malware and data staging detection), EmailEvents (essential for email threat investigation), EmailAttachmentInfo (essential for attachment-based threat analysis), EmailUrlInfo (essential for URL-based phishing detection), UrlClickEvents (essential for phishing blast radius assessment), IdentityLogonEvents (essential for on-premises AD correlation), CloudAppEvents (essential for SaaS and mailbox investigation).

Consider skipping: DeviceInfo (device inventory — useful for enrichment but high volume, consider importing periodically rather than continuously), DeviceNetworkInfo (network adapter details — very high volume, rarely queried in investigations), DeviceFileCertificateInfo (certificate details — niche use cases only), DeviceTvmSoftwareInventory and related TVM tables (vulnerability data — useful for posture but not for incident investigation, consider periodic import).

Cost impact of table selection. In a 5,000-endpoint environment, ingesting all Defender XDR tables can generate 50-100 GB/day. Selective ingestion (the “always ingest” list above) typically reduces this to 20-40 GB/day — a 50-60% cost reduction with minimal investigation impact. The tables you skip are either low-value for security investigation or can be queried directly in the Defender portal without Sentinel ingestion.

Incident correlation across Sentinel and Defender XDR

The unified incident queue combines incidents from both sources, but the correlation engine behaves differently for each.

Defender XDR incident correlation. Defender XDR automatically correlates alerts from different Defender products into a single incident when they share entities (same user, device, or IP). A phishing email alert (Defender for Office 365) + a malicious file download alert (Defender for Endpoint) + a suspicious sign-in alert (Defender for Identity) are automatically grouped into one incident if they involve the same user within a correlated time window.

Sentinel analytics rule incident correlation. Sentinel groups alerts into incidents based on the entity mapping and grouping configuration in each analytics rule. By default, Sentinel creates a new incident for each alert. You can configure alert grouping to: group alerts with the same entities into a single incident (recommended for most rules), group all alerts from the same rule into a single incident within a time window, or create a new incident for every alert (useful for high-fidelity detections where each alert warrants independent investigation).

Cross-source correlation. When both Defender XDR and Sentinel analytics rules fire on the same entity (the same user or IP), the unified platform can correlate them into a single incident. This is the highest-value correlation scenario: a Defender XDR alert (behavioural detection from the endpoint) combined with a Sentinel analytics rule alert (log-based detection from sign-in data or firewall logs) provides multi-source confirmation of the same threat.

Configure your Sentinel analytics rules to use entity mapping consistently — map the same entity types (Account, IP, Host) that Defender XDR uses. This enables the cross-source correlation engine to match Sentinel alerts with Defender XDR alerts when they share entities.

Migration considerations: Defender portal as primary SOC interface

For organisations transitioning to the unified platform, the migration has operational implications.

Analyst workflow changes. Analysts accustomed to the Azure portal Sentinel experience need training on the Defender portal layout, navigation, and feature locations. The investigation workflow is conceptually identical (triage → investigate → respond), but the UI is different. Plan 1-2 weeks of adjustment for the SOC team.

Bookmark and query migration. Hunting queries saved in the Sentinel Azure portal blade need to be recreated or migrated to the Defender portal hunting experience. Custom workbooks remain in the Azure portal. Analytics rule management is available in both portals but the Azure portal provides the more complete management experience.

Automation continuity. Automation rules and playbooks configured in Sentinel continue to work — they are triggered by incidents regardless of which portal created them. No automation migration is needed.

Knowledge check