# Value stream issue management for usnistgov/OSCAL#1910
###### tags: `IssueNotes`, `OSCAL`

## Background
Aligned with [#1688] (https://github.com/usnistgov/OSCAL/issues/1688). See: [Original HackMD](https://hackmd.io/AfAityGDSMSMG74vrzQwDA)

## Organization

This document aims to capture a list of value streams for OSCAL adopters of how to use OSCAL models as part of any system security assurance/assessment, risk management or data governance program. A value stream is a thematic collection of work items, varying in scope of work by quantity or quality (large epics to small issues), related to the same theme in that work.

The list is partial, not exhaustive. We would like to hear from readers and community members on ways they have found to use OSCAL models, together or separately, to accomplish their goals.

## Value streams grouped by use case

[TBD]: Find a way to include the OSCAL models that can be used to accomplish the VS.
:::info
**NOTE:** Each use case is designated with a number to make it easier to reference. Additionally, use cases show which OSCAL models support them with their abbreviations or acronyms, for example CDEF for 'component definition'.
:::

| Use Case | Models |
| -------- | -------- |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Define-catalog-of-controls-or-requirements-VS1" target="_self">UC1</a> | Controls |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Customize-control-statements-VS2)" target="_self">UC2</a> | Control Statements |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Document-policy-requirements-VS3" target="_self">UC3</a> | Policy Requirements |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Express-policy-requirements-VS4" target="_self">UC4</a> | Text |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Document-security-controls-for-system-elements-CDEF-SSP-VS5" target="_self">UC5</a>| CDef, SSP|
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Document-system-implementations-SSP-VS6)" target="_self">UC6</a> | SSP |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Plan-how-to-determine-the-degree-to-which-system-is-compliant-AP-VS7" target="_self">UC7</a> | AP |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Test-implementations-of-controls-or-requirementsAR-VS8" target="_self">UC8</a> | AR |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Track-implementation-findings-POAampM-VS9" target="_self">UC9</a> | POA&M |
| <a href="https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ?view#Implementation-guides-playbooks-for-hardware-firmware-or-software-components-CDef-VS10" target="_self">UC10</a> | CDef |

*[(OSCAL) control statement]: an actionable element in an OSCAL control.
### Define catalog of controls or requirements (UC1)
:::info
(OSCAL) In OSCAL, a control describes and documents a requirement, policy, method, countermeasure or guideline bearing on a system or data security or privacy. Because requirements can be defined at many levels of specificity, many control regimens support information hierarchies within and among controls (for example: _controls_ and _control enhancements_ in NIST SP 800-53), and OSCAL supports this. Controls themselves can often be decomposed into parts or line items, which can be called "control statements."
:::
[ ] 1. Document requirements, controls, or guidelines by representing them as a collection of OSCAL control statements (VS1.1)
[ ] 2. Group control statements into OSCAL controls (VS1.2)
[ ] 3. Group related controls (VS1.3)
[ ] 4. Parameterize particular details of a control statement for reuse as parameters. (VS1.4)
[ ] 5. Parameterize requirement detail templates (VS1.4) <- sorry, I do not get this??

### Customize control statements (UC2)

[ ] 1. Add new actionable detail(s) to control statements (VS2.1)
[ ] 2. Remove actionable detail(s) from control statements (VS2.2)
[ ] 3. Add new control(s), requirement(s) or guidance (VS2.3)
[ ] 4. Remove control(s), requirement(s) or guidance (VS2.4)
[ ] 5. Set or overwrite parameters in control statements. (VS2.5)
[ ] 6. Reorganize control(s) (VS2.6)
[ ] 7. Combine existing control requirements (VS2.7)
[ ] 8. Setting requirement details template(s) with parameters (VS2.8) <- I do not understand this one

### Document policy requirements (UC3)

[ ] 1. Extract requirements from policies and create a list in the form of a catalog of requirements (VS3.1)

### Express policy requirements (UC4)

[ ] 1. Map policy requirements to security controls (VS4.1)
[ ] 2. Document how a policy or porcedure is satisfied by a given set of security or privacy control implementations (VS4.2)

### Document security controls for system elements (CDEF, SSP) (UC5)

[ ] 1. Document how a software, hardware or firmware component implements controls (VS5.1)
[ ] 2. Group two or more components into a functional capabilities (VS5.2)
[ ] 3. Share proof of a policy compliance (VS5.3)

### Document system implementations (SSP) (UC6)
[ ] 1. Import profile (VS6.1)
[ ] 2. Document system characteristics in an SSP (VS6.2)
[ ] 3. Document System implementation (VS6.3)
[ ] 4. Document how system's components implement control or control statements (VS6.4)
[ ] 5. Document system inventory in an SSP (VS6.5)

### Plan how to determine the degree to which system is compliant (AP) (UC7)
[ ] 1. Define data objects that need assessment plan and do not appear in the referenced SSP (VS7.1)
[ ] 2. Define various terms and conditions for the assessment (VS7.2)
[ ] 3. Select Controls, Control Objectives, and Control Methods(VS7.3)
[ ] 4. Select Components to be assessed (VS7.4)
[ ] 5. Identify assets used to perform assessment (VS7.5)
[ ] 6. Document tasks to be performed for the assessment (VS7.6)

### Test implementations of controls or requirements(AR) (UC8)

[ ] 1. Import information about the original plan and define objective, methods and activities not included in the AP (VS8.1)
[ ] 2. Capture the assessment results (starting, ending time, local findings) (VS8.2)
[ ] 3. Capture assessed controls, and objectives (VS8.3)
[ ] 4. Capture attestations and logs (VS8.4)
[ ] 5. Capture observations, risks and findings (VS8.5)

### Track implementation findings (POA&M) (UC9)

[ ] 1. Convey locally found components, inventory items and assets to teh system owner (VS9.1)
[ ] 2. Convey the observations, risks and findings to system owner (VS9.2)
[ ] 3. Document and convey each POAM item to the system owner (VS9.3)

### Implementation guides (playbooks) for hardware, firmware or software components (CDef) (UC10)

[ ] 1. Document in OSCAL how components must be secured, and how controls must be implemented (VS10.1)

## Notes

- Requirements are usually externally or internally imposed mandates such as laws, regulations, contractual obligations and even internal policies

- Controls are safeguards and countermeasures identified and required to be implemented or which are employed to reduce identified risk below the treshole level. Controls are step-by-step procedures applied to address risk.