Alert correlation and incident merging in the Microsoft Defender portal

This article explains how the Microsoft Defender portal aggregates and correlates the alerts that it collects 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.

Outcomes 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 are migrated into the other incident, and the incident abandoned in the process is automatically closed. The abandoned incident is no longer visible or available in the Defender portal, and any reference to it is redirected to the consolidated incident. The abandoned, closed incident remains accessible in Microsoft Sentinel in the Azure portal. The contents of the incidents are handled in the following ways:

• Alerts contained in the abandoned incident are removed from it and added to the consolidated incident.
• Any tags applied to the abandoned incident are removed from it and added to the consolidated incident.
• A Redirected tag is added to the abandoned incident.
• Entities (assets etc.) follow the alerts they're linked to.
• Analytics rules recorded as involved in the creation of the abandoned incident are added to the rules recorded in the consolidated incident.
• Currently, comments and activity log entries in the abandoned incident are not moved to the consolidated incident.

To see the abandoned 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 two incidents eligible for merging are assigned to two different people.
• Merging the two incidents would raise the number of entities in the merged incident above the allowed maximum of 50 entities per incident.
• 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:

• Manage incidents in Microsoft Defender

See also

• The power of incidents in Microsoft Defender XDR
• Inside Microsoft Defender XDR: Correlating and consolidating attacks into incidents