You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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?
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:
OSCAL Leveraged SSP and Leveraging SSP with visibility
OSCAL Leveraged SSP (opaque) using OSCAL Shared-Responsibility (SR) instance conveying the information to an OSCAL Leveraging system
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 ∞].
User Story
Conversation with CNCS, IBM and ReHat resulted in the need of an array of
component
in thesource-ssp
in order to preserve theby-component
granularity of the inherited controls from leveraged systems.Goals
The assembly
shared-responsibility/source-ssp
should also havecomponents [1 to ∞]
. At minimum, "this-system" component should be included, and provide the necessary information for thecomponent
describing the legacy leveraged SSP. Multiplecomponents
will facilitate a finer granularity and ability for the Leveraging system's SSP to be more accurate and not bundle allinherited
controls into onecomponent
when granular information is available in Leveraged SSP assystem-security-plan/control-implementation/implemented-requirement/by-component/provided
and ``system-security-plan/control-implementation/implemented-requirement/by-component/responsibility`The assembly should look like:
Dependencies
none
Acceptance Criteria
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
Revisions
No response
The text was updated successfully, but these errors were encountered: