Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • Security Operations
Table of Contents
Choose your release version
    Home Madrid Security Incident Management Security Operations Security Incident Response Understanding Security Incident Response Domain separation and Security Incident Response

    Domain separation and Security Incident Response

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Domain separation and Security Incident Response

    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:

    1. 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
    2. Security Incident Response Administration
      • Add or review roles: Components installed with Security Incident Response
      • Configure groups and users: Create a security incident group
      • Set up incident escalations: Escalate a security incident
      • Set up security incident risk score calculators: Understanding security incident calculators
      • Set up service level agreements: Create a Security Incident Response SLA
      • Set up security incident process definitions: Understanding Security Incident Response process definition
      • Set up post-incident review processes: Manage post incident activities
    3. 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
    4. Security incident playbook settings
      • Review and set up runbook documents: Create a Security Incident Response runbook
      • Set up security incident workflows: Security Operations common functionality
    5. Capability configurations
      • Select and configure integrations to work with these capabilities:
        • Block request: Security Operations Integration - Block Request capability
        • Email search and delete: Security Operations Integration - Email Search and Delete capability
        • Enrich configuration item: Security Operations Integration - Enrich CI capability
        • Enrich observable: Security Operations Integration - Enrich Observable capability
        • Get network statistics: Security Operations Integration - Get Network Statistics capability
        • Get running processes: Security Operations Integration - Get Running Processes capability
        • Isolate host: Security Operations Integration - Isolate Host capability
        • Publish to Watchlist: Security Operations Integration - Publish to Watchlist capability
        • Sighting search: Security Operations Integration - Sightings Search capability
        • Threat lookup: Security Operations Integration - Threat Lookup capability

    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
    Related topics
    • Domain separation

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Domain separation and Security Incident Response

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Domain separation and Security Incident Response

      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:

      1. 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
      2. Security Incident Response Administration
        • Add or review roles: Components installed with Security Incident Response
        • Configure groups and users: Create a security incident group
        • Set up incident escalations: Escalate a security incident
        • Set up security incident risk score calculators: Understanding security incident calculators
        • Set up service level agreements: Create a Security Incident Response SLA
        • Set up security incident process definitions: Understanding Security Incident Response process definition
        • Set up post-incident review processes: Manage post incident activities
      3. 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
      4. Security incident playbook settings
        • Review and set up runbook documents: Create a Security Incident Response runbook
        • Set up security incident workflows: Security Operations common functionality
      5. Capability configurations
        • Select and configure integrations to work with these capabilities:
          • Block request: Security Operations Integration - Block Request capability
          • Email search and delete: Security Operations Integration - Email Search and Delete capability
          • Enrich configuration item: Security Operations Integration - Enrich CI capability
          • Enrich observable: Security Operations Integration - Enrich Observable capability
          • Get network statistics: Security Operations Integration - Get Network Statistics capability
          • Get running processes: Security Operations Integration - Get Running Processes capability
          • Isolate host: Security Operations Integration - Isolate Host capability
          • Publish to Watchlist: Security Operations Integration - Publish to Watchlist capability
          • Sighting search: Security Operations Integration - Sightings Search capability
          • Threat lookup: Security Operations Integration - Threat Lookup capability

      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
      Related topics
      • Domain separation

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login