forked from usnistgov/OSCAL-DEFINE
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Spiral 2, Use case mapping, gap analysis usnistgov#5
- Loading branch information
1 parent
92bf468
commit e8a1193
Showing
1 changed file
with
236 additions
and
0 deletions.
There are no files selected for viewing
236 changes: 236 additions & 0 deletions
236
research-2023/effort-responsibility-sharing/2022-07-05.002.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,236 @@ | ||
| # 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 | | ||
| | ------------------------------- | ---------------------------------------------------- | | ||
| | Previous Spiral Sequence Number | [2022-07-05.001](2022-07-05.001.md) | | ||
| | Spiral Sequence Number | [2022-07-05.002](2022-07-05.002.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 | ||
|
|
||
| 1. This model needs a name that generally encompasses responsibilities, including shared responsibilities. | ||
| 2. At a minimum, this exported content should include customer responsibility statements associated with components and control definition statements. | ||
|
|
||
| ### This sprial: | ||
|
|
||
| 3. Identify any gaps in the current SSP model where existing data elements do not fit. | ||
| 4. Determine if the data elements in the SSP are exportable into a CRM by automated means. | ||
|
|
||
| ## Participants | ||
|
|
||
| - NIST OSCAL Team | ||
|
|
||
| # Discover | ||
|
|
||
| ## Determination | ||
|
|
||
| ## Analysis | ||
|
|
||
| ## Approach | ||
|
|
||
| Gap Analysis | ||
|
|
||
| ## Constraints and Assumptions | ||
|
|
||
| - Map use case information to existing OSCAL model(s) and identify gaps. | ||
|
|
||
| ## Existing | ||
|
|
||
| ### Benchmark/Practice | ||
|
|
||
| ### Prior Art | ||
|
|
||
| ## Analysis | ||
|
|
||
| In [#1336](https://github.com/usnistgov/OSCAL/issues/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: https://github.com/usnistgov/OSCAL/issues/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. | | ||
|
|
||
| ## Outcome | ||
|
|
||
| ### 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 | | ||
| # Interpretation | ||
|
|
||
| ## Feasibility | ||
|
|
||
| ## Risks | ||
|
|
||
| ### 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. | ||
|
|
||
|  | ||
|
|
||
| ## Workarounds | ||
|
|
||
| ## Resources Required | ||
|
|
||
| ## Action | ||
|
|
||
| # Validation | ||
|
|
||
| # Executive | ||
|
|
||
| | Element | Response | | ||
| | --------------------------- | -------------------------------------------------- | | ||
| | Disposition | Continue | | ||
| | Concurrence Recorded | https://github.com/usnistgov/OSCAL-DEFINE/issues/5 | | ||
| | Next Spiral Sequence Number | [2023-03-08.003.md](2023-03-08.003.md) | | ||
|
|
||
| # References | ||
|
|
||
| No remarks. |