search

finos / common-cloud-controls

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

04/11/2024 Common Cloud Controls - OSCAL WG #157

Closed crawfordchanel closed 4 months ago

crawfordchanel commented 6 months ago

Date

04/11/2024 - 12:00PM ET / 5:00PM UK

Untracked attendees

Meeting notices

Agenda

Zoom info

Join Zoom Meeting https://zoom.us/j/93861901920

Meeting ID: 938 6190 1920 Passcode: 284383

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: 938 6190 1920

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

mlysaght2017 commented 6 months ago

Michael Lysaght/Citi

eddie-knight commented 6 months ago

:wave: :shipit: Eddie Knight / Sonatype

robmoffat commented 6 months ago

Rob / FINOS 👾

jared-lambert commented 6 months ago

Jared Lambert / Microsoft

ojeb2 commented 6 months ago

Oli Bage / LSEG

damienjburks commented 6 months ago

Damien Burks / Citi 🚀 👋🏾

robmoffat commented 6 months ago

@crawfordchanel please add the minutes.

crawfordchanel commented 6 months ago

Meeting Summary - Reviewed PR #153

MI- The community put together a viewer in JSON format for catalogs that can be converted to all the other supported formats for people to have access.

Where do we want this data to be developed?

Community agrees- The data format is going to be dependent on the data contents. This iterative work right now helps us debate about the content and what we want to include in the in these datasets.

The next iteration could be markdowns, if it’s not great, we switch to JSON or YAML but at least we've decided on which content to include in it.

MI- Presenting information on how you can have everything in one file. You can start with the threats, and put the mitigation, then you put the logical controls. Or you can have data maintaining different places and you can still use those to help with mapping,

The community is satisfied with the markdown ML has shared.

ML- Community agrees maintainability can grow later. The idea is that we start getting more examples within a given service as quickly as possible across more than one service to quickly prototype on that.

Community agrees- The catalog is generic, but the specific service implements several controls from that capital. The service is defined generically as part of the CCC. So, the implementation of the control is CSP specific.

Logical controls are described in such a way that is generic across each of the CSP services, albeit for a service that's being defined generically by the CCC. In this case it's for this the Object storage service. It does pertain to a specific service, but in a generic sense across multiple CSP's.

MI – Suggests that we aggregate in one place to be maintained as a catalog and then decide how the team wants to maintain it.

EK – Delivery format discussion –

The SteerCo should create a strike team that can figure out the final output format. A single massive catalogue? Requires dedicated conversation of whiteboarding, and pros and cons and Venn diagrams, multiple perspectives

Steerco to identify dependencies.

Will there be several releases that are version controlled in the way that CIS manages their benchmarks?

EK- In the meantime, this helps us move forward by showing us what will be included. We can have these two separate conversations. Content to be released and how to release it.

MI - Suggested a dedicated catalog for the financial services sector.

ML - Trade ID format needs to be discussed. The name for the threat, A description. And how it maps to a feature effectively within our service taxonomy.

MI - Noted potential taxonomy ID duplication. CSF pillar mapping. This isn't mapping to attack mitigations as opposed to TTP's because TTP's are relevant to the threat catalogue, not the control catalog.

SteerCo Decision: This is where we need to make the distinction as to what amount of data, we want in the future in OSCAL,

ML Are the mappings to the CCC threats? Do we have a mapping directly to MITRE attack or do we have a mapping to our own threats as we identify them within CCC

EK - Let's capture that. Do we intend to be maintaining a threat catalog or do we intend to map to an existing one?

ML - Testing: The efficacy of the controls. This is in the spirit of the type of activity that an attacker would perform. As part of an attack factor that needs to be validated

EK - The idea here is that the statements are all generic and then the implementation is a service specific. This is how we'll be providing that certification. We define the behaviors we want to see and build out against that. I don't see this being cloud specific because every single RDBMS is going to need to have certain features and going to need to be putting certain controls in place. And then we'll just test implementation.

Community Agreed.

JL - Good to me. What's interesting to me is to see codified ways of testing. It's not a not the typical way monitors work if that makes sense, but I like it.

EK – These tests are being built inside the CFI project, according to the CCC Standard. Put it in your build system and when it all passes, then you go for certification.

EK - Cool. Back to the Pull Request #153 The question that I have is

  1. Would an end user want to see all of this information at once?

  2. Would an end user want to see all of the tests at once and all the descriptions at once?

  3. Would they live in separate places where it's like: Here's all of the controls, their descriptions, their IDs.

One place, one file, and then we go deeper in a separate location for the current status is. The tests are in the exact same place because we assume that the end user would want to see them all at once in a single line. Is bouncing back and forth problematic or beneficial?

DB – Suggested: Including tests in the Controls. I think that if we were to include the tests in it, we could just add a pass to the actual feature file. And tag it because it eliminates the possibility for duplication. And if we update the feature file with the test, they can just reference it. Every time we make a change, they just have a reference point rather than us having to modify the feature file and then cut it back and modify that controls that they file. It simplifies it.

EK - That mapping. Would we want to put a test ID? Or the URL or? What would that look like?

EK: The link to that information will have a unique identifier. But that link with the unique identifier will not be able to know when you change the link that it points. There is some kind of action in place depending on how you put that. If I would just use it up myself, I would say whenever I'm updating that one, I'm going to do and have an action of making that date. If we do something with the other one.

Damien - Right. When you raise a PR, there's an action there for the PR stating it'll basically go in and commit the changes.

