Guidance needed on OSCAL structure (blocking CDMC-to-OSCAL mapping work)

[ojeb2]

Directional Design Decision Required

Context

A team from LSEG are working on providing an OSCAL representation of the key controls from the Cloud Data Management Capabilities (CDMC) spec. This is to provide concrete examples of data management controls that have cross-cloud implementations on AWS, Azure, Google and Snowflake. The LSEG team have been working with Michaela Iorga from NIST on the OSCAL representation but are blocked on a directional decision. We believe other CCC working groups are also potentially blocked on this too.

Description of Problem:

In order to successfully implement the CCC in OSCAL, it is imperative we establish the data model structure. As OSCAL is designed to be flexible, establishing the data model would not only provide a consistent approach to implementation but would provide guidance to the various works streams within the CCC project.

Potential Solutions:

The OSCAL data model can be Risk based, Service based or Threat based.

For context: LSEG believe seen a Risk based taxonomy working well for internal cloud control frameworks, but would like practical feedback from other CCC participants.

Action Required

Please comment to recommend which approach your organisation would find most useful, or mention in the next Thursday working group if not able to comment on-line.

[iMichaela]

Thank you, @ojeb2 .

The OSCAL data model can be Risk based, Service based or Threat based

The representation of the CCC in OSCAL needs to support the process: Risk based (implement the controls identified fro each abstract service/component, mitigate the risk through tailoring of the controls , and report the controls' assessment) or Threat based (tracking the threats the controls are mitigating and allowing to report when a control assessment has findings, which are the threats the controls was mitigating)

The Service based approach is supported by OSCAL Component definitions which identify for each service/component which controls must be implemented. The Component-definitions can be used by CSP as 'playbooks' , and can follow the Risk based or Threat based approach.

The PR #124 aims to demonstrate 2 options fro representing the CCC in OSCAL. Other alternatives can be created once the decision is made.