What's New: Introducing Microsoft Sentinel solution for ServiceNow bi-directional sync
Published Dec 08 2022 11:11 AM 33.2K Views
Microsoft

This post presents a shared effort which includes @SebastianMolendijk @Ely_Abramovitch, @Lior Tamir.

 

Case Management is an important activity for any SOC team. Seamless integration of SIEM and ITSM applications enables easier case management. We are announcing public preview of our new integration between Microsoft Sentinel and ServiceNow, which provides bi-directional sync between both products. This integration available as a Microsoft Sentinel solution for ServiceNow in content hub enables analysts and SOC managers to utilize both tools as part of their incident handling workflows while maintaining bi-directional sync between the products.  

Microsoft Sentinel has incident management capabilities with advanced investigational features to enable SOC workflows. There are companies today that currently rely on ServiceNow as part of their security incidents handling and reporting workflows. These companies utilize ServiceNow to better connect to the wider organization, for assignment to professionals outside of the SOC for remediation flows and for supplement capabilities such as custom reporting. We are continuously working on improving the analysts E2E experience by seamlessly integrating with the non-Microsoft solutions used by the SOC team.  
The Microsoft Sentinel solution for ServiceNow runs on the Now platform as an app, and only requires access to the Microsoft Sentinel Management API to synchronize incidents. This solution can be accessed from Microsoft Sentinel content hub as illustrated below, Azure Marketplace and ServiceNow store.  

 

kavishbakshi_0-1670506229653.png

 

 

In this blog post, we’ll guide you through its key features, and provide the link to the installation and configuration documentation. 

 

Key capabilities 

  • Incident creation (Microsoft Sentinel to ServiceNow only) 
  • Incident alerts synchronization 
  • Incident entities synchronization 
  • Incident comments synchronization 
  • Incident status synchronization 
  • Incident severity synchronization 
  • Incident owner assignment synchronization 
  • Incident custom properties support (requires custom code) 

Note: - Traditional Azure Logic app integration or the existing solution does not cleanly support bi-directional synchronization.   

Limitation: - Microsoft Sentinel app works on individual ServiceNow instance and doesn't support domain separation. 

 

Get started 

This solution is a ServiceNow application and fully relies on the Microsoft Sentinel Management API to provide bi-directional sync between both platforms. 

To provide access to Sentinel, create a Service Principal in Azure Active Directory and assign the required "Azure Sentinel Responderpermissions. 

Create a Service principal on Azure 

  1. Go to the Azure portal, in Azure AD service, App Registrations: 
  2. Registered Apps page click on “New registration” Provide a name for the app and click “Register”               
  3. Take note of the Application (client) ID and Directory (tenant) ID. We’ll need them during the ServiceNow configuration               
  4. Go to “Certificates & secrets” and click on “New client secret”              
  5. Provide a name for the secret and a validity period. 
    Note: when the secret will expire, a new one needs to be created and update the ServiceNow configuration               
  6. Note the secret and keep it in a safe location (Azure key vault) for later use 

      For more details, please refer this link            

Assigning needed permission to account  

  1. In the Azure portal, go to the Resource Group containing your Microsoft Sentinel workspace and click on “Access control (IAM)”             
  2. Click on “Add role assignments”             
  3. In the new blade, select the "Azure Sentinel Responder” role, then select the Service Principal created before, and click on the “Save” button           

This completes the Azure configuration part. 

 

Create a user for Microsoft Sentinel on ServiceNow  

To identify the incidents created from Microsoft Sentinel incidents, create a user. This user will be used as the “caller_id” property, when creating new records. 

  1. In ServiceNow, under “User Administration”, click on “Users”   

kavishbakshi_4-1670506761186.png

 

         2. Click on the” New” button              

 

kavishbakshi_2-1670506390163.png

 

      3. Provide the required details, select "Web service access only" select and click on “Submit” 

            

kavishbakshi_3-1670506390164.png

 This will create the user needed, once the needed prerequisites are taken care of the installation steps can be started.  

 

Install the application in your ServiceNow instance from the ServiceNow store 

  1. In the ServiceNow store, search for "Microsoft Sentinel" 

             

      kavishbakshi_5-1670506847033.png

 

  1. Click on the "Get" button and install the app:             

 

     kavishbakshi_6-1670506847035.png

 

The application is now installed.  

Configure the application  

Once the application is installed it needs to be configured with the details to connect to the Microsoft Sentinel Management API. 
All configuration steps are accessible through the Microsoft Sentinel menu. 

Configure the Microsoft Sentinel workspace(s) details

The “Workspaces Configuration” section table contains the Microsoft Sentinel workspaces configuration.

Find in this section a default workspace to configure or create new configurations to access multiple workspaces.

Open the current row to edit its configuration. This will need the workspace name, its subscription and resource group.

kavishbakshi_8-1670507163063.png

 

In addition to the workspace values (available in Microsoft Sentinel), provide the Caller ID “sys_id” value created before in ServiceNow, review the OAuth Provider (configured at next step) and click on the Update button. The incidents synchronization will not start until workspace is enabled:

kavishbakshi_9-1670507163090.png

 

Note: In addition to the workspace configuration, there are the following properties:

  • Incident max age (days): maximum incident age, in days, for incidents to be created in ServiceNow, based on the incident's creation time
  • newIncidentsLastSync: timestamp automatically updated once the app successfully contacts the Sentinel API to retrieve the new incidents since last update. If needed, you can manually change the value to query incidents older than your specified date
  • modifiedIncidentsLastSync: timestamp automatically updated once the app successfully contacts the Sentinel API to retrieve the updated incidents since last update
  • Incidents filter: filter used to retrieve only the matching incidents from Sentinel API. By default, it filters the incidents with a tag “snow”. To get all incidents, just delete the content of this field. Custom tag names can also be used.

          NOTE: This value is case sensitive!

  • Enabled: Boolean value to specify if the workspace is enabled or not. When disabled, the incidents are not retrieved, and the timestamps are not updated

