Design simplified system lifecycle for example system in tutorials

[aj-stein-nist]

User Story

As a developer or system engineer writing software using OSCAL for security automation, I would like a simpler, example system lifecycle.

In this issue, we will design a simple system lifecycle (as opposed to the implied SDLC of the SP 800-37 Risk Management Framework with the seven steps) to simplify demonstration of different OSCAL use cases.

(NOTE: This issue is part of a value stream for tutorial improvements.)

Goals

Goals

1. Let's model systems and relate to controls.
2. Let's focus on use cases for a simplified lifecycle.
3. We will commit to 1 and 2, but not dogmatically. (We will make tutorials for specific data, tools, methodologies as the need comes up, but that comes up later as advanced material.)
4. Design the tutorials and simplified lifecycle around OSCAL models' features.

Non-goals

1. Building a complex, real-world example system.
2. Designing tutorials around an actual control framework or technical stack (see Goal 3).
3. Building contextual examples into our reference model docs (great idea, separate of this).

Dependencies

No response

Acceptance Criteria

• A design document in HackMD with minimally viable details for the system lifecycle.
• Socialization with the NIST OSCAL Team.
• Presentation of this design in a sprint review for the sprint in which this work is allocated.

Revisions

No response

[aj-stein-nist]

Michaela brought up during issue triage and backlog review to consider using ISO/IEC 27005 or alignment with it in the lifecycle we will design.

[iMichaela]

The diagram below aligns the NIST RMF with the ISO/IEC 27005, so we can discuss the feasibility of using a simplified risk management process derived from ISO/IEC 27005, whit endorsing it.

More details are below:

1. context establishment
2. risk assessment
   a) risk analysis,
   b) risk identification,
   c) risk estimation,
   d) risk evaluation
3. risk treatment
4. risk control
   a) risk acceptance
   b) risk communication
   c) risk monitoring and review

Cons/Pros

[-] 'risk assessment' and 'controls assessment' are different processes but the terminology might be confusing to some people since OSCAL ASSESSMENT Plan and Results models are implying controls assessment not risk assessment per ISO/IEC 27005.
[+] having fewer steps allows a tutorial reader to focus on how to use OSCAL and not the detailed tasks of risk management process.
[ ] TBD

[Compton-US]

Maybe - simplified, and just a slice of the whole:

RISK MGMT	Select	Implement	Assess
DEVELOPMENT	Design	Develop	Test

[aj-stein-nist]

Work on this issue is ongoing but incomplete. It will be needed to move onto the next sprint.

[Compton-US]

Team needs to review and provide feedback by Wednesday (15th) for sprint planning. If all is good we can merge.

[iMichaela]

The proposed simplified system lifecycle:

RISK MGMT	Select	Implement	Assess
DEVELOPMENT	Design	Develop	Test

lists Select (controls) , Implement (controls), and Assess (controls) as Risk Management but it only covers Risk Treatment and Risk Control. As long as the example indicates it, the steps are well aligned with the OSCAL Models. Below is an slightly enhanced system lifecycle which can demonstrate also system's monitoring with OSCAL:

RISK Treatment & Control	Select	Implement	Assess & Authorize	Monitor
DEVELOPMENT	Design	Develop	Test & Deploy	Maintenance & Evaluation

ToDo: Document the simplified system lifecycle in an ADR and close the issue.