You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/sentinel/microsoft-sentinel-defender-portal.md
+10-16Lines changed: 10 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -145,22 +145,16 @@ The unified experience in the Defender portal introduces notable changes to inci
145
145
The [Microsoft Sentinel API](/rest/api/securityinsights/api-versions) continues to support actions against Microsoft Sentinel resources, like analytics rules, automation rules and more. For interacting with unified incidents and alerts, we recommend that you use the Microsoft Graph REST API.
146
146
If you're using the Microsoft Sentinel `SecurityInsights` API to interact with Microsoft Sentinel incidents, you may need to update your automation conditions and trigger criteria due to changes in the response body. The following fields are important in the response snippets:
147
147
148
-
+`alertProductNames`: The source that triggered the detection
149
-
+`incidentUrl`: The direct URL to the incident in the Microsoft Sentinel portal
150
-
+`providerName`: The name of the provider
151
-
152
-
After transitioning to the unified experience, the following sections are added and changed:
153
-
+`providerIncidentUrl` : This new field provides the direct URL to the incident in the unified portal.
154
-
+`providerName` : The providerName field value has been changed from *"Azure Sentinel"* to *"Microsoft XDR"*.
155
-
156
-
When using an HTTP GET command for a specific unified incident with the Microsoft Graph REST API, the body response has the following differences:
157
-
158
-
+ The `incidentWebUrl` field provides a direct link to the incident, which can be used to synchronize this information with a third-party ticketing system like ServiceNow.
159
-
+ If the response doesn't contain the `alertProductNames` array, you can retrieve it by updating the initial HTTP GET command to add `?$expand=alerts` after the GET command. For example: `https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts`
160
-
161
-
The following new fields have been added to the response body:
162
-
+`serviceSource` : The service or product that created the alert
163
-
+`detectionSource` : Detection technology or sensor that identified the notable component or activity
148
+
The following table lists fields that are important in the response snippets, and compares them across the Azure and Defender portals:
| Link to the incident|`incidentUrl`: The direct URL to the incident in the Microsoft Sentinel portal |`providerIncidentUrl` : This additional field provides a direct link to the incident, which can be used to synchronize this information with a third-party ticketing system like ServiceNow. `incidentUrl` is still available, but it points to the Microsoft Sentinel portal. |
153
+
| The sources that triggered the detection and published the alert |`alertProductNames`|`alertProductNames`: Requires adding `?$expand=alerts` to the GET. For example, `https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts`|
154
+
| The name of the alert provider|`providerName` = "Azure Sentinel" |`providerName` = "Microsoft XDR" |
155
+
| The service or product that created the alert ||`serviceSource` For example, "microsoftDefenderForCloudApps" |
156
+
| The detection technology or sensor that identified the notable component or activity ||`detectionSource` For example, "cloudAppSecurity"|
157
+
| The name of the product which published this alert. ||`productName` For example, "Microsoft Defender for Cloud Apps" |
0 commit comments