Merge pull request #299308 from batamig/transition-guide-ii

Transition guide take 2 in Sentinel docs

Author: denrea

articles/sentinel/TOC.yml

@@ -53,6 +53,8 @@
     href: enable-sentinel-features-content.md
   - name: Onboard to Microsoft Sentinel
     href: quickstart-onboard.md
+  - name: Connect Microsoft Sentinel to the Defender portal
+    href: /unified-secops-platform/microsoft-sentinel-onboard?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json
   - name: Configure content
     href: configure-content.md
   - name: Set up multiple workspaces
@@ -63,52 +65,56 @@
     href: configure-data-retention-archive.md
   - name: Deploy side-by-side
     href: deploy-side-by-side.md
-- name: Migrate to Microsoft Sentinel
+- name: Migrate
   items:
-  - name: Plan and design your migration
+  - name: Transition your environment to the Defender portal
+    href: move-to-defender.md
+  - name: Migrate to Microsoft Sentinel
     items:
-    - name: Plan your migration
-      href: migration.md
-    - name: Use the SIEM migration experience
-      href: siem-migration.md
-    - name: Track migration with a workbook
-      href: migration-track.md                
-  - name: Migrate from ArcSight      
-    items: 
-    - name: Migrate detection rules
-      href: migration-arcsight-detection-rules.md
-    - name: Migrate SOAR automation
-      href: migration-arcsight-automation.md
-    - name: Export historical data
-      href: migration-arcsight-historical-data.md           
-  - name: Migrate from Splunk
-    items:
-    - name: Migrate detection rules
-      href: migration-splunk-detection-rules.md
-    - name: Migrate SOAR automation
-      href: migration-splunk-automation.md
-    - name: Export historical data
-      href: migration-splunk-historical-data.md
-  - name: Migrate from QRadar      
-    items:
-    - name: Migrate detection rules
-      href: migration-qradar-detection-rules.md
-    - name: Migrate SOAR automation
-      href: migration-qradar-automation.md
-    - name: Export historical data
-      href: migration-qradar-historical-data.md
-  - name: Ingest historical data
-    items:      
-    - name: Select target platform
-      href: migration-ingestion-target-platform.md
-    - name: Select data ingestion tool
-      href: migration-ingestion-tool.md
-    - name: Ingest data
-      href: migration-export-ingest.md
-  - name: Convert dashboards to workbooks
-    href: migration-convert-dashboards.md
-  - name: Update SOC processes      
-    href: migration-security-operations-center-processes.md
+    - name: Plan and design your migration
+      items:
+      - name: Plan your migration
+        href: migration.md
+      - name: Use the SIEM migration experience
+        href: siem-migration.md
+      - name: Track migration with a workbook
+        href: migration-track.md                
+    - name: Migrate from ArcSight      
+      items: 
+      - name: Migrate detection rules
+        href: migration-arcsight-detection-rules.md
+      - name: Migrate SOAR automation
+        href: migration-arcsight-automation.md
+      - name: Export historical data
+        href: migration-arcsight-historical-data.md           
+    - name: Migrate from Splunk
+      items:
+      - name: Migrate detection rules
+        href: migration-splunk-detection-rules.md
+      - name: Migrate SOAR automation
+        href: migration-splunk-automation.md
+      - name: Export historical data
+        href: migration-splunk-historical-data.md
+    - name: Migrate from QRadar      
+      items:
+      - name: Migrate detection rules
+        href: migration-qradar-detection-rules.md
+      - name: Migrate SOAR automation
+        href: migration-qradar-automation.md
+      - name: Export historical data
+        href: migration-qradar-historical-data.md
+    - name: Ingest historical data
+      items:      
+      - name: Select target platform
+        href: migration-ingestion-target-platform.md
+      - name: Select data ingestion tool
+        href: migration-ingestion-tool.md
+      - name: Ingest data
+        href: migration-export-ingest.md
+    - name: Convert dashboards to workbooks
+      href: migration-convert-dashboards.md
+    - name: Update SOC processes      
+      href: migration-security-operations-center-processes.md
 - name: Manage solutions and content
   items:  
   - name: Overview
