Evaluating Microsoft Defender for Cloud and XDR Connector: A Comparative Analysis

Special thanks to BlueVoyant SIEM Engineers Sandor Tokesi and Mahmood Khan.

This blog post delves into a series of tests BlueVoyant conducted to evaluate the functionalities and interactions between Microsoft Defender for Cloud and the XDR connector. The objective of the tests is to provide insights into optimizing and enhancing cybersecurity measures for your organization.

Without XDR

1. In the absence of XDR, enabling the legacy connector allows alerts from Defender for Cloud to flow to Sentinel for specified subscriptions. It is important to note that the legacy connector only forwards alerts, not incidents, which necessitates an incident creation rule to capture incidents. The synchronization between Defender for Cloud and Sentinel operates such that closing an incident in Sentinel also closes it in Defender for Cloud. However, closing something in Defender for Cloud only updates the alert in Sentinel but does not close the incident created by the incident creation rule.
2. If only the new connector is enabled, it only forwards alerts, not incidents, and thus requires an incident creation rule. Initial tests indicate that synchronization may not function for tenant-based solutions. However, further confirmation is required.

If XDR Incidents are Enabled

The XDR connector solely forwards incidents, not alerts, to Sentinel for Defender for Cloud. If none of the Defender for Cloud connectors in Sentinel is enabled, the incoming Defender for Cloud incidents from XDR will lack data and underlying alerts, making them impossible to investigate in Sentinel. In that scenario, without a Defender for Cloud connector, the XDR connector only forwards empty incidents. If any Defender for Cloud connectors are enabled, they will forward alerts, providing information within the XDR incidents. If XDR incidents are enabled, there will be full synchronization between the three solutions. Therefore, closing incidents in any of the solutions will result in their closure in all other solutions.

With XDR and MS Incident Creation Rule for Defender for Cloud-Enabled

In this configuration, one Defender for Cloud incident will result in one XDR incident but two Sentinel incidents - one originating from XDR and one created by the incident creation rule. Closing the Sentinel incident created by the incident creation rule will close all incidents across the board. However, closing the Sentinel incident created by XDR will leave the incident created by the incident creation rule open.

Recommendations

Based on this analysis, the recommended approach to avoid duplicates is to enable any of the Defender for Cloud connectors and disable the incident creation rule. This way, the Defender for Cloud connector will only forward alerts and no incidents, with the incidents coming from XDR. It is crucial to enable the Defender for Cloud connector (even without the incident creation rule) to ensure that created incidents have pertinent information in Sentinel.

Despite initial assumptions, without the Defender for Cloud connectors, incidents will lack alerts, entities, and other critical information. As a result, the proposed guidelines are to select the tenant-based connector, enable XDR and disable the incident creation rule for Defender for Cloud.

In situations where alerts are required only from a few subscriptions, avoid using the subscription + XDR combination, as it can result in empty incidents. The only viable option currently is to use the subscription-based connector, along with the incident creation rule (and/or BV rule) and disable the Defender for Cloud option in Defender XDR. However, this approach may lead to a loss of some functionalities.

Table for Reference