Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.

Domain separation and Threat Intelligence

Log in to subscribe to topics and get notified when content changes.

Domain separation and Threat Intelligence

This is an overview of domain separation as it pertains to the Threat Intelligence module that is available as part of Security Incident Response. Domain separation allows 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

Support: Level 2

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 Threat Intelligence module (as part of the Security Incident Response application), domain separation enables Managed Service Providers (MSP) to create and manage the threat intelligence repository in the following ways:

  • Threat sources and Trusted Automated Exchange of Indicator Information (TAXII) profiles
  • Observables
  • Indicators of compromise
  • Threat attack modes / methods and case management across the customer base they serve with lowered operational costs and a higher quality of service

Having separate customer work spaces for workflows, dashboards, reports, and so on ensures that customer data is separated and never exposed to other clients.

Table 1. Domain separation support in Threat Intelligence by version release
Release Support level Notes
Geneva, Helsinki No support
Istanbul Data only Security incident observables are stored as fields in the IOC table (source IP, destination IP, malware hash, malware URL, referrer URL, other IOC) and are not domain separated individually
Jakarta Level 2 (Data, Requestor, Fulfiller) Security incident observables stored as a related list and are domain-separated individually
Kingston Level 2 (Data, Requestor, Fulfiller) Continued support of capabilities from Jakarta
London Level 2 (Data, Requestor, Fulfiller) Continued support of capabilities from Jakarta
Domain separation for the Threat Intelligence module (as part of the Security Incident Response application) covers the following product functionality:
  • Security incident observables are directed to the appropriate domain of the user whose ID/ Credential/ Scope generates the incident. The observables extracted from the incident are stored in the domain of the security incident.
  • Setting up of TAXII service profiles to download one or more TAXII collections that offer cyber-threat information feeds. The configuration is stored in the domain under which the profile is being set up.
  • Setting up the download of threat feeds into the IOC repository in the domain under which the configuration is being performed.
  • Creation of attack mode/methods in the domain of the threat intelligence source that provides the information automatically or the domain under which a new attack mode/method is being added manually by the user
  • Creation of cases for long-term investigation of incidents, observables, CIs, users, and indicators of compromise (IOC) associated with the case. The case is stored in the domain created by the user.
Note: In all the above 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 Threat Intelligence (as part of Security Incident Response)

Threat Intelligence is part of Security Incident Response in the Professional and Enterprise Tiers, but not with the Standard Tier. Therefore a separate plugin is needed. The Threat Intelligence module (as part of the Security Incident Response application) creates and manages the threat intelligence information associated with security incidents in an organization. The following use cases are domain-separation aware:

  • Creation of security incident observables at the time of incident creation
    • From email parsers (Platform-based, user-reported phishing, custom)
    • From applications in third-party Security Information and Event Management (SIEM) stores
    • Manually keyed in by the SOC analyst
  • Collection of observables from threat feed sources
    • Threat intelligence sources from TAXII collections
  • Manage security incident observables
    • Associate observables with related indicators
    • Associate observables with security incidents
    • Associate observables with child observables
    • Associate observable to threat feed source
    • Add security annotations to observables
  • Manage indicators of compromise
    • Associate indicators with related observables
    • Associate indicators with attack mode/method
    • Associate indicators with indicator types
    • Associate indicators to threat feed source
    • Add security annotations to indicators
  • Manage cases
    • Create new case (manually or from an incident)
    • Edit a new case to add details (choose case type and severity, add incidents, observables, configuration items, users, indicators)
    • Delete a case

Domain separation setup

Setting up domain separation for Threat Intelligence does not require any additional steps. All Threat Intelligence tables acquire the Domain column after the instance is domain separated.

Domain-separated data

Data can be domain separated, which means:

  • Security incident observables in one domain cannot be viewed from the scope of other domains.
  • Indicators of compromise in one domain cannot be viewed from the scope of other domains.
  • Attack modes/methods associated with one domain cannot be viewed from the scope of other domains.
  • TAXII service profiles associated with one domain cannot be viewed from the scope of other domains.
  • Threat intelligence sources associated with one domain cannot be viewed from the scope of other domains.
  • Cases associated with one domain cannot be viewed from the scope of other domains.
Threat Intelligence properties are set at the global level and are not, therefore, domain-separated. The settings include:
  • The domain name to retrieve additional information for IP addresses/URLs
  • The API key to be used for retrieval
  • Lookup of local IoC tables before sending to remote scanner
  • Number of days local observables are considered
  • Marking an attack mode/method as inactive when not received from threat intel sources
  • Marking an indicator as inactive when not received from any source for a specified number of days

Configuration

All aspects of the threat intelligence functionality configuration are self-contained in a domain-separated environment.

The following tasks can be configured per domain:

  1. Creation of TAXII service profiles
    • Choose a Discovery service configuration
    • Choose a Collection service configuration
      • Assign roles to users and groups of users
  2. Creation of threat intelligence sources
    • Configure the REST service that supplies the threat intel information
    • Schedule the download of threat intel information
    • Choose threat details information to assign to the source
  3. Creation of attack mode/methods (manual)
    • Source, malware type, attack mechanism, threat actor type, description, handling, intended effect, first seen, last seen
    • Related indicators, child attack mode/method, associated security incidents
      Note: Attack modes/methods are auto-created from the threat feed sources as well.
  4. Setting default lists for the following threat information categories:
    • Attack mechanisms
    • Discovery methods
    • Feeds
    • Indicator types
    • Intended effects
    • Notifications
    • Observable types
    • Rate limit definitions
    • Threat actor types

How tenant domains manage their own application data

  • Tenant domain owners can create their own TAXII service profiles.
  • Tenant domain owners can create their own threat intelligence sources.
  • Tenant domain owners can create their own attack mode/methods.
  • Tenant domain owners can create their own default lists for threat information categories.
Note: Business logic and processes enable threat intelligence source download schedules to be domain separated by instance owner.
Feedback