Defender for Cloud integration implications

Author: yelevin

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  |
+| 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. 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).       |
+| **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 after the incident is synchronized to run the playbook successfully. |
 
 
 ## Next steps

articles/sentinel/ingest-defender-for-cloud-incidents.md

@@ -4,12 +4,12 @@ description: Learn how using Microsoft Defender for Cloud's integration with Mic
 author: yelevin
 ms.author: yelevin
 ms.topic: conceptual
-ms.date: 11/28/2023
+ms.date: 04/16/2024
 ---
 
 # Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration
 
-Microsoft Defender for Cloud is now [integrated with Microsoft Defender XDR](../defender-for-cloud/release-notes.md#defender-for-cloud-is-now-integrated-with-microsoft-365-defender-preview), formerly known as Microsoft 365 Defender. This integration, currently **in Preview**, allows Defender XDR to collect alerts from Defender for Cloud and create Defender XDR incidents from them.
+Microsoft Defender for Cloud is now [integrated with Microsoft Defender XDR](/microsoft-365/security/defender/microsoft-365-security-center-defender-cloud), formerly known as Microsoft 365 Defender. This integration allows Defender XDR to collect alerts from Defender for Cloud and create Defender XDR incidents from them.
 
 Thanks to this integration, Microsoft Sentinel customers who enable [Defender XDR incident integration](microsoft-365-defender-sentinel-integration.md) can now ingest and synchronize Defender for Cloud incidents through Microsoft Defender XDR.
 
@@ -22,7 +22,9 @@ To support this integration, you must set up one of the following Microsoft Defe
 Both connectors mentioned above can be used to ingest Defender for Cloud alerts, regardless of whether you have Defender XDR incident integration enabled.
 
 > [!IMPORTANT]
-> The Defender for Cloud integration with Defender XDR, and the Tenant-based Microsoft Defender for Cloud connector, are currently in PREVIEW. The [Azure Preview Supplemental Terms](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.   
+> - The Defender for Cloud integration with Defender XDR [is now generally available (GA)](../defender-for-cloud/release-notes.md#general-availability-of-defender-for-clouds-integration-with-microsoft-defender-xdr).
+> 
+> - The **Tenant-based Microsoft Defender for Cloud connector** is currently in PREVIEW. The [Azure Preview Supplemental Terms](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.   
 
 ## Choose how to use this integration and the new connector
 

articles/sentinel/microsoft-365-defender-sentinel-integration.md

@@ -17,7 +17,7 @@ This integration gives Microsoft 365 security incidents the visibility to be man
 - **Microsoft Defender for Identity**
 - **Microsoft Defender for Office 365**
 - **Microsoft Defender for Cloud Apps**
-- **Microsoft Defender for Cloud** (Preview)
+- **Microsoft Defender for Cloud**
 
 Other services whose alerts are collected by Microsoft Defender XDR include:
 
@@ -28,6 +28,8 @@ In addition to collecting alerts from these components and other services, Micro
 
 ## Common use cases and scenarios
 
+- Onboarding of Microsoft Sentinel to the unified security operations platform in the Microsoft Defender portal, of which enabling the Microsoft Defender XDR integration is a required early step.
+
 - One-click connect of Microsoft Defender XDR incidents, including all alerts and entities from Microsoft Defender XDR components, into Microsoft Sentinel.
 
 - Bi-directional sync between Sentinel and Microsoft Defender XDR incidents on status, owner, and closing reason.
@@ -44,9 +46,11 @@ Install the Microsoft Defender XDR solution for Microsoft Sentinel and enable th
 
 - It can take up to 10 minutes from the time an incident is generated in Microsoft Defender XDR to the time it appears in Microsoft Sentinel.
 
-- Alerts and incidents from Microsoft Defender XDR (those items which populate the *SecurityAlert* and *SecurityIncident* tables) are ingested into and synchronized with Microsoft Sentinel at no charge. For all other data types from individual Defender components (such as DeviceInfo, DeviceFileEvents, EmailEvents, and so on), ingestion will be charged.
+- Alerts and incidents from Microsoft Defender XDR (those items which populate the *SecurityAlert* and *SecurityIncident* tables) are ingested into and synchronized with Microsoft Sentinel at no charge. For all other data types from individual Defender components (such as the *Advanced hunting* tables *DeviceInfo*, *DeviceFileEvents*, *EmailEvents*, and so on), ingestion will be charged.
+
+- When the Microsoft Defender XDR connector is enabled, alerts created by its component services (Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, Microsoft Entra ID Protection) will be sent to Microsoft Defender XDR and grouped into incidents. Both the alerts and the incidents will flow to Microsoft Sentinel through the Microsoft Defender XDR connector. If you had enabled any of the individual component connectors beforehand, they will appear to remain connected, though no data will be flowing through them.
 
-- When the Microsoft Defender XDR connector is enabled, alerts created by its component services (Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, Microsoft Entra ID Protection) will be sent to Microsoft Defender XDR and grouped into incidents. Both the alerts and the incidents will flow to Microsoft Sentinel through the Microsoft Defender XDR connector with no additional configuration. The connectors for its individual component services will appear to remain connected, though no alerts will flow through them, to avoid duplication of alerts.
+    The exception to this process is Microsoft Defender for Cloud. Although its [integration with Microsoft Defender XDR](/microsoft-365/security/defender/microsoft-365-security-center-defender-cloud) means that you receive Defender for Cloud *incidents* through Defender XDR, you need to also have a Microsoft Defender for Cloud connector enabled in order to receive Defender for Cloud *alerts*. For the available options and more information, see [Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration](ingest-defender-for-cloud-incidents.md).
 
 - Similarly, to avoid creating *duplicate incidents for the same alerts*, **Microsoft incident creation rules** will be turned off 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 is because Defender XDR has its own incident creation rules. This change has the following potential impacts: