OSCAL
OSCAL copied to clipboard
Provide Link Relations for by-component links in SSP
User Story:
System-Implementation/Component
and Control-Implementation/implemented-requirements
can both utilize links
to create logical and technical relationships between components and the controls they work with. Currently the Link
assembly provides for an href
and rel
field. The rel
field currently allows any token, but only provides reference
as a suggested or directly allowed-value
tokens.
Other meta-schema assemblies of Link provide more common relation notation
During a discussion the following pseudocode represents a possible use of these tokens
system-security-plan
control-implementation
- implemented-requirements
- control[@id="enc-1"]
- by-component[@component-uuid="#storage-array-uuid"]
- description: implementation narrative
- by-component[@component-uuid="app1"]
- link[@rel="provided-by", @href="#storage-array-uuid"]
- description: encryption is provided by the storage array
Goals:
At minimal, I would like to add provided-by
or satisfied-by
as a possible and valid relation to links defined under the by-component
stanza. This will allow all components to be listed under a control and be able to specific which other components assist in the satisfaction of the control.
- [ ] Need to identify potential implementation scenarios to explore.
- [ ] Simple flat system as described above
- [ ] Hierarchical system using leveraged-authorization where the storage array is provided by the leveraged system, and the app resides in the leveraging system.
- [ ] Component definition scenario where two components have a dependency on their control implementation.
Dependencies:
N/A
Acceptance Criteria
- [ ] All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
- [ ] 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.}
Be sure to add @rel
updated values and relevant constraint
s to check the Goals/AC described above per sprint planning this week.
Per discussion in sprint planning, we should explore whether or not https://github.com/usnistgov/OSCAL/issues/756 as an explicit dependency, we should identify if it is a pre-req for this work.
@Compton-NIST and I met up today and began some very constructive modeling work to make sure we understand the problem and are confident with the solution. Chris/I will post an updated visual representation of the straw-man sample CDEF submitted by the issue creator and update here accordingly soon.
PRed.
- We determined that #756 was not applicable here.
- The use of the doc() function to parse the leveraged-authorization will not go beyond the leveraged SSP. There is a plan to update this function to support the deeper parsing in the future.
- Found a bug that will need to be corrected in this model:
./src/metaschema/oscal_ssp_metaschema.xml:672: <index name="by-component-export-provided-uuid" target="implemented-requirement/by-component/export/provided">
Should be implemented-requirement//by-component
to support statement level, as well.
PR now includes a fix for this: https://github.com/usnistgov/OSCAL/pull/1452/commits/805a1fcc9e0cbc75958ba01bc4f73ca7e759d88e
@aj-stein-nist and @Compton-NIST Was there a plan to produce an example or a few? This wasn't explicitly stated in the goals. If so, it might be good to create a new issue around this. Would one of you create one and reference this issue before we close this.
@aj-stein-nist and @Compton-NIST Was there a plan to produce an example or a few? This wasn't explicitly stated in the goals. If so, it might be good to create a new issue around this. Would one of you create one and reference this issue before we close this.
https://github.com/usnistgov/OSCAL/issues/1539 is queued up for triage and inclusion in future sprints.