Add NIST SP 800-171 r3 (CUI) profiles for RHEL 8, 9, and 10 - #15062
Add NIST SP 800-171 r3 (CUI) profiles for RHEL 8, 9, and 10#15062ggbecker wants to merge 6 commits into
Conversation
A control's 'controls:' list can reference controls from another policy (e.g. 'nist_800_53:ac-2'). Such references resolve against the current product's policies at build time. Derived frameworks like NIST 800-171 reference NIST 800-53 controls that only exist for some products (rhel8/9/10), so building any other product would previously fail with 'policy doesn't exist'. Cross-policy references now degrade gracefully: if the target policy or control isn't loaded for the product being built, the reference contributes no rules instead of aborting the build. Same-policy references are still resolved strictly so typos remain hard errors.
|
@ggbecker: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| CONTROL_RE = re.compile(r"([A-Z]{2})-(\d{2})(?:\((\d{2})\))?") | ||
|
|
||
|
|
||
| def strip_tags(line): |
There was a problem hiding this comment.
According to docs/manual/developer/04_style_guide.md, new Python methods and scripts should have type hints.
There was a problem hiding this comment.
I believe this scrip will be a one time thing to this repository and I will remove it from this pull request before we merge it. Sorry for the noise
| @@ -0,0 +1,33 @@ | |||
| --- | |||
| documentation_complete: true | |||
There was a problem hiding this comment.
Are FMF metadata in Contest updated so that Contest tests will test the new profile?
There was a problem hiding this comment.
Yes, this needs to land in sync with: RHSecurityCompliance/contest#664
Add a single, product-agnostic controls/nist_800_171.yml in which each 800-171 requirement references (via cross-policy 'controls:' entries) the NIST 800-53 controls it was tailored from. At build time these resolve against the current product's nist_800_53 policy, so each requirement inherits the union of rules mapped to its source controls for that product; products without nist_800_53 resolve to no rules. Register the nist-800-171 reference type so rules selected under a requirement automatically receive that requirement id as a reference, mirroring the STIG stigid auto-reference behavior. The control file is derived from the official NIST SP 800-171 r3 publication.
Redefine the cui profile on each RHEL product to select all rules from the generic nist_800_171 control file (nist_800_171:all). Each 800-171 requirement resolves against the product's own nist_800_53 policy, so the profile pulls in the union of rules mapped to the source 800-53 controls for that product. RHEL 8 and RHEL 9 previously defined cui by inheriting ospp with a couple of variable overrides; that inheritance is dropped in favor of the control-file-driven selection. RHEL 10 gains a cui profile for the first time.
Consolidate the two NIST 800-171 reference types into one. The repo already had a 'cui' reference (Controlled Unclassified Information) pointing at NIST 800-171 Revision 2. Rather than maintain a separate 'nist-800-171' reference type for Revision 3, repurpose 'cui' as the single, current NIST 800-171 reference: - Point the cui reference URL at the r3 publication and remove the separate nist-800-171 reference type from constants. - Set reference_type: cui on the generic nist_800_171 control file (and the generator), so rules selected under a requirement receive that requirement id as a 'cui' reference automatically. The cui profile now maps to the cui reference end to end: cui profile -> nist_800_171 control file -> product nist_800_53 -> rules, with each rule stamped with its r3 requirement id.
Remove the 304 superseded manual r2 'cui:' references from rule files now that r2 is superseded by r3 (see previous commit repurposing the cui reference type). Drop now-empty references blocks left behind by the removal.
These rules are selected by the CIS profile but were missing from the CUI (NIST 800-171 r3) profile, because they were listed under NIST 800-53 controls that 800-171 does not reference, even though each rule's own nist reference points to a control that 800-171 does reference: - selinux_state -> ac-3 (Access Enforcement), alongside its already-mapped companions selinux_not_disabled and selinux_policytype - package_firewalld_installed -> sc-7 (Boundary Protection), alongside service_firewalld_enabled - package_xorg-x11-server-common_removed, xwindows_runlevel_target -> cm-7 (Least Functionality) on RHEL 9, alongside the other package removals This closes the CUI-vs-CIS parity gaps that were genuine 800-53 mapping inconsistencies; the remaining CIS-only rules map to controls outside the 800-171 subset and are correctly excluded.
Description
This PR adds NIST SP 800-171 Revision 3 (Controlled Unclassified Information, CUI) profiles for RHEL 8, 9, and 10, built on top of the existing NIST 800-53 control mappings.
What's included
controls/resolution now tolerates foreign control references that don't resolve for a given product, so a product-agnostic control file can reference another policy's controls without hard-failing.controls/nist_800_171.yml— derived from NIST 800-53. Each 800-171 requirement references the correspondingnist_800_53control(s), which resolve at build time against the product's 800-53 policy. Generated viautils/nist_sync/generate_nist_800_171.py.cuireference type consolidation — thecuireference now points at the r3 document (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171r3/NIST.SP.800-171r3.html). Rules selected by the control file are auto-stamped with the requirement id as acuireference. Legacy r2cuireferences were dropped from rule files to avoid conflicting/duplicate references.Testing