Merge pull request #271448 from yelevin/yelevin/usx-cxe-open-issues

Addressing USX open isssues from CXE

Author: v-dirichards

articles/sentinel/automate-incident-handling-with-automation-rules.md

@@ -85,11 +85,9 @@ Even without being onboarded to the unified portal, you might anyway decide to u
 - A playbook can be triggered by an alert and send the alert to an external ticketing system for incident creation and management, creating a new ticket for each alert.
 
 > [!NOTE]
-> - Alert-triggered automation is available only for alerts created by [**Scheduled** and **NRT** analytics rules](detect-threats-built-in.md). Alerts created by **Microsoft Security** analytics rules are not supported.
+> - Alert-triggered automation is available only for alerts created by [**Scheduled**, **NRT**, and **Microsoft security** analytics rules](detect-threats-built-in.md).
 >
-> - Similarly, alert-triggered automation for alerts created by Microsoft Defender XDR is not available in the unified security operations platform in the Microsoft Defender portal.
->
-> - For more information, see [Automation with the unified security operations platform](automation.md#automation-with-the-unified-security-operations-platform).
+> - Alert-triggered automation for alerts created by Microsoft Defender XDR is not available in the unified security operations platform. For more information, see [Automation with the unified security operations platform](automation.md#automation-with-the-unified-security-operations-platform).
 
 ### Conditions
 

articles/sentinel/automation.md

@@ -46,18 +46,18 @@ Learn more with this [complete explanation of playbooks](automate-responses-with
 
 After onboarding your Microsoft Sentinel workspace to the unified security operations platform, note the following differences in the way automation functions in your workspace:
 
-|Functionality   |Description  |
-|---------|---------|
-|**Automation rules with alert triggers**     |  In the unified security operations platform, automation rules with alert triggers act only on Microsoft Sentinel alerts. <br><br>For more information, see [Alert create trigger](automate-incident-handling-with-automation-rules.md#alert-create-trigger).       |
-|**Automation rules with incident triggers**     |  In both the Azure portal and the unified security operations platform, the **Incident provider** condition property is removed, as all incidents have *Microsoft Defender XDR* as the incident provider. <br><br>At that point, any existing automation rules run on both Microsoft Sentinel and Microsoft Defender XDR incidents, including those where the **Incident provider** condition is set to only *Microsoft Sentinel* or *Microsoft 365 Defender*. <br><br>However, automation rules that specify a specific analytics rule name will run only on the incidents that were created by the specified analytics rule. This means that you can define the **Analytic rule name** condition property to an analytics rule that exists only in Microsoft Sentinel to limit your rule to run on incidents only in Microsoft Sentinel. <br><br>For more information, see [Incident trigger conditions](automate-incident-handling-with-automation-rules.md#conditions).       |
-| **Changes to existing incident names** | In the unified SOC operations platform, the Defender portal uses a unique engine to correlate incidents and alerts. When onboarding your workspace to the unified SOC operations platform, existing incident names might be changed if the correlation is applied. We therefore recommend that you avoid using incident titles in your automation rules to ensure that your rules always run correctly. |
-|***Updated by* field**     |   - After onboarding your workspace, the **Updated by** field has a [new set of supported values](automate-incident-handling-with-automation-rules.md#incident-update-trigger), which no longer include *Microsoft 365 Defender*. In existing automation rules, *Microsoft 365 Defender* is replaced by a value of *Other* after onboarding your workspace. <br><br>- If multiple changes are made to the same incident in a 5-10 minute period, a single update is sent to Microsoft Sentinel, with only the most recent change. <br><br>For more information, see [Incident update trigger](automate-incident-handling-with-automation-rules.md#incident-update-trigger).      |
-|**Automation rules that add incident tasks**     | If an automation rule add an incident task, the task is shown only in the Azure portal.        |
-|**Microsoft incident creation rules**     |  Microsoft incident creation rules aren't supported in the unified security operations platform. <br><br>For more information, see [Microsoft Defender XDR incidents and Microsoft incident creation rules](microsoft-365-defender-sentinel-integration.md#microsoft-defender-xdr-incidents-and-microsoft-incident-creation-rules).       |
+| Functionality | Description  |
+| --------- | --------- |
+| **Automation rules with alert triggers** | In the unified security operations platform, automation rules with alert triggers act only on Microsoft Sentinel alerts. <br><br>For more information, see [Alert create trigger](automate-incident-handling-with-automation-rules.md#alert-create-trigger). |
+| **Automation rules with incident triggers** | In both the Azure portal and the unified security operations platform, the **Incident provider** condition property is removed, as all incidents have *Microsoft Defender XDR* as the incident provider (the value in the *ProviderName* field). <br><br>At that point, any existing automation rules run on both Microsoft Sentinel and Microsoft Defender XDR incidents, including those where the **Incident provider** condition is set to only *Microsoft Sentinel* or *Microsoft 365 Defender*. <br><br>However, automation rules that specify a specific analytics rule name will run only on the incidents that were created by the specified analytics rule. This means that you can define the **Analytic rule name** condition property to an analytics rule that exists only in Microsoft Sentinel to limit your rule to run on incidents only in Microsoft Sentinel. <br><br>For more information, see [Incident trigger conditions](automate-incident-handling-with-automation-rules.md#conditions). |
+| **Changes to existing incident names** | In the unified SOC operations platform, the Defender portal uses a unique engine to correlate incidents and alerts. When onboarding your workspace to the unified SOC operations platform, existing incident names might be changed if the correlation is applied. To ensure that your automation rules always run correctly, we therefore recommend that you avoid using incident titles in your automation rules, and suggest the use of tags instead. |
+| ***Updated by* field** | <li>After onboarding your workspace, the **Updated by** field has a [new set of supported values](automate-incident-handling-with-automation-rules.md#incident-update-trigger), which no longer include *Microsoft 365 Defender*. In existing automation rules, *Microsoft 365 Defender* is replaced by a value of *Other* after onboarding your workspace. <br><br><li>If multiple changes are made to the same incident in a 5-10 minute period, a single update is sent to Microsoft Sentinel, with only the most recent change. <br><br>For more information, see [Incident update trigger](automate-incident-handling-with-automation-rules.md#incident-update-trigger). |
+| **Automation rules that add incident tasks** | If an automation rule add an incident task, the task is shown only in the Azure portal. |
+| **Microsoft incident creation rules** | Microsoft incident creation rules aren't supported in the unified security operations platform. <br><br>For more information, see [Microsoft Defender XDR incidents and Microsoft incident creation rules](microsoft-365-defender-sentinel-integration.md#microsoft-defender-xdr-incidents-and-microsoft-incident-creation-rules). |
 | **Running automation rules from the Defender portal** | It might take up to 10 minutes from the time that an alert is triggered and an incident is created or updated in the Defender portal to when an automation rule is run. This time lag is because the incident is created in the Defender portal and then forwarded to Microsoft Sentinel for the automation rule. |
-|**Active playbooks tab**     | After onboarding to the unified security operations platform, by default the **Active playbooks** tab shows a pre-defined filter with onboarded workspace's subscription. Add data for other subscriptions using the subscription filter.  <br><br>For more information, see [Create and customize Microsoft Sentinel playbooks from content templates](use-playbook-templates.md).        |
-|**Running playbooks manually on demand**     |The following procedures are not supported in the unified security operations platform:  <br><br>- [Run a playbook manually on an alert](tutorial-respond-threats-playbook.md?tabs=LAC%2Cincidents#run-a-playbook-manually-on-an-alert) <br>- [Run a playbook manually on an entity](tutorial-respond-threats-playbook.md?tabs=LAC%2Cincidents#run-a-playbook-manually-on-an-entity-preview)    |
-| **Running playbooks on incidents requires Microsoft Sentinel sync** | If you try to run a playbook on an incident from the unified security operations platform and see the *Can't access data related to this action. Refresh the screen in a few minutes.* message, this means that the incident is not yet synchronized to Microsoft Sentinel. <br><br>Refresh the incident page after after the incident is synchronized to run the playbook successfully. |
+| **Active playbooks tab** | After onboarding to the unified security operations platform, by default the **Active playbooks** tab shows a pre-defined filter with onboarded workspace's subscription. Add data for other subscriptions using the subscription filter.  <br><br>For more information, see [Create and customize Microsoft Sentinel playbooks from content templates](use-playbook-templates.md). |
+| **Running playbooks manually on demand** | The following procedures are not currently supported in the unified security operations platform:  <br><li>[Run a playbook manually on an alert](tutorial-respond-threats-playbook.md?tabs=LAC%2Cincidents#run-a-playbook-manually-on-an-alert) <br><li>[Run a playbook manually on an entity](tutorial-respond-threats-playbook.md?tabs=LAC%2Cincidents#run-a-playbook-manually-on-an-entity-preview)    |
+| **Running playbooks on incidents requires Microsoft Sentinel sync** | If you try to run a playbook on an incident from the unified security operations platform and see the message *"Can't access data related to this action. Refresh the screen in a few minutes."* message, this means that the incident is not yet synchronized to Microsoft Sentinel. <br><br>Refresh the incident page after the incident is synchronized to run the playbook successfully. |
 
 
 ## Next steps

articles/sentinel/create-incident-manually.md

@@ -14,16 +14,18 @@ ms.date: 08/17/2022
 > Manual incident creation, using the portal or Logic Apps, is currently in **PREVIEW**. See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
 >
 > Manual incident creation is generally available using the API.
+>
+> [!INCLUDE [unified-soc-preview-without-alert](includes/unified-soc-preview-without-alert.md)]
 
-With Microsoft Sentinel as your SIEM, your SOC’s threat detection and response activities are centered on **incidents** that you investigate and remediate. These incidents have two main sources: 
+With Microsoft Sentinel as your security information and event management (SIEM) solution, your security operations' threat detection and response activities are centered on **incidents** that you investigate and remediate. These incidents have two main sources: 
 
-- They are generated automatically by detection mechanisms that operate on the logs and alerts that Sentinel ingests from its connected data sources.
+- They're generated automatically when detection mechanisms operate on the logs and alerts that Microsoft Sentinel ingests from its connected data sources.
 
-- They are ingested directly from other connected Microsoft security services (such as [Microsoft Defender XDR](microsoft-365-defender-sentinel-integration.md)) that created them.
+- They're ingested directly from other connected Microsoft security services (such as [Microsoft Defender XDR](microsoft-365-defender-sentinel-integration.md)) that created them.
 
-There can, however, be data from other sources *not ingested into Microsoft Sentinel*, or events not recorded in any log, that justify opening an investigation. For example, an employee might witness an unrecognized person engaging in suspicious activity related to your organization’s information assets, and this employee might call or email the SOC to report the activity.
+However, threat data can also come from other sources *not ingested into Microsoft Sentinel*, or events not recorded in any log, and yet can justify opening an investigation. For example, an employee might notice an unrecognized person engaging in suspicious activity related to your organization’s information assets. This employee might call or email the security operations center (SOC) to report the activity.
 
-For this reason, Microsoft Sentinel allows your security analysts to manually create incidents for any type of event, regardless of its source or associated data, for the purpose of managing and documenting these investigations.
+Microsoft Sentinel allows your security analysts to manually create incidents for any type of event, regardless of its source or data, so you don't miss out on investigating these unusual types of threats.
 
 ## Common use cases
 
@@ -33,11 +35,11 @@ This is the scenario described in the introduction above.
 
 ### Create incidents out of events from external systems
 
-Create incidents based on events from systems whose logs are not ingested into Microsoft Sentinel. For example, an SMS-based phishing campaign might use your organization's corporate branding and themes to target employees' personal mobile devices. You may want to investigate such an attack, and creating an incident in Microsoft Sentinel gives you a platform to collect and log evidence and record your response and mitigating actions.
+Create incidents based on events from systems whose logs are not ingested into Microsoft Sentinel. For example, an SMS-based phishing campaign might use your organization's corporate branding and themes to target employees' personal mobile devices. You may want to investigate such an attack, and you can create an incident in Microsoft Sentinel so that you have a platform to manage your investigation, to collect and log evidence, and to record your response and mitigation actions.
 
 ### Create incidents based on hunting results
 
-Create incidents based on the observed results of hunting activities. For example, in the course of your threat hunting activities in relation to a particular investigation (or independently), you might come across evidence of a completely unrelated threat that warrants its own separate investigation.
+Create incidents based on the observed results of hunting activities. For example, while threat hunting in the context of a particular investigation (or on your own), you might come across evidence of a completely unrelated threat that warrants its own separate investigation.
 
 ## Manually create an incident
 
@@ -47,6 +49,8 @@ There are three ways to create an incident manually:
 - [Create an incident using Azure Logic Apps](#create-an-incident-using-azure-logic-apps), using the Microsoft Sentinel Incident trigger.
 - [Create an incident using the Microsoft Sentinel API](#create-an-incident-using-the-microsoft-sentinel-api), through the [Incidents](/rest/api/securityinsights/preview/incidents) operation group. It allows you to get, create, update, and delete incidents.
 
+After onboarding Microsoft Sentinel to the unified security operations platform in the Microsoft Defender portal, manually created incidents will not be synchronized with the unified platform, though they can still be viewed and managed in Microsoft Sentinel in the Azure portal, and through Logic Apps and  the API.
+
 ### Create an incident using the Azure portal
 
 1. Select **Microsoft Sentinel** and choose your workspace.

articles/sentinel/fusion.md

@@ -11,6 +11,8 @@ ms.author: yelevin
 
 > [!IMPORTANT]
 > Some Fusion detections (see those so indicated below) are currently in **PREVIEW**. See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
+>
+> [!INCLUDE [unified-soc-preview-without-alert](includes/unified-soc-preview-without-alert.md)]
 
 [!INCLUDE [reference-to-feature-availability](includes/reference-to-feature-availability.md)]
 
@@ -27,6 +29,8 @@ Fusion is enabled by default in Microsoft Sentinel, as an [analytics rule](detec
 > [!NOTE]
 > Microsoft Sentinel currently uses 30 days of historical data to train the Fusion engine's machine learning algorithms. This data is always encrypted using Microsoft’s keys as it passes through the machine learning pipeline. However, the training data is not encrypted using [Customer-Managed Keys (CMK)](customer-managed-keys.md) if you enabled CMK in your Microsoft Sentinel workspace. To opt out of Fusion, navigate to **Microsoft Sentinel** \> **Configuration** \> **Analytics \> Active rules**, right-click on the **Advanced Multistage Attack Detection** rule, and select **Disable.**
 
+In Microsoft Sentinel workspaces that are onboarded to the [unified security operations platform in the Microsoft Defender portal](https://aka.ms/unified-soc-announcement), Fusion is disabled, as its functionality is replaced by the Microsoft Defender XDR correlation engine.
+
 ## Fusion for emerging threats
 
 > [!IMPORTANT]