search

finos / common-cloud-controls

FINOS Common Cloud Controls
https://www.finos.org/common-cloud-controls-project
Other
32 stars 35 forks source link

November 9th 2023 Common Cloud Controls - OSCAL Representation of FINOS CCC #90

Closed mcleo-d closed 10 months ago

mcleo-d commented 11 months ago

Date

November 9th 2023 - 12pm ET / 5pm GMT

Untracked attendees

Meeting notices

Agenda

Zoom info

Join Zoom Meeting https://zoom.us/j/98254617376?pwd=aGV6VzZQOTg3MHptY0tkZHRVSUsxUT09

Meeting ID: 982 5461 7376 Passcode: 305874

Dial by your location • +1 719 359 4580 US • +1 253 205 0468 US • +1 253 215 8782 US (Tacoma) • +1 301 715 8592 US (Washington DC) • +1 305 224 1968 US • +1 309 205 3325 US • +1 312 626 6799 US (Chicago) • +1 346 248 7799 US (Houston) • +1 360 209 5623 US • +1 386 347 5053 US • +1 507 473 4847 US • +1 564 217 2000 US • +1 646 558 8656 US (New York) • +1 646 931 3860 US • +1 669 444 9171 US • +1 669 900 6833 US (San Jose) • +1 689 278 1000 US • 855 880 1246 US Toll-free • 877 369 0926 US Toll-free • +1 438 809 7799 Canada • +1 587 328 1099 Canada • +1 647 374 4685 Canada • +1 647 558 0588 Canada • +1 778 907 2071 Canada • +1 780 666 0144 Canada • +1 204 272 7920 Canada • 855 703 8985 Canada Toll-free

Meeting ID: 982 5461 7376

Find your local number: https://zoom.us/u/acPjHdY2IO

mcleo-d commented 11 months ago

James McLeod / FINOS

nas-hub commented 11 months ago

Naseer Mohammad / Google

rachkim00 commented 11 months ago

Rachel Kim / Google

eziogas-scottlogic commented 11 months ago

Euthyme Ziogas / Scott Logic

smendis-scottlogic commented 11 months ago

Sonali Mendis / Scott Logic

ianmiell commented 11 months ago

Ian Miell, Container Solutions, ianmiell

eteridvalishvili commented 11 months ago

Eteri / FINOS

iMichaela commented 11 months ago

Michaela Iorga/ NIST/OSCAL

davidstonegoogle commented 11 months ago

David Stone / Google

rgriffiths-scottlogic commented 11 months ago

Robert Griffiths - Scott Logic

crawfordchanel commented 11 months ago

Chanel Crawford - Citi

robmoffat commented 10 months ago

Minutes:

CCC Whitepaper Feedback

MI: Critique of OSCAL in the in the white paper. https://github.com/finos/common-cloud-controls/blob/main/docs/Citi-Contributed-White-Paper/Financial-Services-Common-Cloud-Controls-Standard-v1.0-(for%20publication).pdf

MI: Issues around the validity of the OSCAL in the white paper - went through the JSON Schema for the example. Some cardinality details completely missing. Current version is 1.1.2

MI: Controls need to have IDs. Controls have parameters (e.g. length of password), guidelines constraints. Here, we are not using parameters in the right way.

MI: Links should have been used to link back to mitre attacks.

MI: Groups of controls are a thing.

MI: Back matter allows you to document resources (like references).

MI: Controls have children. You can construct them hierarchically.

RM: Who came up with the OSCAL in the white paper?

MI: Someone at Citi, not sure who.

JM: This was Jason Neilsen.

RM: Is this a good approach., though?

MI: yes, I don't see anything wrong with this approach.

RM: Who is picking this up next and working towards the "Steel Thread"?

MI: Rachel Kim. But where will different teams collaborate? This will be hard with a lot of data.

FB: Having a working repo would be a good idea.

MI: We need to configure that.

RM: I can help coordinate the FINOS side of this.

JM: RDS hardening is a Q1 priority. A point was raised about moving too quickly about software for creating OSCAL. Common Cloud Controls is creating OSCAL across all CSPs.

MI: Any tools properly using OSCAL should be able to interoperate. I write OSCAL in an IDE. I use VS Code (for YAML).

JM: It's really up to the working group to own that risk.

FB: Maybe I misunderstood, but it's irrelevant the IDE - it's the file itself. The adoption problem - this isn't a concern. The cloud provider should use whatever tool they want.

RM: I'm not after us mandating a tool, I'm just interested in what's out there!

JM: This should be done in coordination with / and In completion with the RDS service. Can someone look at the work being done by Eddie Knight in the repo about the service description?

RM: What has Eddie Done?

JM: There's a services folder (RM shares screen).

JM: When the gherkin file gets passed to the CSP along with the OSCAL, the gherkin test should test that the controls are implemented correctly. They didn't have the experience to add the OSCAL too.

MI: There are a few controls identified for the RDS. Could these tests be used to generate some OSCAL?

RM: (Shows catalog)

MI: These are like requirements for controls.

JM: Jim Adams was saying there was the possibility for inheritance between these catalogs.

MI: (Agreed this could be done)

FB: There was a question in OSCAL whether we had the right fields to reference the threat model. MI showed it was possible.

FB: Also an opportunity to extend the schema with dedicated fields?

MI: Yes, we have a vision for OSCAL 2.0 to support a threat-based approach. But right now we don't want to break compatibility.

FB: The other element is the testing.

MI: Yes, the scripts can also be linked.

FB: If we could cover with the RDS example, that would be great.

MI: The OSCAL can contain links to tests and props that give information to the tools (IBM TRESTLE (?), OSCAL Compass) to set up tests.

JM: We spoke to that team in OSFF 2022. Adrian Hammond is a maintainer on the standard.

MI: Google has their own platform based on OSCAL. I mentioned IBM TRESTLE since they open-sourced this.

FB: Although control description is common, cloud provider description is for the cloud provider.

MI: (Speaking for RK) - the way the google platform works is they have an internal mapping to their own internal safeguards. They push this though their own internal assessment. When they submitted a package to the US govt. they used their platform. They selected the controls based on what the fed wanted.

FB: Can I ask about the how? Was this in the GCP API?

MI: There's a presentation on this. Recorded in May in Washington.

Please use the agenda (bottom of the page) to determine the time of the presentation. The video is not tagging each presentation. https://www.nist.gov/news-events/events/2023/05/4th-open-security-controls-assessment-language-oscal-conference-and

Google’s team presentation is under 2/15/2023 on this page: https://csrc.nist.gov/Projects/open-security-controls-assessment-language/oscal-adopters-workshops

Generic / Specific Layers in CCC

JM: The RDS needs to be defined at a level that allows consumption across multiple CSPs. Can we get there with the work done by Eddie?

FB: We need an end-to-end example of a platform agnostic security control. The implementation has to be cloud specific.

MI: In the catalog of controls you can add the methods of assessing. The generic methods can be added to the catalog. Each CSP implementing RDS will have a component definition showing how those generic controls are implemented for their database. Those controls can point to the more specific versions.

FB / RM: (discussion about the generic and specific layers of the project).

JM: The CSP will join these up, the Gherkin can demonstrate the implementation, but you can also do it in an abstract way and leave the bindings separate.

JM: This is what the MITRE group are also trying to achieve. Are they testing the configuration of the service or the threats?

RM: That's quite a difficult mapping.

MI: What do I have to do for help?

JM: Could we also find another CSP's database to work on too?

Actions

FB: Would be good to start small and draft some OSCAL documentation. MI: to do peer review on this