Assessment-first
Assessment-first represents a rule as an assessment plan activity or step. A property named check identifies the check on the activity or step. Activities state requirements, and steps describe the procedures used to verify those requirements.
1. Stakeholder roles and OSCAL models
Assessment-first treats a hardening rule as an assessor's procedure, using the assessment-plan model in the Assessment 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 | assessment-planThe mapping provider edits the assessment plan, naming the framework controls covered by the activity. |
| 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 | assessment-planThe guidance provider writes activities and steps. The policy engine provider supplies executable checks. |
| Technology providersVendors publishing configuration guidance for hardware, software and services, independently or with benchmark publishers such as CIS | assessment-planThe technology provider writes activities and steps. The policy engine provider supplies executable checks. |
| 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 | assessment-planThe policy engine provider adds checks to the assessment plan. The plan identifies the engine in assessment-assets. |
| System ownersOrganisations implementing and documenting controls on a system | profilesystem-security-planThe system owner supplies the profile and system security plan. The assessor's workflow does not depend on the owner's automation. |
| 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's run produces assessment results, not implementation claims. The workflow does not update the system security plan. |
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 an assessment plan has these strengths and risks.
2.1 Strengths4
-
Guidance stays outside the plan of record
The assessment plan references implementation claims without adding claims, so adding or retiring a guide does not change the system security plan.
-
Assessment results reference an assessment plan
A separate assessment results document imports a plan; the corpus includes findings that target objectives and reference supporting observations.
-
Subjects can identify individual hosts
An assessment subject can be an inventory item, allowing separate findings for two hosts running one operating system with different configurations.
-
The plan records execution context
Tasks carry schedules and identify execution platforms, placing the timing and runtime context for checks in the assessment plan.
2.2 Risks3
-
Required values lack resolvable parameters
The activity title contains the required value, so changing the value requires editing the plan rather than resolving a profile.
-
Guide hierarchy is limited to two tiers
The model provides activities and steps, so guidance nested four levels deep must be represented within those two structural tiers.
-
Published references and types need correction
The published result references a plan absent from the corpus and assigns an observation a subject type not defined by the model.
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 assessment plan defines the rule as an activity in the assessment layer, outside the implementation claim. The chain starts from the activity uuid.
assessment-plan,activities[].uuid. - Rule to Check. The activity contains the check as the first step. A property on the step identifies an executable check resolved outside OSCAL.
- Rule to Control. The activity references the framework control through related-controls, without a separate mapping document or an additional mapping identifier to maintain.
- Check to Runtime. The example plan identifies platforms for the assessment as a whole. The platform reference does not identify the engine used for each check.
- Runtime to Claim. The plan references one system security plan through a back-matter resource. Where no plan of record exists, the resource can describe the system in prose.
- Runtime to Result. The example observation references the planned activity as the subject. The reference identifies the activity, not an inventory item assessed by the check.
- Result to Control. The finding targets a framework control objective. The target links the result to the framework without depending on an implementation statement in a plan of record.