Component-first
Component-first represents a rule in the proposed rules assembly on the product component. The check uses the proposed checks assembly on a separate component of type validation. The rule states the required configuration; the check describes how to test the configuration.
1. Stakeholder roles and OSCAL models
Component-first treats a hardening rule as a capability statement, using the component-definition model in the Implementation 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 | component-definitionsoftware or validationThe mapping provider edits a component definition. Whether the rules or the checks carry the framework mapping remains open. |
| 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 | component-definitionsoftware |
| Technology providersVendors publishing configuration guidance for hardware, software and services, independently or with benchmark publishers such as CIS | component-definitionsoftware |
| 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-definitionvalidationThe provider publishes checks in a component of type validation. 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-definitionvalidationruntime is read by the policy engine, which runs and writes system-security-plan |
| Independent auditorsAssessors running checks and reviewing results independently of system owners | runs the checks, making the observationsassessment-planruntime is read by the policy engine, which runs and writes assessment-resultsThe auditor runs checks through an assessment plan, allowing the result to identify a host rather than a component. |
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 rules in a component definition has these strengths and risks.
2.1 Strengths4
-
One artifact describes capability and supports automation
A component definition describes how a product can meet controls; the proposed rules provide configuration requirements for automation in the same document.
-
Rules and checks remain separate
The product component holds the rule and a validation component holds the check; a second engine uses a second validation component.
-
Implementation claims can reference rules
The proposed
implementing-rulesassembly links a control implementation claim to the rule used to satisfy the control. -
Technology providers can extend component descriptions
Existing guidance directs technology providers to describe product capabilities in component definitions, where the proposal would also place hardening rules.
2.2 Risks5
-
Four models require schema changes
The proposal changes component definitions, system security plans, assessment plans and assessment results; existing schema support does not cover the proposed assemblies.
-
Desired state enters the plan of record
Rules describing the required component configuration enter the system security plan, which documents the system's implemented controls and current configuration.
-
Published rules omit guide context
Rationale, audit procedure and remediation provide guidance context, but the published rules omit these fields and support remains proposed.
-
Responses do not identify individual instances
A
by-componentresponse can reference a rule but not an individual instance, so exceptions remain associated with the component. -
Host-level claims may require inventory support
Inventory items would also need
implementing-rulessupport for a claim to identify a host rather than a component class.
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 proposed rules assembly defines the rule on the product component. The chain starts from the rule id within that component definition.
component-definition,components[].rules[].id. - Rule to Check. The check references both a rule id and a target component uuid. A rule id is unique only within the declaring component.
- Rule to Control. The component definition contains both references. Control implementations already link components to controls; the proposed implementing-rules assembly adds references to individual rules.
- Check to Runtime. The validation component contains the checks executed by the engine. Each additional engine is represented by a separate validation component.
- Runtime to Claim. The proposed implementing-rules assembly references the rule supporting the claim, allowing a consumer to trace the claim to the check through OSCAL references.
- Runtime to Result. The observation identifies the check and host, allowing different outcomes for two machines within the same system boundary to be recorded separately.
- Result to Control. The example result contains observations but no findings. No finding target identifies the control, and no finding status records whether the objective was satisfied.