Merge branch 'main' into patch-5

Author: aditisrivastava07

ATPDocs/privacy-compliance.md

@@ -22,14 +22,13 @@ For more information see: [Microsoft Defender for Identity monitored activities]
 
 Defender for Identity operates in the Microsoft Azure data centers in the following locations:
 
-- European Union
-- United Kingdom
-- United States
-- Australia
-- Switzerland
-- Singapore
-
-- India
+- European Union (West Europe, North Europe)
+- United Kingdom (UK South) 
+- United States (East US, West US, West US2)
+- Australia (Australia East)
+- Switzerland (Switzerland North)
+- Singapore (Southeast Asia)
+- India (Central India, South India)
 
 Customer data collected by the service might be stored as follows:
 

CloudAppSecurityDocs/includes/entra-conditional-access-policy.md

@@ -30,7 +30,13 @@ Microsoft Entra ID supports both browser-based and non browser-based policies. W
 
 Repeat this procedure to create a nonbrowser based Conditional Access policy. In the **Client apps** area, toggle the **Configure** option to **Yes**. Then, under **Modern authentication clients**, clear the **Browser** option. Leave all other default selections selected.
 
-Note: The Enterprise application “Microsoft Defender for Cloud Apps – Session Controls” is used internally by the Conditional Access App Control service. 
-Please ensure the CA policy does not restrict access to this application in the **Target resources**. 
-
 For more information, see [Conditional Access policies](/azure/active-directory/conditional-access/overview) and [Building a Conditional Access policy](/entra/identity/conditional-access/concept-conditional-access-policies).
+
+> [!NOTE]
+> Microsoft Defender for Cloud Apps utilizes the application **Microsoft Defender for Cloud Apps - Session Controls** as part of the Conditional Access App Control service for user sign-in. This application is located within the 'Enterprise Applications' section of Entra ID. 
+To protect your SaaS applications with Session Controls, you must allow access to this application. 
+If you block access to this application through an Entra ID Conditional Access policy, end users won't be able to access the protected applications under session controls. <br>
+>
+>It's important to ensure that this application isn't unintentionally restricted by any Conditional Access policies. For policies that restrict all or certain applications, please ensure this application is listed as an exception in the **Target resources** or confirm that the blocking policy is deliberate.<br>  
+>
+>To ensure your location-based conditional access policies function correctly, include the **Microsoft Defender for Cloud Apps – Session Controls** application in those policies.

CloudAppSecurityDocs/ip-tags.md

@@ -40,7 +40,7 @@ In the Microsoft Defender Portal, select **Settings**. Then choose **Cloud Apps*
 
     - **Corporate**: These IPs should be all the public IP addresses of your internal network, your branch offices, and your Wi-Fi roaming addresses.
 
