find and replace for unified soc

batamig · batamig · commit 7d2da97d3bab · 2024-03-31T09:29:35.000+03:00
diff --git a/articles/sentinel/add-advanced-conditions-to-automation-rules.md b/articles/sentinel/add-advanced-conditions-to-automation-rules.md
@@ -54,13 +54,13 @@ Let's create a rule that will change the severity of an incoming incident from w
 
 1. Select the trigger **When incident is created**.
 
-1. Under **Conditions**, if you see the **Incident provider** and **Analytics rule name** conditions, leave them as they are. These conditions aren't available if your workspace is onboarded to the unified SOC platform. In either case, we'll add more conditions later in this process.
+1. Under **Conditions**, if you see the **Incident provider** and **Analytics rule name** conditions, leave them as they are. These conditions aren't available if your workspace is onboarded to the unified security operations platform. In either case, we'll add more conditions later in this process.
 
 1. Under **Actions**, select **Change severity** from the drop-down list.
 
 1. Select **High** from the drop-down list that appears below **Change severity**.
 
-For example, the following tabs show samples from a workspace that's onboarded to the unified SOC platform, in either the Azure or Defender portals, and a workspace that isn't:
+For example, the following tabs show samples from a workspace that's onboarded to the unified security operations platform, in either the Azure or Defender portals, and a workspace that isn't:
 
 ### [Onboarded workspaces](#tab/after-onboarding)
 
diff --git a/articles/sentinel/automate-incident-handling-with-automation-rules.md b/articles/sentinel/automate-incident-handling-with-automation-rules.md
@@ -105,9 +105,9 @@ The **current state** in this context refers to the moment the condition is eval
 
 The conditions evaluated in rules defined using the trigger **When an incident is updated** include all of those listed for the incident creation trigger. But the update trigger includes more properties that can be evaluated.
 
-One of these properties is **Updated by**. This property lets you track the type of source that made the change in the incident. You can create a condition evaluating whether the incident was updated by one of the following values, depending on whether you've onboarded your workspace to the unified SOC platform:
+One of these properties is **Updated by**. This property lets you track the type of source that made the change in the incident. You can create a condition evaluating whether the incident was updated by one of the following values, depending on whether you've onboarded your workspace to the unified security operations platform:
 
-##### [Onboarded to the unified SOC platform](#tab/onboarded)
+##### [Onboarded workspaces](#tab/onboarded)
 
 - An application, including applications in both the Azure and Defender portals.
 - A user, including changes made by users in both the Azure and Defender portals.
@@ -117,7 +117,7 @@ One of these properties is **Updated by**. This property lets you track the type
 - An automation rule
 - Other, if none of the above values apply
 
-##### [Not onboarded to the unified SOC platform](#tab/not-onboarded)
+##### [Workspaces not onboarded](#tab/not-onboarded)
 
 - An application
 - A Microsoft Sentinel user
@@ -144,7 +144,7 @@ Also, if an incident is updated by an automation rule that ran on the incident's
 If an incident triggers both create-trigger and update-trigger automation rules, the create-trigger rules will run first, according to their **[Order](#order)** numbers, and then the update-trigger rules will run, according to *their* **Order** numbers.
 
 > [!NOTE]
-> After onboarding to the unified SOC platform, if multiple changes are made to the same incident in a five to ten minute period, a single update is sent to Microsoft Sentinel, with only the most recent change.
+> After onboarding to the unified security operations platform, if multiple changes are made to the same incident in a five to ten minute period, a single update is sent to Microsoft Sentinel, with only the most recent change.
 
 #### Alert create trigger
 
@@ -304,7 +304,7 @@ In the specific case of a Managed Security Service Provider (MSSP), where a serv
 
 ## Creating and managing automation rules
 
-You can [create and manage automation rules](create-manage-use-automation-rules.md) from different areas in Microsoft Sentinel or the unified SOC platform, depending on your particular need and use case.
+You can [create and manage automation rules](create-manage-use-automation-rules.md) from different areas in Microsoft Sentinel or the unified security operations platform, depending on your particular need and use case.
 
 - **Automation page**
 
diff --git a/articles/sentinel/automate-responses-with-playbooks.md b/articles/sentinel/automate-responses-with-playbooks.md
@@ -32,7 +32,7 @@ For example, if an account and machine are compromised, a playbook can isolate t
 
 While the **Active playbooks** tab on the **Automation** page displays all the active playbooks available across any selected subscriptions, by default a playbook can be used only within the subscription to which it belongs, unless you specifically grant Microsoft Sentinel permissions to the playbook's resource group.
 
-After onboarding to the unified SOC platform, the **Active playbooks** tab shows a pre-defined filter with onboarded workspace's subscription. In the Azure portal, add data for other subscriptions using the Azure subscription filter.
+After onboarding to the unified security operations platform, the **Active playbooks** tab shows a pre-defined filter with onboarded workspace's subscription. In the Azure portal, add data for other subscriptions using the Azure subscription filter.
 
 ### Playbook templates
 
diff --git a/articles/sentinel/automation.md b/articles/sentinel/automation.md
@@ -42,19 +42,19 @@ Playbooks in Microsoft Sentinel are based on workflows built in [Azure Logic App
 
 Learn more with this [complete explanation of playbooks](automate-responses-with-playbooks.md).
 
-## After onboarding to the unified SOC platform
+## Automation with the unified security operations platform
 
-After onboarding your Microsoft Sentinel workspace to the unified SOC platform, note the following differences in the way automation functions in your workspace:
+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 SOC 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 SOC 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).       |
+|**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).       |
 |***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 SOC 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).       |
