Merge pull request #299307 from EdB-MSFT/fix-provider-name

API updates

Author: prmerger-automator[bot]

articles/sentinel/automation/automation.md

@@ -56,7 +56,7 @@ After onboarding your Microsoft Sentinel workspace to the Defender portal, note
 | 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 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 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). |
+| **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). |

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

@@ -66,7 +66,7 @@ To ingest and synchronize Microsoft Defender XDR incidents with all their alerts
 
    ```kusto
       SecurityIncident
-      | where ProviderName == "Microsoft Defender XDR"
+      | where ProviderName == "Microsoft XDR"
    ```
 
 When you enable the Microsoft Defender XDR connector, any Microsoft Defender components’ connectors that were previously connected are automatically disconnected in the background. Although they continue to *appear* connected, no data flows through them.
@@ -153,7 +153,7 @@ let Now = now();
 | extend Count = 0 
 | union isfuzzy=true ( 
     SecurityIncident
-    | where ProviderName == "Microsoft Defender XDR"
+    | where ProviderName == "Microsoft XDR"
     | summarize Count = count() by bin_at(TimeGenerated, 1d, Now) 
 ) 
 | summarize Count=max(Count) by bin_at(TimeGenerated, 1d, Now) 

articles/sentinel/microsoft-sentinel-defender-portal.md

@@ -57,7 +57,7 @@ This section covers the Microsoft Sentinel capabilities or integrations that are
 | Entities: Add entities to threat intelligence from incidents | Azure portal only | This functionality is unavailable in the Defender portal. <Br><br>For more information, see [Add entity to threat indicators](add-entity-to-threat-intelligence.md). |
 | Fusion: Advanced multistage attack detection | Azure portal only  | The Fusion analytics rule, which creates incidents based on alert correlations made by the Fusion correlation engine, is disabled when you onboard Microsoft Sentinel to the Defender portal. <br><br>The Defender portal uses Microsoft Defender XDR's incident-creation and correlation functionalities to replace those of the Fusion engine. <br><br>For more information, see [Advanced multistage attack detection in Microsoft Sentinel](fusion.md) |
 | Incidents: Adding alerts to incidents /<br>Removing alerts from incidents | Defender portal only | After onboarding Microsoft Sentinel to the Defender portal, you can no longer add alerts to, or remove alerts from, incidents in the Azure portal. <br><br>You can remove an alert from an incident in the Defender portal, but only by linking the alert to another incident (existing or new). |
-| <a name="5min"></a>Incidents: Creation | After onboarding to the Defender portal: Incidents are created by the correlation engine in the Microsoft Defender portal. | Incidents created in the Defender portal for alerts generated by Microsoft Sentinel have <b>Incident provider name</b> = <b>Microsoft Defender XDR</b>. <br><br>Any active Microsoft security incident creation rules are deactivated to avoid creating duplicate incidents. The incident creation settings in other types of analytics rules remain as they were, but those settings are implemented in the Defender portal, not in Microsoft Sentinel.<br><br>It may take up to 5 minutes for Microsoft Defender incidents to show in Microsoft Sentinel. This doesn't affect features provided directly by Microsoft Defender, such as automatic attack disruption.<br><br>For more information, see the following articles: <br>- [Incidents and alerts in the Microsoft Defender portal](/defender-xdr/incidents-overview) <br>- [Alert correlation and incident merging in the Microsoft Defender portal](/defender-xdr/alerts-incidents-correlation) |
+| <a name="5min"></a>Incidents: Creation | After onboarding to the Defender portal: Incidents are created by the correlation engine in the Microsoft Defender portal. | Incidents created in the Defender portal for alerts generated by Microsoft Sentinel have <b>Incident `providerName`</b> = <b>`Microsoft XDR`</b>. <br><br>Any active Microsoft security incident creation rules are deactivated to avoid creating duplicate incidents. The incident creation settings in other types of analytics rules remain as they were, but those settings are implemented in the Defender portal, not in Microsoft Sentinel.<br><br>It may take up to 5 minutes for Microsoft Defender incidents to show in Microsoft Sentinel. This doesn't affect features provided directly by Microsoft Defender, such as automatic attack disruption.<br><br>For more information, see the following articles: <br>- [Incidents and alerts in the Microsoft Defender portal](/defender-xdr/incidents-overview) <br>- [Alert correlation and incident merging in the Microsoft Defender portal](/defender-xdr/alerts-incidents-correlation) |
 | Incidents: Editing comments | Azure portal only | After onboarding Microsoft Sentinel to the Defender portal, you can add comments to incidents in either portal, but you can't edit existing comments. <br><br>Edits made to comments in the Azure portal don't synchronize to the Defender portal. |
 | Incidents: Programmatic and manual creation of incidents | Azure portal only  | Incidents created in Microsoft Sentinel through the API, by a Logic App playbook, or manually from the Azure portal, aren't synchronized to the Defender portal. These incidents are still supported in the Azure portal and the API. See [Create your own incidents manually in Microsoft Sentinel](create-incident-manually.md). |
 | Incidents: Reopening closed incidents | Azure portal only  | In the Defender portal, you can't set alert grouping in Microsoft Sentinel analytics rules to reopen closed incidents if new alerts are added. <br>Closed incidents aren't reopened in this case, and new alerts trigger new incidents. |
@@ -137,6 +137,7 @@ The following table lists the changes in navigation between the Azure and Defend
 | Automation        | Microsoft Sentinel > Configuration > Automation      |
 | Settings          | System > Settings > Microsoft Sentinel               |
 
+
 ## Related content
 
 - [Microsoft Defender XDR integration with Microsoft Sentinel](microsoft-365-defender-sentinel-integration.md)

articles/sentinel/workspaces-defender-portal.md

@@ -81,7 +81,7 @@ How incident changes sync between the Azure portal and the Defender portal depen
 
 |Workspace |Sync behavior  |
 |---------|---------|
-|Primary     |  For Microsoft Sentinel in the Azure portal, Defender XDR incidents appear in **Threat management** > **Incidents** with the incident provider name **Microsoft Defender XDR**. Any changes you make to the status, closing reason, or assignment of a Defender XDR incident in either the Azure or Defender portal, update in the other's incidents queue.  For more information, see [Working with Microsoft Defender XDR incidents in Microsoft Sentinel and bi-directional sync](microsoft-365-defender-sentinel-integration.md#working-with-microsoft-defender-xdr-incidents-in-microsoft-sentinel-and-bi-directional-sync).|
+|Primary     |  For Microsoft Sentinel in the Azure portal, Defender XDR incidents appear in **Threat management** > **Incidents** with the incident provider name **Microsoft XDR**. Any changes you make to the status, closing reason, or assignment of a Defender XDR incident in either the Azure or Defender portal, update in the other's incidents queue.  For more information, see [Working with Microsoft Defender XDR incidents in Microsoft Sentinel and bi-directional sync](microsoft-365-defender-sentinel-integration.md#working-with-microsoft-defender-xdr-incidents-in-microsoft-sentinel-and-bi-directional-sync).|
 |Secondary   | All alerts and incidents that you create for a secondary workspace are synced between that workspace in the Azure and Defender portals.   Data in a workspace is only synced to the workspace in the other portal.      |
 
 ## Related content