Note: ServiceNow support is available for versions >=3.12 of IriusRisk.
At IriusRisk, we are always introducing new and powerful features, often informed by the feedback and requirements of our customer base. If you are a customer and would like to suggest enhancements to this feature/product, please raise a support ticket, or reach out to your account team.
Why Integrate with ServiceNow?
With IriusRisk, threat modelling starts right at the beginning of your Software Design Life Cycle (SDLC). IriusRisk uses Risk Patterns to automatically determine what might go wrong, and what can be done to mitigate against any inherent risks, however we enable teams to integrate this in their CI/CD pipelines using issue trackers, such as ServiceNow, Jira, RedMine, etc – all of which are configurable at a global, product, and component level. IriusRisk can verify or reopen issues when integrated with vulnerability management tools, such as ThreadFix & Micro Focus Fortify. We also have a fully accessible API for integrating with internal processes and systems.
This guide is intended for those wanting, or already using, ServiceNow, who are interested in leveraging ServiceNow’s functionality for tracking and cataloguing IriusRisk vulnerabilities.
We'll be covering the below
- Why Integrate with ServiceNow?
- Configuring ServiceNow Integration in IriusRisk
- Configuring Settings
- ServiceNow Table Mapping
- Adding new values
- Mapping Guide
- Best Practices
- State
- Description
- Priority
- Comments
- Creating ServiceNow Tickets in IriusRisk
Configuring ServiceNow Integration in IriusRisk
ServiceNow is a heavily customisable tool, and different organisations may choose to use ServiceNow differently; it is for this reason that it is important to properly map IriusRisk fields with the corresponding ServiceNow Table values.
Configuring Settings
Before selecting a table, we first have to authenticate to ServiceNow. For this example, we’ll be configuring this at a Global Default level, however, as mentioned previously, this can also be configured at a product and/or component level. First, navigate to Settings, and then to Issue Tracker:
Select the default Issue Tracker Provider to ServiceNow:
Then, expand the ServiceNow settings. Here you need to provide URL, username and password. You can test the connection with the Test connection button and/or save at any point so that you don’t lose information:
ServiceNow Table Mapping
When raising an issue from IriusRisk for a vulnerability, we need to populate the ServiceNow Table fields with the correspondent values required. At this stage of the configuration, we will be designating values to our example ServiceNow Table.
Once the connection is verified, you can now select the required ServiceNow Table to map to:
Only tables where you have the required permissions in ServiceNow will be visible here.
After selecting the desired ServiceNow Table, we can now map the fields from IriusRisk to those found in the table. You will notice the Mapping Grid:
Ensure that the mandatory fields are mapped. At any point the settings can be saved, however tickets cannot be raised until all mandatory fields are completed and the fields validated.
Be very cautious in order to avoid using the same ServiceNow Table Field for two or more Issue definitions as it could cause unexpected values to be saved and overridden.
Eg: If you mapped Type and State to the same field, your State would always be set to the default value you provided for Type
See below for an example ServiceNow Table mapping:
We can now validate the mapping using Validate Fields. Assuming our mapping is verified, we can now create issues from our IriusRisk countermeasures.
Adding new values
New values can be freely added to the below fields:
-
Default type
-
Open Issue State
-
Closed Issue State
-
Rejected Issue State
-
Issue Weakness priority
-
Default issue labels
If you introduce a new value, it won’t be searchable in the dropdown until it’s been used at least once in ServiceNow (creating a new ticket) since the dropdowns are populated with the distinct values used in the mapped field
Mapping Guide
You need to refresh the IriusRisk settings page in order to retrieve new columns created on ServiceNow
You can use the following table to help you map ServiceNow tables/columns with IriusRisk settings.
In the example column, you have some columns and values extracted from the Incident table, a built-in table of ServiceNow. However, you can use any table on ServiceNow, even a new one.
Issue Definition |
Required |
Preferred |
Description |
Example |
Type |
YES |
The column from ServiceNow’s table to store the information for the Type of ticket |
“category“ |
|
Default type |
YES |
|
The value for the type of ticket (Bug, Task, User Story, etc) |
“Network“ |
State |
YES |
The column from ServiceNow’s table to store the information for the State of the ticket. You need to provide a default value at ServiceNow side |
“state” |
|
Open Issue State |
YES |
|
The value/s in ServiceNow to identify a ticket as Open (can be chosen from the list of already available/used ones or we can add new value/s) |
“New”, “On Hold”, “In Progress” |
Closed Issue State |
YES |
|
The value/s in ServiceNow to identify a ticket as Closed (can be chosen from the list of already available/used ones or we can add new value/s) |
“Resolved”, “Closed” |
Rejected Issue State |
YES |
|
The value/s in ServiceNow to identify a ticket as Rejected (can be chosen from the list of already available/used ones or we can add new value/s) |
“Canceled” |
Summary |
YES |
String |
The column from ServiceNow’s table to store the information for the Summary of the ticket |
“short_description” |
Description |
YES |
The column from ServiceNow’s table where we want to store the information for the Description of the ticket |
“description” |
|
Priority |
YES |
The column from ServiceNow’s table where we want to store the information for the Priority of the ticket |
“severity” |
|
Issue Weakness Priority |
YES |
|
The value in ServiceNow to identify the ticket’s priority (can be chosen from the list of already available/used one or we can add a new one) |
“1 - High” |
Labels |
NO |
String |
The column from ServiceNow’s table to store the information for the Labels of the ticket |
“subcategory” |
Default Issue Labels |
NO |
|
Define default labels for the issues created from IriusRisk. If a comma is introduced in a label, then, after refresh on settings, IriusRisk will split the label using each comma as a delimiter creating more than one label. Example: this,is,a,label will result in four labels: THIS , IS , A , LABEL |
“VPN” |
Comments |
NO |
The column from ServiceNow’s table to store the information for the Comments of the ticket. Note: If the user doesn’t map this field, then will still be able to create comments in IriusRisk but they won’t be synchronized with ServiceNow. |
“work_notes” |
By default, IriusRisk will use the field “sys_id” to map the issue ID.
It is worth considering that some fields in ServiceNow can be configured as read-only. In that case, if you map to one of them, IriusRisk won’t be able to set the field value.
The following ServiceNow fields are not allowed to be mapped:
-
“sys_id”
-
“sys_created_on”
-
“sys_created_by”
-
“sys_mod_count”
-
“sys_updated_by”
-
“sys_updated_on”
Best Practices
When mapping particular fields, we should consider their behaviour before deciding on implementation. We’ve compiled a list of recommended best practices for these fields:
State
For optimal results, this field should be mapped to a Choice List with a provided default value. When creating an issue, the default value for its state can then be automatically managed by ServiceNow. If State is mapped to a string, the value will need to be manually raised in ServiceNow once the ticket is raised.
Description
This field should be mapped to an HTML field type.
IriusRisk produces the description content rendered in a formatted, clear and structured way in the Issue Tracker client. In order to accomplish this, it uses HTML tags.
Priority
For optimal results, this field should be mapped to a Choice List with a provided default value.
The priority of a ticket depends on whether the ticket was created from a countermeasure or a weakness:
-
Countermeasure: IriusRisk calculates the priority by taking the list of priorities available from a choice list, ordering it and comparing the position of each priority from the list against the risk assessed from the countermeasure. If IriusRisk doesn’t find a list of priorities, it will assign a value from the following list depending on the assessed risk:
- "N/A"
- "Very Low"
- "Low"
- "Medium"
- "High"
- "Critical" -
Weakness: The priority will be taken from the value introduced in the Issue Weakness Priority mapping field.
Comments
When mapping comments with ServiceNow, we recommend mapping to a Journal field type. In this case, all the comments added to a countermeasure with a related issue will be propagated to ServiceNow, displayed by IriusRisk, however they won’t be stored in IriusRisk’s database.
If you add comments to a countermeasure first and then create an issue from that countermeasure in ServiceNow, all the previous comments will be propagated to ServiceNow
Creating ServiceNow Tickets in IriusRisk
Now that we have ServiceNow mapped and integrated, we can test the creation of issues in IriusRisk. As we’ve defined the ServiceNow settings at a global level, we can begin to create ServiceNow tickets for our products.
To begin, head over to the Countermeasures tab, and select Create New Issue for a countermeasure:
You can, of course, also create issues on batch (as with any IriusRisk issue tracker integration), or for the Weakness, found in the Threat tab:
Once you’ve created a ServiceNow issue, you will notice that a unique Issue ID will appear in the IriusRisk 'Issue ID' column:
You can easily pivot from IriusRisk to the ServiceNow ticket by selecting the Issue ID hyperlink, as shown below:
Comments
0 comments
Please sign in to leave a comment.