White House RFI : Question 4 Response

[mcleo-d]

Shared Google Doc for White House RFI Response

Please find the shared Google Doc for White House RFI response below ... -https://docs.google.com/document/d/1qIgjIVQtQgNd-DdhzVia_VKhWa_gsV5maPDQG-KzyXI/edit?usp=sharing

Question 4 : Whitehouse RFI

Third-Party Frameworks – Both the government (for example, through the NIST Cybersecurity Framework) and non-government third parties have developed frameworks and related resources that map cybersecurity standards and controls to cybersecurity outcomes. These frameworks and related resources have also been applied to map controls to regulatory requirements, including where requirements are leveled by multiple agencies.

a. Please identify such frameworks and related resources, both governmental and nongovernmental, currently in use with respect to mitigating cybersecurity risk.

b. How well do such frameworks and related resources work in practice to address disparate cybersecurity requirements?

[mcleo-d]

Sep 28, 2023 Meeting Notes

• https://github.com/finos/common-cloud-controls/issues/9#issuecomment-1735940745

🎶📣 Conversation Transcript

• For Q4 it's quite simply around using Oscal.
• It's a very clear and easy target for for people to achieve compliance, and to Jason's point, achieve security as well, cyber security.
• Is this talking about like NIST and CIS?
• Because it has and non-government third parties that's gonna be MITRE, it's gonna be CERN, that's gonna be CSA and organizations like that?
• They're again looking for a population of what we're using and how valuable it is.
• Compliant Financial Infrastructure is also looking at different standards
• So the related resources that map security standards and controls to do sub security outcomes.
• I mean, it does say related resources. This might be one of those anything that comes to mind list.
• And then the follow up question is almost a key value of like, here's the thing that we thought about when you asked this question. And here's how helpful it was.
• And I mean, this might be an opportunity. Compare and contrast private industry like CSP, guidance versus government and NIST.
• We are looking to standardize and use NIST. Vendors are producing proprietary, and you know very biased opinions towards how to use their stuff and they leave out the gaps and don't address the gaps.
• This could be an opportunity to kind of highlight the need for the CCC. Which is basically this is how you use our services, prescriptively and completely.
• There a number of different types of framework as well. So there's some as an example that CSPs produce which are almost automated from the beginning.
• There's ones like Cs which are interpreted and then turned into automation.
• They open to interpretation.
• And if we're building, you have to do some stuff backing to build. That is that important here? Because that describes how well we can actually use these things. I think easy is again, what we're looking to do machine manage from the beginning.
• Is it automatable? Is the key point we want to make? How easy is that to do?
• Because when you go down that path I mean, you're looking at Scap Scotta. But there's a ton of other things in that area that have been built to basically translate NIST guidance
• And then people building their own prescriptive Ssps that are the translated guidance into specific control settings, and then how to evaluate that in an automated way.
• That's all there. But I think what we really want to address is if we're going down that path.
• The potential and the ease of use or adoption of those things, because overall.
• You could write something all day long, and if it's too complicated, you know, or not prescriptive enough like adoption is, gonna be very hard. And it's not gonna be consistent. That's what we're trying to drive towards is the consistency between our all of our institutions, so we don't have to spend the time and resources to individually interpret it.

👽 Direct Question to Answer / Help Wanted

• The next step is to go offline and actually build that list.
• We should go asynchronous, have a period of asynchronous work, and then come back together to review that.

Next Steps

• FINOS CCC community to help piece the answer for Question 4 in the comments of this GitHub issues for future consolidation.

[TheFoxAtWork]

Apologies i couldn't make the meeting (catching up async). Given the questions posed in #49 , does it make sense to have members annotate here (or in the repo) the existing frameworks and standards they currently adhere to and tag them with various elements so we can answer both questions? It doesn't need to be incredibly detailed but enough that we can develop comprehensive answers to these questions between #49 and #50. I suspect this is something this group will inevitably need if we're going to establish Common Controls.

• for each condition of use, adoption and auditability should have its own corresponding record
• for mitigating, identifying the gap it fails to address in addition to the values in examples

I would also recommend potentially capturing if each entity has additional internal policies/controls that supplement or close gaps where these regulations, frameworks, standards dont cover (not to be confused with the NIST controls that define organizational values and parameters, those are assumed to exist and dont need addressed here.)

Title	Use	Adoption	Auditability	Mitigating
title of framework/regulation/standard	conditions under which it applies	Whole / In part / Modified / NA	Yes - Whole, Manual / Yes - Partial, Manual / Yes - Whole, Automated / Yes - Partial, Automated / No	Complete / Partial (requires: supplemental [external link or mark as Org Specific Policy]) / Negligible (gaps: doesnt consider containerized deployments, missing serverless applications)

[mcleo-d]

This item was closed with https://github.com/finos/common-cloud-controls/issues/9