New incident notification

New Contributor


I'm trying to get sentinel incident (Microsoft.SecurityInsights/Cases) properties (json body) on my api endpoint each time when new incident created in the system.

Microsoft.Graph allows you to subscribe on and manipulate with security alerts, but there is no way to get incident based on it alert.

Playbook allows me to get incident only for specific rule, but it should be manually integrated into each existing/new rule.

... and there is no Azure Sentinel API.


Is there a way to do so?


13 Replies
best response confirmed by kastromatos (New Contributor)


Today, the only way is to run a playbook for each rule.  You could have 1 playbook that is used across all your rules.


We will eventually release APIs.

@Nicholas DiCola (SECURITY JEDI) But what about the Microsoft Security rules like Create incidents based on Azure ATP alerts, or MCAS alerts. You can't attach a playbook to those. So how do you get it to automatically log a a SNOW incident lets say, or send an email whenever an Azure Sentinel incident of such type is created? Are you aware of any way to do this with the current functionality?

@Cristian Calinescu 

We are aware you can not call a playbook today.  we plan to change that.  in the short term if you must call a playbook then you would need to disable the MSFT rules and create scheduled rules for each product manually.

@Nicholas DiCola (SECURITY JEDI)- Many thanks for the reply. I managed to find a way around this actually, and it seems to be working pretty well. The solution I've put together is a logic app which runs on a schedule every 5 minutes and does the following:

1. It runs a Log Analytics query to get all Security Alerts generated for the last 5 minutes

| where TimeGenerated >= now(-5m)


There is a slight delay between the time the alert fires in it's respective solution (WDATP, MCAS, etc.) and the time it gets ingested in Log Analytics but so far, with this timespan configuration it hasn't missed any alert. Hopefully it won't going forward :).


2. For each value returned it gets the Azure Sentinel incident (where it finds a match) I had to manually specify the Subscription ID, Resource Group, and Workspace ID and used the dynamic value of SystemAlertId for the "Specify Alert id parameter". this is the only way I managed to get it working


3. It then creates a SNOW incident based on the values from the Get Incident in Sentinel


4. It gets the SNOW record


5. It sends an email containing the desired info


Here's a screenshot of the logic app. Hope it helps and looking forward for you guys to change the MSFT rules. As, going forward it would be nice to have a way to expand/create a logic app that when the status of the incident is set to closed in Sentinel it will automatically close the SNOW incident or at least the alert in it's respective product.





@Cristian Calinescu 


This is great.  you should contribute this playbook to the github.  if you need some help, i am happy to help you do that.

@Cristian Calinescu do you know how we can deal with empty subscription ids/workspace ids? Some of my System alerts (e.g from MCAS) don't have a subscription id and the Azure Sentinel- Get Incident action fails in that case. Also,  I was using a similar logic app as you but instead of the Log Analytics connector I used the Microsoft Graph Security Connector to get the latest alerts. I'm not sure if it works the same way.


Thank you

@aal5890- Yes, I was using the MS Graph as well but it's a little more complicated, and there are some delays between the time generated and ingested in Log Analytics or Sentinel. You will need to hard code your Subscription ID in the Get Incident step as well as the Resource Group and Workspace ID. The only thing that you'll leave as dynamic is System Alert ID. You can find those values on the Azure Sentinel lade - Settings - Workspace Settings. Hope this makes sense and I can provide you with screenshots if needed.

@Cristian Calinescu I meant the value is null so it won't get those values back in the field "Specify subscription id". When it's accessing the path to the azure sentinel incident it fails since my subscription ids for the alert are empty. Do you know if there's anything I can do to access alerts with empty subscription ids?


Thank you



@aal5890 - That's what I was saying. You need to copy the Subscription ID, Resource Group and Workspace ID from your Azure Sentinel - Settings - Workspace Settings (see below)


And paste them into the Get Incident fields as below. The only dynamic value that you will set is the System alert ID (as below)


Now, I asume that you already have the MCAS data source connected to Azure Sentinel and the "Create incidents from Microsoft Cloud App Security alerts" already enabled.

@Cristian Calinescu Sorry ,  I am getting the emails for everything which has a subscription id field but for the alerts that don't, I'm not getting the email. If I hard-code it and don't make the value dynamic I will still only receive those alerts that have the subscription id. I was hoping you had some information on how I could deal with that kind of issue.



@Cristian Calinescu


Its a great workaround although for the same SystemAlertId provided to the Alert - Get Incident i get more than one incident if the SystemAlertId has reoccurred in the past as it seems that Sentinels SystemAlertId is not unique per alert - correct me if i am wrong.


As a result for one SystemAlertId i get 2 or more email messages with older incidents

@akefallonitis I did kind of a workaround.I added 2 additional steps before the create SNOW incident.

The first step is a condition in which we verify if the incident title does NOT contains or starts with (whichever you prefer) the string "INC". If the condition is evaluated as true, we go ahead and continue with the next steps Create the SNOW record and so on. But, after we create the SNOW record we add an additional step to change the Sentinel incident title and add the SNOW reference number "INCxxxxxxx" at the beginning of the Sentinel incident title. This way, when the foreach loop goes again through all the alerts it sees that the Sentinel incident starts with "INC" and it does not log (or send another email) again. So basically we remove the duplicates. Now, if you're not working with SNOW, you can apply the same logic by adding some kind of word (string) to the beginning of the Sentinel incident title, which will basically act like a label for which you can evaluate your condition. Hope this makes sense, and I hope it helps. Please also see below a visual representation:


@Cristian Calinescu


 I am asking mostly to check if it is consistent to have the same SystemAlertId for different events.

 As for your workaround ty - i was thinking on implementing a check of CreatedTime >= now - some minutes