Multiple formats used in NIST 800-53 control ID references

sarnold commented 1 month ago

Share the context

Analysis of NIST rev5 control ID references in OpenEmbedded expanded profile revealed some discrepancies when trying to map references to the OSCAL profiles from NIST.

Description of problem:

Using the following to define 800-53 ID formats:

caps with parens and no dots: AC-11(1)
lowercase with dots and no parens: ac-2.12
current rev5 IDs do not use roman numerals anywhere

Proposed change:

remove spaces in ids?
document? rev4/rev5 expected ID format(s)

References:

sarnold commented 1 month ago

Before I get too far in hacking IDs I should ask about the intent here, starting in the gnome lock rule for AC-11 Device Lock where the references key has:

nist@sle12: AC-11(b),AC-11(a),AC-11(1),AC-11(1).1,AC-11.1(iii),AC-11

The first 3 and the last one are valid IDS for the current rev5 catalog and a match for the rule and the .1 appears to come from 53A but I can't find AC-11.1(iii) anywhere.

In the generic nist line there is only one control CM-6(a) which is not a match for the rule at all. How can I tell which NIST ID references are actually rev5?

For now it seems like the (NIST) IDs with extra spaces are all I should try "fixing" but I'm not very certain about that either. Thanks for any feedback!

sarnold commented 1 month ago

To be more specific using examples CM-6 b and CM-7 (a):

should they both have the space removed?

Mab879 commented 1 month ago

Thanks for this issue.

This project currently doesn't have a standard (as you have seen) for this. This is something that we should establish and put in the style guide. I don't have strong opinion on this on any feedback from the community is appreciated.

Another issue is that the references are not versioned. To my best knowledge there are at least 2, if not more, versions of 800-53 in use in this project. While we are at writing the style guide for 800-53 we should at at least think about this issue as well.

sarnold commented 1 month ago

For my current (work) target of generating a controls file using rev5 i decided on a couple of things:

try to use 2 "standard" formats: 1) uppercase(parens) format like the upstream docs, and 2) lowercase.dotted format like oscal content sources
refactored id_xform to be more tolerant/agnostic to both cleanup errors and add zero-padding
migrate from "natural" sort (no padding) to zero-padded and standard python sort

The above is based mainly on comparing the rh nist control files to the oscal/content repo and the nist pub attachments, where the current rev5 controls use mainly the following:

"top-level" controls may or may not have hierarchical sub-controls
if they do, it follows a template for each level such as AC-2(9)(a) => ac-02.09.a
the latest rev5 change added the above zero-padding

cheesy test output from my ad-hoc tools:

tests/test_misc.py::test_xform_id_tolower
ac-01 ac-01
ac-02.11 ac-02.11
ac-02.a ac-02.a
ac-02.09.a ac-02.09.a
ac-03.01 ac-03.01

tests/test_misc.py::test_xform_id_toupper
AC-01 AC-01
AC-02(11) AC-02(11)
AC-02(a) AC-02(a)
AC-02(09)(a) AC-02(09)(a)
AC-03(01) AC-03(01)

Feel free to flame/refactor that ^^ as i only have so much time for this part for right now; it will get bigger over the next few months (for me anyway).

sarnold commented 1 month ago

Finally, when I analyze or generate a list of controls I still need to (manually) verify whether the existing reference/id/rule actually makes sense when compared to the rev5 control text. Anyone got an AI handy?

sarnold commented 4 weeks ago

Also I only have a small number of current data points BUT one customer (a while back) asked for a GPOS STIG and the same customer on a newer project timeline asked for 800-53 rev5. I fully expect the first one to come back with 800-53 rev5 the next time they bring the topic up. I guess my point is that nobody is asking us for rev4 controls.

ComplianceAsCode / content