Sentinel and Defender XDR Bi-Directional Sync

Microsoft Sentinel and Microsoft Defender XDR (formerly Microsoft 365 Defender) are two pillars of Microsoft's security operations platform. Sentinel is a cloud-native SIEM (Security Information and Event Management) that ingests logs from across the enterprise, while Defender XDR is an extended detection and response (XDR) solution that correlates alerts from Microsoft Defender for Endpoint, Office 365, Identity, and Cloud Apps. The bi-directional sync ensures that alerts and incidents created in either system are automatically shared with the other, enabling a single pane of glass for security analysts.

Before this sync, analysts often had to toggle between Sentinel and Defender XDR consoles, manually correlating incidents. This led to duplication of effort, delayed response, and increased risk of missing critical alerts. The bi-directional sync solves this by making Sentinel the central incident management hub while retaining Defender XDR's native detection capabilities. For SC-200, you must know that this sync is not just a one-way feed; it allows actions taken in one system (like changing an incident status) to be reflected in the other.

The sync operates through the Microsoft Graph Security API and the Microsoft 365 Defender connector in Sentinel. Here's the step-by-step mechanism:

1. Alert Generation: Defender XDR generates an alert based on detection logic (e.g., a suspicious process launch). This alert has a unique ID (e.g., alertId in GUID format). 2. Incident Creation: Defender XDR correlates multiple alerts into an incident. The incident also has a unique ID (e.g., incidentId). 3. Sync to Sentinel: The Microsoft 365 Defender data connector in Sentinel pulls these alerts and incidents via the Graph Security API. The connector uses OAuth 2.0 authentication with a service principal or managed identity. It queries the endpoint https://api.security.microsoft.com/api/incidents every 5 minutes by default (configurable via the connector settings). 4. Mapping to Sentinel Schema: Each Defender XDR incident is mapped to a Sentinel incident with the following fields: - Title → title - Severity → severity (Informational, Low, Medium, High) - Status → status (New, Active, Closed) - AssignedTo → owner - Tags → tags - Comments → comments - Alerts → alerts (each alert becomes a Sentinel alert with its own properties) 5. Sync Back to Defender XDR: When an analyst updates a Sentinel incident (e.g., changes status to 'Closed' with a classification), Sentinel pushes that change back to Defender XDR via the Graph Security API. This uses the PATCH method on the incident's endpoint. The sync is near real-time, typically within 2-3 minutes. 6. Conflict Resolution: If both systems are updated simultaneously, the last write wins. Sentinel's updates take precedence because it is considered the system of record for incident management.

- Microsoft 365 Defender Connector: This is the data connector in Sentinel that enables the sync. It must be enabled and configured with appropriate permissions. - Permissions: The service principal or managed identity used by the connector must have the 'Security Incident Manager' role in Microsoft 365 Defender. Without this, sync will fail. - Sync Interval: Default is every 5 minutes. You can adjust this in the connector's configuration page under 'Polling interval'. Minimum is 1 minute, but this may increase API costs. - Incident Mapping Fields: The following fields are synchronized both ways: - Status: New, Active, Closed - Severity: Informational, Low, Medium, High - AssignedTo: User principal name (UPN) of the analyst - Tags: Custom tags (max 100 per incident) - Comments: Text comments (max 1000 characters each) - Classification: When closing an incident, you must provide a classification (e.g., TruePositive, FalsePositive, BenignPositive). This is required and must match one of the predefined values. - Alert Mapping: Each Defender XDR alert is mapped to a Sentinel alert. The alert's evidence array (containing entities like IP addresses, file hashes, user accounts) is mapped to Sentinel's entities field. - Entity Mapping: Entities are mapped using the Microsoft Graph Security API's entity schema. For example, a Host entity in Defender XDR becomes a Host entity in Sentinel with fields like HostName, OSFamily, RiskScore. - Automation Rules: Sentinel automation rules can trigger on incident creation or update, and these actions can be synced back to Defender XDR. For example, a playbook that changes the incident status to 'Active' will update Defender XDR.

To configure the sync, you use the Azure portal or PowerShell. There is no direct CLI for the sync itself, but you can verify connectivity.

PowerShell Example to Check Connector Status:

# Connect to Azure
Connect-AzAccount

# Get the Microsoft 365 Defender connector
$connector = Get-AzSentinelDataConnector -ResourceGroupName "myResourceGroup" -WorkspaceName "myWorkspace" -DataConnectorName "MicrosoftThreatProtection"
$connector | Format-List

KQL Query to Verify Ingested Defender XDR Incidents:

SecurityIncident
| where ProviderName == "Microsoft 365 Defender"
| take 10

Verification Steps in Portal: - Navigate to Sentinel > Data connectors > Microsoft 365 Defender. - Check the 'Status' column – it should show 'Connected'. - Review the 'Received data' graph to ensure incidents are flowing. - Open an incident in Sentinel and verify that the 'Provider' field shows 'Microsoft 365 Defender'.

You can use automation rules in Sentinel to automatically assign incidents, change severity, or add tags. These changes sync to Defender XDR. For example, an automation rule that sets the incident severity to 'High' when a specific tag is present will update Defender XDR. However, automation rules that trigger on incident update (e.g., when a comment is added) can cause infinite loops if they also update the incident. To avoid this, use conditions that check if the update originated from the sync itself (e.g., by checking the ProviderName field).

A large financial institution with a 24/7 SOC uses Sentinel as their primary SIEM. They have thousands of endpoints protected by Microsoft Defender for Endpoint, and their SOC analysts prefer Sentinel's interface for incident management. Before bi-directional sync, analysts had to manually copy incident details from Defender XDR to Sentinel, leading to delays and errors. After enabling the sync, all Defender XDR incidents appear automatically in Sentinel. Analysts triage and close incidents in Sentinel, and the status updates propagate back to Defender XDR. This eliminated duplicate work and reduced mean time to respond (MTTR) by 40%. The SOC also uses automation rules to assign incidents to specific teams based on severity. A key lesson: they initially forgot to assign the Security Incident Manager role to the connector's managed identity, causing sync failures. After fixing permissions, the sync worked seamlessly.

A multinational corporation has separate teams for endpoint security (using Defender XDR) and cloud security (using Sentinel). The endpoint team wants to retain their native workflows in Defender XDR, while the cloud team uses Sentinel for broader correlation. Bi-directional sync allows both teams to collaborate: when the endpoint team creates an incident in Defender XDR, it appears in Sentinel where the cloud team can enrich it with cloud context (e.g., Azure AD sign-in logs). If the cloud team determines the incident is a false positive, they close it in Sentinel, and the endpoint team sees the closure in Defender XDR. This avoids conflicting statuses. They configured the polling interval to 2 minutes for faster sync. However, they encountered an issue: manual incidents created in Sentinel (not from Defender XDR) were not syncing back, causing confusion. They learned that only incidents originating from Defender XDR are synced back; manual Sentinel incidents are one-way only.