Lab 01 — Control & Authorization-Readiness Engine

Difficulty: 4/5 | Runs locally: yes, standard library only

Pairs with the Phase 15 WARMUP Chapters 2–5 (NIST 800-53, the ATO process, the boundary and inheritance, OSCAL) and the HITCHHIKERS-GUIDE. Flagship of the phase.

Why This Lab Exists (Purpose & Goal)

A FedRAMP ATO (or any NIST 800-53 authorization) is, underneath the binders, a machine-checkable assertion: for the selected baseline, every required control is implemented with evidence, inherited from an authorized provider, or tracked in an open, on-time POA&M. The goal of this lab is to build the engine that computes that readiness — the core of an OSCAL "compliance as code" pipeline — so the authorization becomes a query over data instead of a human reading 300 control narratives.

The Concept, In the Weeds

Three ideas carry the weight, and each is a place real authorizations fail:

Baselines nest. The impact level (FIPS 199) selects Low / Moderate / High, and they nest — Moderate requires every Low control plus more. A Low-complete system is not Moderate-ready (the lab's BASELINE_CONTROLS encodes this).
Authorization is allowed with open gaps. An ATO does not require zero findings — a planned/not-implemented control is acceptable iff it links an open, on-time POA&M. A gap with no POA&M (gap-without-poam), or with an overdue one (poam-overdue), blocks authorization. Mature security manages risk transparently.
Inheritance must be substantiated. A control marked inherited must name the authorized provider it inherits from; an unsubstantiated claim (inheritance-unsubstantiated) is a finding — one of the most common, most dangerous FedRAMP errors ("we assumed the cloud had it").

Why This Matters for Protecting the Company

An authorization is a precondition to selling in regulated markets, and the speed and integrity of getting one is an engineering problem. An automated readiness engine turns "are we authorizable?" from a months-long manual scramble into a continuous, computed answer — surfacing every missing control, unsubstantiated inheritance, missing evidence, and untracked gap before the 3PAO does. It also keeps the authorization honest: gaps are tracked in POA&Ms, not hidden, and inheritance is real, not assumed. That honesty is exactly what makes the resulting authorization a genuine trust signal to customers, not a checkbox.

Secure Implementation Patterns

The anti-pattern. Treat "we have a control document" as "the control is satisfied," and assume the cloud covers what you didn't implement.

The secure pattern — compute readiness deny-by-default (mirrors solution.py):

def assess_authorization_readiness(baseline, controls, poams, *, today):
    if baseline not in BASELINE_CONTROLS:
        return False, ("invalid-baseline",)
    required = BASELINE_CONTROLS[baseline]          # nested: moderate includes low, etc.
    impl = {c.id: c for c in controls}
    findings = []
    for cid in sorted(required):
        c = impl.get(cid)
        if c is None:
            findings.append(f"{cid}:not-addressed"); continue
        if c.status == "inherited":
            if not c.inherited_from:                # inheritance MUST name the provider
                findings.append(f"{cid}:inheritance-unsubstantiated")
        elif c.status == "implemented":
            if not c.has_evidence:                  # implemented without evidence == assertion
                findings.append(f"{cid}:no-evidence")
        else:                                       # planned/not-implemented -> needs a tracked POA&M
            poam = poams.get(c.poam_id) if c.poam_id else None
            if poam is None:
                findings.append(f"{cid}:gap-without-poam")
            elif poam.remediation_date < today:
                findings.append(f"{cid}:poam-overdue")
    return (not findings), tuple(sorted(findings))   # ready iff every control satisfied/inherited/tracked

The real-world equivalent (Phase 15 HITCHHIKERS): express controls/inheritance/POA&Ms as OSCAL data and run this validation continuously over automated, fresh evidence.

Production practices to carry forward:

Drive the required set from the impact categorization (FIPS 199 → baseline), and respect nesting.
Track gaps in POA&Ms with remediation dates — authorization is risk management, not zero-risk theater.
Substantiate inheritance against the provider's Customer Responsibility Matrix; never assume.
Require evidence for every implemented control, and keep it fresh (Phase 07 freshness).

Validation — What You Should Be Able to Do Now

Select a baseline from an impact categorization and explain why baselines nest.
Explain authorizing with open POA&Ms and what makes a gap acceptable vs blocking.
Substantiate (or flag) a control-inheritance claim.
Compute authorization readiness and classify missing controls, unsubstantiated inheritance, missing evidence, and gaps with/without on-time POA&Ms.

The Broader Perspective

This lab is the governance instantiation of the requirement→control→test→evidence chain you built in Phase 03 (threat-model validator), Phase 07 (control-evidence validator), and now scaled to an entire authorization. The deep lesson: trust at scale is computed from data, not asserted in documents — and the discipline of "every control implemented/inherited/tracked, with fresh evidence" is the same one that makes a security program (not just a control) credible to an external auditor. Compliance done as engineering is how you make the company demonstrably trustworthy to the customers and regulators who demand proof.

Interview Q&A

"Can you get an ATO with open findings?" — Yes; an ATO doesn't require zero findings. Every gap must be tracked in an open POA&M with a remediation date and the AO must accept the residual risk; a gap without a POA&M or with an overdue one blocks it.
"What is substantiated control inheritance?" — A control marked inherited must name the authorized provider that actually owns it for your usage (per their CRM); an unsubstantiated claim is a finding. Inheritance shrinks the work; the controls above the line are still yours.

Extension (Stretch)

Express the controls/baselines/POA&Ms as real OSCAL (JSON) and validate with compliance-trestle; import a provider Customer Responsibility Matrix to compute inheritance; add evidence-freshness checks.

References

NIST SP 800-53 Rev. 5 / 800-53B; FedRAMP SSP/POA&M templates; OSCAL spec; Phase 15 WARMUP Chapters 2–5.

Security Engineer