Lion Cipher Lab

Build the full NIST OSCAL model chain (catalog -> profile -> SSP -> component-definition -> assessment -> POA&M) and schema-validate every link

• GRC / Compliance
• Advanced
• ~1 hr
• Free · no account required

Why it matters

A traditional System Security Plan is a 300-page Word document. It is authored once, it is out of date the day it is signed, and the only way to know whether the control it claims for AC-2 still matches reality is for a human to read the paragraph and believe it. You cannot diff it, you cannot query it, you cannot mechanically prove that the control the profile selected is the control the SSP implements is the control the assessment tested is the control the POA&M is remediating. OSCAL — the Open Security Controls Assessment Language, NIST's machine-readable standard — exists to make that…

What you'll learn

• the OSCAL model chain end to end — which model imports which, and the direction authority flows: catalog -> profile -> SSP -> component-definition -> assessment-plan/results -> POA&M
• starting from OFFICIAL NIST content: cloning usnistgov/oscal-content and using the real SP 800-53 rev5 catalog + a baseline profile instead of inventing controls
• profile resolution — running `oscal-cli profile resolve` to flatten a baseline into a concrete resolved catalog, and reading the failure when a selected control-id isn't in the imported catalog
• cross-linking models by UUID: import href to a resource, by-component links from an SSP implemented-requirement to a component uuid, and finding->poam-item links
• the control-id vs UUID distinction that trips everyone: humans select controls by control-id ('ac-2'), but OSCAL cross-links model instances and components by UUID
• validating each model with `oscal-cli <model> validate`, which runs JSON-schema AND Metaschema constraint checks (the constraints are what resolve #uuid references)
• the ajv fallback — validating an OSCAL file against the published JSON schema with Node — and knowing precisely what it catches (structure, required fields, datatype) and what it CANNOT (dangling cross-references)
• diagnosing the named failure modes: dangling UUID href, unresolved profile import, wrong model root element, missing required metadata (last-modified/oscal-version/roles), and a free-text POA&M that should be structured poam-items
• authoring a POA&M as structured poam-items whose related-findings point at real finding UUIDs in the assessment-results, not prose
• the engineering judgment: why machine-readable OSCAL (continuous ATO, diff-able compliance, one source of truth feeding many outputs) beats a hand-written Word SSP, when it's overkill, and the pro do-it-better (generate the SSP from a component library with compliance-trestle, don't hand-edit JSON)

Steps in this lab

1. The mental model: the six models, and that they cross-link by UUID (not by control-id)
2. Install the validator(s) and clone the official NIST content
3. Validate the starting point: the real catalog and a real baseline profile
4. Resolve the profile against the catalog — and meet the unresolved-import failure
5. Author a small SSP that implements a few resolved controls with by-component links
6. Author the component-definition — and deliberately dangle a UUID to watch the validator catch it
7. Author assessment-results with findings, then a POA&M whose items reference those findings
8. Validate the WHOLE chain and recap the named failure modes
9. The judgment: why machine-readable OSCAL, when it's overkill, and how a pro really ships it

Open the full interactive lab →