Alerts, incidents, and correlation in Microsoft Defender XDR

In Microsoft Defender XDR, alerts are signals from a collection of sources that result from various threat detection activities. These signals indicate the occurrence of malicious or suspicious events in your environment. Alerts can often be part of a broader, complex attack story, and related alerts are aggregated and correlated together to form incidents that represent these attack stories.

Incidents provide the full picture of an attack. Microsoft Defender XDR's algorithms automatically correlate signals (alerts) from all Microsoft security and compliance solutions, as well as from vast numbers of external solutions through Microsoft Sentinel and Microsoft Defender for Cloud. Defender XDR identifies multiple signals as belonging to the same attack story, using AI to continually monitor its telemetry sources and add more evidence to already open incidents.

Incidents also function as "case files," providing you a platform for managing and documenting your investigations. For more information about incidents' functionality in this regard, see Incident response in the Microsoft Defender portal.

Here is a summary of the main attributes of incidents and alerts, and the differences between them:

Incidents:

• Are the main "unit of measure" of the work of the Security Operations Center (SOC).
• Display the broader context of an attack—the attack story.
• Represent "case files" of all the information needed to investigate the threat and the findings of the investigation.
• Are created by Microsoft Defender XDR to contain at least one alert, and in many cases, contain many alerts.
• Trigger automatic series of responses to the threat, using automation rules, attack disruption, and playbooks.
• Record all activity related to the threat and its investigation and resolution.

Alerts:

• Represent the individual pieces of the story that are essential to understanding and investigating the incident.
• Are created by many different sources both internal and external to the Defender portal.
• Can be analyzed by themselves to add value when deeper analysis is required.
• Can trigger automatic investigations and responses at the alert level, to minimize the potential threat impact.

Alert sources

Microsoft Defender XDR alerts are generated by many sources:

• Solutions that are part of Microsoft Defender XDR

  • Microsoft Defender for Endpoint
  • Microsoft Defender for Office 365
  • Microsoft Defender for Identity
  • Microsoft Defender for Cloud Apps
  • The app governance add-on for Microsoft Defender for Cloud Apps
  • Microsoft Entra ID Protection
  • Microsoft Data Loss Prevention

• Other services that have integrations with the Microsoft Defender security portal

  • Microsoft Sentinel
  • Non-Microsoft security solutions that pass their alerts to Microsoft Sentinel
  • Microsoft Defender for Cloud

Microsoft Defender XDR itself also creates alerts. With Microsoft Sentinel onboarded to the unified security operations platform, Microsoft Defender XDR's correlation engine now has access to all the raw data ingested by Microsoft Sentinel. (You can find this data in Advanced hunting tables.) Defender XDR's unique correlation capabilities provide another layer of data analysis and threat detection for all the non-Microsoft solutions in your digital estate. These detections produce Defender XDR alerts, in addition to the alerts already provided by Microsoft Sentinel's analytics rules.

When alerts from different sources are displayed together, each alert's source is indicated by sets of characters prepended to the alert ID. The Alert sources table maps the alert sources to the alert ID prefix.

Incident creation and alert correlation

When alerts are generated by the various detection mechanisms in the Microsoft Defender security portal, as described in the previous section, Defender XDR places them into new or existing incidents according to the following logic:

The criteria Microsoft Defender uses 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.

Incident correlation and merging

Microsoft Defender XDR’s correlation activities don’t stop when incidents are created. Defender XDR 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 XDR merges the incidents into a single incident.

How does Defender XDR make that determination?

Defender XDR’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.

When are incidents not merged?

Even when the correlation logic indicates that two incidents should be merged, Defender XDR 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 maximum allowed.
• 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.)

What happens when incidents are merged?

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 Microsoft Defender XDR, 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 moved to the consolidated 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.

Manual correlation

While Microsoft Defender XDR 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.

Next steps

Read more about incidents, investigation, and response: Incident response in the Microsoft Defender portal

See also

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