@@ -1099,8 +1105,6 @@
       href: /azure/azure-monitor/logs/data-retention-configure?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json
     - name: Auxiliary logs use cases
       href: basic-logs-use-cases.md
-  - name: Connect Microsoft Sentinel to Microsoft Defender XDR
-    href: /defender-xdr/microsoft-sentinel-onboard?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json
   - name: Manage multiple workspaces 
     items:
     - name: Workspaces in the Defender portal 

articles/sentinel/automation/automation.md

@@ -53,23 +53,7 @@ For more information, see [Automate threat response with playbooks in Microsoft
 
 After onboarding your Microsoft Sentinel workspace to the Defender portal, note the following differences in the way automation functions in your workspace:
 
-| Functionality | Description  |
-| --------- | --------- |
-| **Automation rules with alert triggers** | In the Defender portal, 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 Defender portal, the **Incident provider** condition property is removed, as all incidents have *Microsoft 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 run only on incidents that contain alerts 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). |
-|**Latency in playbook triggers** | [It might take up to 5 minutes](../microsoft-sentinel-defender-portal.md#5min) for Microsoft Defender incidents to appear in Microsoft Sentinel. If this delay is present, playbook triggering is delayed too. |
-| **Changes to existing incident names** | The Defender portal uses a unique engine to correlate incidents and alerts. When onboarding your workspace to the Defender portal, 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 as condition criteria in your automation rules, and suggest instead to use the name of any analytics rule that created alerts included in the incident, and tags if more specificity is required. |
-| ***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 adds an incident task, the task is shown only in the Azure portal. |
-| **Creating automation rules directly from an incident** | [Creating automation rules directly from an incident](../false-positives.md#add-exceptions-with-automation-rules-azure-portal-only) is supported only in the Azure portal. If you're working in the Defender portal, create your automation rules from scratch from the **Automation** page. |
-| **Microsoft incident creation rules** | Microsoft incident creation rules aren't supported in the Defender portal. <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 Defender portal, by default the **Active playbooks** tab shows a predefined filter with onboarded workspace's subscription. In the Azure portal, 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 aren't currently supported in the Defender portal:  <br><li>[Run a playbook manually on an alert](run-playbooks.md#run-a-playbook-manually-on-an-alert)<br><li>[Run a playbook manually on an entity](run-playbooks.md#run-a-playbook-manually-on-an-entity)    |
-| **Running playbooks on incidents requires Microsoft Sentinel sync** | If you try to run a playbook on an incident from the Defender portal 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 isn't yet synchronized to Microsoft Sentinel. <br><br>Refresh the incident page after the incident is synchronized to run the playbook successfully. |
-| **Incidents: Adding alerts to incidents / <br>Removing alerts from incidents** | Since adding alerts to, or removing alerts from incidents isn't supported after onboarding your workspace to the Defender portal, these actions are also not supported from within playbooks. For more information, see [Capability differences between portals](../microsoft-sentinel-defender-portal.md#capability-differences-between-portals). |
-|**Microsoft Defender XDR integration in multiple workspaces**|If you've integrated XDR data with more than one workspace in a single tenant, the data will now only be ingested into the primary workspace in the Defender portal. Transfer automation rules to the relevant workspace to keep them running.|
-|**Automation and the Correlation engine** |The correlation engine may combine alerts from multiple signals into a single incident, which could result in automation receiving data you didn’t anticipate. We recommend reviewing your automation rules to ensure you're seeing the expected results.|
+[!INCLUDE [automation-in-defender](../includes/automation-in-defender.md)]
 
 ## Related content
 

articles/sentinel/create-analytics-rules.md

@@ -179,7 +179,7 @@ In the **Incident settings** tab, choose whether Microsoft Sentinel turns alerts
      >
      > - In this scenario, incidents are created by Microsoft Defender XDR, not by Microsoft Sentinel.
      > - These incidents appear in the incidents queue in both the Azure and Defender portals.
-     > - In the Azure portal, new incidents are displayed with "Microsoft Defender XDR" as the **incident provider name**.
+     > - In the Azure portal, new incidents are displayed with "Microsoft XDR" as the **incident provider name**.
 
    - If you want a single incident to be created from a group of alerts, instead of one for every single alert, see the next step.
 

articles/sentinel/create-manage-use-automation-rules.md

@@ -118,7 +118,7 @@ Use the options in the **Conditions** area to define conditions for your automat
 
         If you selected one of the incident triggers and you want the automation rule to take effect only on incidents created in Microsoft Sentinel, or alternatively, only on those imported from Microsoft Defender XDR, specify the source in the **If Incident provider equals** condition. (This condition is displayed only if an incident trigger is selected.)
 
-    - **Analytic rule name**: For all trigger types, if you want the automation rule to take effect only on certain analytics rules, specify which ones by modifying the **If Analytics rule name contains** condition. (This condition isn't displayed if Microsoft Defender XDR is selected as the incident provider.)
+    - **Analytic rule name**: For all trigger types, if you want the automation rule to take effect only on certain analytics rules, specify which ones by modifying the **If Analytics rule name contains** condition. (This condition isn't displayed if Microsoft  XDR is selected as the incident provider.)
 
     Then, continue by selecting one of the following operators:
 

articles/sentinel/deploy-overview.md

@@ -25,7 +25,7 @@ The plan and prepare phase is typically performed by a SOC architect or related
 | Step | Details |
 | --------- | ------- |
 | **1. Plan and prepare overview and prerequisites** | Review the [Azure tenant prerequisites](prerequisites.md). |
-| **2. Plan workspace architecture** | Design your Log Analytics workspace enabled for Microsoft Sentinel. Consider parameters such as:<br><br>- Whether you'll use a single tenant or multiple tenants<br>- Any compliance requirements you have for data collection and storage<br>- How to control access to Microsoft Sentinel data<br><br>Review these articles:<br><br>1. [Design workspace architecture](/azure/azure-monitor/logs/workspace-design?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json)<br>3. [Review sample workspace designs](sample-workspace-designs.md)<br>4. [Prepare for multiple workspaces](prepare-multiple-workspaces.md) |
+| **2. Plan workspace architecture** | Design your Log Analytics workspace enabled for Microsoft Sentinel. Regardless of whether you'll be onboarding to the Microsoft Defender portal, you'll still need a Log Analytics workspace. <br><br>Consider parameters such as:<br>- Whether you'll use a single tenant or multiple tenants<br>- Any compliance requirements you have for data collection and storage<br>- How to control access to Microsoft Sentinel data<br><br>Review these articles:<br><br>1. [Design workspace architecture](/azure/azure-monitor/logs/workspace-design?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json)<br>3. [Review sample workspace designs](sample-workspace-designs.md)<br>4. [Prepare for multiple workspaces](prepare-multiple-workspaces.md) |
 | **3. [Prioritize data connectors](prioritize-data-connectors.md)** | Determine which data sources you need and the data size requirements to help you accurately project your deployment's budget and timeline.<br><br>You might determine this information during your business use case review, or by evaluating a current SIEM that you already have in place. If you already have a SIEM in place, analyze your data to understand which data sources provide the most value and should be ingested into Microsoft Sentinel. |
 | **4. [Plan roles and permissions](roles.md)** |Use Azure role based access control (RBAC) to create and assign roles within your security operations team to grant appropriate access to Microsoft Sentinel. The different roles give you fine-grained control over what Microsoft Sentinel users can see and do. Azure roles can be assigned in the workspace directly, or in a subscription or resource group that the workspace belongs to, which Microsoft Sentinel inherits. |
 | **5. [Plan costs](billing.md)** |Start planning your budget, considering cost implications for each planned scenario.<br><br>   Make sure that your budget covers the cost of data ingestion for both Microsoft Sentinel and Azure Log Analytics, any playbooks that will be deployed, and so on. |