Merge pull request #1897 from MicrosoftDocs/main

Published main to live, Thursday 10:30 AM PST, 11/14

Author: padmagit77

defender-office-365/campaigns.md

@@ -183,7 +183,7 @@ The available properties and their associated values are described in the follow
 |Internet Message ID|Text. Separate multiple values by commas. <br/><br/> Available in the **Message-ID** header field in the message header. An example value is `<[email protected]>` (note the angle brackets).|
 |Network Message ID|Text. Separate multiple values by commas. <br/><br/> A GUID value that's available in the **X-MS-Exchange-Organization-Network-Message-Id** header field in the message header.|
 |Sender IP|Text. Separate multiple values by commas.|
-|Attachment SHA256|Text. Separate multiple values by commas. <br/><br/> To find the SHA256 hash value of a file in Windows, run the following command in a Command Prompt: `certutil.exe -hashfile "<Path>\<Filename>" SHA256`.|
+|Attachment SHA256|Text. Separate multiple values by commas. <br/><br/> To find the SHA256 hash value of a file, run the following command in PowerShell: `Get-FileHash -Path "<Path>\<Filename>" -Algorithm SHA256`.|
 |Cluster ID|Text. Separate multiple values by commas.|
 |Alert ID|Text. Separate multiple values by commas.|
 |Alert Policy ID|Text. Separate multiple values by commas.|

defender-office-365/threat-explorer-real-time-detections-about.md

@@ -1224,7 +1224,7 @@ The filterable properties that are available in the **File name** box in the **C
 |Site|Text. Separate multiple values by commas.|✔|✔|
 |File owner|Text. Separate multiple values by commas.|✔|✔|
 |Last modified by|Text. Separate multiple values by commas.|✔|✔|
-|SHA256|Integer. Separate multiple values by commas. <br/><br/> To find the SHA256 hash value of a file in Windows, run the following command in a Command Prompt: `certutil.exe -hashfile "<Path>\<Filename>" SHA256`.|✔|✔|
+|SHA256|Integer. Separate multiple values by commas. <br/><br/> To find the SHA256 hash value of a file, run the following command in PowerShell: `Get-FileHash -Path "<Path>\<Filename>" -Algorithm SHA256`.|✔|✔|
 |Malware family|Text. Separate multiple values by commas.|✔|✔|
 |Detection technology|Select one or more values: <ul><li>**Advanced filter**</li><li>**Antimalware protection**</li><li>**Bulk**</li><li>**Campaign**</li><li>**Domain reputation**</li><li>**File detonation**</li><li>**File detonation reputation**</li><li>**File reputation**</li><li>**Fingerprint matching**</li><li>**General filter**</li><li>**Impersonation brand**</li><li>**Impersonation domain**</li><li>**Impersonation user**</li><li>**IP reputation**</li><li>**Mailbox intelligence impersonation**</li><li>**Mixed analysis detection**</li><li>**spoof DMARC**</li><li>**Spoof external domain**</li><li>**Spoof intra-org**</li><li>**URL detonation**</li><li>**URL detonation reputation**</li><li>**URL malicious reputation**</li></ul>|✔|✔|
 |Threat type|Select one or more values: <ul><li>**Block**</li><li>**Malware**</li><li>**Phish**</li><li>**Spam**</li></ul>|✔|✔|

defender-xdr/TOC.yml

@@ -133,13 +133,13 @@
     - name: Investigate and respond to threats
       items:
        - name: Overview
-         href: incident-response-overview.md
-       - name: Alerts, incidents, and correlation
+         href: incidents-overview.md
+       - name: Correlation and merging
          href: alerts-incidents-correlation.md
        - name: Respond to incidents
          items:
               - name: Overview
-                href: incidents-overview.md
+                href: incident-response-overview.md
               - name: Prioritize incidents
                 href: incident-queue.md
               - name: Manage incidents

defender-xdr/alerts-incidents-correlation.md

@@ -1,6 +1,6 @@
 ---
-title: Alerts, incidents, and correlation in Microsoft Defender XDR
-description: Learn how alerts and incidents are correlated in Microsoft Defender XDR.
+title: Alert correlation and incident merging in the Microsoft Defender portal
+description: Learn how alerts are correlated, and how and why incidents may be merged, in the Microsoft Defender portal.
 ms.service: defender-xdr
 f1.keywords: 
   - NOCSH
@@ -13,6 +13,7 @@ ms.collection:
   - m365-security
   - usx-security
   - tier1
+  - sentinel-only
 ms.topic: conceptual
 search.appverid: 
   - MOE150
@@ -23,92 +24,35 @@ appliesto:
 - Microsoft Sentinel in the Microsoft Defender portal
 ---
 
-# Alerts, incidents, and correlation in Microsoft Defender XDR
+# Alert correlation and incident merging in the Microsoft Defender portal
 
-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](incidents-overview.md).
-
-[!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 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-sentinel-onboard.md), 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**](investigate-alerts.md#alert-sources) table maps the alert sources to the alert ID prefix.
+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](incidents-overview.md).
 
 ## 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:
+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](incidents-overview.md), they're placed 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. |
+- 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 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.
+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.
 
 ## 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.
+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.
 
-### How does Defender XDR make that determination?
+### Criteria for merging incidents
 
-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:
+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.
 
-### When are incidents *not* merged?
+### Outcomes of the merge process
 
-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 of 50 entities per incident allowed.
-- 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.)
-
-### 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:
+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.
@@ -119,15 +63,26 @@ When two or more incidents are merged, a new incident is not created to absorb t
 
 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](/defender-endpoint/machine-groups) as defined by the organization. <br>(This condition is not in effect by default; it must be enabled.)
+
 ## 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.
+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.
 
 [!INCLUDE [Microsoft Defender XDR rebranding](../includes/defender-m3d-techcommunity.md)]
 
 ## Next steps
 
-Read more about incidents, investigation, and response: [Incident response in the Microsoft Defender portal](incidents-overview.md)
+To learn more about prioritizing and managing incidents, see the following articles:
+
+- [Manage incidents in Microsoft Defender](manage-incidents.md)
 
 ## See also
 

defender-xdr/incident-response-overview.md

@@ -37,7 +37,7 @@ On an ongoing basis, you need to identify the highest priority incidents for ana
 - [Prioritizing](incident-queue.md) to determining the highest priority incidents through filtering and sorting of the incident queue. This is also known as triaging.
 - [Managing](manage-incidents.md) incidents by modifying their title, assigning them to an analyst, adding tags and comments, and when resolved, classifying them.
 
-For each incident, use your incident response workflow to analyze the incident and its alerts and data to contain the attack, eradicate the threat, recover from the attack, and learn from it. See [this example](incidents-overview.md#example-incident-response-workflow-for-microsoft-365-defender) for Microsoft Defender XDR.
+For each incident, use your incident response workflow to analyze the incident and its alerts and data to contain the attack, eradicate the threat, recover from the attack, and learn from it.
 
 ## Automated investigation and remediation