-|**Active playbooks tab**     | After onboarding to the unified SOC 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 SOC 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)    |
+|**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).       |
+|**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)    |
 
 
 ## Next steps
diff --git a/articles/sentinel/create-manage-use-automation-rules.md b/articles/sentinel/create-manage-use-automation-rules.md
@@ -92,11 +92,11 @@ Use the options in the **Conditions** area to define conditions for your automat
 
 - Rules you create for when an alert is created support only the **If Analytic rule name** property in your condition. Select whether you want the rule to be inclusive (*Contains*) or exclusive (*Does not contain*), and then select the analytic rule name from the drop-down list.
 
-- Rules you create for when an incident is created or updated support a large variety of conditions, depending on your environment. These options start with whether your workspace is onboarded to the unified SOC platform:
+- Rules you create for when an incident is created or updated support a large variety of conditions, depending on your environment. These options start with whether your workspace is onboarded to the unified security operations platform:
 
-    #### [Onboarded to the unified SOC platform](#tab/onboarded)
+    #### [Onboarded workspaces](#tab/onboarded)
 
-    If your workspace is onboarded to the unified SOC platform, start by selecting one of the following operators, in either the Azure or the Defender portal:
+    If your workspace is onboarded to the unified security operations platform, start by selecting one of the following operators, in either the Azure or the Defender portal:
 
     - **AND**: individual conditions that are evaluated as a group. The rule executes if *all* the conditions of this type are met.
 
@@ -106,11 +106,11 @@ Use the options in the **Conditions** area to define conditions for your automat
 
     For example:
 
-    :::image type="content" source="media/create-manage-use-automation-rules/conditions-onboarded.png" alt-text="Screenshot of automation rule conditions when your workspace is onboarded to the unified SOC platform.":::
+    :::image type="content" source="media/create-manage-use-automation-rules/conditions-onboarded.png" alt-text="Screenshot of automation rule conditions when your workspace is onboarded to the unified security operations platform.":::
 
-    #### [Not onboarded to the unified SOC platform](#tab/not-onboarded)
+    #### [Workspaces not onboarded](#tab/not-onboarded)
 
-    If your workspace isn't onboarded to the unified SOC platform, start by defining the following condition properties:
+    If your workspace isn't onboarded to the unified security operations platform, start by defining the following condition properties:
     
     - **Incident provider**: Incidents can have two possible sources: they can be created inside Microsoft Sentinel, and they can also be [imported from&mdash;and synchronized with&mdash;Microsoft Defender XDR](microsoft-365-defender-sentinel-integration.md).
 
@@ -128,7 +128,7 @@ Use the options in the **Conditions** area to define conditions for your automat
 
     For example:
 
-    :::image type="content" source="media/create-manage-use-automation-rules/conditions-not-onboarded.png" alt-text="Screenshot of automation rule conditions when the workspace isn't onboarded to the unified SOC platform.":::
+    :::image type="content" source="media/create-manage-use-automation-rules/conditions-not-onboarded.png" alt-text="Screenshot of automation rule conditions when the workspace isn't onboarded to the unified security operations platform.":::
 
     ---
 
diff --git a/articles/sentinel/detect-threats-custom.md b/articles/sentinel/detect-threats-custom.md
@@ -230,7 +230,7 @@ In the **Incident settings** tab, choose whether Microsoft Sentinel turns alerts
    - If you don’t want this rule to result in the creation of any incidents (for example, if this rule is just to collect information for subsequent analysis), set this to **Disabled**.
 
      > [!IMPORTANT]
