Merge pull request #581 from yelevin/yelevin/incident-correlation

Incident correlation document

Author: American-Dipper

defender-xdr/TOC.yml

@@ -158,6 +158,8 @@
       items: 
        - name: Overview
          href: incident-response-overview.md
+       - name: Alerts, incidents, and correlation
+         href: alerts-incidents-correlation.md
        - name: Investigate and respond with Microsoft Copilot in Microsoft Defender
          items:
               - name: Overview

defender-xdr/alerts-incidents-correlation.md

@@ -0,0 +1,116 @@
+---
+title: Alerts, incidents, and correlation in Microsoft Defender XDR
+description: Learn how alerts and incidents are correlated in Microsoft Defender XDR.
+ms.service: defender-xdr
+f1.keywords: 
+  - NOCSH
+ms.author: yelevin
+author: yelevin
+ms.localizationpriority: medium
+manager: dansimp
+audience: ITPro
+ms.collection: 
+  - m365-security
+  - usx-security
+  - tier1
+ms.topic: conceptual
+search.appverid: 
+  - MOE150
+  - MET150
+ms.date: 05/30/2024
+appliesto: 
+- Microsoft Defender XDR 
+- Microsoft Sentinel in the Microsoft Defender portal
+---
+
+# 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.
+
+[!INCLUDE [unified-soc-preview](../includes/unified-soc-preview.md)]
+
+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](/azure/sentinel/automate-incident-handling-with-automation-rules?tabs=onboarded), [attack disruption](automatic-attack-disruption.md), and [playbooks](/azure/sentinel/automation/automate-responses-with-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](m365d-autoir.md) at the alert level, to minimize the potential threat impact.
+
+## Alert sources
+
+Microsoft Defender XDR alerts can come from 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
+  - Microsoft Defender for Cloud
+
+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**](investigate-alerts.md#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, Defender XDR places them into new or existing incidents according to the following logic:
+
+| Scenario | Decision |
+| -------- | -------- |
+| The alert is sufficiently unique across all alert sources within a particular time frame. | Defender XDR creates a new incident and adds the alert to it. |
+| The alert is sufficiently related to other alerts—from the same source or across sources—within a particular time frame. | Defender XDR adds the alert to an existing incident. |
+
+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 criterion is in effect only when enabled.
+- One of the incidents was created by a custom detection, and the other was not.
+
+### What happens when incidents are merged?
+
+When two or more incidents are merged, the contents of one incident are migrated into the other incident. A new incident is not created. The incident abandoned in the process is automatically deleted. If the abandoned incident originated in Microsoft Sentinel, it will be closed but not deleted. Any references to the closed or deleted incident are redirected to the consolidated incident. The contents of the incidents are handled in the following ways:
+
+- Alerts contained in the closed 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.
+- Comments and activity log entries in the abandoned incident are *not* moved to the new one.
+
+## 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.
+
+[!INCLUDE [Microsoft Defender XDR rebranding](../includes/defender-m3d-techcommunity.md)]