This is an overview of domain separation as it pertains to the Threat Intelligence module that is available as
part of Security Incident Response. With
domain separation you can 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.
Support level: Standard
- Includes Basic level support.
- Business logic: Processes can be created or modified per customer by the service
provider (SP). The use cases reflect proper use of the application by multiple SP
customers in a single instance.
- The owner of the instance needs to be able to configure the minimum viable product
(MVP) business logic and data parameters per tenant as expected for the specific
application.
Use case: An admin needs to be able to make comments mandatory when a record closes for
one tenant, but not for another.
Overview
In the Threat Intelligence module (as part of the Security Incident Response application),
domain separation enables Service Providers (SPs) 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.
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) |
All integrations reside across multiple domains. |
| Madrid |
Level 2 (Data, Requestor, Fulfiller) |
All integrations can now reside across multiple domains. Continued support of
capabilities from Jakarta. |
| New York |
Level 2 (Data, Requestor, Fulfiller) |
All integrations can now reside across multiple domains. |
| Orlando |
Standard |
All integrations can now reside across multiple domains. |
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:
- Creation of TAXII service profiles
- Choose a Discovery service configuration
- Choose a Collection service configuration
- Assign roles to users and groups of users
- 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
- 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.
- 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
- Attack motivations
- Infrastructure types
- Malware capabilities
- Malware types
- Report types
- Threat actor roles
- Tool 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.