-     > If you onboarded Microsoft Sentinel to the unified SOC platform in the Microsoft Defender portal, and this rule is querying and creating alerts from Microsoft 365 or Microsoft Defender sources, you must set this setting to **Disabled**.
+     > If you onboarded Microsoft Sentinel to the unified security operations platform in the Microsoft Defender portal, and this rule is querying and creating alerts from Microsoft 365 or Microsoft Defender sources, you must set this setting to **Disabled**.
 
    - If you want a single incident to be created from a group of alerts, instead of one for every single alert, see the next section.
 
diff --git a/articles/sentinel/microsoft-365-defender-sentinel-integration.md b/articles/sentinel/microsoft-365-defender-sentinel-integration.md
@@ -56,7 +56,7 @@ Once the Microsoft Defender XDR integration is connected, the connectors for all
 
 - To avoid creating duplicate incidents for the same alerts, we recommend that customers turn off all **Microsoft incident creation rules** for Microsoft Defender XDR-integrated products (Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, and Microsoft Entra ID Protection) when connecting Microsoft Defender XDR. This can be done by disabling incident creation in the connector page. Keep in mind that if you do this, any filters that were applied by the incident creation rules will not be applied to Microsoft Defender XDR incident integration.
 
-- If your workspace is onboarded to the [unified SOC platform](microsoft-sentinel-defender-portal.md), you *must* turn off all Microsoft incident creation rules, as they aren't supported. For more information, see [After onboarding to the unified SOC platform](automation.md#after-onboarding-to-the-unified-soc-platform).
+- If your workspace is onboarded to the [unified security operations platform](microsoft-sentinel-defender-portal.md), you *must* turn off all Microsoft incident creation rules, as they aren't supported. For more information, see [Automation with the unified security operations platform](automation.md#automation-with-the-unified-security-operations-platform)
 
 ## Working with Microsoft Defender XDR incidents in Microsoft Sentinel and bi-directional sync
 
diff --git a/articles/sentinel/microsoft-sentinel-defender-portal.md b/articles/sentinel/microsoft-sentinel-defender-portal.md
@@ -32,7 +32,7 @@ The following table describes the new or improved capabilities available in the
 
  Most Microsoft Sentinel capabilities are available in both the Azure and Defender portals. In the Defender portal, some Microsoft Sentinel experiences open out to the Azure portal for you to complete a task.
 
-This section covers the Microsoft Sentinel capabilities or integrations in the unified SOC platform that are only available in either the Azure portal or Defender portal. It excludes the Microsoft Sentinel experiences that open the Azure portal from the Defender portal.
+This section covers the Microsoft Sentinel capabilities or integrations in the unified security operations platform that are only available in either the Azure portal or Defender portal. It excludes the Microsoft Sentinel experiences that open the Azure portal from the Defender portal.
 
 ### Defender portal only
 
@@ -50,11 +50,11 @@ The following capabilities are only available in the Azure portal.
 |---------|---------|
 |Tasks   |     [Use tasks to manage incidents in Microsoft Sentinel](incident-tasks.md)    |
 |Add entities to threat intelligence from incidents | [Add entity to threat indicators](add-entity-to-threat-intelligence.md)   |
-| Automation | Some automation procedures are available only in the Azure portal. <br><br>Other automation procedures are the same in the Defender and Azure portals, but differ in the Azure portal between workspaces that are onboarded to the unified SOC platform and workspaces that aren't.  <br><br>For more information, see [Security Orchestration, Automation, and Response (SOAR) in Microsoft Sentinel](https://aka.ms/unified-soc-automation-lims). |
+| Automation | Some automation procedures are available only in the Azure portal. <br><br>Other automation procedures are the same in the Defender and Azure portals, but differ in the Azure portal between workspaces that are onboarded to the unified security operations platform and workspaces that aren't.  <br><br>For more information, see [Security Orchestration, Automation, and Response (SOAR) in Microsoft Sentinel](https://aka.ms/unified-soc-automation-lims). |
 
 ## Quick reference
 
-Some Microsoft Sentinel capabilities, like the unified incident queue, are integrated with Microsoft Defender XDR in the unified SOC platform. Many other Microsoft Sentinel capabilities are available in the **Microsoft Sentinel** section of the Defender portal.
+Some Microsoft Sentinel capabilities, like the unified incident queue, are integrated with Microsoft Defender XDR in the unified security operations platform. Many other Microsoft Sentinel capabilities are available in the **Microsoft Sentinel** section of the Defender portal.
 
 The following image shows the **Microsoft Sentinel** menu in the Defender portal:
 
diff --git a/articles/sentinel/tutorial-respond-threats-playbook.md b/articles/sentinel/tutorial-respond-threats-playbook.md
diff --git a/articles/sentinel/ueba-reference.md b/articles/sentinel/ueba-reference.md
