Domain separation and Vulnerability Response
Summarize
Summary of Domain separation and Vulnerability Response
Domain separation in the Vulnerability Response (VR) application allows ServiceNow customers to isolate data, processes, and administrative tasks into distinct logical groupings called domains. This ensures data visibility and access control are properly segmented, supporting multiple customers or tenants within a single instance while maintaining security and operational efficiency. Domain separation is supported at the Standard level from multiple VR release versions, enabling service providers to customize processes per tenant and control data visibility.
Show less
Key Features
- Data Isolation: Vulnerability data ingested from third-party scanners (e.g., Qualys, Rapid7, Tenable) is stored within the integration user's domain and is not accessible from other domains.
- Domain-aware Processes: Risk scoring, remediation task rules, approval workflows, and reports operate within the domain context, ensuring that each tenant's data and processes are segregated.
- Global Domain Sharing: Knowledge data such as the National Vulnerability Database (NVD) can be ingested into a global domain and shared across tenants.
- Tenant-specific Configuration: Analysts can create and manage integrations, workflows, remediation rules, and risk calculators specific to their domain, allowing tailored vulnerability management.
- Import Management: Import templates and scheduled imports are domain-aware, enabling data ingestion into the correct domain and avoiding conflicts in multi-domain instances.
- Comprehensive Lifecycle Support: Supports the full vulnerability management lifecycle including ingestion, de-duplication, enrichment, task assignment, remediation, deferral workflows, and reporting within domains.
Practical Implications for ServiceNow Customers
- Service providers can efficiently manage multiple tenants in a single VR instance without data leakage across clients.
- Customers gain confidence that their vulnerability data, remediation efforts, and risk scoring remain private and domain-specific.
- Domain separation reduces operational overhead by standardizing VR procedures while allowing customization per tenant.
- Configuration of domain-separated imports and workflows requires no additional setup beyond enabling domain separation on the instance.
- Scheduled import templates must be distributed and assigned to each domain to ensure proper data segregation and avoid conflicts.
What to Expect
When domain separation is enabled in Vulnerability Response, customers experience segregated workflows, dashboards, reports, and data visibility aligned to their domain. Vulnerable items and remediation tasks remain isolated per domain, while shared knowledge bases reside in a global domain accessible to all. Analysts have control over domain-specific configurations to manage vulnerability data lifecycle effectively. Service providers can deliver tailored, secure, and scalable vulnerability management services across multiple tenants within the same ServiceNow instance.
Domain separation is supported in Vulnerability Response. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
Support level: Standard
- Includes all aspects of Basic level support.
- Application properties are domain-aware as needed.
- Business logic: The service provider (SP) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance.
- The instance owner must configure the minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application.
Sample use case: An admin must be able to make comments required when a record closes for one tenant, but not for another.
For more information on support levels, see Application support for domain separation.
How domain separation works in Vulnerability Response
With domain separation you can standardize VR (Vulnerability Response) procedures, across the customer base you serve, with lowered operational costs and a higher quality of service.
Separate customer work spaces for workflows, dashboards, reports, and so on, ensures that customer data is separated and never exposed to other clients.
| Release | Support level | Notes |
|---|---|---|
| Orlando | Standard | |
| Paris | Standard | |
| Quebec | Standard | |
| Rome | Standard | |
| San Diego | Standard | |
| Tokyo | Standard | |
| Utah | Standard | |
| Vancouver | Standard | |
| Washingtondc | Standard |
Domain separation for the Vulnerability Response application covers the following product functionality:
- Ingests the vulnerable items from third-party scanners (for example, Qualys, Rapid 7, or Tenable) in the correct domain. The data ingests in the same domain as that of the integration user, whose credentials are used for integration.
- Re-scans specific assets from Vulnerability Response in the domain from which it was requested.
- Uses the CMDB CI lookup process to ensure that the CI information from the scanners matches the CIs in CMDB of the integration user’s domain.
- Calculates risk scores at the vulnerable item level as per the risk score calculator defined in the same domain as that of the integration user.
- Remediation target rules are executed on vulnerable items as per the remediation target rules defined in the same domain as that of the integration user.
- Remediation task rule(s) can be defined, and stay in, the same domain as the domain of the integration user.
- Remediation tasks created using the remediation task rules stay in the same domain as where the group rules are created.
- Deferral workflow goes through the approval process in the same domain for which the deferral is requested.
- Reports and dashboards display the vulnerable item-states such as age of vulnerable item, open vulnerable items by CI, vulnerabilities by impact, and remediation target date status in the domain to which it belongs.
- Knowledge from third-party scanners or the National Vulnerability database (NVD) can be ingested in the global domain and data can be shared across multiple clients.
For more information on how to create and support domain-separated imports, see Create domain-separated imports for an integration and Create and support multiple domains in the background jobs framework.
Use cases
The Vulnerability Response application manages the life cycle of a vulnerability item end to end. The following use cases are domain-separation aware:
- Ingest vulnerable items (vulnerabilities on asset) from your
third-party integration.
- Ingest data from multiple instances
- De-duplicate the vulnerable item
- Match up with CMDB CI
- Enrichment of vulnerable item with risk scores and remediation
target dates
- Asset enrichment (CMDB)
- Risk score and remediation target date enrichment
- Group vulnerable items and assign the remediation task
- Automatically group the vulnerable items
- Automatically assign the remediation task
- Remediate
- Remediation tasks
- Comprehensive remediation life cycle
- Deferral workflow
- Measure the security posture of the organization and vulnerability
management program
- Vulnerability trend, most vulnerable asset, vulnerability by age
- Remediation status by the remediation target date
Setup
Setting up domain separation for Vulnerability Response does not require any additional steps. All Vulnerability Response tables acquire the Domain column after the instance is domain separated. You can direct vulnerability integration import data to specific domains. See Create domain-separated imports for an integration for more information.
Domain-separated data
- Vulnerable item ingested from third-party scanners stays in the same domain as the domain of the integration user, and is not accessible from any other domain.
- Vulnerabilities, vulnerable items (instances) or assets in one domain cannot be viewed from other domains.
- The risk scoring algorithm, the remediation task rules and the remediation target rules cannot be viewed by anyone outside the domain.
- Vulnerability information from the NVD can exist in the global domain and be shared with all customers.
- Remediation tasks in one domain cannot be viewed from another domain.
- Deferral workflows created in one domain are not visible in another domain.
- All email notifications are contained within the domain they belong to.
- Distribute the import templates available on the instance across the number of domains involved in the integration.
- Update the import template record's domain to the sys_id of the target domain.
- If necessary, create import templates for each domain.
- Ensure each domain has 2 import templates.
- sn_vul_sched_import_pool: This table records should be domain separated if domain separation is present on instance
How vulnerability analysts manage their own application data
- Analysts create their own application installation, multi-source application management, and CI lookup rules.
- Analysts can configure specific integrations exclusively for use within the domain.
- Analysts can create their own deferral and change management workflows.
- Analysts can create their own remediation task rules, risk-scoring logic to accurately prioritize vulnerabilities, auto-assign remediation tasks and assign to the correct assignment group.
- Domain users create a manual vulnerability item and then close the item.
Business logic and processes that can be domain-separated by instance owner
- Vulnerability Response users and groups
- Vulnerability Response integrations
- Complete setup configuration (user and group management, application installation, multi-source application management, CI lookup rules, remediation task rules, risk calculators, remediation target rules etc.)
- Complete remediation life cycle including deferral
- Schedule jobs