As an OSCAL SSP validation developer, in order to ensure consistency with OSCAL changes, I want to ensure validations work against updated versions of the OSCAL information model and data model schemas.

[ohsh6o]

Context:

There have been changes from when the validations were completed with the 1.0.0-milestone3 version of OSCAL was published. At the conclusion of the the 10x Phase 2 Project, we had to pause as 1.0.0-rc1 was released. In the interim, NIST developers have updated the information model and XML data model schemas in 1.0.0-rc2. We will need to port changes in our validations to accommodate for that.

Acceptance Criteria:

• Documentation for developers explaining how this analysis is performed for future major or minor changes: Task Developer documentation on how to map changes in OSCAL SSP data model from one version to another. #61
• Document strategy for handling FedRAMP Extensions (upgraded from previous FedRAMP XML Values), specifically the o:allowed-values currently in use by the rules
• Update mechanism for reading FedRAMP Extension data for o:allowed-values
• Work with FedRAMP PMO on deprecation strategy for older versions and document it: Task Determine deprecate strategy with FedRAMP PMO and document it. #62
• Perform mapping of changes from 1.0.0-milestone3 to 1.0.0-rc1 to 1.0.0-rc2 to completion: Task Refresh mapping differences from RC1 to RC2. #60
• Update rules accordingly for review

[ohsh6o]

Initiated conversation with @mike-stern, @brianrufgsa, and Zach Baldwin, we have begun review of potential changes between revision changes between M3 and RC1 now that usnistgov/OSCAL#758 has landed. Minor changes to FedRAMP extensions will need an update, in advance of documentation and example SSP changes that are forth coming upstream.

Per direction, from @brianrufgsa, will begin validation work against upstream content in oscal-content repo until FedRAMP automation resources are fixed.

[ohsh6o]

Per conversation Gitter it seems a lot of the churn in the FedRAMP extensions is around the missing-response-points assertion, potentially a bug. I will examine more over the next few days. I started sample results in a Gist here, in addition to the necessary review agreed to with Brian this morning, by looking at the up-converter from M3 to RC1 that was just released with 1.0.0-rc1 here in src/release/content-upgrade.

[ohsh6o]

Also per updates in OSCAL Gitter channel yesterday, definitely need to review the changelog updates for M3->RC1 but might be too general.

[ohsh6o]

