-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PROTOTYPE SHARED RESPONSIBILITY MODEL] - Add <components> to <source-ssp> . #2012
Comments
Hi @iMichaela, thank you for adding this issue. Adding component information to the I have a question around the utilization of |
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:
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 |
@iMichaela I created some examples and starting testing the change on a fork. Sharing those links here for all who are interested. |
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 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? |
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: