[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 ∞].

[jpower432]

@iMichaela I created some examples and starting testing the change on a fork. Sharing those links here for all who are interested.

• SRM Examples from fork. This proposed changes was added to the example in this commit.
• Branch from fork with this proposed change

[iMichaela]

Thank you, @jpower432 power. Was thinking for 2-3 days of the reviews we had and while discussing the SR model with the AWS team, I realized that SR model will be needed not only in the context we discussed:

A) A system is leveraging a previously authorized (leveraged) system ( e.g. a PaaS or SaaS system is deployed on a IaaS from where it inherits controls, and has responsibilities to satisfy in order to inherit the control)

B) There is a need for a CSP that submits a SSP package to FedRAMP, to provide information regarding secure configurations and controls to their future consumers of a FEdRAMP provisionally ATO isystem Assuming an agency selects few services from a larger IaaS ATOed package, to authorize the use of their IaaS, they will have to generate their own SSP by pointing to (or copying if the permissions will change in the future) the services of choice documented as components in the larger FedRAMP SSP. This new (agency's) SSP will define what the agency approved to use but they will also need to know what are the agency's responsibilities regarding all secure configurations and controls. Such responsibilities can exist for controls that are not inheritable by a future PaaS or SaaS. So one way of accomplishing it could be using in the FedRAMP SSP the provided & responsibility with the flag exportable=0 . The agency will add the satisfied into their SSP but will not have an inherited field.
I am concerned this use case could be possibly confused with a leveraged ATO scenario where a CSP prohibits their customers to further provide the inheritable controls by setting provided@exportable=0.

I am looking forward to further discuss it. Would it be possible for the team to also think at this scenario and work an example in the ROSA context?

[jpower432]

Hi @iMichaela,

I want to summarize my understanding of the our discussions on the above consideration you have presented under item B. Please let me know if this aligns with what you were trying to convey in the comment.

Summary

Responsibilities or provided capabilities may changed based on context of how the infrastructure is interacted with (i.e. user vs deployer).

In some cases, a customer deploying infrastructure might not want controls to be inherited by future PaaS or SaaS layers. The SSP author can use the exportable flag within the SSP to denote controls that are specific to their environment and cannot be inherited outside of the local system.

Questions

1. Based on the provided definition of exportable in the prototype documentation, it seems like if the CSP set provided@exportable=0 the default behavior of a tool be to not include it in the SR. Does exportable in the context of an SSP and exportable in the context of SR have a different meaning? If so, would updating the description of exportable under the SR model help avoid the confusion?

To expand:
exportable in the context of an SSP = not safe to share outside of the local system
exportable in the context of an SR = safe to share with direct customer through SRM, but no further

I think once the team has a shared understanding, I think we could work at the scenario with more realistic (but still example system) content.

[iMichaela]

The latest scenario for the test drive of the SRM and in general the data flow is represented below. The purpose of this exercise is to validate the Share Responsibility model and its ability to convey the necessary information in ways that helps GRC tools understand how to manipulate data with minimal human interaction and max output accuracy .

[sunstonesecure-robert]

@iMichaela in the diagram above wouldn't ALL the Controls have the yellow Comp Def arrows, ie in @jpower432 's examples linked, the components are the ones providing the control implementation.

[iMichaela]

@iMichaela in the diagram above wouldn't ALL the Controls have the yellow Comp Def arrows, ie in @jpower432 's examples linked, the components are the ones providing the control implementation.

The model that conveys the data is not applicable only to the controls , but to the entire data set. Sorry I did not clearly represented or document it. So yes, a Component Definition (CDef) artifact, to be useful, would have to represent inheritable and non-inheritable controls - any SSP information available for entities allowed to see it.
An SR instance/artifact is designed to captures all SSP's controls with all by-component .. A CDef allows to cherry pick the services . A CDef could work to convey FedRAMP package info because the package represents an offer not a deployed instance under an agency's account. So FedRAMP SSP is a semi implemented... SR is paired with an SSP ... at the "system" level which in FedRAMP's approach is the total set of services offered by a CSP. A real system is implemented by an agency by cherry picking services an agency needs.

[sunstonesecure-robert]

A real system is implemented by an agency by cherry picking services an agency need

i generally agree - and - this is a very IaaS view of cloud (as correctly shown in your diagram) - and your depiction of PaaS similarly makes sense. However - for SaaS the agency will not have any such cherry picking capabilities. example - the SaaS may use Cloud vulnerability scanning PaaS service ATO, which in turn uses underlying Cloud IaaS hosts. The SaaS CSP SSP RA-5 control should have what as the by-component? The IaaS host? the PaaS Service? Both? none of the above?

[iMichaela]

A real system is implemented by an agency by cherry picking services an agency need

However - for SaaS the agency will not have any such cherry picking capabilities. example - the SaaS may use Cloud vulnerability scanning PaaS service ATO, which in turn uses underlying Cloud IaaS hosts. The SaaS CSP SSP RA-5 control should have what as the by-component? The IaaS host? the PaaS Service? Both? none of the above?

SaaSț SSP will document the leveraged ATOs as components. A system can leverage more than one system.

RA-05 is Vulnerability Monitoring and Scanning. Are you implying that a SaaS should not scan for vulnerabilities if the underlaying PaaS or IaaS are scanning for vulnerability their managed layer? Software can also be full of vulnerabilities... and you know it , so I might miss your point here.

[sunstonesecure-robert]

Are you implying that a SaaS should not scan for vulnerabilities if the underlaying PaaS or IaaS are scanning for vulnerability their managed layer?

No - I'm saying that the SaaS CSP implements vulnerability scanning for their app/code by utilizing the underlying ATO'd vulnerability scanner. The component doing the scanning is ATO'd scanner X which scans CSP component Y which is a web app in this example running in an ATO'd serverless PaaS running on an ATO'd VM service running on an ATO'd physical datacenter server.

[iMichaela]

Are you implying that a SaaS should not scan for vulnerabilities if the underlaying PaaS or IaaS are scanning for vulnerability their managed layer?

No - I'm saying that the SaaS CSP implements vulnerability scanning for their app/code by utilizing the underlying ATO'd vulnerability scanner. The component doing the scanning is ATO'd scanner X which scans CSP component Y which is a web app in this example running in an ATO'd serverless PaaS running on an ATO'd VM service running on an ATO'd physical datacenter server.

So, the control's implementation in the SSP or SR of the leveraged ATO would have to say that the control is provided and indicate what the responsibility is in addition to the implementation description. IF the SSP or SR of the leveraged ATO package does not indicate it, the control is not inheritable, because the infrastructure does not make it available , so the SaaS' SSP will have to implement the control and not inherit it. If the control is inherited, the leveraging system's SSP will document what was provided to them under inherited and how they satisfied the responsibility (if any) under the satisfied assembly.