This article is contributed. See the original author and article here.
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 our customer engagements we learned that in some cases our customers need to maintain incidents in their existing ticketing (ITSM) system and use it as a single pane of glass for all the security incidents across the organization. One critical request that raises is the need for a bi-directional sync of Azure sentinel incidents.
This means, for example, that if a security incident is created in Azure Sentinel, it needs to be created in the ITSM system as well, and if this ticket is closed in the ITSM system, this should be reflected in Azure sentinel.
In this article, I demonstrate how to use Azure sentinel SOAR capability and ServiceNow (SNOW) Business Rules feature to implement this bi-directional incident sync between the two.
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 “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(/(rn|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:
We just walked through the process of implementing incident sync between Azure Sentinel and Service Now by leveraging a Logic App and a ServiceNow business rule.
Thanks @Ofer_Shezaf for all the help during this blog creation.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments