generated from usnistgov/opensource-repo
-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Chris Compton
authored
Mar 9, 2023
1 parent
92bf468
commit c650b72
Showing
1 changed file
with
201 additions
and
0 deletions.
There are no files selected for viewing
201 changes: 201 additions & 0 deletions
201
research-2023/effort-responsibility-sharing/2022-07-05.001.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,201 @@ | ||
| # Initiate: | ||
|
|
||
| ## Define: Customer Responsibility Model | ||
|
|
||
| ## Problem | ||
|
|
||
| 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 | | ||
| | ---------------------- | ---------------------------------------------------- | | ||
| | Spiral Sequence Number | [2022-07-05.001](2022-07-05.001.md) | | ||
| | GitHub Project Link | https://github.com/usnistgov/OSCAL/ | | ||
| | GitHub Issue # | [722](https://github.com/usnistgov/OSCAL/issues/722) | | ||
| | Author(s) | Chris Compton | | ||
| | Impact | | | ||
| | Criticality | Significant | | ||
| | Scope | Project | | ||
| | Audience | Service Providers and Security Practitioners | | ||
|
|
||
| ## Constraints | ||
|
|
||
| - 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. | ||
|
|
||
| ## Requirements | ||
|
|
||
| - Identify a few sources of test data sets to use for demonstration. | ||
| - Demonstrate the application of the outline from OSCAL/issues/722. | ||
| - Identify potential issues, or improvements that should be made to support modeling CRM content. | ||
| - 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. | ||
|
|
||
| ## Approach | ||
|
|
||
| - Use Case and Sample Data Creation | ||
|
|
||
| ## Participants | ||
|
|
||
| - NIST OSCAL Team | ||
|
|
||
| # Discover | ||
|
|
||
| ## Determination | ||
|
|
||
| Two use cases were created: one for a full inherited scenario, and the other for a shared responsibility scenario. | ||
|
|
||
| ## Constraints and Assumptions | ||
|
|
||
| No remarks. | ||
|
|
||
| ## Existing Benchmarks, Practices and Prior Art | ||
|
|
||
| Current security practice is to use spreadsheets (or similar documents) from service providers that outline control inheritance and responsibility sharing. | ||
|
|
||
| Current OSCAL models do not explicitly support sharing information from an SSP for a responsibility matrix. The OSCAL model, at minimum should support existing practice so that information can be represented in machine readable format as a part of the OSCAL models. | ||
|
|
||
| ## Analysis | ||
|
|
||
| There is a desire to produce a model that can be used to represent the Customer Responsibility Matrix (CRM) or Shared Security Responsibility Matrix (SSRM) documents. In order to encompass both cases, I will refer to this as a **Responsibility Matrix Model**. | ||
|
|
||
| The **System Security Plan** and **Component Definition** models contain attributes that support the communication of information related to implementation of controls, the status of the implementation and assignment of responsibility to roles. These data address how requirements are satisfied, but lack attributes that support communicating to another party what the remaining responsibilities are for a particular system, component and/or control. | ||
|
|
||
| If the System Security Plan and Component Definition supported the ability to define this responsibility, and the requirements to be passed to other entities, it would likely address the gap that appears to exist for producing a responsibility matrix from these two models. | ||
|
|
||
| After review of four publicly accessible CRM documents, the following fields were common to each: | ||
|
|
||
| | Field | Description | Sample | | ||
| | :--------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------- | | ||
| | Control ID | Typically the identifier of a control imported from a catalog of controls (e.g. NIST 800-53). | AC-8, CP-8 | | ||
| | Control Name | Typically the name/title of a control imported from a catalog of controls (e.g. NIST 800-53). | System Use Notification | | ||
| | Control Description | Typically the description of a control imported from a catalog of controls (e.g. NIST 800-53). | _See 800-53 Catalog_ | | ||
| | Control Origination (Ownership/Responsibility) | Assigns responsibility for a control. | Provider, Shared, Customer | | ||
| | Implementation Model/Entity | Assigns the responsibility for the defined implementation detail to a group or entity. | IaaS, PaaS, SaaS, Customer Provided | | ||
| | Implementation Details | This is a narrative field that outlines the manner and context of implementation of a control's requirements. | _Variable prose, may contain paragraphs_ | | ||
| | Implementation Status | Indicates the extent of progress for a control's implementation. | Implemented, Partially Implemented, Planned, Alternative | | ||
| | Implementation Requirement (Responsibility) | Outlines the required customer actions to address the requirement, or a portion of a requirement when the implementation is a shared responsibility. | _Variable prose, may contain paragraphs_ | | ||
| | Inheritable | Indicates whether the control is inheritable. | Yes, No, Partial | | ||
| | Baseline | Indicates the level of baseline that a control can address. (e.g., FedRAMP) | Low, Moderate, High | | ||
| | Baseline Entity/Framework | While the "Baseline" most relates to FedRAMP, this could relate to other regulatory frameworks | FedRAMP | | ||
|
|
||
|
|
||
| Impressions: | ||
|
|
||
| * Most of the fields above are supported by existing attributes in the models. | ||
| * `Inheritable` and `Baselines` are likely not necessary. These seems addressable through profiles as a part of the OSCAL workflow. | ||
| * `Implementation Model/Entity` and `Implementation Requirement` are likely not fully addressed within the current model attributes in the context of communicating to one of more inheriting entities when implementation actions must be performed to fully satisfy a security control. | ||
| * In many cases, narrative fields such as implementation requirement repeat the same content for multiple controls in a category, for example, "The customer is responsible for appropriately terminating customer personnel." | ||
|
|
||
| ## Outcome | ||
|
|
||
| The following use cases were created: | ||
|
|
||
| ### Direct | ||
| In the first case, consider a responsibility that is passed directly from the provider to customer. | ||
|
|
||
|  | ||
|
|
||
| The data could be similar to: | ||
|
|
||
| Field Value | ||
| Control ID PE-11 | ||
| Control Name Emergency Power | ||
| Control Description Provide an uninterruptible power supply to facilitate [Selection (one or more): an orderly shutdown of the system; transition of the system to long-term alternate power] in the event of a primary power source loss. | ||
| Control Origination (Ownership/Responsibility) Provider | ||
| Implementation Model/Entity IaaS | ||
| Implementation Details 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. | ||
| Implementation Status Implemented | ||
| Implementation Requirement (Responsibility) Customers do not have physical access to any system resources in Provider datacenters. Customer fully inherits this control from the Cloud Service Provider (CSP). | ||
| Inheritable Yes | ||
| Baseline Moderate | ||
| Baseline Entity/Framework FedRAMP | ||
|
|
||
| ### Shared | ||
| In the second case, consider a responsibility that is passed from a cloud service provider to a managed service provider, and finally to the customer. | ||
|
|
||
|  | ||
|
|
||
| The goal of this example is to show information that may need to be documented through some level of shared responsibility. This scenario presents a situation where an organization operates cloud-based systems for customers who focus solely on developing and maintaining applications. This also demonstrates how a customer could understand how responsibilities are addressed for a control, and provides a mechanism to further delegate responsibility to subordinates. | ||
|
|
||
| Field Value | ||
| Control ID SI-4(d) (Statement) | ||
| Control Name System Monitoring | ||
| Control Description Analyze detected events and anomalies | ||
| Control Origination (Ownership/Responsibility) Shared | ||
| Inheritable Partial | ||
| Baseline Low | ||
| Baseline Entity/Framework FedRAMP | ||
|
|
||
| #### Cloud Service Provider (IaaS) | ||
| The Cloud Service Provider states the baseline implementation and the overall responsibilities that must be met to fully address the control. In this case, a distinction is not made for entities that will inherit the control, or what portion of responsibility is assigned to each inheriting entity. | ||
|
|
||
| Field Value | ||
| Implementation Model/Entity IaaS | ||
| Implementation Details 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. | ||
| Implementation Status Implemented | ||
| Implementation Requirement (Delegated Responsibility) 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. | ||
|
|
||
| #### Managed Service Provider (PaaS) | ||
| In this scenario, the Managed Service Provider is presumed to operate services on behalf of the customer. The MSP provides monitoring services for the platform, but not for customer developed applications. The MSP assumes a portion of the Implementation Requirement from the IaaS, and delegates responsibility for application monitoring. | ||
|
|
||
| Field Value | ||
| Implementation Model/Entity PaaS | ||
| Implementation Details 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. | ||
| Implementation Status Implemented | ||
| Implementation Requirement (Delegated Responsibility) 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. | ||
|
|
||
| #### Customer (Application Owner) | ||
| The customer addresses the application monitoring requirement, and while it wouldn't be required, it could also document responsibilities within the organization for an internal responsibility matrix utilized by a development team or business unit. This could be useful for developing a Component Definition for a service or application. | ||
|
|
||
| Field Value | ||
| Implementation Model/Entity Application Owner | ||
| Implementation Details Application and service monitoring must be provided by the development team, and incidents reported within one hour of discovery to the Information Security Officer. Access to events are limited to authorized personnel. | ||
| Implementation Status Planned | ||
| Implementation Requirement (Delegated Responsibility) Application logs are reviewed daily by approved members of the development team, and suspicious events are reported to the Information Security Officer. | ||
|
|
||
|
|
||
| # Interpretation | ||
|
|
||
| ## Feasibility | ||
|
|
||
| - This spiral does not consider feasibility for implementation because further discovery is required to apply the examples to the existing model(s) and determine opportunities for adjustment. | ||
|
|
||
| ## Risks | ||
|
|
||
| - Will need to consider instances of a control under the shared use case, and how this is handled in practice. | ||
| - If the SSP is used as the basis of exporting content, care will need to be taken that sensitive information is not inadvertently published. This should be considered in a future spiral. | ||
|
|
||
| ## Workarounds | ||
|
|
||
| No remarks. | ||
|
|
||
| ## Resources Required | ||
|
|
||
| At this time, the resources required would be a few members of the community to provide feedback, and one OSCAL Team member to take the next set of actions. | ||
|
|
||
| ## Action | ||
|
|
||
| 1. Communicate | ||
|
|
||
| - Recommend sharing the use cases with the community for feedback to enhance or add additional scenarios that may be needed. | ||
|
|
||
| 2. Prototype | ||
|
|
||
| - Recommend applying use case content to the current OSCAL models and discover gaps. | ||
|
|
||
| # Validation | ||
|
|
||
| No remarks. | ||
|
|
||
| # Executive | ||
|
|
||
| Map use case information to existing OSCAL model(s) and identify gaps. | ||
|
|
||
| | Element | Response | | ||
| | --------------------------- | -------------------------------------------------- | | ||
| | Disposition | Continue | | ||
| | Concurrence Recorded | https://github.com/usnistgov/OSCAL-DEFINE/issues/5 | | ||
| | Next Spiral Sequence Number | [2022-07-05.002](2022-07-05.002.md) | | ||
|
|
||
| # References | ||
|
|
||
| No remarks. |