Setup Assistant reference

The Setup Assistant walks you through the steps you need to perform to set up the Security Incident Response base system. This section provides additional information on the complicated steps for which you may require more explanation.

Roles

The Setup Assistant requires the sn_secops_setup.admin role for full access to setup assistant configuration. Users with the sn_si.admin role automatically inherit this role.

The following access levels are enforced through the sn_secops_setup.admin role:

• Setup Assistant SIR Admin - Access to Security Incident Response setup configuration.
• Setup Assistant VR Admin - Access to Vulnerability Response setup configuration.
• Setup Assistant VR/SIR Admin - Access to combined Vulnerability Response and Security Incident Response setup configuration.
• Setup Assistant System Admin - Access to system-level setup assistant operations.

Setup status

The Setup Status (sn_secops_setup_status) table tracks the completion state of each setup step. The key and complete fields on this table are enforced as strict read-only and can't be modified through client-side mechanisms.

Create a Security Incident Response process definition

You can create a process definition to define the way security incidents transition from one state to the next. Process definitions give service desks and end users help tracking the problem throughout its life cycle.

Before you begin

Role required: sn_si.admin

Procedure

1. Navigate to All > Security Incident > Administration > Process Definition.

2. Click New.

3. Fill in the fields, as appropriate.

   Field	Description
   Name	Name of the record which describes the process encoded in the script include file. The name is displayed as a choice in the Process Definition Selector list.
   Script include	The name (including the sn_si. prefix) of the script include containing the definition of the process. The script must be in the Security Incident (sn_si) application scope. See Create a custom Security Incident Response process definition script include for more information. If this field does not contain a valid script include name, the default ProcessDefinition_NIST_Stateful definition is used.
   Description	Helpful information about the script include.
   Order	Determines the position in the process definition list.
   Active	When checked, it makes this process definition selectable from the Process Definition Selector page.

4. Click Submit.

Related topics

Security Incident Response Process Selection

Understanding Security Incident Response process definition

Understanding Security Incident Response process definition

Security Incident Response Process Definition replaces state flows and provides end users and service desks with the status of a problem. A process definition helps track the problem through its life cycle. Security Incident Response is a Service Management (SM) application, which has its own set of states. Invalid states are reported as part of Process Selection.

Security Incident Response Process Definition

The default process definition (NIST Stateful) defines the following incident states:

Note: Available states vary based on the current state of the incident.

Security Incident task process definitions

The following process definitions are used for security incident tasks.

NIST supports the following two models:

• NIST Stateful

  This process definition enables analysts to move from one state to another in a sequential order without skipping any step. For example, if the Analyst starts with the Draft state, then the sequential order of this process definition is Draft>Analysis>Contain>Eradicate>Recover. So, the NIST Stateful process definition is unidirectional and enables analysts only to progress only to the forward states.

  Here’s another example, if the Analyst starts with the Analysis state, then the sequential order of this process definition is Analysis>Contain>Eradicate>Recover.

• NIST Open

  This process definition enables analysts to move from one state to another, either forward or backward. For example, if the Analyst starts with the Analysis state, then the order of the process definition can either be Analysis>Contain>Eradicate>Recover or Analysis>Draft. So, the NIST Open process definition is bidirectional and enables analysts to move to the forward or backward states depending on their requirements.

Security Incident Response Process Selection

Security Incident Response Process Selection lists processes with invalid states for security incidents and response tasks.

An administrator can correct the incident or task to valid states either manually or by using a script. An empty related list (no incidents; no tasks) indicates that every active task is in a valid state. Available states vary based on the current state of the incident. For more information, see Correct an invalid security incident or task state with process definition.

Select a Security Incident Response process definition

You can select the process definition to use for the appropriate states for your company security incidents and response tasks.

Before you begin

Role required: admin and sn_si.admin

About this task

Procedure

1. Navigate to All > Security Incident Response > Administration > Process Selection.

2. Select the search icon to list the available process definitions.

1. Select a process definition.

2. Select Update.

Create a custom Security Incident Response process definition script include

Create a custom Process Definition script for the appropriate states for your company security incidents and response tasks.

