Skip to content

Add NIST SP 800-171 r3 (CUI) profiles for RHEL 8, 9, and 10 - #15062

Draft
ggbecker wants to merge 6 commits into
ComplianceAsCode:masterfrom
ggbecker:nist-800-171
Draft

Add NIST SP 800-171 r3 (CUI) profiles for RHEL 8, 9, and 10#15062
ggbecker wants to merge 6 commits into
ComplianceAsCode:masterfrom
ggbecker:nist-800-171

Conversation

@ggbecker

Copy link
Copy Markdown
Member

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

  • Cross-policy control references degrade gracefullycontrols/ 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.
  • Product-agnostic control file controls/nist_800_171.yml — derived from NIST 800-53. Each 800-171 requirement references the corresponding nist_800_53 control(s), which resolve at build time against the product's 800-53 policy. Generated via utils/nist_sync/generate_nist_800_171.py.
  • CUI profiles for RHEL 8, 9, and 10 — selecting the rules mapped through the 800-171 → 800-53 chain.
  • cui reference type consolidation — the cui reference 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 a cui reference. Legacy r2 cui references were dropped from rule files to avoid conflicting/duplicate references.

Testing

  • Unit tests, product-stability and profile-stability data updated for all three products.
  • Profile-stability and product-stability tests pass locally.

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.
@openshift-ci

openshift-ci Bot commented Aug 26, 2026

Copy link
Copy Markdown

@ggbecker: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-aws-openshift-platform-compliance f2caa10 link true /test e2e-aws-openshift-platform-compliance

Full PR test history. Your PR dashboard.

Details

Instructions 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.

@Mab879 Mab879 added this to the 0.1.83 milestone Aug 26, 2026
@jan-cerny jan-cerny added New Profile Issues or pull requests related to new Profiles. Highlight This PR/Issue should make it to the featured changelog. RHEL8 Red Hat Enterprise Linux 8 product related. RHEL9 Red Hat Enterprise Linux 9 product related. RHEL10 Red Hat Enterprise Linux 10 product related. labels Aug 27, 2026
CONTROL_RE = re.compile(r"([A-Z]{2})-(\d{2})(?:\((\d{2})\))?")


def strip_tags(line):

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to docs/manual/developer/04_style_guide.md, new Python methods and scripts should have type hints.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are FMF metadata in Contest updated so that Contest tests will test the new profile?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this needs to land in sync with: RHSecurityCompliance/contest#664

@ggbecker
ggbecker marked this pull request as draft August 27, 2026 10:43
@openshift-ci openshift-ci Bot added the do-not-merge/work-in-progress Used by openshift-ci bot. label Aug 27, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge/work-in-progress Used by openshift-ci bot. Highlight This PR/Issue should make it to the featured changelog. New Profile Issues or pull requests related to new Profiles. RHEL8 Red Hat Enterprise Linux 8 product related. RHEL9 Red Hat Enterprise Linux 9 product related. RHEL10 Red Hat Enterprise Linux 10 product related.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants