Map use case information to existing OSCAL model(s) and identify gaps.

[Compton-US]

User Story

As an OSCAL model developer, I need to understand the degree to which the SSP model contains sufficient data to generate a customer responsibility matrix (CRM) aligned with the examples from issue #1336.

Goals

Based on last discussion, use the sample use cases to continue research started in #1336.

• Based on the examples created in Research use of a Customer Responsibility Matrix (CRM) model for control element content. #1336, identify where in the SSP model the data elements will exist.
• Identify any gaps in the current SSP model where existing data elements do not fit.
• Determine if the data elements in the SSP are exportable into a CRM by automated means
• Identify follow-on issues
  • Adjustments to the SSP model Metaschemas (SSP Control Implementation Scope/Origination #784)
  • Creation of the CRM model Metaschemas (Customer Responsibility and Inheritance - Export Mechanism #722)
  • Socialization of the updated SSP model and new CRM model

Supporting Issue: #1336

Acceptance Criteria

• SSP examples are produced based on the use cases from Research use of a Customer Responsibility Matrix (CRM) model for control element content. #1336 are created.
• SSP model gaps are identified and documented in this issue.
• All required follow-on issues are identified
• 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.

[aj-stein-nist]

Hey @Compton-NIST! I saw you brought this into current sprint TODO and self-assigned. Given that you are likely going to work this soon (given it will come after #1336) I will mark this "Assigned to Developer" as part of the triage process. Let me know if you have any questions, comments, or concerns.

[Compton-US]

Overview

In #1336, two use cases were documented for the purpose of evaluating the SSP model, and how it supports content that could be tranferred into a new responsibility model for sharing with other parties. This allows sensitive content to remain in the unshared SSP.

This issue was created to 1) apply the use case information and 2) document a recommended approach for populating this information, and 3) identify any gaps in the SSP model. The information is shared below for input and discussion regarding a recommended approach and potential changes to the SSP model.

Another issue will be used to guide the responsibility model development, likely: #722.

Terms

Customer Responsibility Matrix (CRM)

Shared Security Responsibility Model (SSRM)

These are used to describe documents that convey control implementation and responsibility information to others. CRM model has been used to describe the future model that will contain this information. I would recommend naming this model in a way that it broadly supports communication of:

1. a model that is intended for sharing,
2. the controls implemented in the system,
3. the responsibilities addressed by each participating party, and
4. the remaining responsibilities to be addressed.

Controls and Responsibilities Sharing Model, Controls and Responsibilities Communication Model, Responsibility Matrix Model, or similar, is worth consideration.

Leveraged Authorization

Based on the broader capabilities of export in the by-components assembly, documentation likely needs to be updated to generalize leveraged-authorization to indicate not only inheritance of authorization from another party, but to include sharing of responsibility that may, or may not, imply the relationship between the parties.

General Approach

The general approach uses the export section of the by-components assembly that is present in the SSP model. Currently, my understanding is that this is used for leveraged authorization purposes, but this seems to be the best available mechanism for defining and exporting sharable information.

Comments are recommended around a few additions to this portion of the SSP model:

by-components["this-system"]:export:provided

Field	Value
import-ref	This could contain a reference to the catalog, ssp, component or another resposibility model as a reference to the source for this entry. When a control is addressed by multiple organizations, in a shared responsibility situation, this would be important to trace responsibility without parsing multiple layers of models.
implementation-status:state	This would be an assembly with a remark field that allows the provider to define the state of this provided item. For example, the item may be planned, and this would clearly communicate this state to the other party.
inheritance:type	This is an indicator to the degree of implementation of the control (full, partial, etc). This would be the primary means for determining whether responsibility for a control is shared.

by-components["this-system"]:export:responsibilities

Field

Value

action

This seems to be something not identified in the use case. While working through the scenarios, it was unclear whether an action was informational, recommended or required for a particular responsibility. If a provider creates a responsibility entry, the action element clearly communicates what is intended or expected, and could assist with machine interpretation of the intent. action could be intent, or a similar name.

