Merge pull request #590 from MicrosoftDocs/main

publish main to live 3:30 PM 5/30/24

Author: American-Dipper

defender-office-365/submissions-admin.md

@@ -39,7 +39,7 @@ In Microsoft 365 organizations with Exchange Online mailboxes, admins can use th
 
   After an admin submits the message from the **User reported** tab, an entry is also created on the corresponding tab on the **Submissions** page (for example, the **Emails** tab). These types of admin submissions are described in the [Admin options for user reported messages](#admin-options-for-user-reported-messages) section.
 
-When admins submit messages or sends user report to Microsoft for analysis, we do the following checks:
+When admins or users submit messages to Microsoft for analysis, we do the following checks:
 
 - **Email authentication check** (email messages only): Whether email authentication passed or failed when it was delivered.
 - **Policy hits**: Information about any policies or overrides that might have allowed or blocked the incoming email into the organization, thus overriding our filtering verdicts.
@@ -845,7 +845,7 @@ For email messages, admins can see what users are reporting on the **User report
 
 **Notes**:
 
-- User reported messages that are sent to Microsoft only or to Microsoft and the [reporting mailbox](submissions-user-reported-messages-custom-mailbox.md) appear on the **User reported** tab. Although these messages have already been reported to Microsoft, admins can resubmit the reported messages.
+- User reported messages that are sent to Microsoft only or to Microsoft and the [reporting mailbox](submissions-user-reported-messages-custom-mailbox.md) appear on the **User reported** tab.
 - User reported messages that are sent only to the reporting mailbox appear on the **User reported** tab with the **Result** value **Not Submitted to Microsoft**. Admins should report these messages to Microsoft for analysis.
 
 In organizations with Microsoft Defender for Office 365 Plan 2 (add-on licenses or included in subscriptions like Microsoft 365 E5), admins can also see [user reported messages in Microsoft Teams in Defender for Office 365 Plan 2](submissions-teams.md) (currently in Preview).

defender-office-365/submissions-users-report-message-add-in-configure.md

@@ -93,7 +93,7 @@ After the add-in is installed and enabled, users see the following icons based o
   - Outlook included with Microsoft 365 apps for Enterprise
   - Outlook for iOS and Android
 
-- Currently, reporting messages in shared mailboxes or other mailboxes by a delegate using the add-ins isn't supported. Messages aren't sent to the [reporting mailbox](submissions-user-reported-messages-custom-mailbox.md) or to Microsoft. Built-in reporting in Outlook on the web in shared mailboxes or other mailboxes by a delegate is supported. Messages are sent to the reporting mailbox or to Microsoft.
+- Currently, reporting messages in shared mailboxes or other mailboxes by a delegate using the add-ins isn't supported. Messages aren't sent to the [reporting mailbox](submissions-user-reported-messages-custom-mailbox.md) or to Microsoft. Built-in reporting in Outlook on the web or the new Outlook for Windows in shared mailboxes or other mailboxes by a delegate is supported. Messages are sent according to the reported message destination in user reported settings.
 
 - The add-ins aren't available for on-premises Exchange mailboxes.
 

defender-office-365/tenant-allow-block-list-email-spoof-configure.md

@@ -45,6 +45,10 @@ This article describes how admins can manage entries for email senders in the Mi
 
 - Entries for spoofed senders never expire.
 
+- For blocking inbound and outbound email from a domain, any subdomains in that domain, and any email addresses in that domain, create the block entry using the syntax: `*.TLD`, where `TLD` can be any top-level domain, interal domain, or email address domain.
+
+- For blocking inbound and outbound email from a sudomain in a domain and any email addresses in that subdomain, create the block entry using the syntax: `*.SD1.TLD`, `*.SD2.SD1.TLD`, `*.SD3.SD2.SD1.TLD`, etc. for internal domains and email address domains.
+
 - For details about the syntax for spoofed sender entries, see the [Domain pair syntax for spoofed sender entries](#domain-pair-syntax-for-spoofed-sender-entries) section later in this article.
 
 - An entry should be active within 5 minutes.

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)]