This is an overview of domain separation and Security Incident Response. Domain
separation enables you to separate data, processes, and administrative tasks into logical
groupings called domains. You can then control several aspects of this separation, including
which users can see and access data.
Overview
Domain separation is
supported in this application. Not all ServiceNow applications support domain
separation; some include limitations on the data and administrative settings that can be
domain separated. To learn more, see Application support for domain
separation.
In the Security Incident Response
application, domain separation enables Managed Service Providers (MSP) to standardize SOC
(Security Operations Center) and Security Incident Response (SIR) procedures across the
customer base they serve with lowered operational costs and a higher quality of service.
Separate customer workspaces for workflows, dashboards, reports, and so forth, ensures that
customer data is separated and never exposed to other clients.
Table 1. Domain separation support in Security Incident Response by version releases
Release |
Support level |
Notes |
Geneva, Helsinki |
No support |
Initiation of data-level domain separation |
Istanbul |
Data only |
|
Jakarta |
Level 2 (Data, Requestor, Fulfiller) |
New features: 3rd-party Integrations support with
Level 2 domain separation under a single instance of integration, including Threat
Intelligence integrations |
Kingston |
Level 2 (Data, Requestor, Fulfiller) |
New features: Sighting Search integration for SIR is
enabled with multiple instances, but all instances still live under a single
domain. Example: If there are two instances of a Splunk integration configured
(SplunkCLOUD and SplunkCORP), both are still leveraged for incident response
activities in a single domain, where the implementation was originally
configured. |
Madrid |
Level 2 (Data, Requestor, Fulfiller) |
New features: All integrations can now reside across
multiple domains. In the above example, SplunkCloud can be domain1 and SplunkCORP
domain2. |
Domain separation for the Security Incident Response application
covers the following product functionality:
- Security alerts are directed to the appropriate domain of the user whose ID/
credential/ scope generates the incident and is registered as a Security Incident.
- Alerts generate “observables,”which represent stateful properties or measurable
events.
- Observables extracted from the alert are stored in the domain of the security
incident.
- Security workflows in the domain of the security incident are used to orchestrate the
response.
- Integrations are configured in the domain of the security incident for response
automation.
- Capabilities are configured in the domain of the security incident for response
automation. These capabilities (as of the Kingston release) include:
- Threat Lookup
- Enrich Observable
- Enrich Configuration item
- Get Running Process
- Get Network Statistics
- Block Request
- Isolate Host
- Sighting Search
- Email Search and Delete
- Publish to Watchlist
- Results from Response Automation (such as Threat Lookup or Sighting Search) are stored
in the domain of the security incident.
- Other security incidents are cross-referenced in the same domain of the security
incident based on a shared set of observables.
- Other users are cross-referenced in the domain of the security incident.
- Configuration Items are cross-referenced in the same domain as the security
incident.
- Manual response tasks are added to the domain of the security incident.
- Knowledge base articles and run books are referenced in the domain of the security
incident.
- Security Incident Response metrics pertinent to incidents in the domain are displayed
on dashboards as well as in reporting.
Note: In the preceding cases, the overarching principles of visibility in separated domains
in the NOW Platform apply. As always, an incident in the parent domain can reference
artifacts in the child domain, but not the other way around.
How domain separation works in Security Incident Response
The Security Incident Response
application manages the life cycle of a security incident end to end. The following use
cases are domain-separation aware:
- Ingestion of events and alerts to create security incidents for
the analyst in the customer SOC or the MSP to respond:
- Email parsers (platform based, user-reported phishing, custom)
- De-duplication events/alerts prior to incident creation
- Auto extraction of observables
- Applications in third-party SIEM store
- Enrichment of artifacts involved in the incidents (IP, URLs,
domains, file hashes):
- Asset enrichment (CMDB)
- Users (Platform)
- Automation: Observable enrichment (Ex: WhoIs)
- Investigate the incidents with the help of the artifacts and
their reputation or association with known threats
- Orchestrate: Playbooks and knowledge base articles
- Automation: Threat Lookup (Ex: VirusTotal), Sighting Search (Ex: Splunk), Get
Running Processes (Ex: Carbon Black)
- Eradicate the threat-related artifacts involved in the incident
based on the investigation performed
- Orchestrate: Playbooks and knowledge base articles
- Automation: Email search and delete (Ex: Microsoft Exchange), Block IP (Ex: Palo
Alto Firewall)
- Measure the efficiency or Incident response operations
- Performance Analytics Dashboards: Productivity and incident trends
- Reconstruction of incident investigation steps from work notes
- Post-incident review
Domain separation setup
Setting up domain separation for Security Incident Response does not
require any additional steps. All Security Incident Response tables acquire
the Domain column after the instance is domain separated.
Domain separated data
Data can be domain separated, which means:
- Security incidents in one domain cannot be viewed from other domains.
- Observables extracted from the security incident are placed in the same domain and
cannot be viewed from other domains.
- Up to the Kingston release, configured third-party integrations exist in the global
domain and are accessible to all other domains in the instance.
- In the Madrid release, third-party integrations can be configured and activated on a
per-domain basis. This means that the integration activated and configured in one domain
cannot be leveraged in another domain.
- Automations that run on the observables using third-party integrations (for Threat
Investigation, Containment, or Eradication), place their results in the domain of the
security incident and the results cannot be viewed from another domain.
- Orchestration workflows created in one domain are not visible in another domain.
- Capabilities (as delineated in the preeding capabilities function list) that are
invoked stay generic across domains with domain-specific implementation of the
capability being called. For example, a Sighting Search on an IP can invoke a Splunk
implementation in one domain and a QRadar implementation in another.
Configuration
All aspects of product configuration are self-contained in a domain-separated environment.
Setup can be tailored for individual domains.
Note: Business logic and the processes in #2-5
below can be administered within the tenant domain.
The following tasks must be configured:
- System Administration
- Assign roles to users and groups of users: User roles installed with Security
Incident Response
- Install one or more third-party integration plugins to work with Security Incident Response: Security Incident Response integrations
- Security Incident Response Administration
- Security incident email settings
- Set the email parsing inbox: Security Operations email parsing
- Set up email parsers for alert ingestion: Create email parsers in Security Operations
- Set up email matching rules for user-reported phishing: Create rules to validate user-reported phishing attacks
- Set up email inbound actions:
Inbound email actions
- Security incident playbook settings
- Capability configurations
- Select and configure integrations to work with these capabilities:
How tenant domains manage their own application data
- Tenant domain owners create their own email parsing rules for ingesting security
incidents.
- Tenant domain owners can configure specific integrations exclusively for use within
the domain.
- Tenant domain owners can create their own incident response workflows.
- Tenant domain owners can create their own incident categories, incident response
knowledge base articles and runbooks to be associated with incident response
workflows.
- Tenant domain users create and close their own security incidents.
Business logic and processes that can be domain separated by instance owner
- Security Incident Response users
and groups
- Security Incident Response
integrations (starting with the Madrid release)
- Email parsing rules for incident creation
- Business rules to consolidate multiple events or alerts into a security incident
- Workflows for incident response orchestration
- Security incident risk score calculators
- Security incident escalation path
- Security incident SLAs
- Security incident process definitions
- Security incident post-incident review processes