Why does the ServiceNow connector require both User password and API token when connecting via oAuth2.0?
This is a common question; the answer is that this is the practice Servicenow recommends. See read the ServiceNow document for more information.
How does the Vulcan-ServiceNow ticket life-cycle work?
Vulcan integration with ServiceNow tickets such as Incidents or Problems helps users track remediation progress for vulnerabilities. Vulcan creates tickets using take-action or automation actions. changes to the ticket are reflected in Vulcan.
When the vulnerability is no longer detected by the vulnerability scanner, Vulcan will automatically close the campaign and associated tickets, Alternatively
users can manually close the campaign and choose to close associated tickets.
ServiceNow incidents are opened in the "New" state, when closed by Vulcan the state will change to "Closed".
ServiceNow problems have problem tasks related to them, Vulcan will change only the state of the problem tasks to "Closed".
Service now can be configured to automatically close the problem when all problem tasks are completed.
Users can also manually close the campaign and choose to close associated problem tasks.
For Vulcan to close problem tasks the following configuration must be set in ServiceNow:
Assignee must be set on the problem task
Remove read-only from problem task state field
Disable problem task workflow
Choice list -> table [Problem task] -> element[state] -> label [Closed] - must exist
The event flow graph below describes the lifecycle of a problem ticket created with Vulcan.
Notes:
Tenable is used as an example of Vulnerability scanner but this flow will work with any vulnerability scanner
The flow for incidents is similar, an incident will be created instead of a problem, and on a closed event the incident will be closed (instead of the problem task).
How is a ticket opened?
Following the previous section example, we will walk through the automated ticket opening via ServiceNow.
After choosing ServiceNow as the remediation action, we will choose how to open the tickets.
To demonstrate the most common use case, we will choose to separate each ticket by unique vulnerability, update the ticket with subsequent discoveries, and open the ticket on the Problem table.
This way, we ensure that its unique vulnerability will group every affected asset into a Problem ticket, and each affected asset will be opened as a problem task ticket.
To demonstrate that, we will take this vulnerability for example, with the two affected assets:
And see that the automation created Problem task for the unique vulnerability (Microsoft Windows Security Update for May 2020) and problem tasks for the affected assets (SCCMSRV2016A, SCCMPLAY3WIN10)
Problem ticket for the unique vulnerability jas created:
And problem task for the affected assets:
How does Separation by ticket work in ServiceNow?
When creating a ticket on Vulcan to ServiceNow, there are three possible options for the ticket creation method:
Option number 1 - Separate tickets per unique vulnerability
This is the first of the three options:
For this example, we will use the following Vulnerability:
Unique Vulnerability name - Debian Security Update for e2fsprogs (DLA 1935-1)
Number of vulnerability instances - 4
With this ticket creation option, Vulcan will create a Problem ticket for the unique vulnerability with the name: Debian Security Update for e2fsprogs (DLA 1935-1), and will create 4 Problem task tickets, for the 4 vulnerability instances, with the name of the affected hosts:
Problem:
Problem Tasks:
Option number 2 - Separate tickets per asset
This is the second option of the three:
For this example, we will use the following Asset:
Asset name: Prod1-AppSrv-51001
Number of related vulnerabilities: 159
With this ticket creation option, Vulcan will create a Problem ticket for the Asset and will create 159 Problem task tickets, for the 159 related vulnerabilities to this asset:
Problem:
Problem Tasks will be a list of 159 related problem tasks.
Option number 3 - Separate tickets per asset
This is the third option of the three:
With this option, all the findings will be aggregated into 1 problem ticket, as an attached CSV.
How is a ticket closed?
After the tickets are created, and the automation is in place, the campaign will remain up to date based on the daily data ingestion from the scanners. Based on the ingested data, the campaign will update the tickets by the following steps:
Affected assets that were vulnerable are now ingested as fixed.
The status of the affected asset is changing into "Fixed" in Vulcan.
The affected asset changed to "Fixed" in the open campaign.
The Problem task of the affected asset is automatically moving into "Fixed.
Once all the affected assets is moved into fixed, and the campaign is completely remediated, the complete campaign will close the move to the "Closed" tab.
Why is the "assignment group" dropdown empty when creating a ServiceNow ticket?
When taking action to open the ServiceNow ticket, Vulcan will pull the relevant fields from the ServiceNow table.
Before creating your first ticket, please make sure the intended table (Problem/incident table) contains at least one existing ticket in the table.
If the ServiceNow table has no tickets in it, Vulcan will not be able to fetch the list of assignment groups.
To handle that, make sure to have at least one existing ticket in the table, then go into Vulcan and try to create the ticket again.
Where can I see statistics about ServiceNow tickets and campaigns?
You can see stats on tickets created in ServiceNow on the Campaign Tracking Report in Vulcan Analytics (Reports).
Go to Reports/Analytics.
Enter the Campaign Tracking Report.
Check the widgets that provide comprehensive stats on the campaign and tickets created through the Vulcan Platform.
Comparison between ServiceNow to JIRA capabilities
Feature | ServiceNow – Problem and Problem task option (The workflow elaborated above) | ServiceNow – Incident table option | JIRA |
Ability to open a ticket for every unique vulnerability | Yes. The ticket can be opened in the Problem table. | Yes. The ticket can be opened in the Incident table. | Yes, the ticket will be opened as Task/Epic/or any other JIRA option. |
Ability to have the affected assets related to the ticket. | Yes. In the Problem table, the affected assets will be opened as Problem Task under the Problem ticket. | Yes. In the Incident table, the affected assets will be attached as CSV. | Yes. the affected assets will be attached as CSV. |
Ability to automatically close the ticket for each of the affected assets. | Yes. Each affected asset will be as a Problem Task. When the affected asset will be remediated, the problem task will automatically be closed. | No. The ticket will have an updated CSV for every update in the affected assets. But the ticket will be closed only when all the affected assets will be remediated. | No. The ticket will have updated CSV for every update in the affected assets. But the ticket will be closed only when all the affected assets will be remediated. |