04/11/2024 Common Cloud Controls - OSCAL WG #157
Comments
crawfordchanel
added
the
OSCAL representation of FINOS CCC
|
Michael Lysaght/Citi |
|
👋 |
Eddie Knight / Sonatype
|
Rob / FINOS 👾 |
|
Jared Lambert / Microsoft |
|
Oli Bage / LSEG |
|
Damien Burks / Citi 🚀 👋🏾 |
|
@crawfordchanel please add the minutes. |
|
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
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. |
|
Thanks for this @crawfordchanel! |
|
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 @crawfordchanel<https://urldefense.com/v3/__https:/github.com/crawfordchanel__;!!Jkho33Y!k2yEueLT4AjF6xPC7V1sRghiqdhig_gatALjX-LQHJRUUwJfAbLmca77TWUtuFnck5Puno2dkce4JtgbdiPJbzW2BHUh$>!
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/finos/common-cloud-controls/issues/157*issuecomment-2073346591__;Iw!!Jkho33Y!k2yEueLT4AjF6xPC7V1sRghiqdhig_gatALjX-LQHJRUUwJfAbLmca77TWUtuFnck5Puno2dkce4JtgbdiPJb2nHB0u2$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/BDCEC6NPTIZTS5AJUVBCNPDY625B5AVCNFSM6AAAAABF7AGUTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTGM2DMNJZGE__;!!Jkho33Y!k2yEueLT4AjF6xPC7V1sRghiqdhig_gatALjX-LQHJRUUwJfAbLmca77TWUtuFnck5Puno2dkce4JtgbdiPJb8yiqahU$>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Date
04/11/2024 - 12:00PM ET / 5:00PM UK
Untracked attendees
Meeting notices
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
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
The text was updated successfully, but these errors were encountered: