Blocker Clearing for OSCAL & Related Design Questions

[eddie-knight]

Feature Request

This was drafted in collaboration with @iMichaela.

This may relate to #131.

Description of Problem:

We currently have a blocker for OSCAL development stemming from a lack of clarity around the FINOS' assurance process which needs to be supported by the information captured in the CCC catalog and the way the information is represented in OSCAL.

Potential Solutions:

We should have a dedicated design session with the maintainers, steering committee, and any interested community members to dive into this issue and clear the blocker.

Before the design session, decisions need to be made and considerations need to be addressed for the design session to be efficient, and for all of us, collectively, to move the project forward.

Additional Considerations

Decisions that would trigger different approached for representing the catalog in OSCAL:

• Content that needs to be represented:
  • [ ] 1.Threats mitigated by logical controls
  • [ ] 2. Mitigations implemented by logical controls
  • [ ] 3. Logical Controls
  • [ ] 4. Guidance (generic implementation guidance) - Note: service specific guidance can be captured in a Component Definition and not a Catalog.
  • [ ] 5. Examples (implementation examples)
  • [ ] 6. Control objectives (useful in assessing the outcome of a control)
  • [ ] 7. Assessment methods accepted for each control
  • [ ] 8. Something else (e.g. metrics)
• Assessment process details that can affect the way the information is represented
  • [ ] A certification/assessment process will only focus on the logical controls and report their status
  • This approach can simplify the CCC Catalog by focusing only on the logical controls and related info (3 and after from the above list) and a resilience analysis can be performed (automatically) using either a "Catalog" of Mitigations annotated with the Threats info and links to MITRE ATT&CK, mapped in OSCAL to the CCC catalog OR Threats & Mitigations - mapped to - CCC Controls. The distinction is in how the reporting is expected (e.g. which mitigations are properly implemented OR which threats are properly defended)
  • [ ] A certification/assessment process will extend to analyzing the resilience of the system incorporating the threats and mitigation.
  • This approach will have to have all the necessary information in one OSCAL CCC Catalog (all 1 through 8, from the above list).
• Other OSCAL information: Component Definitions for each service. (The following decision needs to be made) FINOS intends to generate and maintain:
  • [ ] OSCAL Profiles for each service
  • (aka the list of CCC Controls a service needs to implement and any necessary tailoring of the controls for each service).
    • Note: a profile can be 'resolved' into a mini Catalog for each service.
  • [ ] OSCAL Component Definitions for each service
  • (aka Detailed guidance , for each service , of how logical controls should be satisfied)
  • This will allow to be more specific per service, as opposed to the generic guidance listed above in item 4.)

Decisions that would affect who does what and where the work takes place:

• Where this information (Threats, mitigations, logical controls ...) will be collected in a format equally friendly to humans to review and update, AND to OSCAL converter tool to generate OSCAL. Suggestions:
  • [ ] Markdown maintained in the GitHub (updates done through reviewed PR)
  • [ ] Others (feel free to suggest)
• Who develops the conversion tool (which group assumes the responsibility, which developer(s). The tool should be developed in GitHub, Actions (CI/CD pipeline) should be used to validate generate content upon each release. Documentation needs to be created for anyone to know how to use it.
  • [ ] OSCAL WG
  • [ ] MITRE /Threats WG
  • [ ] Taxonomy
  • [ ] New group

[zeal-somani]

Would love to participate in the follow - up discussion on design intent of control catalog.

[iMichaela]

@eddie-knight -- The issue was update, per the 3/7/2024 discussion. Anyone should feel free to enhance and add (or delete) information above.

[mlysaght2017]

Would love to be part of follow-up call on this

[mlysaght2017]

See Security Control Framework Mappings to ATT&CK repo: https://github.com/center-for-threat-informed-defense/attack-control-framework-mappings/tree/main

and project summary: https://mitre-engenuity.org/cybersecurity/center-for-threat-informed-defense/our-work/nist-800-53-control-mappings/

Scoping decisions made for the NIST-800-53 to ATT&ACK use case are worth discussing: https://github.com/center-for-threat-informed-defense/attack-control-framework-mappings/tree/main/frameworks/attack_12_1/nist800_53_r4

[eddie-knight]

Thanks for adding context @iMichaela and the additional resources @mlysaght2017. This will help accelerate things a lot.

I'm also going to be bringing another proposal/PR to Tuesday's Steerco call related to overall project structure, which should dramatically streamline this design effort.

[iMichaela]

See Security Control Framework Mappings to ATT&CK repo: https://github.com/center-for-threat-informed-defense/attack-control-framework-mappings/tree/main

and project summary: https://mitre-engenuity.org/cybersecurity/center-for-threat-informed-defense/our-work/nist-800-53-control-mappings/

Scoping decisions made for the NIST-800-53 to ATT&ACK use case are worth discussing: https://github.com/center-for-threat-informed-defense/attack-control-framework-mappings/tree/main/frameworks/attack_12_1/nist800_53_r4

Great initiative, but I have concerns over the 800-53 version . Rev 4 is obsolete. WE are at Rev 5 (available in OSCAL) and getting ready fro another update, Rev 6 (sometimes this year or so).

[iMichaela]

@eddie-knight and team - PwC UK led by Tom Nash thomas.nash@pwc.com delivered a fantastic end to end controls assessment automation with OSCAL. Tom agreed to present to this team their pilot so the team gets a better understanding of OSCAL and the processes that can leverage it. Please let me know if I should facilitate it.

[eddie-knight]

Awesome @iMichaela! Very happy to discuss this on the steerco call tomorrow.

[iMichaela]

@eddie-knight - please let me know if you need my support in the steering committee meeting for this issue. I can try to free myself and join.

[eddie-knight]

Thank you @iMichaela! I think your notes here should be sufficient if you're not available.

If there's anything we can't tackle, we'll try to use this issue or a followup meeting to address it further.

[zeal-somani]

From the discussion on 3/14, some key decisions need to be captured for the next WG meeting about the outcome from FINOS CCC work such as

• group controls by mitigation
• group controls by threat
• group controls by NIST control family
• least common denominator / a set of controls that will be part of CCC

[iMichaela]

From the discussion on 3/14, some key decisions need to be captured for the next WG meeting about the outcome from FINOS CCC work such as

• group controls by mitigation
• group controls by threat
• group controls by NIST control family
• least common denominator / a set of controls that will be part of CCC

@zeal-somani can you elaborate on the note above? In particular the statement referring to grouping controls by NIST family. NIST 800-53 catalog is already represented in OSCAL, and I do not recommend doing it again. Also multi-grouping is not possible in the context of one catalog.

[github-actions[bot]]

This issue will be closed as stale in 7 days. Please update this issue if it is still needed.