Domain separation and Configuration Compliance
Summarize
Summary of Domain Separation and Configuration Compliance
Domain separation in Configuration Compliance allows for the logical grouping of data, processes, and administrative tasks into distinct domains. This feature enables users to control access to data and enhances security by ensuring that customer data remains isolated from other clients.
Show less
Key Features
- Terminology Changes: Notable terms have been updated in version 14.9, such as "Test Result Group" to "Remediation Task Group" and "Rules" to "Remediation Task Rules."
- Support Levels: Configuration Compliance supports Standard-level operations, allowing application properties to be domain-aware and enabling service providers to customize processes per tenant.
- Data Management: Test results from third-party scanners like Qualys are ingested and remain within the respective domain of the integration user.
- Risk Scoring: Risk scores are calculated based on the specific domain's configuration and are used for prioritizing remediation tasks.
- Comprehensive Life Cycle Management: The application manages the entire life cycle of test results, including ingestion, scoring, grouping, and remediation.
Key Outcomes
Implementing domain separation results in:
- Enhanced security with data confined to its respective domain.
- Improved operational efficiency through standardized processes across multiple clients.
- Customizable workflows and integration management tailored to specific domains.
- Analysts gaining autonomy to manage application data, including creating their own workflows and remediation logic.
Setting up domain separation requires no additional steps, as all tables automatically include a Domain column once enabled. This promotes seamless integration and management of compliance-related data within distinct domains.
Domain separation is supported in Configuration Compliance. 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.
| Terminology prior to v14.9 | Terminology v14.9 onwards |
|---|---|
| Test Result Group | Remediation Task |
| Group Rules | Remediation Task Rules |
| Policy | Test group |
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 Configuration Compliance
With domain separation you can standardize (Configuration Compliance) 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 |
Domain separation for the Configuration Compliance application covers the following product functionality:
- Ingests the test results from third-party scanners (Qualys) 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 hosts from Configuration Compliance 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 test result level as per the risk score calculator defined in the same domain as that of the integration user.
- Remediation task rule(s) can be defined, assigned, and stay in, the same domain as the domain of the integration user.
- Remediation tasks created using the doc 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 test result states such as age of test results, open test results by CI, test results by impact in the domain to which it belongs.
- Knowledge from third-party scanners (Qualys) can be ingested in the global domain and data can be shared across multiple clients.
Use cases
The Configuration Compliance application manages the life cycle of a test result end to end. The following use cases are domain-separation aware:
- Ingest test results from Qualys
- Ingest data from multiple instances
- De-duplicate the test results
- Match up with CMDB CI
- Enrichment of test results with risk scores
- Asset enrichment (CMDB)
- Risk score
- Group test results and assign the remediation task
- Automatically group the test results
- Automatically assign the remediation task
- Remediate
- Remediation task assigned as a remediation task
- Comprehensive remediation life cycle
- Deferral workflow
- Measure the security posture of the organization and compliance management program
- Results trend, by compliance, category, criticality and technology
- Status and distribution on policies, tests, hosts, test results, and risk score
Setup
Setting up domain separation for Configuration Compliance does not require any additional steps. All Configuration Compliance tables acquire the Domain column after the instance is domain separated. You can direct test result integration import data to specific domains. For more information, see Create domain-separated imports for an integration. For more information on additional precautions and settings, see Additional settings for domain separation.
Domain-separated data
- Test results 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.
- Test results or hosts in one domain cannot be viewed from other domains.
- The risk scoring algorithm and the test results group rules cannot be viewed by anyone outside the domain.
- Deferral workflows created in one domain are not visible in another domain.
- All email notifications are contained within the domain they belong to.
How compliance 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 results, auto-assign remediation tasks and assign to the correct assignment group.
- Domain users create a manual remediation task and then close it.
Business logic and processes that can be domain-separated by instance owner
- Configuration Compliance users and groups
- Configuration Compliance integrations (starting with the Madrid release)
- Complete setup configuration (user and group management, application installation, multi-source application management, CI lookup rules, remediation task rules, risk calculators, etc.)
- Complete remediation life cycle including deferral