What's New: Introducing Microsoft Sentinel solution for ServiceNow bi-directional sync

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.

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.

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 Responder” permissions.

Create a Service principle 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”
   

2. Click on the” New” button

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

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"
   

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

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.

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:

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.
   

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
     

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

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:

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

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.

View the environment's values using the following technique:

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.

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.

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.

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:

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:

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
   

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

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

The application uses the following business rules:

• add_work_note_to_sentinel: sycnhronizes work notes to sentinel comments
  

• 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
  

• 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
  

Closing

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

Continue reading...