Document NIST SP 800-53 identifiers

[aj-stein-gsa]

User Story:

As a developer of OSCAL-based tools and content, in order to better understand how to analyze and process each group, control, control enhancement, and various part identifiers in different programming languages.

Goals:

When discussing FedRAMP use of the upstream NIST catalogs in this repository and how FedRAMP derives customized catalogs from resolving it with our profiles, we frequently receive developer feedback that it is unclear how the use of separators with -, _, . works for groups versus their controls, control enhancements, and the sub-parts of various kinds across SP 800-53 and SP 800-53A. It would be most helpful to document them in pseudo-code, and their relationship to one another, as implemented today for people to more confidently develop their own processing logic, whether it be Metaschema/Metapath-based or not.

Dependencies:

{Describe any previous issues or related work that must be completed to start or complete this issue.}

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[matoszz]

I came here to open a similar issue as @aj-stein-gsa but he accurately summed up the problem. I would add that it's incredibly confusing that other NIST tools like CPRT have added leading 0's to the control identifiers (ref: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) which then do not match the actual published oscal catalog control identifiers (e.g. ac-1 vs. ac-01 vs. AC-01). Additionally the "zero-padded" control identifier format seemingly introduced parenthesis (AC-02(02)) but the control identifier remains (ac-2.2)

[matoszz]

I'm certain that my request is a lot more complicated than "just update the identifiers" but I also opened an issue on the oscal repository: usnistgov/OSCAL#2100

[iMichaela]

@aj-stein-gsa and @matoszz - Documenting how the IDs were generated from the initial rules the RMF team used in the 800-53 and 800-53A is reasonable. The 800-53 (rev4 and rev5.1.1) are also leveraging propss with name="label" that FedRAMP team insisted must be carried on between versions despite the fact that 800-53rev5.1.1 is no longer maintained in Word/PDF and the therefore the labels became an unnecessary balast in our opinion. We will like to incorporate a complete documentation and are very open to contributions.
@wendellpiez is the 800-53 OSCAL catalog expert and might be able to share useful information.

I came here to open a similar issue as @aj-stein-gsa but he accurately summed up the problem. I would add that it's incredibly confusing that other NIST tools like CPRT have added leading 0's to the control identifiers (ref: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) which then do not match the actual published oscal catalog control identifiers (e.g. ac-1 vs. ac-01 vs. AC-01). Additionally the "zero-padded" control identifier format seemingly introduced parenthesis (AC-02(02)) but the control identifier remains (ac-2.2)

Please note, the latest 800-53 53B and 53A is rev 5.1.1 not rev 5. It is available here for human consumption

[aj-stein-gsa]

@aj-stein-gsa and @matoszz - Documenting how the IDs were generated from the initial rules the RMF team used in the 800-53 and 800-53A is reasonable. We will like to incorporate a complete documentation and are very open to contributions.
@wendellpiez is the 800-53 OSCAL catalog expert and might be able to share useful information.

How do we work together on this issue then?

The 800-53 (rev4 and rev5.1.1) are also leveraging propss with name="label" that FedRAMP team insisted must be carried on between versions despite the fact that 800-53rev5.1.1 is no longer maintained in Word/PDF and the therefore the labels became an unnecessary balast in our opinion.

I cannot find the history about the who in FedRAMP and why, but to keep it professional: if you want to remove the ballast, why do we not remove it? I will circle back with the current FedRAMP Team, but I am not sure if there is currently a reason to keep it now. I will document it in a comment in this issue for posterity.

Please note, the latest 800-53 53B and 53A is rev 5.1.1 not rev 5. It is available here for human consumption

Just to make sure I understand here, the upstream CPRT site content and the OSCAL catalog content in this repository are both 5.1.1 not "Rev 5" or 5/5.0/5.0.0 proper? I just checked because I recalled prepping that material for you and Wendell before my departure. I picked a low profile to look at its metadata as an example, and it looks like 5.1.1. Are we on the same page here?

[iMichaela]

I cannot find the history about the who in FedRAMP and why, but to keep it professional: if you want to remove the ballast, why do we not remove it? I will circle back with the current FedRAMP Team, but I am not sure if there is currently a reason to keep it now. I will document it in a comment in this issue for posterity.

I did remove the labels on the first version of 800-53 v5.1.1 and had to put them back because FedRAMP and other GRC vendors were using them to render the information fro humans in their platforms, tools. It was a big storm then.

[iMichaela]

How do we work together on this issue then?

We can talk after Feb 11 and we will find a way. If the community is involved we can also identify ways to clean the formatting 800-53 rev6.

[wandmagic]

i am in favor of removing any un-needed props, any organization that needs prop labels can add them themselves after downloading the official nist catalogs.

I believe this additional labelling is in the scope of individual organizations maintaining their own baseline profiles.
Even if fedramp needs them, we can put them in the baseline.

[wendellpiez]

There are two distinct things being discussed:

• Documenting how existing IDs in current data sets relate to known identifiers, including how to map them deterministically
• Updating and changing anything in the data set for any (good) reason

The second of these may be very important on its own, but treating it as a blocker for the first one is a way to keep it blocked.

If the goal is only the first, I propose that a volunteer analyst could propose theories and I could respond by testing/validating that theory. Collaboratively: they would write the prose, then I would help them write the XPath. No reason to trust someone's memory.

FWIW a Schematron now in place already validates some expected regularities such as format and contiguity of IDs and expected properties ... anyone with strong XPath could take a look ...

In my view this could be done without raising the huge data governance issues implied by the second task.