Nov 13 2019 06:36 AM
Nov 13 2019 06:36 AM
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?
Nov 21 2019 03:51 AM
@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?
Nov 22 2019 12:21 AM - edited Nov 22 2019 02:55 AM
@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.
Dec 02 2019 07:25 AM
@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.
Dec 02 2019 07:32 AM
@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.
Dec 02 2019 07:48 AM
@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?
Dec 02 2019 10:53 AM
@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.
Dec 02 2019 11:57 AM
@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.
May 25 2020 03:03 AM - edited May 25 2020 03:05 AM
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
May 25 2020 03:29 AM
@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: