Spiral 4: Create draft of responsibility model. about oscal-define HOT 10 OPEN

This is a very important thread to thoroughly consider in this spiral: usnistgov/OSCAL#1300

from oscal-define.

Additional input needed to go into the document, but the latest spiral was moved out of my personal fork into the project for visibility, will add changes/updates to the branch referenced below.

https://github.com/usnistgov/OSCAL-DEFINE/blob/research-responsibility-model-spiral-4/research-2023/effort-responsibility-sharing/2023-05-01.004.md

from oscal-define.

Preliminary brief and discussion around CRM support in OSCAL.

briefing-2023-08-23.pdf

from oscal-define.

Consider trying this in working branch as a concept for export.

from oscal-define.

@Compton-NIST The intent of the export is to provide a container for descriptive data that is to be made public, while the data in the containing object can be kept private. This gives SSP authors the ability to have BOTH public and private information. This mirrors capabilities that are available in GRC tools today.

While deprecating the use of export and providing an exportable flag is simple, at face value it looks like the descriptive information can only be public or private. Under this solution, how would an SSP author represent both public and private information? This is not clear from the examples in your briefing.

from oscal-define.

@david-waltermire-nist Thanks for this. More depth is on the way, and I can demonstrate this concept of public vs private. I have a round of feedback to process, and I'll share updates here. Hopefully by end of this week.

from oscal-define.

@Compton-NIST - Please find below some food for thoughts. I summarized the proposal discussed and then try to look at a DB scenario documented as CDef ->used in SaaS SSP -> with provided and responsibilities -> carried into PaaS CRM -> leveraged in SaaS SSP where some responsibilities are satisfied, others are passed on to -> SaaS CRM for the Client SSP.

Let's discuss tomorrow some concerns I tried to capture. I included the usnistgov/OSCAL/#1300 issue to discuss it since it makes sense for the CRM to document the implementation-status similar to the SSP.

from oscal-define.

Latest briefing on state of the modeling.

Note that there is awareness of the uuid concerns noted above, but for now I'm assuming CDef as a pass through for the identifiers that should exist in the SSPs. I'm minimized those in the diagrams to focus on the essential parts. Technically, the CDef should not be required if full SSPs are shared.

briefing-2023-08-31.pdf. See below.

from oscal-define.

Updated with corrections to a few identifiers in the Application Owner SSP. briefing-2023-08-31.pdf

from oscal-define.

To Do:

• Need to add context in the SSP and CDef models so that visitors to the reference understand the intentions in the prototype.

from oscal-define.