MI – Agrees that's possible. Because from the catalog perspective you change the content to link but the catalog would have to know that the content was changed.

ML- SteerCo Decision: Do we see value in the CSF column? Effectively defining the control type. We could declare the CSP native capabilities to log specific API calls. Any kind of native trap detection capabilities within the within the CSP potentially as well

EK: Community Agrees: Try it and see if you want to keep maintaining that and is the scope beneficial to the community. If we have the end user value and the contributor desire, then the answer is yes. For now, keep the column in there to see if somebody wants to try out detective stuff. And if we get six months down the line and nobody wants to try it, then we've answered our question.

MI - I wanted to bring to the attention where the word "should" is used and not "shall" or must. Because from the standards perspective, should mean I can do whatever I want.

EK - I think this is the case where it might help to just increase documentation, but If it says something should happen then the test is finding out did it happen and put them back on. In that case the test is treating the should as a must.

Action: We must document our language for writing tests.

ML – RE: Mitigation. Do we see sense in mapping the MITRE attack mitigations? I mean one thing that it does expose is the lack of mitigation within the MITRE attack catalog, I can see some value in exposing that and working with the MITRE folks to fill those gaps.

Jared - From my end, mapping into existing control sets is a really easy way for me to go and find the solution to the thing, and in a fairly automated way, right? I can map existing frameworks that we've already done. I need to see if I need to check on the MITRE attack stuff and see if we already have that.

EK - Would it be valuable or possible to take anything that we know these map to and it'll just be a growing list. Would that be? Practical or beneficial?

Jared: I would rather have a well-curated framework.

Damien: More familiar with MITRE than I am with me of the other controls that they have like this. And, I feel like MITRE gives a bit more detail into how to mitigate things. in a way it makes sense from an attacker's perspective. I think it does add value because there's a lot of support behind the mitigation strategies and it's easier for people to be able to find the automation to make those changes to their environments.

MI - MITRE maintains a comprehensive set of controls, about 1200. They are detailed and very technical. NIST is expanding The Australian and Japanese government are adopting controls from NIST catalog. The end user value is there for both NIST and MITRE mapping.

EK – We don't want to be incidentally ad hoc with this. But also, if we increase the scope to say we're going to do both MITRE and NIST, we're increasing their requirements for every contribution. Is that something we're comfortable considering now, or do we want to kick that down the road a little bit?

MI: Once we do this catalog in OSCAL using the mapping model, the portal population will be quite easy. A lot of mapping between it and the and the other frameworks in the world can be a follow up work. mapping won't be an entirely manual activity. I

MI: I'm saying that you could do the mapping manually. There are tools. Previous providers that map using AI but require peer review

EK - Community decided to keep mappings as a road map item. But. Maybe we don't require it for contributions right now. If you are working on this and have the mapping already lined up, drop it in. This is a good place to keep it. But we do not necessarily need to require it for every contribution.

Jared: That makes sense to me. At the end of the day, I am going to have to map this to policies and Somewhere along the line I will convert it, but there's a lot of different ways to do that.

ML - Next one is. Service to attack. Does it make sense to keep the Service Feature ID here?

EK - I think that is something you want close by when you are looking at this catalog. What feature does this relate to? Seems like a no brainer to me. If you are writing a control for a particular feature on a particular service, then it is nice to have them. Have a connection point and mapping too to that.

ML - We certainly come up against this internally. I think we should anticipate it.

EK - A few years back we used CIS benchmarks as the policy and the tests that we have built out. We would write a behavior test that says, if you tell me the name of your registry then I will try to access your registry and get public registry; good behavior and the bad behavior. My perspective is that at the end of the day, we can write a test for it.

eddie-knight commented 6 months ago

Thanks for this @crawfordchanel!

crawfordchanel commented 6 months ago

Of course! Thank you for being patient. I’m catching up.

I’ll have the taxonomy agenda ready in the morning.

Chanel

From: [github.com] Eddie Knight @.***> Sent: Tuesday, April 23, 2024 4:04 PM To: finos/common-cloud-controls Cc: Crawford, Chanel [OT-TECH]; Mention Subject: Re: [finos/common-cloud-controls] 04/11/2024 Common Cloud Controls - OSCAL WG (Issue #157)

Thanks for this @crawfordchanel! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned. Message ID: finos/common-cloud-controls/issues/157/2073346591@ github. com ‍ ‍

Thanks for this @crawfordchanelhttps://urldefense.com/v3/__https:/github.com/crawfordchanel__;!!Jkho33Y!k2yEueLT4AjF6xPC7V1sRghiqdhig_gatALjX-LQHJRUUwJfAbLmca77TWUtuFnck5Puno2dkce4JtgbdiPJbzW2BHUh$!

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/finos/common-cloud-controls/issues/157*issuecomment-2073346591__;Iw!!Jkho33Y!k2yEueLT4AjF6xPC7V1sRghiqdhig_gatALjX-LQHJRUUwJfAbLmca77TWUtuFnck5Puno2dkce4JtgbdiPJb2nHB0u2$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/BDCEC6NPTIZTS5AJUVBCNPDY625B5AVCNFSM6AAAAABF7AGUTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTGM2DMNJZGE__;!!Jkho33Y!k2yEueLT4AjF6xPC7V1sRghiqdhig_gatALjX-LQHJRUUwJfAbLmca77TWUtuFnck5Puno2dkce4JtgbdiPJb8yiqahU$. You are receiving this because you were mentioned.Message ID: @.**@.>>

github-actions[bot] commented 4 months ago

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