Information Gap Analysis

Use Case 1 - Fully Inherited Control

The first use case from #1336 outlines a control that is fully inherited.

control-implementation:implemented-requirements

Field	Value
control-id	PE-11

by-components["this-system"]:export:provided

This describes, in a sharable way, how the control is addressed by the provider.

Field	Value
import-ref	Reference:model
implementation-status:state	implemented
inheritance:type	full
inheritance:remark	(Optional) IaaS, Moderate Baseline for FedRAMP
description	The infrastructure is supported by multiple uninterruptible power supplies, and a redundant backup generator system capable of continuous operation for an extended period of time.

by-components["this-system"]:export:responsibilities

This describes, in a sharable way, remaining responsibilities for the control. In this case, it communicates that the control is fully inheritable.

Field	Value
provided-uuid	Reference:provided
description	Customers do not have physical access to any system resources in Provider datacenters. Customer fully inherits this control from the Cloud Service Provider (CSP).
action	inherit (or informational)

Note: Under action, inherit would be a useful term that could be interpreted by a machine with clear understanding of the intention of this responsibility statement.

Use Case 2 - Shared Responsibility for a Control

The second use case from #1336 outlines a control where responsibility is shared between three parties.

Cloud Service Provider (IaaS)

control-implementation:implemented-requirements

Field	Value
control-id	si-4

statements

Field	Value
statement-id	si-4.d_stmt

by-components["this-system"]:export:provided

Field	Value
import-ref	Reference:model
implementation-status:state	full
inheritance:type	partial
inheritance:remark	(Optional) IaaS, Moderate Baseline for FedRAMP
description	Provider implements portions of this control for IaaS and PaaS customers. Servers upload logs to a log monitoring tool and the audit logging process for aggregation and analysis. Access to tool and the audit logging process is restricted as specified in the AU family of controls, specifically AU-9. Provider Infrastructure devices are configured to upload their logs to a central repository managed by the Provider Security team. Access to manage the security incident and event management tool used with the Infrastructure is limited to authorized personnel. These personnel are members of a security incident management team.

by-components["this-system"]:export:responsibilities

Field	Value
provided-uuid	Reference:provided
description	The customer is responsible for monitoring customer-deployed resources. The customer control implementation statement should address the protection of intrusion-monitoring tool information from unauthorized access, modification, and deletion.
action	required

Managed Service Provider (PaaS)

control-implementation:implemented-requirements

Field	Value
control-id	si-4

statements

Field	Value
statement-id	si-4.d_stmt

by-components["this-system"]:export:provided

Field	Value
import-ref	Reference:model
implementation-status:state	full
inheritance:type	partial
inheritance:remark	(Optional) PaaS, Moderate Baseline for FedRAMP
description	Monitors customer-deployed resources for events. Access to events are limited to authorized personnel. The platform management team reviews alerts and logs as events are reported to the customer, and conducts daily analysis.

by-components["this-system"]:export:responsibilities

Field	Value
provided-uuid	Reference:provided
description	Application owners are responsible for monitoring their application logs for signs of unauthorized activity according to laws and regulations, and applying heightened scrutiny when there is an indication of increased risk.
action	recommended

Chaining and Tracing of Responsibilities

While working through the shared scenario, it appeared that a means for tracking the chain of responsibilities is needed. This would allow the Application Owner in the scenario to understand which parties have taken responsibility for aspects of the control without parsing multiple layers of models, particularly if the documents are not shared directly (such as an SSP). It also clearly outlines the entity passing on a responsibility in the export.

One question is how to handle this. Two potential examples are depicted below: 1) provided-uuid allows many uuids from the provided section, or 2) a provided-uuid is added to the assembly for provided so that the inheritance of provided responsibilities can be traced.

Next Steps

Feedback and input is recommended here. This ticket will form the basis of the approach used to create the responsibility model in the next issue (#722), and additional follow on work.

[david-waltermire]

Some work to address gaps is being done as part of #784.