Configure the Service Principals/OAuth Provider credentials

  1. To call the Microsoft Sentinel Management API from ServiceNow, the credentials created previously in Azure AD need to be configured. This is done using an “Application Registry". By default, “Az Sentinel OAuth app” is used but custom name can be used, if it matches the name provided in the workspace configuration.          

        credsMenu.gif

           

  1. On the credentials configuration page, provide the information collected during the Service Principal creation:
    • Name: Az Sentinel OAuth app (can be different. This is the default name used by the workspace configuration)
    • Client ID (1): Azure AD application/client ID
    • Client secret (2): Azure AD client secret
    • Default Grant type: Client Credentials
    • Token URL (3): add your Azure AD tenant ID in the URL: https://login.microsoftonline.com/{AAD_tenant_id}/oauth2/token
    • Token Revocation URL (4): add ServiceNow instance name in the URL: https://{instance_name}.service-now.com/oauth_redirect.do

                 kavishbakshi_11-1670507163222.png

 

 

  1. Click on the “Submit” button to save changes                

        kavishbakshi_12-1670507163224.png

Verify the “Sentinel Severity to ServiceNow” table mapping

This table is used to map the Sentinel severity to the ServiceNow value, when creating or updating AzureSentinel incidents.
Note that in this case, because Sentinel has four different severities values, while we have only three in ServiceNow, both “Informational” and “Low” have been assigned the value 3:

kavishbakshi_13-1670507163225.png

 

The environment's values can be viewed using the following technique

 

showSnowSevValues.gif

Verify the “Sentinel State to ServiceNow” table mapping

This table is used to map the Sentinel state/status to the ServiceNow value, when creating or updating Microsoft Sentinel incidents.
Note that Sentinel has probably less states than ServiceNow, so select the initial ServiceNow value used by the application.

 

kavishbakshi_15-1670507163285.png

View the environment's values using the following technique:

 

showSnowStateValues.gif

Verify the “ServiceNow Severity to Sentinel” table mapping

This table is used to map the ServiceNow severity to the Microsoft Sentinel value, when updating ServiceNow incidents and synchronizing the changes to Microsoft Sentinel.
Review the values to validate that they map to the environment's configuration.

kavishbakshi_17-1670507163525.png

Review and validate the system properties

In addition to the configuration stored in the tables, the app keeps some information in system properties.
Review the default values and change it to match your environment.

kavishbakshi_18-1670507163533.png

 

The available properties are:

  • apiUrl: URL to the Microsoft Sentinel API. If the workspace is in Gov Cloud, change it to "https://management.usgovcloudapi.net"
  • apiVersion: Microsoft Sentinel API version (should not be changed, unless new version is available)
  • incidentTableName: table where the incident are created. The default value is "incident", but any table where one wants to create incidents can be specified.
  • incidentUniqueKey: ServiceNow incident property used to uniquely map incidents between Sentinel and ServiceNow. By default, the app uses “correlation_id”. If already using this property, specify or create another one
  • severityField: incident property to store the incident severity. By default, the app uses “impact”. Verify what is used in environment.
  • statusField: incident property to store the incident state. By default, the app uses “state”. Verify what is used in environment

Verify the “Closure classification” table entries

This table is used to map Sentinel and ServiceNow closure codes and should match the closure codes used when closing incidents.
To verify the values, open the "Closure code" section in the Microsoft Sentinel menu.

closurecodeMenu.gif

 

Update the provided values with needed environment ones (the label column is used to describe the value, while the ServiceNowCode column is used to match the system resolution code). Find the closure code by looking at the "Resolution code" values in incidents:

kavishbakshi_20-1670507163624.png

 

showClosureCode.gif

 

IMPORTANT: in this table, the last column, “SourceIsSentinel” contains Boolean values to define which values should be used in ServiceNow when a close status has been set in Sentinel incidents.
There should be only one “true” row per Sentinel possible status:

kavishbakshi_22-1670507163850.png

 

Owner mapping

This table allows custom mapping between the owner's username (userprincipal property) in Azure AD and Microsoft Sentinel, and ServiceNow incidents. To create such mapping, follow the steps below:

  1. Click on the "New" button to create a new mapping

kavishbakshi_23-1670507163857.png

 

  1. Provide the ServiceNow username, Azure AD UPN and optionally the Sentinel workspace and click on the "Submit" button

kavishbakshi_24-1670507163860.png

Additional configuration

If another incident table is configured to store Sentinel incidents, the changes must reflect to the two business rules being triggered by changes. Additional filters can be added if needed if needed.

IMPORTANT 
If running versions older than Rome, verify that the "When to run" value is using async and not async_alway:
If running versions older than 

kavishbakshi_25-1670507163862.png

 

The application uses the following business rules:

  • add_work_note_to_sentinel: sycnhronizes work notes to sentinel comments

kavishbakshi_26-1670507163869.png

 

  • update_changes_to_sentinel: synchronizes severity, status, closure code, owner to Sentinel.
    If using other fields than the default for unique identifier, severity and state set the correct values in the filters
    If using other fields than the default for unique identifier, severity and state

kavishbakshi_27-1670507163875.png

 

  • custom_mapping: business rule that can be used to code specific custom mapping during incidents creation or updates. By default, no custom mapping is performed but we provide some examples in the code

kavishbakshi_28-1670507163892.png

 

Closing

Try out this Microsoft Sentinel solution for ServiceNow and share your feedback via any of the channels listed in the resources.

 

 

 

 

29 Comments
Version history
Last update:
‎Apr 04 2024 11:07 PM
Updated by: