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.