Automating Technical Hardening Guidance with OSCAL
The analysis compares three approaches to representing technical hardening guidance and informing automated checks in OSCAL, including the roles of the parties involved. Hardening guides considered:
The guidance inventory loads from data/sources.json.
1. One recommendation, three paths
A guidance author writes a hardening recommendation, an implementer applies the recommendation, and an assessor checks implementation. The recommendation serves all three roles. Placement in OSCAL determines how well the recommendation meets each role's needs.
The three paths start from the same recommendation without passing through another path. An assessor can use the recommendation and independent checking methods without waiting for implementer-produced artifacts.
2. Implementation and assessment layers are both viable for a hardening recommendation
A rule derived from a recommendation can be introduced in either of two OSCAL layers. Each option identifies the locations of the rule, check, and response.
Provide rules and checks to implementers
Rules and checks are available to implementers. Catalog-first and component-first record responses in the system security plan but place rules in different models.
- Rule a control in a product-specific catalog
- Check a check in a component definition
- Response system security plan
- Rule a component definition
- Check a check in a component definition of type validation
- Response system security plan
The check and runner
A rule names a check; a runner executes the check. The same automation can serve an implementer analysing and recording an environment's state or an assessor producing a result.
Write the rule and the check in the assessment
The assessment plan holds the check and records the rule as an activity and a step in prose. The response is recorded as an assessment result rather than in the system security plan.
- Rule an activity or a step in the assessment plan, in prose
- Check a check linked directly to the rule
- Response assessment results
Assessors may automate direct assessments of environments or assessments of security packages. Assessors do not rely on system-owner-defined hardening guidance and use assessment capabilities independent of system features.
3. The six questions evaluated for each option
Each approach is evaluated against the same six questions:
- The six questions load from data/six-questions.json.
4. The three approaches and available answers
Questions 1 to 6 cover rule and check placement, check execution, timing, and assessment subjects. The label "first" names the OSCAL model where the rule first appears.
The three cards load from data/six-questions.json.
The legend loads from data/six-questions.json.
The six questions page compares the encodings each approach would use to answer each question.
5. Why question 6 splits: a claim is not a result
Question 6 has two parts, 6a and 6b, answered by different stakeholders. An implementer uses a system security plan to describe how a control is satisfied: standing design intent asserted by the system owner. An assessment result records whether the control was satisfied at a point in time on a named subject, as asserted by the assessor.