-    - **Risky**: These IPs should be any IP addresses that you consider risky. They can include suspicious IP addresses you've seen in the past, IP addresses in your competitors' networks, and so on.
+    - **Risky**: These IPs should be any IP addresses that you consider risky. They can include suspicious IP addresses you've seen in the past, IP addresses in your competitors' networks, and so on. It is suggested to be cautious with applying automatic governance actions only based on risky IP, since there are some cases when IPs that serve malicious actors are also being in use by legitimate employees, hence our recommendation is to examine each case by itself.
 
     - **VPN**: These IPs should be any IP addresses you use for remote workers. By using this category, you can avoid raising [impossible travel](anomaly-detection-policy.md#impossible-travel) alerts when employees connect from their home locations via the corporate VPN.
 

CloudAppSecurityDocs/policies-threat-protection.md

@@ -88,7 +88,7 @@ You must have at least one app connected using [app connectors](enable-instant-v
 
 ## Detect and alert when Admin activity is detected on risky IP addresses
 
-Detect admin activities performed from and IP address that is considered a risky IP address, and notify the system admin for further investigation or set a governance action on the admin's account.
+Detect admin activities performed from and IP address that is considered a risky IP address, and notify the system admin for further investigation or set a governance action on the admin's account. Learn more [how to work with IP ranges and Risky IP](/defender-cloud-apps/ip-tags).
 
 ### Prerequisites
 

CloudAppSecurityDocs/troubleshooting-api-connectors-using-error-messages.md

@@ -49,6 +49,7 @@ App connector errors can be seen in the app connector dialog after attempting to
 > |Get Permissions: NoHttpResponseException: `*******.salesforce.com:443` failed to respond|Salesforce|IP restriction on customer ENV.|In the Salesforce portal, under **Setup** > **Session Settings**, clear the **Lock sessions to the IP address from which they originated** check box.|
 > |team_not_authorized|Slack|Slack Discovery API is not enabled.|Contact Slack support and ask to enable Discovery API.|
 > |RuntimeException: com.adallom.adalib.httputils.exceptions.HttpRequestFailure: Server returned: 403 Forbidden|ServiceNow|Permissions are incorrect|Follow the process to connect ServiceNow to Defender for Cloud Apps again using an admin account.|
+> |Operation you are attempting to perform is not supported by your plan|Smartsheet|The Smartsheet Plan is not correct, an enterprise license with the platinum package is required|Upgrade Smartsheet license.|
 > |Get events: {"code":403,"serverResponse"<br />Get users: {"code":403,"serverResponse"<br />…<br />"body":"{"error":"permission denied"}"|Workday|Insufficient permission to access audit logs and/or user endpoints|Verify all permissions are in place. [Learn more](./connect-workday.md#prerequisites)|
 > |"code":400,"serverResponse"<br />…<br />body":"{"error":"invalid_grant"}|Workday|Authentication issue|Account used to set up the instance may be locked or disabled. To verify, view the Workday account and select **View Sign-on History**. You may see an authentication failure message in the report specifying that the System Account is disabled. [Learn more](./connect-workday.md#how-to-connect-workday-to-defender-for-cloud-apps-using-oauth)|
 > |"code":401,"serverResponse":<br />…<br />body":"{"error":"invalid_client"}"|Workday|Client token validity issue|OAuth 2.0 REST API Client token not valid. The token may have expired, or may be incorrect. Generate another token and assign it to the connected instance. [Learn more](./connect-workday.md#how-to-connect-workday-to-defender-for-cloud-apps-using-oauth)|

defender-xdr/alerts-incidents-correlation.md

@@ -18,15 +18,15 @@ ms.topic: conceptual
 search.appverid: 
   - MOE150
   - MET150
-ms.date: 10/25/2024
+ms.date: 02/02/2025
 appliesto: 
 - Microsoft Defender XDR 
 - Microsoft Sentinel in the Microsoft Defender portal
 ---
 
 # Alert correlation and incident merging in the Microsoft Defender portal
 
-This article explains how the Microsoft Defender portal aggregates and correlates the alerts that it collects from all the sources that produce them and send them to the portal. It explains how Defender creates incidents from these alerts, and how it continues to monitor their evolution, merging incidents together if the situation warrants. To learn more about alerts and their sources, and how incidents add value in the Microsoft Defender portal, see [Incidents and alerts in the Microsoft Defender portal](incidents-overview.md).
+This article explains how the correlation engine in the Microsoft Defender portal aggregates and correlates the alerts collected from all the sources that produce them and send them to the portal. It explains how Defender creates incidents from these alerts, and how it continues to monitor their evolution, merging incidents together if the situation warrants. To learn more about alerts and their sources, and how incidents add value in the Microsoft Defender portal, see [Incidents and alerts in the Microsoft Defender portal](incidents-overview.md).
 
 ## Incident creation and alert correlation
 
@@ -56,36 +56,45 @@ Defender's correlation engine merges incidents when it recognizes common element
 - Time frames
 - Sequences of events that point to multistage attacks—for example, a malicious email click event that follows closely on a phishing email detection.
 
-### Outcomes of the merge process
+### Details of the merge process
 
-When two or more incidents are merged, a new incident is not created to absorb them. Instead, the contents of one incident are migrated into the other incident, and the incident abandoned in the process is automatically closed. The abandoned incident is no longer visible or available in the Defender portal, and any reference to it is redirected to the consolidated incident. The abandoned, closed incident remains accessible in Microsoft Sentinel in the Azure portal. The contents of the incidents are handled in the following ways:
+When two or more incidents are merged, a new incident is *not* created to absorb them. Instead, the contents of one incident (the **"source incident"**) are migrated into the other incident (the **"target incident"**), and the source incident is automatically closed. The source incident is no longer visible or available in the Defender portal, and any reference to it is redirected to the target incident. The source incident, though closed, remains accessible in Microsoft Sentinel in the Azure portal.
 
-- Alerts contained in the abandoned incident are removed from it and added to the consolidated incident.
-- Any tags applied to the abandoned incident are removed from it and added to the consolidated incident.
-- A **`Redirected`** tag is added to the abandoned incident.
+#### Merge direction
+
+The direction of the incident merge refers to which incident is the source and which is the target. This direction is determined by Microsoft Defender, based on its own internal logic, with the goal of maximizing information retention and access. The user doesn't have any input into this decision.
+
+#### Incident contents
+
+The contents of the incidents are handled in the following ways:
+
+- All alerts contained in the source incident are removed from the source incident and added to the target incident.
+- Any tags applied to the source incident are removed from the source incident and added to the target incident.
+- A **`Redirected`** tag is added to the source incident.
 - Entities (assets etc.) follow the alerts they're linked to.
-- Analytics rules recorded as involved in the creation of the abandoned incident are added to the rules recorded in the consolidated incident.
-- Currently, comments and activity log entries in the abandoned incident are *not* moved to the consolidated incident.
+- Analytics rules recorded as involved in the creation of the source incident are added to the rules recorded in the target incident.
+- Currently, comments and activity log entries in the source incident are *not* moved to the target incident.
 
-To see the abandoned incident's comments and activity history, open the incident in Microsoft Sentinel in the Azure portal. The activity history includes the closing of the incident and the adding and removal of alerts, tags, and other items related to the incident merge. These activities are attributed to the identity *Microsoft Defender XDR - alert correlation*.
+To see the source incident's comments and activity history, open the incident in Microsoft Sentinel in the Azure portal. The activity history includes the closing of the incident and the adding and removal of alerts, tags, and other items related to the incident merge. These activities are attributed to the identity *Microsoft Defender XDR - alert correlation*.
 
 ### When incidents aren't merged
 
 Even when the correlation logic indicates that two incidents should be merged, Defender doesn't merge the incidents under the following circumstances:
 
 - One of the incidents has a status of "Closed". Incidents that are resolved don't get reopened.
-- The two incidents eligible for merging are assigned to two different people.
-- Merging the two incidents would raise the number of entities in the merged incident above the allowed maximum of 50 entities per incident.
+- The source and target incidents are assigned to two different people.
+- The source and target incidents have two different classifications (for example, true positive and false positive).
+- Merging the two incidents would raise the number of entities in the target incident above the allowed maximum.
 - The two incidents contain devices in different [device groups](/defender-endpoint/machine-groups) as defined by the organization. <br>(This condition is not in effect by default; it must be enabled.)
 
-[!INCLUDE [Microsoft Defender XDR rebranding](../includes/defender-m3d-techcommunity.md)]
-
 ## Next steps
 
 To learn more about prioritizing and managing incidents, see the following articles:
 
 - [Manage incidents in Microsoft Defender](manage-incidents.md)
 
+[!INCLUDE [Microsoft Defender XDR rebranding](../includes/defender-m3d-techcommunity.md)]
+
 ## See also
 
 - [The power of incidents in Microsoft Defender XDR](https://techcommunity.microsoft.com/t5/microsoft-defender-xdr-blog/the-power-of-incidents-in-microsoft-365-defender/ba-p/3515483)