Catalog and Profile Versioning Strategy

[ohsh6o]

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the FedRAMP OSCAL Profiles and Catalogs (JSON or XML Format)

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

Per vendor feedback, there needs to be better version information in the profiles in the /o:metadata/o:version field of the respective profiles and catalog. Currently, it is in our catalogs and baselines currently set to 1.3. Additionally, it is only apparent from the o:title field external file naming and directory structure that it is a 800-53 Revision 4 derived profile.

More investigation is needed to better accommodate metadata for downstream users to introspect the XML or JSON and know this information from the model data alone.

Goals:

Users have given feedback that they do not want to have to interpret version information and its relationship to 800-53B baselines (Rev 4 and Rev 5). Introspectable metadata would allow them to know this information without human interpretation and render it usable in programmatic analysis of catalogs and profiles as necessary.

Dependencies:

None known at this time.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

[ohsh6o]

I met with @david-waltermire-nist and @wendellpiez for our weekly tech touch base. Dave and I will do a tech spec next week.

[ohsh6o]

Met with @david-waltermire-nist and we discussed key requirements from FedRAMP that can be generalized out to NIST and likely other organizations authoring similar kinds of compliance baselines. I took design notes and I volunteered to put forth two related issues and advocate for the addition of a series property in metadata to bring together the necessary data elements to complete this work.

[ohsh6o]

Will establish basic release strategy, before defining versioning inside OSCAL artifacts, to start in #96 .

[ohsh6o]

So we have created more explicit release strategy and versioning procedure, but the dataset origin problem will still require some more work in usnistgov/OSCAL#961 as part of the community design and review process. That requires adding explicit props and improving the profile resolution process.

So, to be very clear about AC around this story, this will not be ready for 1.0.0 release, so we will move this out tentatively to the next release for now.

[ohsh6o]

Judging the model review updates and schedule around this, I am removing it from the 1.1.0 milestone because it will likely arrive after the fact for that.

[volpet2014]

FedRAMP now has a release strategy documented. This will update in the guidance when the new 800-53 rev 5 profiles, resolved-profile-catalogs and templates are released.