diff --git a/research-2023/effort-responsibility-sharing/2022-07-05.001.md b/research-2023/effort-responsibility-sharing/2022-07-05.001.md index b1698db..d21668c 100644 --- a/research-2023/effort-responsibility-sharing/2022-07-05.001.md +++ b/research-2023/effort-responsibility-sharing/2022-07-05.001.md @@ -2,6 +2,8 @@ ## Define: Customer Responsibility Model +(Content originally posted to [OSCAL/issues/1336](https://github.com/usnistgov/OSCAL/issues/1336), but posted here for historical purposes.) + ## 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. @@ -90,67 +92,78 @@ Impressions: The following use cases were created: ### Direct + In the first case, consider a responsibility that is passed directly from the provider to customer. ![Control Inheritance-Direct drawio](https://user-images.githubusercontent.com/107055718/180248607-347b9a65-bafc-4e1e-b40e-deeec382978e.png) 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 +| 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. ![Control Inheritance-Shared drawio](https://user-images.githubusercontent.com/107055718/180248643-48d6d5a4-88e5-44d1-af3b-77b64ce0102d.png) -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. +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 +| 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. +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. +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. +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 @@ -198,4 +211,4 @@ Map use case information to existing OSCAL model(s) and identify gaps. # References -No remarks. \ No newline at end of file +No remarks. diff --git a/research-2023/effort-responsibility-sharing/2023-03-08.003.md b/research-2023/effort-responsibility-sharing/2023-03-08.003.md new file mode 100644 index 0000000..1e93e9d --- /dev/null +++ b/research-2023/effort-responsibility-sharing/2023-03-08.003.md @@ -0,0 +1,265 @@ +## Define: Customer Responsibility Model + +## Problem + +As an OSCAL model developer, I need examples of the an SSP that contain content available for export to a responsibility model based on #1336 and #1385. Responds to: https://github.com/usnistgov/OSCAL/issues/1467 + +| Element | Response | +| ------------------------------- | ---------------------------------------------------- | +| Previous Spiral Sequence Number | [2022-07-05.001](2022-07-05.001.md) | +| Spiral Sequence Number | [2023-03-08.003](2023-03-08.003.md) | +| GitHub Project Link | https://github.com/usnistgov/OSCAL/ | +| GitHub Issue # | [722](https://github.com/usnistgov/OSCAL/issues/722) | +| Author(s) | Chris Compton, Ned Goren | +| Impact | | +| Criticality | Significant | +| Scope | Project | +| Audience | Service Providers and Security Practitioners | + +## Constraints + +- This spiral only addresses examples of exports, and not the format of a model for sharing the exports. +- Data in the examples are synthetic, and not based on actual SSP content. +- We encourage contributions of realistic content that has been thoroughly sanitized of any sensitive, or identifiable information. + +## Requirements + +- Produce an example based on the common fields that were identified in OSCAL Issue [1336](https://github.com/usnistgov/OSCAL/issues/1336) and recorded in [Spiral 1](2022-07-05.001.md). +- Produce an example that demonstrates a potential approach that does not require modification to the existing SSP model. (or requires minimal modification). + +## Approach + +- Synthetic responses to implementation requirements were prepared for a set of controls. +- A repository of reusable synthetic controls was created based on work in the BloSS@M project. + - https://github.com/usnistgov/csv-synthetic-controls/tree/feature-oscal-generators (May not be public until reviewed) +- Python scripts were written to support easier experimentation and export of SSP content. + +## Participants + +- No other participants in this spiral, other than the authors. + +# Discover + +## Determination + +The goal of this spiral was to produce examples of exports, one question did arise that if all exportable content was not located under the export assembly, is there still a need to explicitly define which content is exportable? + +Two potential options: + + - The export assembly defines the exported fields. + - An attribute, such as `exportable`, could be added to content to be exported. + +The content of this spiral should be reviewed with those that are interested in meeting on this topic. + +## Constraints and Assumptions + +- We are working with a limited set of controls, so more complex systems with hundreds or thousands exports may have unique needs that are not fully understood in this spiral. +- We only focus on the format of the export, and do not fully explore a shared responsibility scenario. This may need to be considered in a future spiral. + +## Existing Benchmarks, Practices and Prior Art + +- For OSCAL, a responsibility model, is new. +- Current practices use spreadsheets, and this was reviewed as a part of [Spiral 1](2022-07-05.001.md). + +## Analysis + +To help ensure that we do not lose sight of the focus in the examples, we seek the ability to communicate the common fields from the [review of publicly available Customer Responsibility Matrix (CRM) documents](https://github.com/usnistgov/OSCAL/issues/1336). The table is repeated below: + +| 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 | + + +### Single Control Examples + +An example of an export using [Use Case 1: PE-11](2022-07-05.001.md#outcome), based on the approach [outlined in the previous sprial](2022-07-05.002.md#general-approach). + +```yaml +control-implementation: + implemented-requirements: + - uuid: NISTDEMO-IR01-0000-0000-000000000000 + control-id: pe-11 + by-components: + - component-uuid: NISTDEMO-BC01-0000-0000-000000000000 + uuid: NISTDEMO-CD01-0000-0000-000000000000 + 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. + # Export Assembly + export: + description: Infrastructure as a Service - This is actually the redacted content to share for the control. + responsibilities: + - uuid: NISTDEMO-RES1-0000-0000-000000000000 + provided-uuid: NISTDEMO-PRO1-0000-0000-000000000000 + description: >- + Customer fully inherits this control from the Cloud Service Provider (CSP). + # Additional fields + import-ref: NISTDEMO-EXT01-0000-0000-000000000000 + action: fully-inherit + provided: + - uuid: NISTDEMO-PRO1-0000-0000-000000000000 + # Implementation Status Assembly + implementation-status: + - state: implemented + remark: "Optional communication of intent" + description: >- + Customers do not have physical access to any system resources in Provider datacenters. +``` +--- + +An example based on [community feedback](https://github.com/usnistgov/OSCAL-DEFINE/discussions/11#discussioncomment-5336282) to consider an option that uses existing assemblies of the SSP model. This assumes *common fields* with more structured information in the SSP would not typically contain sensitive information, for example, the implementation status of a control. Unstructured fields containing potentially sensitive information use the existing description fields in the export assembly. + +The concern is that any transformation of the SSP into a CRM-style model would have to follow a set of rules to prevent inadvertently publishing unintended information. Placing all exportable content under the export, is a clear intent to publish customer-facing content. + +```yaml +control-implementation: + implemented-requirements: + - uuid: NISTDEMO-IR01-0000-0000-000000000000 + control-id: pe-11 + by-components: + - component-uuid: NISTDEMO-BC01-0000-0000-000000000000 + uuid: NISTDEMO-CD01-0000-0000-000000000000 + 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. + # Implementation Status Assembly + implementation-status: + - state: implemented + remark: "Optional communication of intent" + # Export Assembly + export: + description: Infrastructure as a Service - This is actually the redacted content to share for the control. + responsibilities: + - uuid: NISTDEMO-RES1-0000-0000-000000000000 + provided-uuid: NISTDEMO-PRO1-0000-0000-000000000000 + description: >- + Customer fully inherits this control from the Cloud Service Provider (CSP). + provided: + - uuid: NISTDEMO-PRO1-0000-0000-000000000000 + description: >- + Customers do not have physical access to any system resources in Provider datacenters. +``` + +The remarkable difference is that the implementation-status assembly appears outside of the export assembly, and the action, import-ref changes in the previous example would be omitted. + + +### Synthetic SSP Examples + +An example fully dependent upon the export assembly, and requiring SSP model modifications. + +#### SSP Excerpt | [Full SSP Content](https://gist.githubusercontent.com/Compton-NIST/d8376fb5cf29c093f325c324b36f11f9/raw/SSP.exports.example.a.yaml) + +```yaml + - uuid: 20b8fda3-40da-42c9-ae61-6cf4e610d852 + statement-id: ac-2_smt.f + by-components: + - uuid: d8281cd5-2a8c-4b8f-bd61-52fc8a1a99af + component-uuid: 40fd7704-d074-4f94-8776-397c51c39bfd + description: 'Cloud service provider account management policies and procedures + are followed for creating, enabling modifying, disabling, and removing + accounts. ' + # Export Assembly + export: + provided: + uuid: 5892d1a6-86f4-421c-ac71-81faec29a3f2 + description: Cloud service provider account management policy and procedures + include actions that can be taken. + # Implementation Status Assembly + implementation-status: + state: implemented + remarks: '' + # New assemblies/fields + import-ref: '' + inheritance: + type: full + remarks: '' + responsibilities: + uuid: 3b37d40f-5316-4691-aec3-10a579d9a103 + provided-uuid: 5892d1a6-86f4-421c-ac71-81faec29a3f2 + description: Account management policy and procedures are followed for + managing cloud service provider accounts. + action: '' +``` +--- + +An example using existing fields and assemblies, requiring no SSP model modifications. + +#### SSP Excerpt | [Full SSP Content](https://gist.githubusercontent.com/Compton-NIST/d8376fb5cf29c093f325c324b36f11f9/raw/SSP.exports.example.b.yaml) + +```yaml + - uuid: d5c617c5-2936-4db7-8d59-e78f389f5337 + statement-id: ac-2_smt.f + by-components: + - uuid: 03714ddd-b12a-4b81-a06b-5aa1f9eb9e56 + component-uuid: 58f13c7b-c094-42c0-9e15-133877a1b68c + description: 'Cloud service provider account management policies and procedures + are followed for creating, enabling modifying, disabling, and removing + accounts. ' + # Export Assembly + export: + provided: + uuid: f81abfee-7a07-467b-9642-97ae7dfd7683 + description: Cloud service provider account management policy and procedures + include actions that can be taken. + responsibilities: + uuid: 28b89927-2f1a-4561-9869-853209363c45 + provided-uuid: f81abfee-7a07-467b-9642-97ae7dfd7683 + description: Account management policy and procedures are followed for + managing cloud service provider accounts. + # Implementation Status Assembly + implementation-status: + state: implemented + remarks: '' +``` + +## Outcome + +The examples have been completed based on a single, fully inheritable control, and a set of controls prepared for another project as synthetic data. + +The shared responsibility use case was not prepared for this spiral, so that we could attempt to prepare an SSP using synthetic controls. + +# Interpretation + +## Feasibility + +It appears feasible to use the existing SSP assemblies, but to fully address the common fields, props may be needed. This would assume that implementation-status:state is the only element of the SSP that is exported outside of the export assembly. + +## Risks + +- Without a method to communicate exportable information from the SSP, it is very difficult to share information without exposing the contents of an entire SSP. +- Information could be exposed if content is exported from assemblies that are not specifically marked for export. This could be a significant concern with a large volume of implemented requirements as a part of a more complex system. + +## Resources Required + +- Community Feedback + +## Action + +Recommendations: +- The content of this spiral should be reviewed with those that are interested in meeting on this topic. I believe we have three or four individuals that have expressed an interest in participating in a draft for a responsibility model. +- The next spiral should be an initial exploration of a potential model for the exported content that is shared with others (e.g., customers). +- The addition of the export-related assemblies to the Component Definition model needs to be evaluated. + +# Executive + +TBD + +| Element | Response | +| --------------------------- | -------- | +| Disposition | TBD | +| Concurrence Recorded | TBD | +| Next Spiral Sequence Number | TBD | + +# References + +No references. diff --git a/research-2023/effort-responsibility-sharing/README.md b/research-2023/effort-responsibility-sharing/README.md index 21c618d..a80c530 100644 --- a/research-2023/effort-responsibility-sharing/README.md +++ b/research-2023/effort-responsibility-sharing/README.md @@ -1,6 +1,6 @@ # Define: An Approach to Communicating Responsibilities and Inheritance in OSCAL -> Status: Initiation +> Status: Discovery ## Problem Statement @@ -10,11 +10,13 @@ OSCAL SSP authors need the ability to export particular content pertaining to co ## Spirals -- Not Started +- [Spiral 1: Use Cases](2022-07-05.001.md) +- [Spiral 2: Mapping and Gap Analysis](2022-07-05.002.md) +- [Spiral 3: Export Examples](2023-03-08.003.md) ## Summary -N/A +The current status of this effort is to develop export examples in preparation for future spirals with the community to define a model. ## Presented @@ -22,4 +24,4 @@ N/A ## Feedback -N/A \ No newline at end of file +N/A