usnistgov
Explicit Definition and Linking Approach for Risks to SSP Models (Before SAP, SAR, and POA&M)
User Story:
As an OSCAL user and security practitioner , in order to properly define risks during the categorization, selection, and implementation before a full implementation and a SAP is warranted, I want a consistent, recommended linking structure to define risks in a POA&M early on, throughout the lifecycle of an information system.
Goals:
Based on previous conversation in OSCAL model meetings on the topic of tracking risks and documenting them as part of the system before implementation is complete, given recommendation of that approach from RMF guidance (specifically, I believe this came up as part of RA-3), it would be a worthy consideration to structure those risks from the earliest phase of an information system's formation.
Per discussion in the model meeting, this can be done arbitrarily with rlink usage. That is possible, but less explicit.
Dependencies:
None I perceive at this time, but feedback welcome!
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.
@ohsh6o -- @david-waltermire-nist and I discussed the importance of documenting identified risks in the implementation layer, but the use of a POA&M model might not be appropriate. A similar model might be necessary to be developed or have the SSP expanded to support it. More research is necessary.
Will talk about this as one of the use cases in the Gitter OSCAL/use-cases channel and continue fleshing out this issue later.
One question to address might be, how could a system risk registry be included in or referenced from an OSCAL SSP?
Also, how does a system owner/builder document which controls mitigate which risks? How would an assessor import risks from the system risk registry to further identify and explore risks during an assessment?
One question to address might be, how could a system risk registry be included in or referenced from an OSCAL SSP?
Good questions. I am going to commit and volunteer to come up with notional examples of a risk register. Hopefully we can present them in GitHub in a week's time for community review and potential feedback in a model meeting.
Might be important to provide support for adjustment of the perceived risk ( = risk identified during implementation cycles) based on the observed/found risk ( = risk determined during assessment), which can be higher or lower than the perceived risk. For traceability reasons and in alignment with the 5.31.2022 discussion/requirement of not overwriting/deleting any perceived risk, the information should be linked/referenced. For example, the observed/found risk could reference the latest related perceived risk, and the updated perceived risk could reference the previous description of the perceived risk found in the system risk registry.
After reviewing this topic, it appears there are many key questions about core requirements in this from a research perspective that goes beyond the Further Analysis Needed status, I will set this as DEFINE Research Needed status. /cc @usnistgov/itl-oscal-define