Before you begin

Role required: sn_si.admin

About this task

The sn_si.ProcessDefinition main script include controls process definitions. Process Definition determines which definition is in use (using Process Selection). It calls the appropriate script include file to determine the initial states and transitions for both security incidents and response tasks.

Procedure

1. Navigate to All > System Definition > Script Includes.

2. Select New.

3. Fill in the fields, as appropriate.

1. Select Submit.

Related topics

Process Definition script include

Process Definition script include

The Process Definition script include provides methods for defining a process definition.

Implement the constants, attributes, arrays, and method calls described here to customize a process definition script include.

Where to use

Use this script include to create a process definition.

Script include body

The script include body is composed of three sections:

• Constants: Initial state definitions
• Security Incident and Response Task: Process definition arrays
• Method calls: Retrieving information

Constants

Constants are used to define the initial states of security incidents and response tasks.

The use of constants is optional but encouraged for readability. For example:

INITIAL_INCIDENT_STATE: 10,
INITIAL_TASK_STATE: 1,

Which are later used by the following methods:

getInitialIncidentState: function() {
return this.INITIAL_INCIDENT_STATE;
},
getInitialTaskState: function() {
return this.INITIAL_TASK_STATE;
},

The next set of constants defines the states for both security incidents and response tasks.

Each array also contains the definition of which states are available when the incident or task is in a specific state.

For example:

TASK_STATES: [{state:1, label:"Draft", choice:[1, 10]},
 {state:10, label:"Ready", choice:[10, 16]},
 {state:16, label:"Assigned", choice:[16, 18]},
 {state:18, label:"Work in Progress", choice:[18, 3]},
 {state:3, label:"Close Complete", choice:[]},
 {state:7, label:"Cancelled", choice:[]},
 ],

The example is an array of objects. Each object defines a state and possible transition states.

The order of the state's object determines the desired order for the flow.

When the task is in the 'Draft' state (value 1), possible states are: 1 (Draft, which is no change) and 10 (Ready, the next step in the process).

There is no limit on the number of transitions out of a state. The 'Close Complete' and 'Canceled' state are final states and therefore have no possible state transitions.

The order of the attributes in the object is not important. If it makes the definition clearer, put the label first.

Attributes

Required attributes in a state definition object are:

• state: numerical value of the state
• label: human readable text associated with the state
• choice: an array of state values the state can transition to (determines the content of the state dropdown)

Optional attributes are:

• mandatory: list of field IDs that become mandatory in this state
• readonly: list of field IDs that become read-only in this state
• visible: list of field IDs that become visible in this state
• notmandatory: list of field IDs that become non-mandatory in this state
• notvisible: list of field IDs that would no longer be visible in this state

Note:

If optional attributes are used, it is the author's responsibility to ensure that fields are made visible/invisible, mandatory/non-mandatory, visible/hidden, or readonly appropriately between states.

For example, hiding a field in one state does not make it visible in another state later unless the 'visible' attribute is used.

Process flow definition arrays

To define the information displayed in the process flow formatter (the bar at the top of the Security Incident and Response task forms), the system requires information on what to display for each state.

For example:

TASK_PF: [{label:"Draft", condition:"state=1^EQ", description:"<p>Security Incident Response Task is in draft</p>"},
 {label:"Ready", condition:"state=10^EQ", description:"<p>Security Incident Response Task is ready to be assigned</p>"},
 {label:"Assigned", condition:"state=16^EQ", description:"<p>Security Incident Response Task is assigned</p>"},
 {label:"Work in Progress", condition:"state=18^EQ", description:"<p>Work has started on this Security Incident Response Task</p>"},
 {label:"Closed", condition:"state=3^ORstate=4^ORstate=7^EQ", description:"<p>Security Incident Response Task is complete</p>"},
],

The TASK_PF array is a collection of labels, conditions, and descriptions used to determine the text displayed in the process formatter bar (including order and activity).

In the example, the text 'Ready' is the second item displayed. It is highlighted when the task satisfied the condition 'state=10^EQ'.

When the pointer hovers over the text, the description 'Security Incident Response Task is ready to be assigned' is displayed.