So I was able to review the release notes (particularly around this part around the OSCAL SSP XML model changes, the converter, and used the xmllint --c14n tool to generate a canonicalized differential between the old example SSP and the "upgraded" example SSP provided by Brian. So I will try and break down the potential issues encountered and how they impact us below.

🤷 - does not impact us yet
⌛ - need feedback from others
✅ - did not break anything for us even though it impacts checks we do
❌ - broke something and it does impact us and changes we do

Changes affecting the catalog and profile XML formats

• Changes to all "part" elements:
  • ⌛ changed the data type of "ns" to "uri" (I feel I might be missing something, so I will check next Tuesday with Brian about this)
• Changes to all "param" elements:
  • 🤷 added the "prop" and "link" elements.
  • 🤷 changed the sequencing of where "link" appears to be consistent with other elements that include "link".
  • 🤷 changed the data type of "usage" from "markup-line" to "markup-multiline"
  • ⌛ changed "constraint" from an element with a text value, to an element with child elements. The text value is now contained in the "description" element. Also changed the "test" attribute to be a sequence of child "test" elements, with the text value now contained in the "expression" child element of "test". This structure will allow for more extension going forward. (I cannot find an example of this but it should help us for things "moving up" from being a FedRAMP extension to OSCAL core, but the ones that matter to us are not defined. Will ask around from Brian and other NIST devs in Gitter next week)
  • 🤷 changed the cardinality of "value" to allow for multiple values". The data type of a value has changed from markup-line to string. (Seem helpful but we are not doing much with it yet.)

Changes to the SSP XML format

• For /system-security-plan/system-characteristics:
  • ⏳ added allowed values for prop/@name, annotation/@name, link/@rel, and responsible-roles/role-id (but @mike-stern say otherwise, I am not sure if that branch is ready for review yet)
• For /system-security-plan/system-characteristics/*/diagram:
  • 🤷 added "annotation"
  • 🤷 changed the data type of "caption" from "string" to "markup-line"
  • 🤷 added allowed values for link/@rel="diagram", which allows for the linking of an image to use for the diagram.
• For /system-security-plan/system-characteristics/system-information/information-type:
  • 🤷 renamed "id" to "uuid"
  • 🤷 changed structure of "information-type-id" to be wrapped by an outer "categorization", which now defines the "system" for all referenced information type identifiers.
  • 🤷 added "annotation"
• For /system-security-plan/system-characteristics/system-information/information-type/*-impact:
  • 🤷 added "annotation" and "link"
• For /system-security-plan/system-implementation/leveraged-authorization:
  • 🤷 defined additional allowed values "implementation-point", "leveraged-authorization-uuid", "inherited-uuid" for prop/@name, which provides traceability to a leveraged SSP
  • 🤷 defined allowed values for link/@rel
• For /system-security-plan/system-implementation/user:
  • ⌛ defined allowed values for annotation/@name and role-id (but @mike-stern say otherwise, I am not sure if that branch is ready for review yet)
• For /system-security-plan/system-implementation/component:
  • 🤷 renamed "component-type" to "type", and updated allowed values
  • 🤷 defined allowed values for prop/@name, annotation/@name, link/@rel, and responsible-role/@role-id
• For /system-security-plan/system-implementation/inventory-item:
  • 🤷 moved "@asset-id" to a required prop/@name
  • 🤷 defined allowed values for prop/@name, annotation/@name, link/@rel, and responsible-role/@role-id
• For /system-security-plan/system-implementation/inventory-item/implemented-component:
  • ✅ renamed "component-id" to "component-uuid"
  • ✅ defined allowed values for prop/@name, annotation/@name, and responsible-party/@role-id
  • ✅ removed "use", since this is capturing similar information to the component's type
• For /system-security-plan/control-implementation/implemented-requirement:
  • ✅ removed "description" (will now remove code for that)
  • ✅ added allowed values for annotation/@name including "implementation-status", "control-origination"
  • ✅ added allowed values for prop/@name including "leveraged-authorization" to indicate if a control implementation is inherited from an underlying authorized system
  • 🤷 added allowed values for responsible-role/$role-id
  • 🤷 changed the sequencing of "set-parameter" and "responsible-role"
• For /system-security-plan/control-implementation/implemented-requirement/by-component:
  • ✅ renamed "component-id" to "component-uuid"
  • ✅ added "export", "inherited", and "satisfied" to support documenting leveraged authorizations
  • ✅ added "remarks" to allow for adding general commentary
  • ✅ changed the sequencing of where "set-parameter" appears
• For /system-security-plan/control-implementation/implemented-requirement/statement:
  • ✅ removed "description" (will now remove code for that)
• For /system-security-plan/control-implementation/implemented-requirement/statement/by-component:
  • ✅ renamed "component-id" to "component-uuid"
  • ✅ added "export", "inherited", and "satisfied" to support documenting leveraged authorizations
  • ✅ added "remarks" to allow for adding general commentary
  • ✅ changed the sequencing of where "set-parameter" appears

[ohsh6o]

Other issues outside the release notes that did or will cause issues:

• o:annotation[@name='implementation-status'] we got lucky with because I had not added back the Registry namespace filter I should have.
• I got caught up with the stmt versus smt thing from Example FedRAMP SSP Statement IDs for Implemented Requirements of Control Implementations Incorrect GSA/fedramp-automation#69 again while fixing this stuff too, but that is all good for now as the resolved profile catalogs in github.com/usnistgov/oscal-content reminded me. :-)
• Both for o:annotation[@name='implementation-status'] and o:annotation[@name='control-origination'] the concept of an allowed-value enum still exists, and the FedRAMP ns namespace tag has been removed, suggesting they have been upstreamed. 🎉 But if they are not extensons, and the allowed values exist, unlike some other items, I cannot find where they are encoded in the oscal_ssp_metaschema.xml file or other metaschema files, even if I want to use them. I will need to discuss with @brianrufgsa and NIST devs, as I feel I am missing something obvious.
• Response points seem to have gone away entirely, which we discussed, but now we have nested o:part objects and nothing to distinguish them.

Before:

            <part id="ac-1_smt.b" name="item">
               <prop name="label">b.</prop>
               <p>Reviews and updates the current:</p>
               <part id="ac-1_smt.b.1" name="item">
                  <prop name="response-point" ns="https://fedramp.gov/ns/oscal"/>
                  <prop name="label">1.</prop>
                  <p>Access control policy <insert param-id="ac-1_prm_2"/>; and</p>
               </part>
               <part id="ac-1_smt.b.2" name="item">
                  <prop name="response-point" ns="https://fedramp.gov/ns/oscal"/>
                  <prop name="label">2.</prop>
                  <p>Access control procedures <insert param-id="ac-1_prm_3"/>.</p>
               </part>
            </part>

After:

            <part id="ac-1_smt.b" name="item">
               <prop name="label">b.</prop>
               <p>Reviews and updates the current:</p>
               <part id="ac-1_smt.b.1" name="item">
                  <prop name="label">1.</prop>
                  <p>Access control policy <insert param-id="ac-1_prm_2"/>; and</p>
               </part>
               <part id="ac-1_smt.b.2" name="item">
                  <prop name="label">2.</prop>
                  <p>Access control procedures <insert param-id="ac-1_prm_3"/>.</p>
               </part>
            </part>

This not a major problem, but I picked ac-1_smt.b, ac-1_smt.b.1, and ac-1_smt.b.2 to prove the point that the response point extension was useful in that I only got the actual response points (ac-1_smt.b.1 and ac-1_smt.b.2) and not ever part (including ac-1_smt.b) and there is no longer a clever way to distinguish them. Did I get this right @brianrufgsa, thoughts?

[ohsh6o]

OK, so per discussion this morning, @mike-stern, I will ask for feedback on Gitter, at least for implementation-status it looks like we finally need Metaschema for the allowed-values/@enum values, as that does not seem to be in XSD outputs for the github.com/usnistgov/OSCAL repo.

[ohsh6o]

Per discussion from David Waltermire from NIST, it appears we will might have to implement this approach sooner rather than later. I will take a stab at it, but I am awaiting more feedback.

Continuing the FedRAMP-specific conversation here.

cc @brianrufgsa

[ohsh6o]

We now need to refresh this story, RC1 is a thing of the pass and RC2 will be dropping shortly.