This research effort is focused on the creation of a model that supports the ability to export content from the System Security Plan (SSP) for customers to import/reference in a separate System Security Plan. This responsibility model is used 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.
| Element | Response |
|---|---|
| Previous Spiral Sequence Number | 2022-07-05.001 |
| Spiral Sequence Number | 2022-07-05.002 |
| GitHub Project Link | https://github.com/usnistgov/OSCAL/ |
| GitHub Issue # | 722 |
| Author(s) | Chris Compton |
| Impact | |
| Criticality | Significant |
| Scope | Project |
| Audience | Service Providers and Security Practitioners |
- Initially, the focus will be on evaluating existing spreadsheets typically shared by service providers to ensure the model will support this aspect of the security practitioner workflow.
- This model needs a name that generally encompasses responsibilities, including shared responsibilities.
- At a minimum, this exported content should include customer responsibility statements associated with components and control definition statements.
- 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.
- NIST OSCAL Team
Gap Analysis
- Map use case information to existing OSCAL model(s) and identify gaps.
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: usnistgov/OSCAL#722.
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:
- a model that is intended for sharing,
- the controls implemented in the system,
- the responsibilities addressed by each participating party, and
- the remaining responsibilities to be addressed.
Controls and Responsibilities Sharing Model, Controls and Responsibilities Communication Model, Responsibility Matrix Model, or similar, is worth consideration.
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.
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:
| 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. |
| 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. |
The first use case from #1336 outlines a control that is fully inherited.
Field Value control-idPE-11
This describes, in a sharable way, how the control is addressed by the provider.
Field Value import-refReference:model implementation-status:stateimplemented inheritance:typefull inheritance:remark(Optional) IaaS, Moderate Baseline for FedRAMP descriptionThe infrastructure is supported by multiple uninterruptible power supplies, and a redundant backup generator system capable of continuous operation for an extended period of time.
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-uuidReference:provided descriptionCustomers do not have physical access to any system resources in Provider datacenters. Customer fully inherits this control from the Cloud Service Provider (CSP). actioninherit (or informational) Note: Under action,
inheritwould be a useful term that could be interpreted by a machine with clear understanding of the intention of this responsibility statement.
The second use case from #1336 outlines a control where responsibility is shared between three parties.
Field Value control-idsi-4
Field Value statement-idsi-4.d_stmt
Field Value import-refReference:model implementation-status:statefull inheritance:typepartial inheritance:remark(Optional) IaaS, Moderate Baseline for FedRAMP descriptionProvider 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.
Field Value provided-uuidReference:provided descriptionThe 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. actionrequired
Field Value control-idsi-4
Field Value statement-idsi-4.d_stmt
Field Value import-refReference:model implementation-status:statefull inheritance:typepartial inheritance:remark(Optional) PaaS, Moderate Baseline for FedRAMP descriptionMonitors 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.
Field Value provided-uuidReference:provided descriptionApplication 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. actionrecommended
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.
| Element | Response |
|---|---|
| Disposition | -- |
| Concurrence Recorded | -- |
| Next Spiral Sequence Number | -- |
No remarks.