CRM/Leveraged SSP Support

[jpower432]

Issue description / feature objectives

For SSPs that inherit controls from leveraged SSPs, support the ability to extract component UUIDs and provided and responsibility statements from a leveraged SSP and import the information into a leveraging SSP.

Caveats / Assumptions

• Assumption: The leveraged SSP would be stripped of information outside of the implemented requirements.
• Assumption: This is a epic-level feature that may require more sub-issues to be filed for full implementation.

Completion Criteria

OSCAL content initialization from leveraged authorizations

We would need a feature that takes an SSP and a parent profile to create the following OSCAL content:

• [x] Create profiles based on what on inheritable + implemented and the remaining controls. https://github.com/IBM/compliance-trestle/issues/1388

  Output -> OSCAL Profile JSON

• [ ] Create a component definition shell. This will need to generate the CSV from a profile with pre-populated controls.

  Output -> CSV

• [x] Create an SSP shell with exportable control information from a leveraged SSP to populate the inherited field under by_components and any responsibility statement UUIDs. This would need to generate the leveraged component information and leveraged authorization under system_implementation as well. https://github.com/IBM/compliance-trestle/issues/1393

Output -> OSCAL SSP JSON

Proposed UX

trestle author profile-inherit --profile my_prof --ssp "my_leveraged-ssp"` -o my_profile
trestle author ssp-inherit --profile my_prof --ssp "my_leveraged-ssp"` -o my_ssp
trestle author component-seed --profile my_prof  -o my_component

flowchart TD
    A[Leveraged SSP] --> B(Controls Delta Profile)
    C[Parent Profile] --> B
    A --> E(SSP Shell)
    B --> D(Component Definition Shell)
    C --> E

OSCAL Component Definitions CRM support

• [ ] Allow ssp-assemble (and ssp-generate?) to populate export information from component definition properties. The export information from the component definition would map directly on to the export fields in the SSP. https://github.com/IBM/compliance-trestle/issues/1397

• [ ] Add Markdown support for exported statements similar to how implementation status is done for component definitions.

SSP Markdown support for responsibility statements

• [x] Add markdown support for satisfied field in SSP. This should have the responsibility information as documented by the leveraged SSP. https://github.com/IBM/compliance-trestle/issues/1398

Additional Resources

https://github.com/usnistgov/oscal-content/pull/26/files#diff-08463cadab48b4e35f46367158c8fedfc967805d1d0f62ab3ff95c1962e8511c

[ancatri]

After a synch w OSCAL, here are a few additional points to consider:

1. On the OSCAL side, their next release will add to the Component Definition (in view of CRM support) the following items

• under implemented_requirements both control and statement level [export][0 or 1]: { … }, => To indicate the control/statement is intended for external consumption / inheritance (only the exported can be used in ROSA SSP) [implementation-status] => [0 or 1]: => To indicate the control/statement readiness (only the implemented can be used in ROSA SSP) The value may be locally defined, or one of the following: implemented: The control is fully implemented. partial: The control is partially implemented. planned: There is a plan for implementing the control as explained in the remarks. alternative: There is an alternative implementation for this control as explained in the remarks. not-applicable: This control does not apply to this system as justified in the remarks.

• under statements [responsible-roles] [0 or 1] => To fix the responsibility at this level

2. On the Agile Authoring side, the above means the following:

• when we do the control_delta between the [AWS] SSP and the [FedRAMP] Profile, only the exported controls can be considered as inherited controls and exempt from implementation
• we need to declare in the ROSA SSP the controls exported for the customer with the responsibility details
• when we generate the [ROSA] SSP from the [AWS] SSP and the [ROSA] component definition, only the SSP exported controls can be considered for the population of the [ROSA] inherited controls

3. On the ROSA side, we need the AWS SSP part with their controls export considerations , not just the list of controls as I initially stated in my Meeting Notes email

[jpower432]

Thanks for adding this information @ancatri.

This seems to result in a few concrete requirements that I could use to define completion criteria for this issue.

1. We would need a feature that takes an SSP or one or more component definitions and a parent profile to allow a consumer to create profiles based on what on inheritable + implemented and the remaining controls.

2. Allow ssp-generate to detect exportable control information from a leveraged SSP to populate the inherited field under by_components. This feature would need to generate the leveraged component information under system_implementation as well as populate any exported responsibility statements and IDs in the satisfied field. Allow ssp-generate to populate export information from component definitions.

3. Add markdown support for control responsibility authoring the Component Definition level and the SSP level.

Update To add some clarification after the community call. The idea would be to only support extracting this information from the component definitions. To move this forward until they are officially part of the Component Definition schema, we will test locally using properties.

[jpower432]

flowchart TD
    A[Leveraged SSP] --Filters--> B(Controls Delta Profile)
    B --Imports--> C[Parent Profile]
    E(SSP Shell) --Inherits--> A
    B --Filters--> D(Component Definition Shell)
    D --Imports--> C
    E --Imports--> C
    B --Filters--> E

cc @ancatri @vikas-agarwal76 Updated diagram based on the community call conversation.

• The controls delta profile should address all controls in the parent profile and separate them by include/exclude fields.
• The controls delta profile is a mechanism for filtering. All SSP and component definitions should reference the original parent profile.