Alert XX was added to the incident by Microsoft Defender XDR - alert correlation

Question

Hey, I am sending alarms/incidents from another SIEM to sentinel for centralization. The goal is that sentinel mirrors the alarms/incidents exactly.

The data is sent to a custom log table, in the log analytics workspace through an API call, and I have a NRT analytics rule that creates an alert pr event, and places it in an incident in sentinel.

But if any of the N next alarms being sent from my other SIEM has the same entities, XDR correlates them into one incident. This breaks my mirroring. I have tried to set an entity with a unique identifier to be created in each alert, but that doesn't work.

Any idea how I can exclude the alarms/incidents created from my custom table from this alert correlation?

Answer 1

Hello Lorents,

Thank you for posting your query on Microsoft Q&A.

XDR automatically correlates based on entities like IP addresses, usernames, etc., it can mistakenly group alarms with the same entities into one incident. XDR might have a more granular control over how incidents are correlated based on entities. Depending on the specific configuration of XDR and Sentinel, you may be able to adjust the correlation settings for your custom log table to prevent these alarms from being correlated with other incidents. Check your correlation policies to see if there's an option to exclude alarms from specific sources or types.

You mentioned that you've already tried creating a unique identifier for each alert, but it seems like the correlation rules are still being applied. To make sure this identifier works

Make sure that every alarm has a unique GUID or SIEMAlertID, or any other custom identifier field. Even if the same entities are involved, each alarm should have a unique identity.

When creating an incident, include this custom field Include this identity in the incident when setting up the alert rule. To distinguish it from other alerts, make sure the identification is appended to the IncidentId or AlertId.
https://learn.microsoft.com/en-us/azure/sentinel/relate-alerts-to-incidents

If a unique identifier isn't enough, you can use custom tags or an AlertType to differentiate alarms. For example, tag alerts with AlertSource: CustomSIEM and modify your KQL queries to filter based on this tag, preventing correlation when it matches.

Check the IncidentCreation settings in your custom NRT analytics rules. Adjust correlation logic to avoid grouping by common entities (e.g., IP, user) and create exclusion rules to prevent correlation for alerts from your custom log table.
https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules

https://learn.microsoft.com/en-us/defender-xdr/alerts-incidents-correlation

I hope this clarifies things.

Answer 2

Consider revising your connector to work with the new correlation model. Sentinel rules and the other Microsoft security solutions create alerts in XDR. Those alerts are correlated into incidents by XDR. The name of the incident matched the name of the alerts until there are alerts from multiple sources. Then the incident is replaced by one with a name that better reflects the correlated alerts. Sentinel has 2-way integration with XDR to sync incidents.

I have seen several ticket integration solutions. It is a common mistake to focus on alert rather than incident integration. This was more feasible before the XDR integration. Sentinel alone does not have the ability to correlate incidents; only alerts.

I am not aware of a way to break this process intentionally. Consider that as an investigator, it is better to see these incidents in light of all related evidence that tells a more complete story. For example, if you were a police investigator, you would have a case file full of evidence from multiple sources. Pulling out and focusing on a single piece of evidence will likely only cause confusion. Improving your connector to work with this model will also improve how you ingest incidents from other 1st party Microsoft security services. Rather than trying to degrade the solution to support an outdated approach.