Open
Description
User Story:
As an OSCAL SSP Author, I need to extract customer responsibilities from my OSCAL-based SSP and provide an OSCAL file to customers using the component model syntax.
Two common use cases include:
- Leveraged cloud systems, such as where an authorized IaaS or PaaS is selling services to customers who are establishing a SaaS.
- Legacy government data centers where an authorized general support system (GSS) is leveraged by several individual systems within the data center - not all of which have the same system owner.
Background
We are considering three possible scenarios for leveraged authorizations:
- The downstream customer is entitled to have access to the entire SSP of the leveraged system. (Ideal situation - no transform needed)
- The downstream customer is not entitled to have access to the entire SSP of the leveraged system. (The reason for this issue.)
- The downstream customer is authoring their SSP using OSCAL, however, the system being leveraged has no OSCAL-based SSP to adopt. (Must be handled another way.)
In other words, this issue assumes:
- both the leveraged system and leveraging system are using OSCAL for SSP content;
- the leveraging customer is not entitled to have access to the leveraged system's complete SSP; and
- a downstream consumer (such as a leveraging agency) is entitled to have access to both the leveraged and leveraging SSPs, thus would benefit from the ability to reconnect the two, such that an individual control can be adjudicated in the context of both the leveraging and leveraged system's implementation.
Goals:
Create a transform to extract customer responsibility statements from an SSP and transform them to component syntax suitable for delivery to customers. This means the resulting file must:
- Use component syntax, such that the leveraged system's content can be imported into the leveraging client's SSP;
- Includes only the information from the leveraged system's SSP that the leveraging system's SSP author needs to know (and is entitled to know);
- Includes linkages to the leveraged system's full SSP such that a downstream consumer can re-connect the two SSPs for holistic adjudication of individual controls.
- Includes sufficient detail about the leveraged system, to ensure it is identified correctly (system name, authorization date, authorizing official(s), system owner, primary system POC,
Dependencies:
This is related to issue #572.
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
DEFINE Research Needed