Catalog-first
Catalog-first represents a rule as a catalog control and a check as a software component. TechnicalControlId links the control to the check component; ConfigRuleId identifies the executable rule. The control states the requirement, and the component describes the check.
1. Stakeholder roles and OSCAL models
Catalog-first treats a hardening rule as a requirement, using the catalog model in the Control layer. The table shows the models each party uses to publish guidance, implement controls or record assessment results.
Seven parties publish, implement or assess hardening guidance. The table maps each party to OSCAL models and groups guidance authors separately from automation providers and operators.
| Party | OSCAL model |
|---|---|
| Regulatory control providersNIST and other bodies publishing regulatory controls, such as SP 800-53 | catalog |
| Mapping providersOrganisations linking guidance to frameworks through DISA's CCI list, NIST's OLIR programme or the Secure Controls Framework | mapping-collectionThe mapping provider writes a separate framework mapping. The published corpus contains no mapping collection for hardening guidance. |
| Hardening guidance authorsBenchmark publishers and technology providers author guidance in the same OSCAL model for each approach. | |
| Technical hardening guidance providersCIS, DISA and other benchmark publishers | catalog |
| Technology providersVendors publishing configuration guidance for hardware, software and services, independently or with benchmark publishers such as CIS | catalog |
| Automation providers and operatorsProviders build policy engines. System owners and auditors run checks to produce implementation responses or assessment results. | |
| Policy engine providersProviders of assessment and checking tools such as OPA, Kyverno, ScubaGear and OpenSCAP | component-definitionsoftwareThe provider publishes checks as components of type software, referencing the guidance authors' catalog. System owners and auditors run the checks. |
| System ownersOrganisations implementing and documenting controls on a system | profilesystem-security-planruns the checks, making the control-implementation responsescomponent-definitionsoftwareruntime is read by the policy engine, which runs and writes system-security-planThe system owner selects requirements and merges catalogs through a profile imported by the system security plan. |
| Independent auditorsAssessors running checks and reviewing results independently of system owners | runs the checks, making the findingscomponent-definitionsoftwareruntime is read by the policy engine, which runs and writes assessment-resultsThe auditor runs the checks independently. The resulting finding targets the system owner's implementation statement. |
The runtime. A policy engine reads OSCAL, executes checks and writes OSCAL. Providers publish the checks; each flow identifies the party executing the checks.
2. Strengths and risks
Publishing technical hardening guidance as a catalog has these strengths and risks.
2.1 Strengths4
-
Technical and regulatory requirements use one model
Technical requirements use catalog controls and follow the same references through the remaining OSCAL models as regulatory controls.
-
Rules can be tailored
A profile selects the hardening requirements an organisation adopts and sets organisationally defined parameters without changing the source catalog.
-
Catalog structures represent guide content
Controls, parts and nested groups represent checks, remediation and explanatory prose, including the structure of a thousand-page guide.
-
Third parties can publish framework mappings
A separate
mapping-collectionlinks guidance to a framework, allowing a third party to publish the mapping without owning either catalog.
2.2 Risks3
-
Benchmark catalogs add maintenance work
The system security plan must address benchmark requirements alongside regulatory controls; whether each additional catalog requires a separate plan remains unsettled.
-
Combined baselines complicate profile resolution
Multiple frameworks and benchmarks require catalogs, profiles and mappings to be maintained together, increasing tool integration work and profile resolution complexity.
-
Responses do not identify individual instances
A
by-componentresponse identifies a component, not an instance, so one exception among a hundred hosts sharing that component cannot be distinguished.
3. Tracing rules and checks from implementation to assessment
The chain connects a rule to checks, implementation claims and assessment results. Each step identifies the relationships a consumer must resolve and the fields used to resolve those relationships.
- Rule definition. The product catalog defines the rule as a control, using the same OSCAL structure as a regulatory control. The chain starts from the control id.
catalog,controls[].id. - Rule to Check. The control references the check by title, a match not enforced by the schema. The check references the control by a resolvable id.
- Rule to Control. A separate mapping collection links the catalogs. A third party can publish the mapping after both catalogs are published without owning either source.
- Check to Runtime. ConfigRuleId identifies the executable rule, but the content does not identify the engine that executes the check.
- Runtime to Claim. The claim references a component, not a host. The by-component assembly has no assessment subject field for an individual instance.
- Claim to Result. The finding targets the implementation statement in the system security plan and references supporting observations, connecting the assessment outcome to the claim.