Security and Threat Models of OSCAL Information Model Flows

[aj-stein-nist]

User Story:

As a security professional, in order to advise my organization on how to the benefits, challenges, and risks of sharing the different data encoded in OSCAL, I would like to have a security model and a generalized threat model to understand how the sharing of certain data and with whom we share it will have impacts to my information system, business unit, division, and agency's information security programs.

Goals:

With the stable release of 1.0.0, the number of organizations, and their security tooling, will increase the use of data sharing outlined by OSCAL. This sharing poses challenges, as a great deal of security documentation is presumed, as a whole, to be sensitive. Via OSCAL document instances or not, there is a presumption that many or most of the security details of an information system or organization cannot be shared, except manually between select individuals, let alone in an automated fashion.

This work will examine the implications of this sharing for different OSCAL document models, the risk impact of their respective data elements, and how they can or cannot be shared with or without modification or redaction.

Dependencies:

N/A

Acceptance Criteria

• A page describing the security model of OSCAL and/or the core OSCAL tooling's software stack (if embedded by others in their tools, not just the OSCAL artifacts themselves)
• A page with a threat model describing common workflows for sharing one or more OSCAL documents across notional trust boundaries representing different personas in common risk-managed assessment and authorization processes (RMF or RMF-like)
• 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]

They are not explicit dependencies, but discussion of the relevance and impact of this work came up when reviewing the long-term implications of #1058, #1059, and #1060 during a weekly work review with Dave.

[aj-stein-nist]

This work was proposed a while back by me, and although it is ambitious and potentially useful, it seems far outside the scope of relevant work for the OSCAL development board. I am opting to close this issue, as sender and receiver, as WONTFIX (or more accurately, cannot do now. :-)