Alert correlation and incident merging in the Microsoft Defender portal
This article explains how the correlation engine in the Microsoft Defender portal aggregates and correlates the alerts collected from all the sources that produce them and send them to the portal. It explains how Defender creates incidents from these alerts, and how it continues to monitor their evolution, merging incidents together if the situation warrants. To learn more about alerts and their sources, and how incidents add value in the Microsoft Defender portal, see Incidents and alerts in the Microsoft Defender portal.
Incident creation and alert correlation
When alerts are generated by the various detection mechanisms in the Microsoft Defender portal, as described in Incidents and alerts in the Microsoft Defender portal, they're placed into new or existing incidents according to the following logic:
- If the alert is sufficiently unique across all alert sources within a particular time frame, Defender creates a new incident and adds the alert to it.
- If the alert is sufficiently related to other alerts—from the same source or across sources—within a particular time frame, Defender adds the alert to an existing incident.
The criteria used by the Defender portal to correlate alerts together in a single incident are part of its proprietary, internal correlation logic. This logic is also responsible for giving an appropriate name to the new incident.
Manual correlation of alerts
While Microsoft Defender already uses advanced correlation mechanisms, you might want to decide differently whether a given alert belongs with a particular incident or not. In such a case, you can unlink an alert from one incident and link it to another. Every alert must belong to an incident, so you can either link the alert to another existing incident, or to a new incident that you create on the spot.
For instructions, see Link alerts to another incident in the Microsoft Defender portal.
Incident correlation and merging
The Defender portal's correlation activities don't stop when incidents are created. Defender continues to detect commonalities and relationships between incidents, and between alerts across incidents. When two or more incidents are determined to be sufficiently alike, Defender merges the incidents into a single incident.
Criteria for merging incidents
Defender's correlation engine merges incidents when it recognizes common elements between alerts in separate incidents, based on its deep knowledge of the data and the attack behavior. Some of these elements include:
- Entities—assets like users, devices, mailboxes, and others
- Artifacts—files, processes, email senders, and others
- Time frames
- Sequences of events that point to multistage attacks—for example, a malicious email click event that follows closely on a phishing email detection.
Details of the merge process
When two or more incidents are merged, a new incident is not created to absorb them. Instead, the contents of one incident (the "source incident") are migrated into the other incident (the "target incident"), and the source incident is automatically closed. The source incident is no longer visible or available in the Defender portal, and any reference to it is redirected to the target incident. The source incident, though closed, remains accessible in Microsoft Sentinel in the Azure portal.
Merge direction
The direction of the incident merge refers to which incident is the source and which is the target. This direction is determined by Microsoft Defender, based on its own internal logic, with the goal of maximizing information retention and access. The user doesn't have any input into this decision.
Incident contents
The contents of the incidents are handled in the following ways:
- All alerts contained in the source incident are removed from the source incident and added to the target incident.
- Any tags applied to the source incident are removed from the source incident and added to the target incident.
- A
Redirectedtag is added to the source incident. - Entities (assets etc.) follow the alerts they're linked to.
- Analytics rules recorded as involved in the creation of the source incident are added to the rules recorded in the target incident.
- Currently, comments and activity log entries in the source incident are not moved to the target incident.
To see the source incident's comments and activity history, open the incident in Microsoft Sentinel in the Azure portal. The activity history includes the closing of the incident and the adding and removal of alerts, tags, and other items related to the incident merge. These activities are attributed to the identity Microsoft Defender XDR - alert correlation.
When incidents aren't merged
Even when the correlation logic indicates that two incidents should be merged, Defender doesn't merge the incidents under the following circumstances:
- One of the incidents has a status of "Closed". Incidents that are resolved don't get reopened.
- The source and target incidents are assigned to two different people.
- The source and target incidents have two different classifications (for example, true positive and false positive).
- Merging the two incidents would raise the number of entities in the target incident above the allowed maximum.
- The two incidents contain devices in different device groups as defined by the organization.
(This condition is not in effect by default; it must be enabled.)
Next steps
To learn more about prioritizing and managing incidents, see the following articles:
Tip
Do you want to learn more? Engage with the Microsoft Security community in our Tech Community: Microsoft Defender XDR Tech Community.