Add a FedRAMP 'prop' with name="published" for back-matter>resources

[Telos-sa]

This is a ...

improvement - something could be better

This relates to ...

• [X] the Guide to OSCAL-based FedRAMP Content
• [X] the FedRAMP SSP OSCAL Template (JSON or XML Format)
• [X] the FedRAMP OSCAL Validations

User Story

When linking Laws & Regulations in back-matter resources, there is a NIST 'prop' with name="published" which validates the value against the date-time-with-timezone data type.

[ERROR] [/system-security-plan/back-matter[1]/resource[11]/prop[2]/@value] Value '1994' did not conform to the data type '{http://csrc.nist.gov/ns/metaschema/metapath}date-time-with-timezone' at path '/system-security-plan/back-matter[1]/resource[11]/prop[2]/@value'

There are a number of Laws & Regulations from the FedRAMP Laws, Regulations, Standards and Guidance Reference found on FedRAMP Documents & Templates which have the date as just "Month YYYY" or sometimes a string: "As amended".

We are proposing that FedRAMP add a 'prop' with name="published" and ns="https://fedramp.gov/ns/oscal" for back-matter>resources that validates differently than the NIST prop, and allows these shortened date formats and strings such as "As amended".

Goals

Add a FedRAMP 'prop' with name="published" and ns="https://fedramp.gov/ns/oscal" for back-matter>resources that validates differently than the NIST prop, and allows shortened date formats and strings such as "As amended".

Dependencies

No response

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption (https://github.com/GSA/fedramp-automation) 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 information

No response

[aj-stein-gsa]

Thank you for the report, @Telos-sa. We will have to review this request and update it accordingly. If you export this information about the relevant law regulation, how do your staff or users, with your tools or others, use this information on important and analysis? It would seem "1994" or especially "As amended" does not have a meaningful impact to import and subsequent analysis, but I would like to hear more detail on that front before accepting the work item and working it into the backlog.

[Telos-sa]

Telos has identified two user stories for this workflow

1. CSP has not identified any additional laws and regulations - beyond what is scoped and provided by FedRAMP. In this scenario, Telos recommends that CSPs use the FedRAMP provided document as a backmatter resource, without defining each of the laws and regulations (as there are not leveraged).

2. CSP has identified additional laws/regulations/standards/guidance, that they leverage when leveraged components do NOT have a current FedRAMP Accreditation package. In this user story, we recommend that the law/regulation/guidance is identified, and in the component section, a link is created to tie back to the specific external requirement.

Is this what you are looking for? Do you see any other alternative user stories that may need to be taken into consideration before establishing rules and requirements?

[aj-stein-gsa]

In an office hours, with more context provided, I would propose we add a property of prop[@name="accessed"] or prop[@name="last-accessed"] to identify when a resource was last reviewed, irrespective of a specific publication version and date for relevant laws, regulations, and standards (one example provided in the meeting for the latter were ISO 2700x:20yz variant of standards as well, but the former two were really the case of "as amended.")

Most importantly, per @david-waltermire, we should clarify in guidance on automate.fedramp.gov to clearly indicate that digital authorization package owners MUST not resend information as-is in the legacy Word-based templates that apply to FedRAMP. We know those already, but it is not explicit on our website documentation.