Inventory value streams for OSCAL data models

[aj-stein-nist]

User Story

As a developer, integrator, or technologist that is a very novice user to OSCAL, in order to understand minimally viable context for implementing support for it in my software, I want a list of value streams on the website that identify how I use OSCAL models, in part or in whole, as part of my governance program.

Goals

• ~Communicate in plain language, with the minimally requited use of cybersecurity terminology possible, OSCAL's value streams (meaning what governance tasks you can do with OSCAL models)~
• [x] Group use cases for OSCAL models, part or in whole, and how they fit into high-level value streams

NOTE: Examples at a first WIP attempt of doing so can be found in this draft document related to usnistgov/OSCAL#1688.

Dependencies

No response

Acceptance Criteria

• [ ] Socialize the value streams concept with the community to confirm if there are value streams or use cases left out
• [ ] All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• [ ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• [ ] The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

1. Add link to HackMD with draft document with contextual examples of value streams from previous work
2. Plain language requirement was difficult to achieve, removed from goals

[iMichaela]

work is being done here: https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ

[aj-stein-nist]

Moving to Sprint 77.

[iMichaela]

10/09/2023

Finished the proposed value stream inventory. @Arminta-Jenkins-NIST and others, please review https://hackmd.io/zUxatAFfQaesBVGA6eY6jQ . If the content is OK, we can move it here in the issue.

[aj-stein-nist]

Although this is not technically done, it is very close. We will talk about moving this forward in sprint planning.

[aj-stein-nist]

During sprint review today, the team agreed that the inventory itself is complete, which is the core of this issue. New issues to build out the gaps in tutorials needs to be completed outside of this ticket, and acceptance criteria around socialization of this work and publication on the website were not done. These will be added to a follow-on issue.

[iMichaela]

11/13/2023

Sprint review. This issue is done and we will close it after adding checkboxes. Will adjust #1688 to adapt and plan next work

[iMichaela]

Value stream issue management

Background

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

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

:::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
UC1	Controls
UC2	Control Statements
UC3	Policy Requirements
UC4	Text
UC5	CDef, SSP
UC6	SSP
UC7	AP
UC8	AR
UC9	POA&M
UC10	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. :question: Parameterize requirement detail templates (VS1.4)

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. :question: Setting requirement details template(s) with parameters (VS2.8)

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 procedure 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.

[Compton-US]

Work will continue in 1688.