Azure Sentinel Incident sync with ServiceNow
Azure Sentinel has built-in Incidents which aggregates alerts into a single Incident, and you can interact with those Incidents directly in Sentinel. You can do investigations, assign to analysts and even close the Incident with a classification and comment. However, you might be using an ITSM for operations, and it would be great to have a synchronization for these Incidents with your ITSM and to be able to close these Incidents in either system — and have the incident closure synchronized.
Microsoft has already published a blog post with a solution to synchronize incidents with ServiceNow. This solution also synchronizes Incident closure from ServiceNow to Sentinel, enabling analysts to work in their primary ITSM while automatically closing incidents in Sentinel when they’re closed in ServiceNow. However, this solution doesn’t synchronize Incident closure from Sentinel to ServiceNow; meaning you can’t close an Incident in Sentinel and have it automatically close in ServiceNow.
I created another solution with two Logic Apps, and an Azure Table for data. One Logic App creates an Incident in ServiceNow and writes to an Azure Table, while the other Logic Apps queries the Table and the Incident status in both ServiceNow and Sentinel, and acts upon closure in either system.
The Logic App for Incident creation utilizes the new trigger and the new automation rules in Sentinel to act on all new Incidents in Sentinel. It calculates Priority and convert Entities (if any) to HTML, and uses all of the data to create a new Incident in ServiceNow. Finally, it writes the Sentinel Incident ARM ID and the ServiceNow SysID to an Azure Table.
The Logic App for Incident synchronization queries the Azure Table on a schedule for all entities which are not yet processed. It uses the Incident ARM ID to check the status in Sentinel, and the SysID to check the status in ServiceNow. If the Incident is closed in either system, it closes the corresponding Incident in the other system, and changes the entity to processed.
Hi, I’m finding this post very useful and am looking to setup something very similiar.
Can you provide any guidance on setting up the Azure Table storage. I understand when inserting entities you must provide a row and partition key. How do you create these within a logic app?
Your help would be much appreciated and thank you for posting.
Daniel
Apologies for the late reply.
The Row Key should be unique, so for this example it could be the unique ARM ID for the Sentinel Incident. When looking at a single entity, you’ll use the RowKey to look up either the the Sentinel Incident, and you’ll have another column for the ServiceNow SysID, so you can find the corresponding ServiceNow Incident.
The Partition Key, as far as I’ve understood, is less important unless you have large amounts of entries and want to partition them (e.g. if it’s a table of users, you’d maybe want the partition key to be the cities, to partition the data accordingly) — so I usually keep it static across all entries.
tl;dr: RowKey is just like any other column, but it has to be unique. PartitionKey can be static across all entries.