Merge pull request #4382 from MicrosoftDocs/main

[AutoPublish] main to live - 07/01 04:28 PDT | 07/01 16:58 IST

Author: m365-skilling-repo-management[bot]

defender-xdr/TOC.yml

@@ -94,6 +94,9 @@
           href: investigate-incidents.md
         - name: Move alerts to another incident
           href: move-alert-to-another-incident.md
+        - name: Merge incidents manually
+          href: merge-incidents-manually.md
+        - name: Alerts
         - name: Investigate alerts
           href: investigate-alerts.md
         - name: Investigate entity pages

defender-xdr/alerts-incidents-correlation.md

@@ -37,19 +37,19 @@ When alerts are generated by the various detection mechanisms in the Microsoft D
 
 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.
 
-### Alert correlation by workspace
+### Alert correlation by Microsoft Sentinel workspace
 
-The Defender portal allows you to connect to one primary workspace and multiple secondary workspaces for Microsoft Sentinel. A primary workspace's alerts are correlated with Microsoft Defender XDR data. So, incidents include alerts from Microsoft Sentinel's primary workspace and Defender XDR in a unified queue. All other onboarded workspaces are considered secondary workspaces. For secondary workspaces, incidents are created based on the workspace’s data and won't include Defender XDR data. The Defender portal keeps incident creation and alert correlation separate between the Microsoft Sentinel workspaces. For more information, see [Multiple Microsoft Sentinel workspaces in the Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2310579).
+When the Defender portal is configured to include Microsoft Sentinel as a data source, each Microsoft Sentinel workspace is considered its own separate data source. If you have multiple workspaces for Microsoft Sentinel, the Defender portal allows you to configure one of those workspaces as the *primary workspace*. The alerts that come from the primary workspace can be correlated with Microsoft Defender XDR alerts, and they can be included together in incidents. <!-- XDR data? Or data from any other sources in the portal? In other words, are Sentinel alerts from secondary workspaces ON AN ISLAND? They can be correlated amongst themselves, right? --> Any other onboarded Microsoft Sentinel workspaces are considered *secondary workspaces*. Alerts from these secondary workspaces are *not* correlated with alerts from Defender XDR or any other Defender portal data sources, including other Microsoft Sentinel workspaces. The Defender portal keeps incident creation and alert correlation separate between the Microsoft Sentinel workspaces. For more information, see [Multiple Microsoft Sentinel workspaces in the Defender portal](/azure/sentinel/workspaces-defender-portal).
 
 ### 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.
+While Microsoft Defender already uses advanced correlation mechanisms, you might want to decide differently whether a given alert belongs with a particular incident. 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 more information on moving an alert from one incident to another, see [Move alerts from one incident to another in the Microsoft Defender portal](move-alert-to-another-incident.md).
 
 ## 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 alerts across incidents. When two or more incidents are determined to be sufficiently alike, Defender merges the incidents into a single incident.
+The Defender portal's correlation activities don't stop when incidents are created. Defender continues to detect commonalities and relationships between incidents and alerts across incidents. When multiple incidents are determined to be sufficiently alike, Defender merges the incidents into a single incident.
 
 ### Criteria for merging incidents
 
@@ -66,7 +66,7 @@ When two or more incidents are merged, a new incident is *not* created to absorb
 
 #### 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.
+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, even when merging incidents manually.
 
 #### Incident contents
 
@@ -77,20 +77,32 @@ The contents of the incidents are handled in the following ways:
 - A **`Redirected`** tag 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*.
+- Currently, comments and activity log entries in the source incident are *not* moved to the target incident.<br>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).
+- The source and target incidents have two different classifications (for example, true positive and false positive) or two different determinations (the subcategories of classifications).
 - 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](/defender-endpoint/machine-groups) as defined by the organization. <br>(This condition is not in effect by default; it must be enabled.)
 
