Customer Responsibility and Inheritance - Export Mechanism

[brian-ruf]

User Story:

As an OSCAL SSP Author, I need the ability to export content from my SSP suitable for my customers to import into their SSP.
At a minimum, this exported content should include customer responsibility statements associated with components and control definition statements.

When the SSP author uses optional syntax to define customer-consumable content about what is inherited, this content must also be included.

Goals:

• Define the syntax for representing the customer responsibility and inheritance content in a stand-alone OSCAL file, suitable for importing into a customer's OSCAL-based SSP.
• Design the mechanism for automatically extracting this content from the SSP.

Dependencies:

This builds on work performed under 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.

[brian-ruf]

Status 24-Sept-2020

Nearly finished the definition in issue #572, and will be turning our attention to this shortly.

[brian-ruf]

THIS WAS ORIGINALLY POSTED TO ISSUE #713. THIS IS A MORE APPROPRIATE LOCATION

Looking for public review and feedback on this comment
The point of the CRM is to expose only the appropriate and necessary SSP content to a leveraging system, when the leveraging system owner is not entitled to see the entire SSP of the leveraged system.

It should also be noted, that while we are using the term CRM, an OSCAL CRM will contain both inheritance and customer responsibility information, as well certain other system details. Some system information would need to be discretionary, while other system information will be required to properly support the cited inheritance and/or customer responsibility information content.

With the SSP syntax for leveraged authorizations now fully drafted an implemented in the OSCAL schema, the next step is to identify what an OSCAL-based CRM must contain. I believe the following represents the high-level information requirements for an OSCAL CRM model:

• metadata [1]
  • same syntax and required flags, fields, assemblies as with all OSCAL files
  • Primary system POC for leveraging systems [1 or more]
  • Authorizing Official POC [1 or more]
  • Other POC information [0 or more]
  • System data center location(s) [0 or more]
• system characteristics [1]
  • System Name [1]
  • System Name Short [1]
  • Unique system identifier (system-id) [0 or more]
  • System description [0 or 1]
    • This could potentially come from the component description for the "This System" component if the full SSP description is not appropriate to share with customers.
    • If we implement an import assembly in component (see below), this could would most appropriately come from that location.
  • Security Impact Level [1 or more]
• system implementation [1]
  • leveraged-authorization [0 or more] (if the leveraged system is also leveraging one ore more systems beneath it, such as SaaS on PaaS on IaaS)
  • component [1 or more]
    • Always at least one component representing the leveraged system itself.
    • Other components included as they pertain to inheritance or customer responsibility statements
    • Each individual component must use its original UUID as it appears in the leveraged system's SSP
    • Minimum required: name and original UUID
    • System owner determines what else is included, but same component syntax is supported with relaxed cardinality
      • Possibility of implementing an export assembly in component, where system owner can specify exactly what component information is shared.
• control implementation [0 or 1]
  • implemented-requirement [1 or more]
    • by-component [0 or more]
      • export (and everything within the import) [1]
    • statement [0 or more
      -by-component [1 or more]
      • export (and everything within the import) [1]
• back-matter [0 or 1]
  • same syntax as with all OSCAL files

NOTE: Where practical, we will try to use the same syntax and relative placement within the CRM as compared to the SSP syntax.

[brian-ruf]

Status 8-Oct-2020

Sketched out information requirements for CRM file and made available for comment.
Our plan is to focus on this following the preparation of the OSCAL release candidate. By late October, we will consider any comments and make a more critical review of the above model, then move to build the OSCAL syntax for the CRM.

[brian-ruf]

For feedback

In today's modeling session, we discussed the idea that "Customer Responsibility Matrix (CRM)" does not fully convey what we intend for this model in OSCAL since it carries authorization information, customer responsibility information, and inheritance information.

We are aware of a few other names out there, and are soliciting feedback as to an appropriate name for this model.
Please respond as a comment to this issue.

[brian-ruf]

Insights

During today's modeling session, two considerations were raised which warrant attention related to:

• Baseline Details; and
• Aggregated Capabilities

Baseline Details

The point was raised that it may not be enough to simply cite the leveraged system's impact level.
The leveraging system needs more context.

Ideally, this OSCAL model should enable the leveraged system owner to share baseline information with some flexibility, such as:

• a URL to the baseline (OSCAL profile) used by the leveraged system
• an attachment (back-matter/resource) of a resolved profile catalog, reflecting the final, tailored control baseline used by the leveraged system
• a human-readable description of the baseline used
• a reference to the organization and/or compliance body on which the leveraged system's baseline is based.

The concept is for the OSCAL model to support any combination of this information, but allow the system owner of the leveraged system to decide how much baseline information to share with leveraging system owners depending on circumstances.

Are there other aspects of the leveraged system's control baseline that OSCAL should support?

Aggregated Capabilities

The point was raised that a leveraged system's owner may not wish to expose the individual components associated with inheritance and customer responsibilities, and should have the option to roll those up into aggregated capabilities.

details of a capability to customers, such as the individual components involved, and prefer the ability to aggregate individual components into a capability for sharing.

A few possibilities were discussed, such as:

• extending component-definition/capabilities syntax to the SSP and allowing the system owner for the leveraged system to create capability definitions for export; or
• enabling some kind of post-processing of the exported content whereby the system owner can aggregate capabilities from the individual components outside of the SSP model.

One key goal of the "CRM" model that should not be lost is the traceability back to the individual components and responsibility/inheritance statements in the leveraged system's SSP for adjudicating officials.
If we offer a way to aggregate individual components into capabilities, we must ensure it does not undermine this traceability.

While I believe our approach can support this method, further analysis is required to ensure this goal is maintained and the best possible solutions are identified.
Feedback is welcome

[ohsh6o]

I'm hugely enthusiastic and definitely want to support this work, let me know how I can help!

[erikjohnson2]

I would note that the ability to consume (ingest) CRM information is useful in the case of FedRAMP customers whether or not they access to the full CSP FedRAMP SSP. The CRM is a useful, very focused artifact/data set that cloud customers can use to establish an Shared Security Responsibility Model (SSRM) baseline for their own cloud service implementation SSP and ATO. The CRM provides two very important sets of information that sets the table for customer implementation and authorization of their cloud service instance, specifically:

1. Identifying the set of FedRAMP controls that the customer is responsible for implementing in whole (Customer Owned controls) or in part (shared controls)
2. Pulling in customer responsibility implementation guidance from the CSP for each control that can be leveraged by the customer in implementing, documenting and assessing their controls in their SSP and ATO package.

I'd also note that the same can be said about the SSRM info in the CSA CCM V4 CSP CAIQ questionnaires (e.g. in the CSA STAR Registry.)