In this article you will find:

  1. Technical information
  2. How to define ServiceNow connector in Vulcan
  3. How to manually open ServiceNow incident via Vulcan
  4. How to automate ServiceNow incidents
  5. How to fetch data from ServiceNow to Vulcan
  6. Ticket lifecycle management

1. Technical information

ServiceNow connector is being used for both creating incidents (automatically or manually) and for pulling data from CMDB. For that reason, the configuration of the connector requires several parameters. The is data being pulled from the following ServiceNow tables:

Username and password are used for pulling assets. Assets are taken from the following tables: cmdb_ci_computer, cmdb_ci_vm_instance.
Client Id and Client Secret are used to creating incidents.
Users are being pulled from the table sys_user.
Business units are being pulled from the table cmn_department.

2. Defining a connector

In the Connectors page, click on Add a Connector.

Click on ServiceNow connector.


Fill in all the relevant fields:

Instance Name - Name of the hosted ServiceNow instance.
For example: dev123456

Select Authentication method - Basic Auth/OAuth 2.0


Username (Basic and OAuth 2.0) - Username which is used o login to ServiceNow instance. User must have admin permission when using Basic Auth, and security_admin when using OAuth 2.0.
Make sure the user name is indicative to Vulcan's platform.
In order to assign role to user, follow the next steps:

  1. In your ServiceNow instance, navigate to User Administration > Users, then open a user record.
  2. In the Roles related list, click Edit.
  3. In the Collection list, select the desired roles, and then click Add.
  4. Click Save.

Password (Basic and OAuth 2.0) - Password of same user which is used to login to ServiceNow instance

Client Id (OAuth 2.0 only) - Key in order to communicate with ServiceNow API

Client Secret (OAuth 2.0 only) - Key in order to communicate with ServiceNow API

Collect Users - Will allow assigning a vulnerability to a ServiceNow user entity through Vulcan.
Users are being pulled from the table sys_user.

Collect Assets - Will collect computer assets from ServiceNow, which will be validated against the scanner's data. This will allow finding unscanned assets that are configured in ServiceNow but not in the scanner.
Assets are taken from the following tables: cmdb_ci_computer, cmdb_ci_vm_instance.

When enabling the option to collect assets you will also have the ability to choose if there are assets from specific classes which you don't want to display in Vulcan. Click on Choose CMDB_CI table values to pull the available values which you can filter out.

You can select exactly which assets you want to display in Vulcan. The available values are only the ones who are relevant to your ServiceNow account. Note that by default Vulcan's ServiceNow connector is pulling all the assets.
Click Save. 

Click on Create. 

  • You can see the connector’s progress in the Logs tab:

3. Manually opening a ServiceNow Incident

  • From a specific vulnerability, you can choose to Take Action, and open a ServiceNow ticket:

  • For that ticket you can choose to alter the specific ServiceNow fields as you wish (including which assets / solution to include in that ticket):

Connector pulls all categories, subcategories and fields within your ServiceNow instance.

4. Manually opening a ServiceNow Problem and Problem Tasks

Another type of entity in you can create via Vulcan is Problem and Problem Task.
Problem will contain the vulnerability details (similar to an incident), only for each vulnerable asset a Problem Tasks will be created with the asset name as a "Configuration Item" (if cannot find a Configuration Item ->  the asset name will be under the short description attribute). Problem tasks are related to their parent problem. Read more about problem life cycle management.

In order to create Problem and Problem Tasks follow the instructions: 

  • From a specific vulnerability, you can choose to Take Action.
  • Choose Problem
  • Fill all relevant fields to create the Problem
  • Scroll down in order to fill relevant fields for creating Problem Tasks
  • Click Open Ticket

4. Automating ServiceNow incidents

ServiceNow incidents can be opened up automatically using Vulcan.

Navigate to the Automation page, click on Create new Playbook.


Name your Playbook.

Choose your Playbook’s trigger (Vulnerability to fix)

  • Vulnerability from source – The connector from which we pull assets. For example: Vulnerabilities from source AWS.
  • Vulnerability where – The rule which the playbook will be attached by. For example: Vulnerability where CVSS Score is greater than 7.
  • On assets where – The asset’s property you wish to be automated. For example: On assets where OS is Windows.
  • In this example, the vulnerability that will be fixed is any vulnerability with CVSS score higher than 7, which was found on assets with Windows OS, and that was discovered by AWS connector.

 Choose Open ServiceNow ticket at Remediation actions

Fill the fields on Open ServiceNow ticket:
Assignee - The person that will be assigned to remediating the vulnerability.
Category - The incidents will be categorized as the selected category.
Subcategory - The incident will be categorized as the selected subcategory.
Playbooks note (optional) - Additional information to be included in the incident.

Click on Save

That’s it. From now on, a ticket will be generated automatically by the parameters you’ve set. You can create as many playbooks as you want and define different rules to assign tickets to different teams.

5. Getting ServiceNow Data

This is an example of a vulnerability that has a ServiceNow incident attached to it. You can see it in the right pane under: ‘Open Tickets’.

The activity log for the vulnerability will show any changes in the ticket:

  • To locate assets coming from ServiceNow, you can filter ‘ServiceNow’ as a source in the appropriate filter:

6. Ticket lifecycle management

ServiceNow ticket states can be changed by Vulcan when vulnerabilities are fixed or no longer not needed. see more on this in ServiceNow ticket lifecycle.

Did this answer your question?