+### Manual merging of incidents (Preview)
+
+If two incidents should be merged, but aren't merged for any of the reasons listed in the [previous section](#when-incidents-arent-merged), you can now merge the incidents manually after you fix the underlying reasons.
+
+For example, if the incidents weren't merged because they were assigned to two different people, you can remove the assignment of one of the incidents and then merge the incidents manually.
+
+Merging incidents together is preferable to unlinking alerts from one incident and linking them to another, because all the incident information (for example, the activity log) is preserved.
+
+Currently, five incidents at a time can be merged manually.
+
+Other rules governing manual merging are the same as automatic merging. See [Details of the merge process](#details-of-the-merge-process) above.
+
+For instructions and more information on how to merge incidents manually, see [Merge incidents manually in the Microsoft Defender portal](merge-incidents-manually.md).
+
 ## Next steps
 
 To learn more about prioritizing and managing incidents, see the following articles:

defender-xdr/media/merge-incidents-manually/merge-incident-from-incident-page.png

@@ -0,0 +1,86 @@
+---
+title: Merge incidents manually in the Microsoft Defender portal
+description: Learn how to merge two or more incidents into a single incident in the Microsoft Defender portal, to help you investigate incidents more efficiently and effectively and resolve them more quickly and accurately.
+ms.service: defender-xdr
+ms.author: yelevin
+author: yelevin
+ms.localizationpriority: medium
+manager: raynew
+audience: ITPro
+ms.collection: 
+- m365-security
+- tier2
+- usx-security
+- sentinel-only
+ms.topic: how-to
+ms.date: 04/09/2025
+search.appverid: met150
+appliesto:
+    - Microsoft Defender XDR
+    - Microsoft Sentinel in the Microsoft Defender portal
+---
+
+# Merge incidents manually in the Microsoft Defender portal (Preview)
+
+Incidents are automatically created in the Microsoft Defender portal when suspicious activities are detected. When two incidents describe parts of the same attack story, Defender usually merges those incidents into a single incident automatically to help you investigate incidents more efficiently and effectively and resolve them more quickly and accurately.
+
+Sometimes, however, the automatic merging doesn't happen, due to certain conditions that prevent it. To learn more about when incidents are or aren't merged, see [Incident correlation and merging](alerts-incidents-correlation.md#incident-correlation-and-merging). In these circumstances, or if you decide independently that two (unmerged) incidents are related and should be investigated as a single unit, you can merge them manually. This article explains how to do so.
+
+## Prerequisites
+
+- Users must have permissions to view the incidents queue.
+- Users must have read and write permissions on all the incidents they wish to merge. Incidents from different sources have different RBAC roles defined.
+- Incidents that are candidates for merging must have either the same values as each other, or null values, for the **Assigned to**, **Classification**, and **Determination** fields.
+
+## Merge incidents from the incident queue page
+
+1. Open the incident queue. Select **Investigation & response > Incidents & alerts > Incidents** from the quick launch menu in the Microsoft Defender portal.
+
+1. Select the two incidents you want to merge by marking the checkboxes at the beginning of their rows in the queue. When two incidents are marked, the **Merge incidents** button appears on the toolbar.
+
+    :::image type="content" source="media/merge-incidents-manually/merge-incidents-from-queue.png" alt-text="Screenshot of selecting incidents from queue to merge them." lightbox="media/merge-incidents-manually/merge-incidents-from-queue.png":::
+
+1. Select **Merge incidents** from the toolbar. The **Merge incidents** flyout opens.
+
+1. In the **Reason for merging** text box, type a description of the reason why you want to merge the incidents.
+
+1. Select **Merge incidents** at the bottom of the flyout to execute the merge.
+
+    :::image type="content" source="media/merge-incidents-manually/merge-incidents-panel-from-queue.png" alt-text="Screenshot of merging incidents from queue.":::
+
+1. In the confirmation dialog that appears, select **Merge**. When the merge is complete, a "Success" notification appears, with a link to follow to go to the merged (target) incident.
+
+    If the merge fails, a dialog box appears with a message that the incidents failed to merge. Verify that both incidents have the same values, or that at least one of the incidents has a null value, for **Assigned to**, **Classification**, and **Determination**.
+
+## Merge incidents from within the incident page
+
+1. Select the name of one of the two incidents you want to merge from the incident queue. This could be either the source or the target incident, as Microsoft Defender decides which is which. For more information, see [Details of the merge process](alerts-incidents-correlation.md#details-of-the-merge-process).
+
+1. The incident page appears. There, from the **Actions** menu (the three dots in the upper right corner), select **Merge incidents**.
+
+    :::image type="content" source="media/merge-incidents-manually/merge-incident-from-incident-page.png" alt-text="Screenshot of merging incidents from incident page." lightbox="media/merge-incidents-manually/merge-incident-from-incident-page.png":::
+
+1. The **Merge incidents** flyout appears. In the **Other incident name or ID** field, begin typing the name or ID of the incident you want to merge with the open one. The list of available incidents is dynamically displayed and filtered as you type. When you see the one you want in the list, select it.
+
+    :::image type="content" source="media/merge-incidents-manually/merge-incidents-panel-from-incident-page.png" border = "false" alt-text="Screenshot of incident merge panel from incident page.":::
+
+1. In the **Comment** text box, type a description of the reason why you want to merge the incidents.
+
+1. Select **Merge incidents** at the bottom of the flyout to execute the merge.
+
+1. In the confirmation dialog that appears, select **Merge**. When the merge is complete, a "Success" notification appears, the open incident is closed, and you are redirected to the merged (target) incident.
+
+    If the merge fails, a dialog box appears with a message that the incidents failed to merge. For the merge to succeed, both incidents must have the same values—or at least one incident must have a null value—for **Assigned to**, **Classification**, and **Determination**.
+
+## Notes
+
+- When the incidents are in the process of merging, you can't display or make any changes to either incident.
+
+- Incident merges are recorded in the target incident's activity log. The log messages show the names and IDs of the source incidents that were merged into the open (target) incident.
+
+- Activity log entries from the source incident are copied into the target incident's activity log. The entries appear with an indication that they were merged from the source incident. You can filter the activity log to show entries from either the source or target incidents, or from both.
+
+## See also
+
+- [Alert correlation and incident merging in the Microsoft Defender portal](alerts-incidents-correlation.md)
+- [Manage incidents in Microsoft Defender](manage-incidents.md)

defender-xdr/media/merge-incidents-manually/merge-incidents-from-queue.png

@@ -87,3 +87,4 @@ When an alert is correlated with an incident, a message is written to the incide
 ## See also
 
 - [Alert correlation and incident merging in the Microsoft Defender portal](alerts-incidents-correlation.md)
+- [Merge incidents manually in the Microsoft Defender portal](merge-incidents-manually.md)

defender-xdr/media/merge-incidents-manually/merge-incidents-panel-from-incident-page.png

@@ -68,6 +68,9 @@ For example, if the incidents weren't merged because they were assigned to two d
 
 To understand more about merging incidents, see [Alert correlation and incident merging in the Microsoft Defender portal](/defender-xdr/alerts-incidents-correlation).
 
+For instructions on merging incidents manually, see [Merge incidents manually in the Microsoft Defender portal](/defender-xdr/merge-incidents-manually).
+
+
 ### Multi workspace and multi tenant support for Microsoft Sentinel (Preview)
 
 Microsoft Sentinel now supports multiple workspaces in the Defender portal, using one primary workspace per tenant and multiple secondary workspaces.