Hitchhiker's Guide — Engineering and Operating an Authorization

The operator's manual for Phase 15 WARMUP. The WARMUP derives the concepts; this is how you actually express controls as OSCAL data, substantiate inheritance, automate evidence, compute authorization readiness, and run continuous monitoring — with concrete artifacts and the discipline behind them.

Table of Contents

Categorize, Then Select a Baseline

FIPS 199 first: rate the confidentiality / integrity / availability impact (Low / Moderate / High); the high-water mark sets the system impact level, which selects the NIST 800-53 baseline. Baselines nest — Moderate = Low + more; High = Moderate + more — so a Low-complete system is not Moderate-ready (Lab 01). Get the boundary right at the same time: too broad over-tests; too narrow excludes something that touches the data.

Controls as OSCAL Data

Express each control as machine-readable data, not a Word narrative:

{
  "control-id": "AC-2",
  "status": "implemented",
  "implementation": "Accounts are provisioned via Terraform + SSO; quarterly access reviews; "
                    "automated disable on termination via the HR->IdP webhook.",
  "evidence": ["ci/test_access_review_runs", "iam-export-2026-06.json"],
  "owner": "platform-security",
  "frequency-days": 90,
  "last-verified": 20260610
}

Now a tool (Lab 01) can validate readiness across the whole baseline instead of a human reading 300 narratives. This is the compliance-as-code leverage that makes High-baseline tractable.

Substantiating Inheritance

{ "control-id": "PE-3", "status": "inherited",
  "inherited-from": "AcmeCloud-IaaS (FedRAMP High ATO #F1234567890)",
  "customer-responsibility": "none (physical access fully provider-owned within the boundary)" }

An inherited control with no named provider is a finding (inheritance-unsubstantiated, Lab 01). Import the provider's Customer Responsibility Matrix (CRM) so the line between their controls and yours is explicit — mis-stated inheritance ("we assumed they had it") is a classic FedRAMP failure.

Automating Evidence

Pull evidence from live sources, not screenshots, and attach a freshness cadence:

control          evidence source (automated)                    cadence
AC-2 access review   IAM export + access-review job result        90d
AU-2 audit logging   cloud audit-config query + a "log present" test   30d
SC-8 TLS in transit  admission/config check rejecting cleartext   continuous
SI-4 monitoring      detection-coverage report (Phase 09)         continuous

A control whose evidence aged past its cadence is failing — the audit becomes a query over fresh data, not an annual fire drill (Phase 07 "verify effective state, not configured intent").

Computing Authorization Readiness

The engine (Lab 01) answers "are we authorizable?" deterministically:

for each required control in the baseline:
   missing                          -> not-addressed
   inherited without a provider     -> inheritance-unsubstantiated
   implemented without evidence     -> no-evidence
   planned/not-implemented:
       no open POA&M                -> gap-without-poam
       POA&M past remediation date  -> poam-overdue
ready  <=>  no findings   (gaps tracked in on-time POA&Ms are OK -> the ATO does not require zero gaps)

Running Continuous Monitoring

The ConMon engine (Lab 02) answers "are we staying authorized?" each month:

scans: os/web/db each <= 30 days old (else scan-stale/scan-missing)
findings: remediate within severity SLA from first detection:
          High 30 days | Moderate 90 | Low 180
deviations: an approved (FP / risk-adjustment / operational-requirement), UNEXPIRED deviation stops the
            clock; an expired/absent one does not
vendor-dependency findings: tracked separately, not the customer's SLA

A stale scan or an overdue POA&M is a compliance failure the AO sees — and a lapse can cost the ATO.

FIPS Crypto Inventory

data at rest (DB)     -> KMS backed by a FIPS 140-3 validated HSM (CMVP #XXXX)
data in transit       -> TLS via the OS FIPS-validated module, FIPS mode ON (approved suites only)
app-level hashing     -> validated library in FIPS mode
ANY non-validated crypto path touching sensitive data == a finding

"AES-256" is not the requirement; a validated module used in its approved mode is.

The Regime Crosswalk

Build the control once, map it to many:

control: "TLS 1.2+ enforced and tested for all sensitive data in transit"
  FedRAMP SC-8/SC-8(1)  |  PCI DSS 4.2.1  |  HIPAA 164.312(e)  |  SOC 2 CC6.7  |  ISO A.8.24

One engineered control + a crosswalk = one implementation serving multiple authorizations.

Failure Drills

  • Stale scan (45 days) → scan-stale → ConMon deliverable failure.
  • High finding at 31 days → overdue-high → POA&M SLA breach.
  • Expired deviation → the SLA clock resumes → overdue.
  • Inherited control, no provider → inheritance-unsubstantiated.
  • Planned control, no POA&M → gap-without-poam → blocks the ATO.

Evidence Packet

The FIPS-199 categorization and baseline; an authorization-boundary diagram; an OSCAL control set with a substantiated inheritance map; an automated-evidence inventory with freshness; a readiness report (Lab 01); a monthly ConMon posture with a POA&M aging report (Lab 02); a FIPS crypto inventory; and a regime crosswalk.

References

  • NIST OSCAL spec and compliance-trestle (Trestle) tooling; NIST SP 800-37 (RMF), 800-53/53B.
  • FedRAMP templates (SSP/SAR/POA&M, ConMon strategy); the CMVP search (FIPS 140-3 validated modules).
  • OpenSCAP; open-source GRC/compliance-as-code projects; Phase 03 and Phase 07 cross-references.