Note:

States can be combined to a single formatter state.

In the example, both the 'Close Complete' and the 'Canceled' states show up as 'Closed' in the top bar.

Method calls

The following methods must be present in the script include as they are used by sn_si.ProcessDefinition:

The next set of methods are called whenever an incident or a task is updated and allows actions to be taken on specific change transitions.

The same actions performed by these two methods can be accomplished using a business rule. By defining them in the script include, switching process definitions is made easier.

Correct an invalid security incident or task state with process definition

An administrator can correct the security incident or task to valid states, either manually or using a script. Available states vary based on the current state of the incident.

Before you begin

Role required: admin

About this task

After you have switched process definitions, the new definition may not support some of the old states. To correct the orphan incident or task states, you can change your process definition, edit your script include, or manually open each incident or task to update the state. Generally, updating the state (which can be done in bulk) is the easiest solution.

To change states in bulk, do the following:

Procedure

1. Navigate to All > Security Incident > Administration > Process Selection.

2. Highlight the State field for the incidents or tasks you want to change.

3. Double-click the State field in the first record, select the new State, and select the green check mark (

1. Select Update.

Create a security incident group

Set up a security incident group and assign the appropriate roles and users to the group.

Before you begin

Roles required:

• If you have the user_admin role, you can create security incident assignment groups.
• If you have the sn_si.admin role, you can create and edit security incident assignment groups.

About this task

Users in a group inherit the roles of the group, so you do not have to assign roles to each user separately.

It is a good practice to create as many groups as needed in your organization. It is also a good practice to create one group for administrators and assign the admin role to this group only.

Procedure

1. Navigate to All > User Administration > Groups or Security Incident > Setup > Groups.

2. Select New.

3. On the form, fill in the fields.

   Note:

   For more information, see Create a user group.

4. Make sure that you select the security incident type for this group.

   1. If the Type field is not visible, configure the form to add it.

   2. Select the lock icon beside the Type field.

   3. Select the reference lookup icon (

4.  Search for and select the **security incident** type.

1. Select and hold (or right-click) the form header and select Save.

2. In the Roles related list, add the roles that each member of this group receives.

   For example, if you're making a group for Security Incident Response team members, add sn_si.analyst. If you're making a group for Security Incident Response administrators, add sn_si.admin.

3. In the Group Members related list, add users to this group.

4. Select Update.

Create a security incident calculator group

Security incident calculator groups are used to group calculators.

Before you begin

Role required: sn_si.admin

Procedure

1. Navigate to All > Security Incident > Setup > Security Incident Calculator Groups.

2. Click New.

3. Fill in the fields on the form, as appropriate.

   Field	Description
   Name	The name of the security incident calculator.
   Application	The application that contains this record.
   Order	The order in which the security incident calculator is run. A calculator with an order entry of 100 runs before a calculator with an order entry of 200.
   Description	A description of this calculator group.
   Created by	Enter the name of the user who created

4. Click Submit.

Create a security incident calculator

Security incident calculators allow you to calculate the severity of a security incident based on pre-defined formulas. You can define your own security incident calculators, as needed.

Before you begin

Role required: sn_si.admin

Procedure

1. Navigate to All > Security Incident > Setup > Security Incident Calculator Groups.

2. Click the name of the group for which you want to create a calculator, or you can create a calculator group.

3. Click New.

4. Fill in the fields on the form, as appropriate.

1. Right-click the form header and select Save.

   The Conditions and Values to Apply tabs appear.

2. Fill in the fields in the Conditions tab, as appropriate.

1. Click the Values to Apply tab and fill in the fields on the form, as appropriate.

   You have the choice of creating a script for defining the values to apply to the calculation or defining a template based on fields in the selected table.

1. When you have completed all entries, click Submit.

Understanding security incident calculators

Security incident calculators are used to update record values when pre-defined conditions are met. The calculators are grouped based on the criteria used to determine how the records are updated.

The Security Incident Response base system includes the following security incident calculator groups and calculators. Within each group, the first calculator that matches the conditions is run.

Severity calculators

When you create a security incident, the Risk score, Business Impact, and Priority fields contain default values. When you save the incident, a business rule automatically validates the information in the security incident against conditions defined in each of your active severity calculators. They are validated one security calculator at a time, in the order defined by the Order field in each calculator. If information in the security incident matches the conditions defined in one of the calculators, the severity field values are updated accordingly to the rules set up in the calculator.

For example, assume that you create a security incident for an affected CI, and the CI is highly critical. When the security incident is saved, the CI information is compared to the conditions defined in the severity calculators. When the security incident is validated against the Critical service affected severity calculator, the severity fields are automatically updated, and a message appears at the top of the security incident.

You can use these severity calculators as is or you can edit them to more closely meet the needs of your business. For example, if you want to identify web and email threats that are specific to the Finance business unit, you can change the conditions of the Multi Attack Vectors calculator:

• [Attack Vector] [contains] [Web]
• [Attack Vector] [contains] [Email]
• [Business Unit] [contains] [Finance]

You can also update the severity values in an existing security incident at any time by opening the record and clicking the Calculate Severity related link.

Security incident risk score calculators

The Set priority with category and services and Set priority with observables calculators are used to calculate a risk score for a security incident.

User criticality calculators

The two calculators in the User criticality group (Get user criticality and Get user group criticality) provide examples of how you can drive criticality based on criteria defined in a user record or based on the group to which a user belongs.

They can be edited as needed, or new user criticality calculators can be created.

The Get user criticality calculator causes user business criticality to change to 1 - Critical when the Department field is changed to Finance.

The Get user group criticality calculator causes user business criticality to change to 1 - Critical when the user is added to the Database group.

Note: Get user group criticality is an example of a calculator that runs on data in a related list. If you want to add more groups to initiate a criticality change, add a comma-separated list of group sys_ids in the first line of the script. Example: var CRITICAL_GROUPS = [group1_sys_id, group2_sys_id, group3_sys_id].

Security incident risk score calculations

The risk score is calculated as an arithmetic mean that represents the risk based on the priority of a security incident, the type of security incident (Denial of Service, Spear Phishing, or Malicious code activity), and the number of sources that triggered a failed reputation score on an indicator.

The risk score aids in prioritizing security incident work for the analysts.

Important: If you want to use the new Risk Score Calculator, refer to Define the new Risk Score Calculator Rules.

The Set priority with category and services and Set priority with observables security incident calculators are used to calculate a risk score for a security incident. Additionally, the following business rules trigger automatic calculation of risk scores:

• Calculate Severity
• Update risk score
• Update SI risk score

Note: The risk calculator available in the base system depends on your Security Operations pricing tier.

When you look at a list of security incidents in the base system, notice the Risk score column.

The risk score is calculated using weights defined in Risk score configuration.

For example, if a security incident has a Business impact set to 2-High and a Priority set to 3-Moderate, the respective weights in the Risk Score Weights table are looked up and calculated thus:

Security Incident Business Impact with a value of 2 = a weight of 60.

Security Incident Priority with a value of 3 = a weight of 40.

(60 + 40)/2 = a risk score of 50.

The position of the security incident in the security incident list is then re-ordered based on its updated risk score.

If, in the example above, the Business impact or Priority of the security incident are changed, the risk score is recalculated, and the changes are reflected in the work notes.

The work notes are updated when the following fields are changed (causing the risk score to be updated):

• Business impact on the Security Incident form
• Priority on the Security Incident form
• Severity on the Security Incident form (hidden by default)
• Business impact on the Affected Users related list
• Business impact on the Affected Services related list
• Business impact on vulnerabilities on the Vulnerable items related list

Additionally, the work notes are updated in the following situations:

• When an association between affected users and a security incident is created or modified
• When an association between affected services and a security incident is created or modified
• When an association between vulnerable items and a security incident is created or modified

Work notes are also updated whenever Update All Risk Scores and Clear All Risk Scores on the Risk Score Weights form are clicked.

Maintain risk score weights

The risk score weights used to calculate risk scores in security incidents can be removed or updated on an individual basis. They can also be removed or updated for all security incidents. The ability to remove them from security incidents is useful when changing weight values.

Before you begin

Role required: sn_sec_cmn.admin

Note: Users with the sn_si.read role can view the risk score configuration in Security Incident Response.

Procedure

1. Navigate to All > Security Incident > Setup > Risk Score configuration.

   Note: Users with the sn_si.read role can view the risk score configuration by navigating to Security Incident > Alerts & Events > Risk Score Configuration.

2. To add a new risk score weight, click New and enter information in the fields.

   Field	Description
   Type	Select the type of risk score you are defining.
   Value	Specify the value associated with the selected type. If multiple values are available for the type, you may want to define multiple risk score weight records. Example: Security Incident Priority with a value of 1, Security Incident Priority with a value of 2, and so forth.
   Weight	The weight associated with the selected type/value pair. Valid entries are between 0 through 100, with 0 being the lowest weight and 100 the highest.

3. Click Submit.

4. Perform any of these steps, as needed.

   • To clear a risk score weight record, open it from the list and click Delete.
   • To clear all risk score weight records, click Clear All Risk Scores.
   • To update all risk score weight records, click Update All Risk Scores.

Create a Security Incident Response SLA

You can define a Service Level Agreement (SLA) for Security Incident Response.

Before you begin

Role required: sn_si.admin

Procedure

1. Navigate to All > Security Incident > Setup > SLAs.

2. Click New.

   For field descriptions and detailed instructions, see Create an SLA definition.

Repair security incident SLAs

You can repair SLA records to ensure that SLA timing and duration information is accurate.

Before you begin

Role required: sn_si.basic

Procedure

1. If it is not already open, open the security incident you want to repair SLAs for.

2. Select the form header context menu and select Repair SLAs:

3. Select OK in the Warning confirmation box.

   For more information, see Repair SLAs.

Create a Security Incident Response runbook

A runbook is an association between a published knowledge article and a specific task. While you are performing the task, a knowledge article in the runbook automatically opens, providing information pertinent to the task.

Before you begin

There must be existing knowledge articles in the Security Incident Response Runbook knowledge base. When you create a security incident knowledge article, be sure to select Security Incident Response Runbook in the Knowledge base field. After you publish the article, you can select the Create Runbook button.

Role required: sn_si.knowledge_admin

About this task

You can use runbooks during the security incident or response task creation processes, or you can associate the knowledge base articles in a runbook with tasks in the playbook.

Procedure

1. Navigate to All > Security Incident > Manual Runbook > Create New Runbook.

2. Fill in the fields, as appropriate.

1. Right-click the form header and select Save.

   The Knowledge Article Details tab and a series of buttons appear.

2. To view the details of the runbook, click the Knowledge Base Details tab.

3. To see the knowledge article as it would appear to the user, click View Article.

4. To edit the details of the knowledge article, click Edit Article.

Create rules to validate user-reported phishing attacks

When your employees receive emails that appear to be phishing attacks, they can report them to you using a phishing email address. The suspicious email is validated using rules defined by your organization.

Before you begin

Before email matching rules can be used to identify potential phishing attacks, define an email address to which emails forwarded from your employees would be sent for processing. You have the following options for defining this email address (assuming your company email domain is acme.com):

• Define an email address such as acme+phishing@service-now.com. The +phishing tag is supported by SMTP to enable filtering and your instance can receive emails sent to it.
• Define an email address, such as phishing@acme.com (your Exchange mailbox), which in turn forwards it to acme+phishing@service-now.com (your instance mailbox defined through a mail forwarding rule).

Role required: sn_sec_cmn.write

About this task

When an employee encounters a suspicious email, they should forward it as an attachment to your phishing email address. If the attached email matches a rule defining a threat, a security incident is created.

Procedure

1. Navigate to All > Security Operations > Email Processing > User Reported Phishing.

2. Select New.

3. Fill in the fields, as needed.

   Field	Description
   Name	Name for this email matching rule. For example, User Reported Phishing.
   Conditions	Use the condition builder to validate whether an email sent to your company phishing email address is a phishing attack. See the following example.

4. Select Submit.

Example

This example shows a matching rule for handling user-reported phishing.