Over the past few weeks, Microsoft Defender for Cloud has received multiple updates. Microsoft has introduced a new tenant-level Defender for Cloud connector, replacing the old subscription-level one. Additionally, they have implemented a new functionality, allowing detections from Defender for Cloud to be integrated into Defender XDR, along with detections from other Defender solutions.
There are multiple articles about these topics, but seemingly there are still unanswered questions. This post will focus on the effects of enabling and disabling the various options available in these tools.
I utilized the default Defender XDR configuration during these initial tests, which implies that MDC is connected to Defender XDR, and all MDC alerts are processed by XDR.
Subscription-Based Connector
This is the legacy way of connecting Defender for Cloud to Sentinel.
Two benefits of this connector are:
- You can enable the alert collection on subscription-level.
- You can enable a (limited) bi-directional synchronization between Sentinel and Microsoft Defender for Cloud.
Both benefits come with some drawbacks as well:
- Enabling alert collection on a subscription-level requires ensuring that every subscription is being monitored at all times, necessitating additional automation or policies to ensure newly created subscriptions also forward alerts to Sentinel.
- The synchronization is not a complete solution, potentially requiring additional automation for a fully-fledged synchronization between the services.
Alert Forwarding and Synchronization
When an alert is generated in Defender for Cloud, the subscription-based connector forwards this alert to Sentinel. In Sentinel, this detection appears as an alert in the SecurityAlert table – so, just an event -, but it does not automatically generate an incident.
In Sentinel alerts and incidents are different. Alerts are simply events recorded in the SecurityAlert table. They include a lot of information on a given detection, yet they remain static. This means that their fields and values cannot be updated once the event has been saved in the SecurityAlert table. Incidents in Sentinel are the tickets that analysts should investigate. Incidents, unlike alerts, are dynamic; they have a state that can be changed, assigned to someone, and different fields that may be modified.
The alerts in Defender for Cloud function similarly to incidents in Sentinel. They can be opened, closed, or assigned, resembling a ticket.
When an alert is generated in Microsoft Defender for Cloud, the subscription-based connector transfers it to the SecurityAlert table in Sentinel. If the status of the MDC alert changes (e.g., to ‘Resolved’), the connector attempts to reflect this in Sentinel. However, as the status of an alert in Sentinel cannot be modified, the connector creates a new event for the same MDC alert with the updated ‘Resolved’ status. This approach enables querying the latest event to check the current status of an MDC alert in Sentinel.
The SystemAlertId field uniquely identifies the alert. By looking up the alert ID, one can track the status changes of specific MDC alert in Sentinel.
As previously mentioned, this connector only generates alerts in Sentinel, not incidents. Typically, the SOC investigates incidents, so if we need them to review the detection, we must create an incident for them.
To achieve this, a ‘Microsoft incident creation rule’ can be created. These rules are specifically designed for this purpose and were developed for the legacy connectors to ensure that the alerts forwarded by various Defender solutions are treated as incidents.
Creating such a rule is straightforward. On the Analytics page, you simply need to create a new ‘Microsoft incident creation rule’ and define which security service you want to include, such as Microsoft Defender for Cloud in our case.
After this setup, whenever a Defender alert is created or modified, the connector will push a new event into the SecurityAlert table. Additionally, the newly created incident creation rule will pick up the initial alert and generate a new incident from it. As a result, the SOC will have all the necessary information to commence monitoring and investigation.
Sync
The syncing capabilities of the subscription-based connector involve the following processes:
From the MDC side, when a new MDC alert is created or an existing one is modified, the connector generates a new event in the SecurityAlert table with the updated fields. However, this information is not replicated in the created Sentinel incident. Therefore, if the MDC alert is closed, it will create a Sentinel event (alert) in the SecurityAlert table with the status field set to ‘Dismissed’ or ‘Resolved’, while the Sentinel incident will remain intact.
Conversely, if the Sentinel incident is closed or updated, it will create a new event in the SecurityAlert table containing the updated value of the alert. Since the synchronization works fully between the SecurityAlert table and the MDC alert, as a result, the alert in Defender for Cloud will also be closed.
This diagram illustrates the path of the incident creation (blue arrows) and the synchronization of alerts and incidents (red arrows):
Without bi-directional sync enabled, MDC will still push updates into the SecurityAlert table in Sentinel, but there won’t be synchronization between the Sentinel incident and the SecurityAlert table. Consequently, there won’t be anything to be pushed back to MDC.
Tenant-Based Connector
The new preview connector from Microsoft facilitates the forwarding of Defender for Cloud alerts to Sentinel. Like the previous one, this new connector forwards alerts to Sentinel and does not create incidents. To generate incidents for the created MDC detections, a ‘Microsoft incident creation rule’ must be deployed. Notably, the same rule works for the subscription-based and the tenant-based connector.
The tenant-based connector presents some small, yet significant differences compared to the subscription-based connector:
- The tenant-based connector enables alert collection from all subscriptions in the tenant. This simplifies management as it ensures that all subscriptions are constantly connected to Sentinel. However, it does not offer the option to selectively configure alert collection from specific subscriptions.
- Unlike the subscription-based connector, the tenant-based connector does not include a built-in synchronization option. Thus, native synchronization between MDC alerts and Sentinel alerts is not supported.
Alert Forwarding and Synchronization
When an MDC alert is generated, the tenant-based connector retrieves the data and generates a new entry in the SecurityAlert table within Sentinel. Additionally, any modifications made in MDC are mirrored in the SecurityAlert table, akin to the behavior observed with the subscription-based connector. However, changes made to the Sentinel incident do not trigger the creation of a new event in the SecurityAlert table.
This behavior represents the extent of its limited syncing functionality, similar to the behavior of the subscription-based connector when syncing is disabled.
Both Connectors
So now Sentinel has two connectors for the same purpose with slightly different capabilities. One can be curious what happens if you enable both connectors in Sentinel at once.
Duplicated Alerts/Single Incident
Both connectors will pick up the Defender for Cloud Alerts, resulting in duplicate alerts being forwarded to Sentinel. The delay of the tenant-based connector is typically bigger, causing the duplicates to arrive after the subscription-based connector has delivered its alerts.
Regardless of the presence of duplicate alerts, the Incident creation rule will only create one incident. As the subscription-based connector forwards the logs more quickly, incidents will be created based on those alerts. Bi-directional syncing works on these incidents.
It’s important to note that the connectors capture the most recent status of the Defender for Cloud alerts. For instance, if the subscription-based connector forwards an alert to Sentinel and the corresponding Sentinel incident is promptly closed, this information will be synchronized back to Defender for Cloud (bi-directional sync). As a result, the tenant-based connector will only forward an alert to Sentinel with the ‘Resolved’ status.
In the picture above, the oldest event is the one created by the subscription-based connector. The automation rule promptly closed the incident. This is indicated by the second event, where the alert is in a ‘Resolved’ state. This second event was generated by the bi-directional sync coming from from the Sentinel incident. The newest event, with some delay, is the one from the tenant-based connector, and it already shows a ‘Resolved’ state.
Tenant-Based Connector with Non-Default XDR Settings
The previous tests were run by keeping Defender XDR on the default settings, which was to process all MDC alerts.
To gain a comprehensive understanding of how the connectors operate, it’s beneficial to conduct tests by modifying the default configurations. In one such test, the Microsoft Defender for Cloud (MDC) alerts settings in Defender XDR were changed from ‘All alerts (Default)’ to ‘No alerts’. The expected outcome was observed, with MDC alerts no longer being forwarded to Defender XDR. However, this change also resulted in the Tenant-based MDC connector not forwarding any alerts to Sentinel. This suggests that the Tenant-based connector does not directly forward the alerts to Sentinel, but rather retrieves them via XDR.
Furthermore, the SecurityAlert events created in Sentinel contain different links based on the connector through which the alert is picked up. Specifically, the events contain a portal.azure.com link if the alert is picked up by the Subscription-based connector, while they include a security.microsoft.com (Defender XDR) link if the alert is picked up by the Tenant-based connector.
The alert links are illustrated in the following image, showcasing both the subscription-based link and the tenant-based link:
A diagram depicting the alert flow from MDC to Sentinel using both Defender for Cloud connectors was also created. In it the purple color represents the path of the alerts with the condition-less subscription-based connector, while the green line indicates the path of the alerts via the tenant-based connector, which only functions when XDR uses the default (All alerts) setting.
Notably, if ‘All alerts’ is configured but the tenant-based connector is not enabled in Sentinel, Defender XDR will still receive the alerts, but they will not be forwarded from XDR to Sentinel.
Comparison of the Two MDC Sentinel Connectors
Please be aware, during all these tests the Defender for XDR connector in Sentinel was completely disabled. It will be enabled for the tests coming after this point.
The Defender XDR Connector
The Defender XDR connector plays a crucial role in forwarding alerts and incidents to Sentinel, along with telemetry data when necessary.
One notable feature of the Defender XDR connector is its synchronization capability. Unlike the legacy Defender connectors that required the manual creation of incidents via a Microsoft incident creation rule, the incident generation now occurs within the connector itself. This streamlined approach means that when an incident is closed in either Sentinel or Defender XDR, the corresponding incident in the other tool will also be closed, promoting efficient incident management.
An important development is the ability of Defender XDR to retrieve Defender for Cloud incidents and transmit them to Sentinel through the XDR connector. This advancement raises questions regarding the interconnection between the Defender XDR connector and the Defender for Cloud connectors.
In the context of upcoming tests, the MDC configuration in Defender XDR will be reverted to its default value, ‘All alerts (Default)’, to enable the processing of MDC alerts for further evaluation.
MDC Connectors and Defender XDR Connector
Upon activation of the Defender XDR connector in Sentinel for alert and incident creation, it facilitates the forwarding of MDC incidents from XDR to Sentinel, regardless of the chosen MDC connector.
The Defender XDR connector includes synchronization capabilities, ensuring that closures in Sentinel are mirrored in Defender XDR (and MDC), and vice versa.
The question arises: Is there a necessity for the MDC connectors in Sentinel if the XDR connector is enabled. According to Microsoft: 
In practical terms, this means that while the Defender XDR connector synchronizes the incident, the actual alert is forwarded by one of the MDC connectors. So, if no MDC connector is enabled, an incident from XDR may be received without an underlying alert, resulting in a lack of information, entities, and useful details in the incident within Sentinel. This means that although the information will be available in Defender XDR, it will not be accessible within Sentinel. This, in turn, restricts the utilization of the Investigation experience in Sentinel.
Here is a Sentinel incident without MDC connector enabled:
And the same incident with the subscription-based connector enabled:
The architecture of how the modules are working together functionality-wise:
The diagram indicates that for a Sentinel incident to include data and an underlying alert, it is necessary to have one of the MDC connectors enabled. If the tenant-based connector is in use, the XDR setting must be configured as ‘All alert’; otherwise, the alerts will not be forwarded to XDR, leading to the absence of incidents for MDC detections. In the absence of MDC connectors, the vital correlation between the alert and the Sentinel incident cannot occur.
So, if you enable the Defender XDR connector and you allow MDC alert processing, then it is highly recommended to use at least one of the MDC connectors in Sentinel. For the best experience I would recommend using the tenant-based connector.
Duplicated Incidents
Enabling the Microsoft Incident creation rule on top of the Defender XDR connector results in the creation of duplicated incidents derived from the forwarded alert. Consequently, there will be an incident where the Incident provider name is’Microsoft Defender XDR’ and another where the provider is ‘Azure Sentinel’.
Defender XDR has the capability to correlate incidents into one comprehensive incident. In scenarios where incidents are already present in Sentinel and XDR decides to correlate them, a new incident will be created in Sentinel, encompassing all the alerts. In this process, the existing individual incidents will be closed and marked with the ‘Redirect’ tag.
Summary
In table format:
Issues with the Connectors and MDC
During the testing phase, I encountered some issues with the various connectors. While some connectors are new, some of the are here for a long time. While I anticipate that some of the bugs will be addressed, others may persist until Microsoft retires the solution. The specific issues encountered are as follows:
1. Incorrect Time Information in Defender for Cloud Alerts: This issue is related to MDC directly. On certain occasions, I observed alerts containing future time, which can pose an issue when creating incidents using customized rules that exclude future time from queries. (like | where StartTime > ago(1h) and StartTime < now()).
2. Inaccurate Timing Information in Sentinel: here have been instances where the timing information in Sentinel was incorrect despite the time field in MDC containing accurate data. This discrepancy occurred with the subscription-based connector on two separate occasions. The image below shows that the delay of some alerts was more than an hour, but then just 10 minutes later the delay decreased to just a few minutes. What happened here in reality is that StartTime field in Sentinel does not contain UTC time.
3. In some rare occasions the Defender XDR incident arrived to Sentinel before the related alert : At least the correlation was slow – , which resulted in the incidents being empty for a short period. This delay was particularly notable with the tenant-based connector, which appears to be slower than the subscription-based one, requiring the SOC to wait before initiating investigations.
4. Duplicate alert forwarding with the tenant-based connector: With the tenant-based connector, there were instances where the same MDC alert was forwarded to Sentinel multiple times. However, the Microsoft incident creation rule only generated a single incident despite the multiple alerts.