Vol VI Book 06 — Federal Compliance — Configuration Baselines & Hardening

SCuBA, CIS, and STIG baselines expressed as policy-as-code with drift detection and reconciliation

0.1 Draft Proposal — Subject to Review

Developed by the CSI Team (Cloud Services Infrastructure); not yet reviewed or approved by the Agency CIO Office, OIS, or leadership. Date Code: 2026-07-09 15:13 ET

Series Context — Volume VI Book 06. Deployable realization of the configuration and posture architecture of Volume III (Cloud-Native Posture, Patch & Systems Management): secure-baseline policy-as-code with continuous drift detection, applied through the Book VI-00 pipeline.

1 What This Document Addresses

A baseline that no pipeline enforces is a document, not a control. Volume III establishes the required secure-configuration posture — SCuBA for the cloud business applications, CIS/STIG for the platforms — and makes the sharp point that conformance tooling measures drift from an intended state; it cannot author one.

This book authors the intended state as machine-enforced policy, detects drift against it continuously, and reconciles or reports it. It operationalizes, through CM-6(1)/(2) automation, the enforce-detect-reconcile loop over base CM-6: an enforced configuration, a detection of deviation, and a documented reconciliation — not a spreadsheet of settings someone once applied.

2 The Baseline Lifecycle

Each baseline moves through four as-code stages; the last two are what turn a one-time hardening into a standing control.

Stage	Artifact	Control tie
Author	Baseline definition (SCuBA/CIS/STIG mapped to policy)	CM-6 settings
Assign	Policy assignment to the target scope	CM-2 baseline
Detect	Continuous compliance scan → drift record	CM-3 change; CM-6
Reconcile / report	Auto-remediate where safe; POA&M where not	CM-6; SI-2 feed

3 Deployable Artifacts

Artifact	Realizes (Vol III)	Deployed example	Multi-CSP substitution
SCuBA baseline conformance packs	CM-6 cloud business-app baseline	ScubaGear assessment + policy-as-code	equivalent CIS cloud benchmark packs
Guest/machine-config baselines	CM-2/6 OS configuration	Azure Machine Config (Guest Config)	AWS SSM State Manager; GCP OS Config
Host hardening roles	CM-6/7 least functionality	Ansible/DSC roles mapped to STIG/CIS	Chef/Puppet equivalents
Drift detection + reconciliation	CM-3 change control; SI-2 flaw feed	Config drift export to evidence contract	native config-compliance exports

3.1 Illustrative artifact — a machine-config baseline with drift export

The baseline declares the desired setting and what to do when the fleet drifts from it. The drift record is not a dashboard tile — it is emitted to the evidence contract so CM-6 compliance is continuously attestable and SI-2 sees the remediation feed.

# Guest/machine-config baseline (deployed example: Azure Machine Config) — CM-6
baseline: cis-l1-win-server
assignment:
  scope: /subscriptions/*/resourceGroups/prod
  enforcementMode: AuditThenRemediate     # detect first, remediate the safe rules
rules:
  - id: 2.3.1.1
    setting: "Accounts: Administrator account status"
    desired: "Disabled"
    onDrift: remediate
  - id: 18.9.x
    setting: "Configure SMBv1 client driver"
    desired: "Disabled"
    onDrift: report          # TUNE: report-only where auto-remediation risks a break
driftExport:
  target: evidence-contract  # Book VI-07: every drift + reconciliation is an evidence record

The SCuBA conformance packs are the cloud-business-application counterpart: the assessment output is diffed against the intended SCuBA baseline, and any governed exception is carried as a documented deviation rather than an open drift — so an assessor sees a governed exception backed by policy, not a silent gap.

4 Deployment

1. Assign each baseline in audit-only first; measure the drift population before enabling any auto-remediation — a baseline that auto-remediates a setting the estate depends on is an availability incident.
2. Split rules into remediate (safe, idempotent) and report (needs human judgment); the split is itself reviewed in the pull request.
3. Wire drift and reconciliation records to the evidence contract (Book VI-07) so CM-6 is continuously evidenced.
4. Feed unremediated drift into the SI-2 remediation queue and the POA&M.

5 Closure Necessity

5.1 Closure Necessity — an unenforced baseline is not a baseline

Volume III proves conformance tooling measures drift from an intended state; it cannot author one. This book authors the intended state as code and enforces it. Base CM-6 requires an established, documented, and implemented baseline; this book operationalizes it through CM-6(1) automated management and verification and CM-6(2) response to unauthorized changes, so the baseline is machine-enforced and drift is detected and dispositioned — a spreadsheet of settings no pipeline applies closes nothing, and a scanner with no authored baseline has nothing to measure against.

6 Controls Operationalized

Control	Title	How this book deploys it
CM-2/6	Baseline Configuration / Settings	Policy-as-code baselines + drift detection
CM-3	Configuration Change Control	Drift records + reconciliation through the pipeline
CM-7	Least Functionality	Host hardening roles
SI-2	Flaw Remediation	Drift/patch-state feed into the remediation queue

7 Honest Limits

• Auto-remediation is safe only for idempotent, low-blast-radius settings; the report path exists precisely because not every drift can be closed without human judgment.
• SCuBA/CIS/STIG baselines are point-in-time; they must track the publishing authority’s updates, or the “baseline” silently ages out of currency.
• Cloud-native posture (CSPM) findings on multi-CSP estates require per-CSP packs; the mechanism is uniform, the pack content is not.

8 Cross-References

• Volume III — Cloud-Native Posture / Patch & Systems Management — the architecture this book deploys.
• Book VI-07 — drift and conformance results emit to the evidence contract.
• Book VI-08 — baseline conformance is validated by the test harnesses.

9 Provenance

Draft. Products are deployed examples; substitution columns preserve the mechanism. The baseline YAML is an illustrative pattern to adapt, not a drop-in pack. Baseline sources (CISA SCuBA, CIS Benchmarks, DISA STIG) cite their publishing authority.