[PROTOTYPE SHARED RESPONSIBILITY MODEL] - Add <components> to <source-ssp> .

[iMichaela]

User Story

Conversation with CNCS, IBM and ReHat resulted in the need of an array of component in the source-ssp in order to preserve the by-component granularity of the inherited controls from leveraged systems.

Goals

The assembly shared-responsibility/source-ssp should also have components [1 to ∞]. At minimum, "this-system" component should be included, and provide the necessary information for the component describing the legacy leveraged SSP. Multiple components will facilitate a finer granularity and ability for the Leveraging system's SSP to be more accurate and not bundle all inherited controls into one component when granular information is available in Leveraged SSP as system-security-plan/control-implementation/implemented-requirement/by-component/provided and ``system-security-plan/control-implementation/implemented-requirement/by-component/responsibility`

<source-ssp ssp-uuid="uuid"> [0 or 1]
      <title>markup-line</title> [0 or 1]
      <published>date-time-with-timezone</published> [0 or 1]
      <last-modified>date-time-with-timezone</last-modified> [0 or 1]
      <version>string</version> [0 or 1]
      <date-authorized>date</date-authorized> [0 or 1]
      <party-uuid>uuid</party-uuid> [1]
      <referenced-profile href="uri-reference"/> [0 or 1]
      <prop name="token" uuid="uuid" ns="uri" value="string" class="token" group="token"> …       </prop> [0 to ∞]
      <link href="uri-reference" rel="token" media-type="string" resource-fragment="string"> … </link> [0 to ∞]
      <remarks>markup-multiline</remarks> [0 or 1]
</source-ssp>

The assembly should look like:

      <title>markup-line</title> [0 or 1]
      <published>date-time-with-timezone</published> [0 or 1]
      <last-modified>date-time-with-timezone</last-modified> [0 or 1]
      <version>string</version> [0 or 1]
      <date-authorized>date</date-authorized> [0 or 1]
      <party-uuid>uuid</party-uuid> [1]
      <referenced-profile href="uri-reference"/> [0 or 1]
      <component uuid="uuid type="string"> [1 to ∞]
            <title>markup-line</title> [1]
            <description>markup-multiline</description> [1]
            <purpose>markup-line</purpose> [0 or 1]
            <prop name="token" uuid="uuid" ns="uri" value="string" class="token" group="token"> … </prop> [0 to ∞]
            <link href="uri-reference" rel="token" media-type="string" resource-fragment="string"> … </link> [0 to ∞]
            <status state="token"> … </status> [1]
            <responsible-role role-id="token"> … </responsible-role> [0 to ∞]
            <protocol uuid="uuid" name="string"> … </protocol> [0 to ∞]
            <remarks>markup-multiline</remarks> [0 or 1]
      </component>
      <prop name="token" uuid="uuid" ns="uri" value="string" class="token" group="token"> …       </prop> [0 to ∞]
      <link href="uri-reference" rel="token" media-type="string" resource-fragment="string"> … </link> [0 to ∞]
      <remarks>markup-multiline</remarks> [0 or 1]
</source-ssp>

Dependencies

none

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.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

[jpower432]

Hi @iMichaela, thank you for adding this issue. Adding component information to the source-ssp will certainly be helpful in allowing granular definition of inherited controls.

I have a question around the utilization of components with a legacy SSP use case. If the source-ssp is not an OSCAL SSP and there are no defined components, would it make more sense to change the cardinality of components under source-ssp to [0 to ∞]? At that point a recipient would only have the choice to bundle the inherited elements under one component. From the recipient point of view what would be the intended usage of this system component as defined in the issue description?

[iMichaela]

Hi @iMichaela, thank you for adding this issue. Adding component information to the source-ssp will certainly be helpful in allowing granular definition of inherited controls.

I have a question around the utilization of components with a legacy SSP use case. If the source-ssp is not an OSCAL SSP and there are no defined components, would it make more sense to change the cardinality of components under source-ssp to [0 to ∞]? At that point a recipient would only have the choice to bundle the inherited elements under one component. From the recipient point of view what would be the intended usage of this system component as defined in the issue description?

I think that you are bringing forward a use case scenario with have not considered thoroughly. The scenarios NIST envisioned for leveraged ATO use case were:

1. OSCAL Leveraged SSP and Leveraging SSP with visibility
2. OSCAL Leveraged SSP (opaque) using OSCAL Shared-Responsibility (SR) instance conveying the information to an OSCAL Leveraging system
3. Legacy leveraged SSP (non-OSCAL) with SR in OSCAL providing the necessary information to an OSCAL Leveraging SSP

The last use case (3) is the one you are raising, and I agree, in this scenario, the SR will not have the necessary information for source-ssp/components, and therefore the cardinality for components should be [0 to ∞].