Feature 800 53 updates

[Compton-US]

Committer Notes

This incorporates the following PRs:

• [ ] https://github.com/usnistgov/oscal-content/pull/220
• [ ] https://github.com/usnistgov/oscal-content/pull/147

It also corrects a few content issues.

All Submissions:

• [ ] Have you followed the guidelines in our Contributing document?
• [ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [ ] Have you squashed any non-relevant commits and commit messages? [instructions]
• [ ] Do all automated CI/CD checks pass?

Changes to Core Features:

• [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
• [ ] Have you written new tests for your core changes, as applicable?
• [ ] Have you included examples of how to use your new feature(s)?

[Compton-US]

When this has been reviewed for other potential issues, we need to do the following to complete the changes:

• [x] Update the document uuid.
• [x] Update the last-modified date.
• [x] Update the +u version increment.
• [x] Regenerate profiles (resolved profiles should reflect text changes in controls.
  • Tested locally. The resolved profiles are generated by GH actions
• [x] Update the resolved profiles root uuid.
  • Tested locally. The resolved profiles' UUIDs are updates by GH actions
• [x] Update the last-modified date for resolved profiles.
  • Updated the profiles' metadata. Tested locally. The resolved profiles' last-modified dates are updates by GH actions
• [x] Update the +u version increment resolved profiles.

[david-waltermire]

Any estimate on when this will get a full release? FedRAMP wants to align the baselines with 5.1.1, but we need this content to do so.

Can we do anything to help?

[iMichaela]

Any estimate on when this will get a full release? FedRAMP wants to align the baselines with 5.1.1, but we need this content to do so.

Can we do anything to help?

@david-waltermire-nist - I provided this information/answer in the chat of the FedRAMP bites today. We are just one step away from finishing it (there are some missing links between assessment-objectives to their control statements that need to go in). We will finish them and review them this week (tomorrow) and release early next week (Monday is my hope, if we do not get any issue with the resolved profiles to capture the text changes for some controls). I also mentioned in the chat that there is only one extra control IA-13 which is not part of any NIST baselines but it might be of interest to FedRAMP to bring it into scope for some use cases since is dealing with identity federation. If the decision is made this is not the case, then the rest of the updates are minimal (text clarifications).

[nikitawootten-nist]

I'll be investigating the cardinality warning today

[david-waltermire]

Happy to see the relationships between the assessment-method and the statement. This is a move in a good direction.

For the assessment-method links that point to the statement, I am not sure depends-on communicates the intended semantics. This is not exactly a dependency relationship. Instead, this is about communicating that the assessment-method provides a means of assessing the statement. Maybe something like assesses or assessment-for would be better?

[iMichaela]

As noted in a comment. It might be worth considering a different link relationship name for the relationships between the assessment-method and the statement. Maybe something like assesses or assessment-for would be better?

I had a similar thought with @david-waltermire-nist when I reviewed @wendellpiez 's PR we incorporated, but believed that was discussed with the RMF team (participants: @aj-stein-nist and @wendellpiez ). I wanted to suggest related-to. I feel rel="related-to" is more generic. Thoughts, @david-waltermire-nist ?

[david-waltermire]

Using related-to is a more abstract version of depends-on or assessment-for. These are both forms of "relations". My leaning is towards a relationship that details the semantic in a more specific way, such as assessment-for.

The problem with being too general is you run into semantic "clashes". Say for example we have the need to both describe the associated statement, and a dependency on another assessment method. If all we have is related-to, we cannot differentiate the relationship types. This is why it is better to be more specific in the relationship types.

[wendellpiez]

Also noting - the advantage of keeping the included updating XSLT here is we can do a global change if wanted, by running this XSLT again (with any mods needed).

The proposed change however is simple enough I would suggest a small refactoring operation in a capable editor (I can demo if called on).

[iMichaela]

Using related-to is a more abstract version of depends-on or assessment-for. These are both forms of "relations". My leaning is towards a relationship that details the semantic in a more specific way, such as assessment-for.

The problem with being too general is you run into semantic "clashes". Say for example we have the need to both describe the associated statement, and a dependency on another assessment method. If all we have is related-to, we cannot differentiate the relationship types. This is why it is better to be more specific in the relationship types.

I see the point you are making. The links are linking an assessment-objective to its statement not the assessment-method.

A highly specific type is valuable only to humans that understand it when processing the information. A tool will not know what to do with the relation unless it is coded to understand it. So a GRC tool developer will have to guess all possible values if the relation is important to be processed or will just ignore it if the value is not understood by the tool. This was the reason behind the proposed generalization - the reuse. In the example you provide above, the "identity" (statement vs another assessment-objective, aka same type of information ) of the element thelink points to could be used by a tool programmatically to infer additional information.

I'll bring this discussion tomorrow to our team and let them decide but the community's input is highly desired. The PR can not stay open for too long since FedRAMP needs the 800-53 rev 5.1.1. This link relation type can be updated at any time in the future should it be proven to not satisfy the GRC tool developers' expectations.

[david-waltermire]

Using related-to is a more abstract version of depends-on or assessment-for. These are both forms of "relations". My leaning is towards a relationship that details the semantic in a more specific way, such as assessment-for. The problem with being too general is you run into semantic "clashes". Say for example we have the need to both describe the associated statement, and a dependency on another assessment method. If all we have is related-to, we cannot differentiate the relationship types. This is why it is better to be more specific in the relationship types.

I see the point you are making. The links are linking an assessment-objective to its statement not the assessment-method.

Indeed. Sorry about that. I somehow switched this around. I'm glad you understood what I was saying.

A highly specific type is valuable only to humans that understand it when processing the information.

I am not looking for a highly specific type, just one that is aligned well to the semantics of the relationship. IMHO, something like assessment-for is a good compromise. It indicates the subject of the link is an assessment method for the target of the link. It isn't tied to SP 800-53, so it can be used in general.

This link needs to be suitable for machine consumption, which is why having a codepoint, i.e. the link "rel", that aligns with the given semantics is important.

A tool will not know what to do with the relation unless it is coded to understand it. So a GRC tool developer will have to guess all possible values if the relation is important to be processed or will just ignore it if the value is not understood by the tool. This was the reason behind the proposed generalization - the reuse. In the example you provide above, the "identity" (statement vs another assessment-objective, aka same type of information ) of the element thelink points to could be used by a tool programmatically to infer additional information.

I believe the assessment-for should be added as a standard link relation in OSCAL. This would allow for standardized implementation in tools. I am happy to provide a PR for this.

I'll bring this discussion tomorrow to our team and let them decide but the community's input is highly desired. The PR can not stay open for too long since FedRAMP needs the 800-53 rev 5.1.1. This link relation type can be updated at any time in the future should it be proven to not satisfy the GRC tool developers' expectations.

Indeed. As a member of the OSCAL community and the FedRAMP OSCAL lead, I'm providing input here in this thread. This relationship is something we want to use at FedRAMP for validation and in our GRC solution. Updating it in the future, would require we change all things downstream that depend on it. This is why I am concerned about getting this right now. We want to rely on this, so we would like it to be stable for long-term use.

[iMichaela]

Indeed. As a member of the OSCAL community and the FedRAMP OSCAL lead I providing input here in this thread. This relationship is something we want to use at FedRAMP for validation and in our GRC solution. Updating it in the future, would require we change all things downstream that depend on it. This is why I am concerned about getting this right now. We want to rely on this, so we would like it to be stable for long-term use.

I'll ask the team to consider the importance to FedRAMP of the group/control/link@rel when linking assessment-objectives to control statements in SP800-53 v5.1.1 to be assessment-for. I can push the change later today.

The catalog does not provide any links from the assessment-methods to control statements -- if this is what you are looking for in SP 800-53 to automate FedRAMP's A&A process. The assessment-methods keep coming back into this dialog and I want to make sure this is not what you are looking for.

The schema allows for locally defined values, and I would not recommend including any other values besides the existing reference one it until we demonstrate other catalogs besides SP 800-53 need assessment-for to be documented. FedRAMP solution will know what to do with assessment-for.

[wendellpiez]

Let's make the improvements - I like the assessment-for representation.

[david-waltermire]

Indeed. As a member of the OSCAL community and the FedRAMP OSCAL lead I providing input here in this thread. This relationship is something we want to use at FedRAMP for validation and in our GRC solution. Updating it in the future, would require we change all things downstream that depend on it. This is why I am concerned about getting this right now. We want to rely on this, so we would like it to be stable for long-term use.

I'll ask the team to consider the importance to FedRAMP of the group/control/link@rel when linking assessment-objectives to control statements in SP800-53 v5.1.1 to be assessment-for. I can push the change later today.

Great! Thank you.

The catalog does not provide any links from the assessment-methods to control statements -- if this is what you are looking for in SP 800-53 to automate FedRAMP's A&A process. The assessment-methods keep coming back into this dialog and I want to make sure this is not what you are looking for.

While this would be helpful, I am happy if any additional work on this is deferred to a future update to move the OSCAL 5.1.1 catalog forward with a release ASAP.

The schema allows for locally defined values, and I would not recommend including any other values besides the existing reference one it until we demonstrate other catalogs besides SP 800-53 need assessment-for to be documented. FedRAMP solution will know what to do with assessment-for.

Ok. Thanks.

[iMichaela]

@david-waltermire-nist - All links were updated per FedRAMP's request to assessment-for. We are planning to release the OSCAL content (NIST SP 800-53 v5.1.1 included) tomorrow, so this is the last chance to ensure no other immediate changes are needed.