Improved Diagrams to OSCAL Rules Relationship to SDLC and DevSecOps

[aj-stein-nist]

User Story:

As an OSCAL stakeholder, I want to see clearer workflow diagram (as part of documentation for usnistgov/OSCAL#1058, and snapshot draft in usnistgov/OSCAL#1068) to explain the relationship of OSCAL generally, and the rules construct in particular, to the SDLC and DevSecOps lifecycles.

Goals:

The current diagram we would like to improve upon is below.

Some improvements we would like to see in a new derivative diagram, reiterated from the current draft of the document:

We need a figure 8 diagram similar to the above with the following steps. "Development" will be on the left. "Operations" will be on the right. "Security" surrounds the figure 8.

• The "release" step is the transition from "development" to "operations".
• The "adapt" step is the transition from "operations" to "development".
• "development" is provider-focused relative to a system asset, meaning it can be done by both 1) external providers delivering a product to be consumed, or 2) internal teams delivering an aspect of the system.
• "operations" is consumer-focused relative to a system asset, meaning it is consuming from "development".
• There is an artificial seperation between "development" and "operations" in this workflow. These aspects can be performed by the same person or by multiple people depending on the organization applying this workflow.

Development: (provider-focused)

• Adapt (Categorize System)
• Plan (Select Controls)
• Develop (Implement Controls)
• Test/Verify (Assess Controls) -> loop back to plan
• Release (Authorize by provider)

Operations: (consumer-focused)

• Release
• Deliver (Implement Controls and Assess Controls)
• Deploy (Authorize System)
• Operate (Monitor Controls)
• Adapt

Dependencies:

{Describe any previous issues or related work that must be completed to start or complete this issue.}

Acceptance Criteria

• [ ] 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.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[aj-stein-nist]

@david-waltermire-nist is this close to what you had in mind? I added it to the triage list for tomorrow.

[Rene2mt]

Per today's model review, I wonder if the "development (provider-focused)" should be described as follows:

• Plan (Categorize System & Select Controls)
• Develop (Implement Controls)
• Test/Verify (Assess Controls)
• Adapt (Assess or Monitor) -> loop back to Develop (note: this could happen after testing or after release, depending on when risks are identified).
• Release (Authorize by provider)

[wendellpiez]

Here is an SVG path that could be used as the basis for an 'infinity loop' diagram....