Tailor a catalog into a profile without destroying it, and keep the SSP, assessment results and POA&M pointing at the same control ids.
50 min 200 XPSkills: OSCAL, Tailoring, Baselines
Six layers, one set of ids
OSCAL is not one document. It is a stack: a catalog of control definitions, a profile that selects and tailors them, a system security plan that says how you implement the selection, an assessment plan that says how it will be tested, assessment results that record what was found, and a plan of action and milestones that tracks what is not fixed yet.
Each layer references the one above it by control id. That single discipline is what makes the stack machine-readable: change an id and every layer below quietly points at nothing.
The layers are not paperwork tiers. They are joins. If the join key is unstable, the whole stack is prose again.
Every layer is a reference to the one above it, keyed on the control id.
Tailoring belongs in the profile
A catalog is somebody else's document: NIST's, ISO's, your regulator's. You do not own it, and you do not edit it. What you own is the profile: the record of which controls you selected, which parameters you set, and why.
The most common OSCAL failure in practice is a team that copies the catalog into their repo and edits the control statements to describe how they actually work. Everything still validates. What is lost is the difference between the requirement and your interpretation of it, which is exactly the thing an assessor is there to examine.
Set values in the profile. Describe implementation in the SSP. Never touch the catalog.
Baselines are a starting point, not an answer
A baseline, low, moderate, high, is a pre-tailored selection someone else made for a generic system at a given impact level. Adopting one is a legitimate and fast decision. Pretending it is a risk assessment is not.
Every deviation from the baseline needs a recorded rationale in the profile: added because our contract requires it, removed because we inherit it from the platform, parameter tightened to match the internal standard. A removal with no rationale is indistinguishable from a removal because the control was inconvenient.
Referential integrity across the stack
Because every layer joins on control ids, the checks that matter are boring and mechanical: does every SSP implementation statement reference a control the profile actually includes, does every assessment result reference a control the assessment plan covers, does every POA&M item reference a real finding.
Run those checks in CI on every change to any layer. Dangling references never announce themselves: they surface as an assessor asking why your SSP describes a control you dropped two quarters ago.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The catalog someone improved
Scenario sim+70 XP
Name the layer the edits belonged in, then the activity that was performed.
Incident brief
An engineer vendors the 800-53 Rev 5 catalog into the compliance repo and, over three PRs, rewrites eleven control statements "so they describe what we actually do". Two parameter values are changed inside the same file. The commit message reads "align catalog with reality".
Validation passes: the file is still schema-valid OSCAL. Six weeks later an assessor asks which requirements the organisation modified and no one can produce a list, because the modified text is now the only text.
The engineer's defence: "It is our copy of the catalog."
Term bank, not all of these are right
profilecatalogssptailoringbaselineassessment plan
1.1Name the layer those edits belonged in. (one word)
1.2Name the activity the engineer was actually performing. (one word)
Task 2: Describing a control you dropped
Scenario sim+70 XP
Name the check family that failed, then the layer holding the stale statement.
Incident brief
Last quarter the platform team removed SC-7(3) from the production profile, correctly, because the boundary is now inherited from the managed landing zone. Nobody touched anything else.
This quarter the assessor reads a detailed implementation statement for SC-7(3), owner, diagram, evidence query, and asks to test it. The owner named has left. The evidence query returns rows from a subnet layout that no longer exists.
The compliance lead says the document is "still accurate, just not in scope this year".
Term bank, not all of these are right
referential integrityschema validationssppoamprofileassessment plan
2.1Name the check family that would have caught it. (two words)
2.2Name the layer holding the stale statement. (one word)
Task 3: Findings with nowhere to go
Scenario sim+60 XP
Name the layer that records what was found, then the layer that tracks the fix.
Incident brief
An internal assessment runs against the production profile and produces 34 findings. They are pasted into a slide, discussed, and the slide is filed in a shared drive.
At the next assessment, 19 of the 34 recur. There is no record of which were remediated, which were accepted, which had a target date, and which owner agreed to any of it: the OSCAL stack ends at the assessment plan.
The programme manager insists remediation is "tracked in Jira", where the tickets exist but carry no control ids.
Term bank, not all of these are right
assessment resultspoamsspprofilecatalogassessment plan
3.1Name the layer that records what the assessment found. (two words)
3.2Name the layer that carries unresolved findings forward. (one word)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
The platform lead hands you a branch where the vendored 800-53 Rev 5 catalog has been edited directly: three control statements rewritten, one parameter value changed inside the catalog file. He describes this as "our tailored baseline".
Rebuild the decision as a profile instead. Reference the source catalog rather than replacing it, adopt the impact baseline the production tenant sits at, select exactly the controls the scope note lists, set the tightened parameter at the profile layer, record why, and state explicitly that the catalog is not edited in place.
Scope note and the branch under review
source catalog: nist-800-53-rev5 (vendored, currently edited in place)
production tenant impact level: moderate
scope note: controls in scope for this profile:
AC-2 account management
IA-2 identification and authentication
AU-6 audit record review
internal access standard: inactive accounts disabled after 15 days
(the catalog default for this parameter is 30 days)
1
2
3
4
5
6
7
8
9
10
11
12
Checks
References the source catalog instead of replacing it
A pull request against the production OSCAL stack touches the catalog, the profile and the SSP in one change. It is due to merge before the assessment window opens, and the author has already had it approved once by a colleague who reviewed it for typos.
Accept the entries that are legitimate tailoring decisions. Reject the ones that damage the stack, whatever the commit message says.
Verdicts are accept or reject. Every rejection needs one reason code from: catalog-edited-in-place | tailoring-without-rationale | broken-control-reference | untracked-parameter.
PR #812: entries under review
O-1 Adds AC-2 to include_controls, rationale cites the internal access standard.
O-2 Rewrites the AU-6 control statement inside the vendored catalog file "so it matches how we review logs".
O-3 Sets the AC-2 inactivity parameter to 15 days at the profile layer, rationale names the standard.
O-4 Removes SC-7(3) from include_controls; commit message reads "n/a", no rationale field recorded.
O-5 Leaves an SSP implementation statement for SC-7(3), which the same PR removes from the profile.
O-6 Pins source_catalog to the published rev5 identifier instead of a local copy path.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Automation & Code
Automating GRC with APIs
Script against Okta, Jira and cloud APIs for evidence: authentication, pagination, throttling and proving the population was complete.
