One of the main SIEM use cases is incident management. Azure Sentinel offers robust features that help the analyst to manage the life cycle of security incidents, including:
- Alert grouping and fusion
- Incident triaging and management
- An interactive investigation experience
- Orchestration and response using Logic Apps
In some cases, customers maintain incidents in their IT Service Management (ITSM) systems for remediating security incidents across the organization. For organizations using ITSM systems, there is often a need for a bi-directional sync of Azure Sentinel incidents to their ITSM tool. When this integration occurs, a security incident created in Azure Sentinel, would also be created in the ITSM system. If this ticket is closed in the ITSM system, it will be closed in Azure Sentinel.
In this article, I demonstrate how to use Azure Sentinel Security Orchestration, Automation and Response (SOAR) capability and ServiceNow’s (SNOW) Business Rules feature to implement this bi-directional incident sync between the two systems.
High level flow of the solution
Send an Azure Sentinel incident into ServiceNow incident queue
The playbook, available here and presented below, works as follows:
- Triggers automatically on a new Alert.
- Gets relevant properties from the Incident.
- Populates the workspace name variable.
- Creates a record of incident type in ServiceNow and populate the Azure Sentinel Incident properties into the SNOW incident record using the following mapping:
|
ServiceNow |
Sentinel |
|
Number |
Incident Unique ID |
|
Short Description |
Description |
|
Severity |
Severity |
|
Additional comment |
Incident Deep link |
Deploying the solution
- Deploy the above Logic APP
- Attached this logic app to every analytics rule that you want to sync to ServiceNow, by Selecting it on the automated response section. (currently you need to run this process for each analytics rule that you want to sync)
Once an analytics rule generates a new incident, a new incident will pop-up on the ServiceNow incident Page.
Close Sentinel Incident When it closed in ServiceNow.
Closing the incident in Azure Sentinel when it is closed in ServiceNow requires two components:
- A Business Rule in ServiceNow that run custom JS code when the incident is closed.
- A Logic App in Azure Sentinel that waits to the Business Rule POST request.
Step 1: Deploy the Logic App on Azure Sentinel.
The playbook, available here and presented below, works as follows:
- Triger when an HTTP POST request hits the endpoint (1)
- Get relevant properties from the ServiceNow Incident.
- Close the incident on Azure Sentinel (4)
- Add comment with the name of the user who closed into an Azure sentinel incident comment (5)
Step 2: Configure the Logic App
- Copy the HTTP endpoint URL from the Logic App trigger part.
2. In “run query and list results” (2) authenticate with user that has log analytics read permission or Azure Sentinel Reader role as a minimum requirement.
3. In “get incident – bring fresh ETAG” (3) authenticate to AAD APP with a user that has an Azure Sentinel Reader role, or with a Managed identity with the same permission.
4. On the close incident step (4) we will need to use a user that has an Azure Sentinel Responder role as the identity for
5. On “add comment to incident” (5) use a user that has an Azure Sentinel Contributor account.
Step 3: ServiceNow Business Rule
What is Business Rule?
Per ServiceNow documentation, a business rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried.
To create the business rule
- Login to your ServiceNow Instance.
- In the left navigation type business rules, press New to create a new business rule.
(For a business rule types and scopes refer to ServiceNow documentation)
- Give the business rule a name, select Incident as the table, and check the Active and the Advanced checkboxes.
4. On the “When to run” tab, configure the controls as depicted on the screenshot below.
5. On the Advance tab, paste the above (like the picture below)
In line 8, replace the URL with the URL that we copied from the webhook Logic App above; this will be the endpoint that the business rule will interact with.
{
var ClosedUser = String(current.closed_by.name);
var Description = current.short_description.replace(/(\r\n|\n|\r|['"])/gm,", ");
var number = String(current.number);
var request = new sn_ws.RESTMessageV2();
var requestBody = {"Description": Description , "number": number , "ClosedBy":ClosedUser };
request.setRequestBody(JSON.stringify(requestBody));
request.setEndpoint('https://prod-65.eastus.logic.azure.com:443/workflows/9afa26062b1e4a0180d6ecefd26ab58e/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=gv1HMcDt8DanJmOe3UvG22uyU_nere4rTQF8XnInYog');
request.setHttpMethod('POST');
request.setRequestHeader("Accept","application/json");
request.setRequestHeader('Content-Type','application/json');
var response = request.execute();
var responseBody = response.getBody();
var httpStatus = response.getStatusCode();
var parsedData = JSON.parse(responseBody);
gs.log(response.getBody());
}In the above example I only send to sentinel 3 properties:
- ClosedBy – the username that closed the incident in Service Now
- Description – the incident description
- Number – the incident ID, originally received from Azure Sentinel.
You can modify the business rule Java Script code and add other properties that can add value to your use case.
Summary
Once the user closes the incident in ServiceNow, the listener Logic App triggers and closes the incident in Azure Sentinel, adding a relevant comment as you can see below:
This completes the process of implementing incident sync between Azure Sentinel and ServiceNow by leveraging a Logic App and a ServiceNow business rule.
Thanks @Ofer_Shezaf and @Kara Cole for all the help during this blog creation.
