crawfordchanel
commented
8 months ago 12.12.2023 FINOS CCC Steerco Meeting Minutes @finos/ccc-participants
Rationale for meeting and Introductions:
JM: There is a risk that working groups can begin to operate out of boundaries. They are not all hitting the same targets or goals. We have used milestones for working groups, but we need a steering committee to deliver on the standard. We want to make sure that CCC standard is being delivered by and for the financial services industry.
JM – We are here to define the working principles of the steering committee, maintainer time commitments and how the steering committee should engage with the project. We should start with quick introductions.
JA – Introduction – I am here to help shape CCC and proud to be a part of getting the standard at 1.0
PS – Hello. I am Senior Principal Engineer- I am interested because we did a lot of work around cloud controls. There is a gap here and I am excited to help build the standard policy. It is going to be a game changer. And once in place, we will leverage that as part of our framework.
SZ – I am new to this open-source community. I lead the cloud and platform teams in cloud control and resiliency. I want to help and learn as we go.
JN – Director of Cloud Security. I have worked on similar projects in the past. My focus is on the configuration side of things and MITRE tag team.
Harden First FINOS CCC Service against FINOS CCC Working Group expectations
JA – One of the first things we need to focus on is taking our first service to the point of completion according to the standard and running that for potential adoption and road mapping. It is the services themselves, but it is also the capacity that represent the CSPs. There needs to be a capability taxonomy as well. Then we can look at the validity of the common controls. We are trying to make sure we have portability. We are trying to determine the commonality of controls with the relational databases.
PS – I agree with that. Discovering the differences across CSPs is important. We have a RDS feature file. Can we then run that against Aurora? Or Oracle? I am all for that and trying it end to end.
JA – We need to make sure we do not model just one. Validation of the first service is key. If we get that wrong, nothing will be equivalent. It will be a moot effort.
RM – Encryption at rest in enabled. Is there work to do on this?
JN – Each of these services, like AWS, Google Cloud, Azure…. because it is a platform, they are going to have specific controls. This effort is about the common controls that exist between them all. That is why this exists. My part is to build the controls using that framework.
RM – So, you are going to test if the control exists?
JN – Just the behavior
JA – As we produce features, the taxonomy will be shared across different services.
RM – How would you even build a test?
JM – It comes down to the standard and how OSCAL is used to define how the services are configured. As part of that, it will allow the CSPs to certify.
JA – We run other test to assess the efficacy of the control. The actual service work is a little different.
JM – I want to make sure we define what the goals are for Q1 2024 without getting too far into the weeds. Let’s get a high-level agreement of where we want to get to by the end of Q1. That would be ideal.
SZ – I agree with going with the RDMS. We have 2 documents, the CCC, and CFI. There are examples of taxonomy and a level of detail. I am wondering can we agree, the services we are showing is in line with the current work already completed?
JA – Just for some background. The CCC whitepaper was not meant to be definitive. It was meant to prove to ourselves that the standard has legs. The paper was created for a little clarity. Not saying it may not carry forward, but the working groups are the definitive work. The ontology of the services will relate to the capability and features. We want to create cross region replication. We need to understand a few things; the equivalence of the service. Transaction level, performance characteristics resilience, security. If we get it wrong, nothing will be equivalent.
JM – That is where making decisions on partnerships would be beneficial. CDMC joins many of the taxonomy working groups. Their mappings provide that level of equivalence. In Q1, can we agree we need to understand where and how partnerships benefit us?
JA – Yes. I agree. Relationships are quite important.
JM – Am I right in thinking partnerships?
JA – I would vote yes.
SZ – Yes.
JM – In terms of the equivalence mapping, I know google cloud is here now and are maintainers. We need to recruit more CSPs to do that mapping more horizontally
JA – The success for this standard is, are we able to map services to capabilities and capabilities to features. The best way would be that, is that they do it themselves. CSPs would be the definitive source of truth. Having them participate in the taxonomy working group would be ideal.
JM – So, maybe we take the first RDS service….
JA – W ell, you must use 2 diff services for validation. We looked across 2 CSPs we to validate commonalities. Each CSP has specific implementation details. When you try to normalize threat models, you need to view more than one RDMS model.
RM – I agree with that. We build most with one desktop agent, but we are not able say definitively it was enough. We definitely need at least two
JN – Actually, you need to do all of them. There are differences between all the platforms. You will find each platform has specifications that do not exist, or they exist differently. You need to understand differences before you can migrate.
RM – Have we thought about giving badges when they conform?
JM – I do not know if we are as advanced as that right now. We need to find away to attract the other CSPs into the project to begin those conversations.
JA – For overall success CCC will be tied to threat model. Then we certify a version of service, e.g., v1.0 against the version of the standard.
JM – Do you think this is doable in Q1? A certification of a service in Q1? Is that achievable? Right now, I think Google would go all in on that. One cloud certification would get the other CSPs on board.
JA – We need more than one CSP engaged. Azure and AWS might need a little convincing to come to the party. And regulators want to solve the problem, they just do not know how. I think they should join as well.
JM – The OSCAL working group has been talking about a catalogue that contains definitions. https://github.com/finos/common-cloud-controls/issues/54 This goes deeper into the practical implementation of OSCAL and MITRE as well. Maintainers? Any ideas how we set expectations across OSCAL and MITRE in Q1?
JN – Two people from our organization are working on those streams. They have deep knowledge of OSCAL. From what I understand, implementation is pretty straightforward.
JA – This one is easy to get caught up in. The control must demonstrate the control has been effective. There is a large gap b/t the definition of the outcome and the implementation. The tooling is going to be a trap that could easily sidetrack us for a while. The outcome of the control is what we have to problem solve.
JA – The aspiration, of course is for it to be automated and repeatable. The tooling to do that may be CSP specific. We can have a set of human beings to validate. I would not want NIST or OSCAL definitions to get bogged down. If the CSPs were contributing, we could plug those in.
JM – I do not think they wanted to write it but investigate the best tools to use.
RM – Google ran a test script for their relational db. Is there mapping between the logical controls and test controls.
JA – That is how I see it working. CSP number one gives one, CSP two has none, CSP three has a little of both.
JM – Do you think that call to action should be stated?
JA – Not Q1. But in the future.
PS – I am trying to concentrate on the taxonomy. I think there’s value in doing an example base, end to end, a simple example in OSCAL of what that looks like. Keeping it light should be the goal. Defining the first service and using that as a template to go forward.
JM – MITRE is engaged in the CCC project now. Is there anything we need to focus on in Q1 around that?
JN - I think to the level they have agreed. What we want to do is to write the content. I think a lot of value for them is more broad contributions. If we identify a new threat, or a new category, we will likely introduce new cloud focused threats and mitigation's. We have identified several in the past. They have agreed to take input from us because we run cloud programs globally. We are a source of truth. First quarter, as we create content, there will be participation and they expect they will consume some stuff from us, and we can ask more questions from them.
JM – So the MITRE relationship will grow as we focus on delivering a service. From what I understand everything from Q1 will be RDS from end to end. Do we want to state to the CSPs?
JA – Lets frame it differently. Lets identify services that have that.
JM: There is a risk that working groups can begin to operate out of boundaries. They are not all hitting the same targets or goals. We have used milestones for working groups, but we need a steering committee to deliver on the standard. We want to make sure that CCC standard is being delivered by and for the financial services industry.
JM – We are here to define the working principles of the steering committee, maintainer time commitments and how the steering committee should engage with the project. We should start with quick introductions.
JA – Introduction – I am here to help shape CCC and proud to be a part of getting the standard at 1.0
PS – Hello. I am Senior Principal Engineer- I am interested because we did a lot of work around cloud controls. There is a gap here and I am excited to help build the standard policy. It is going to be a game changer. And once in place, we will leverage that as part of our framework.
SZ – I am new to this open-source community. I lead the cloud and platform teams in cloud control and resiliency. I want to help and learn as we go.
JN – Director of Cloud Security. I have worked on similar projects in the past. My focus is on the configuration side of things and MITRE tag team.
Harden First FINOS CCC Service against FINOS CCC Working Group expectations
JA – One of the first things we need to focus on is taking our first service to the point of completion according to the standard and running that for potential adoption and road mapping.
JA - It is the services themselves, but it is also the capacity that represent the CSPs. There needs to be a capability taxonomy as well. Then we can look at the validity of the common controls. We are trying to make sure we have portability. We are trying to determine the commonality of controls with the relational databases.
PS – I agree with that. Discovering the differences across CSPs is important. We have a RDS feature file. Can we then run that against Aurora? Or Oracle? I am all for that and trying it end to end.
JA – We need to make sure we do not model just one. Validation of the first service is key. If we get that wrong, nothing will be equivalent. It will be a moot effort.
RM – Encryption at rest in enabled. Is there work to do on this?
JN – Each of these services, like AWS, Google Cloud, Azure…. because it is a platform, they are going to have specific controls. This effort is about the common controls that exist between them all. That is why this exists. My part is to build the controls using that framework.
RM – So, you are going to test if the control exists?
JN – Just the behavior
JA – As we produce features, the taxonomy will be shared across different services.
RM – How would you even build a test?
JM – It comes down to the standard and how OSCAL is used to define how the services are configured. As part of that, it will allow the CSPs to certify.
JA – We run other test to assess the efficacy of the control. The actual service work is a little different.
JM – I want to make sure we define what the goals are for Q1 2024 without getting too far into the weeds. Let’s get a high-level agreement of where we want to get to by the end of Q1. That would be ideal.
SZ – I agree with going with the RDMS. We have 2 documents, the CCC, and CFI. There are examples of taxonomy and a level of detail. I am wondering can we agree, the services we are showing is in line with the current work already completed?
JA – Just for some background. The CCC whitepaper was not meant to be definitive. It was meant to prove to ourselves that the standard has legs. The paper was created for a little clarity. Not saying it may not carry forward, but the working groups are the definitive work. The ontology of the services will relate to the capability and features. We want to create cross region replication. We need to understand a few things; the equivalence of the service. Transaction level, performance characteristics resilience, security. If we get it wrong, nothing will be equivalent.
JM – That is where making decisions on partnerships would be beneficial. CDMC joins many of the taxonomy working groups. Their mappings provide that level of equivalence. In Q1, can we agree we need to understand where and how partnerships benefit us?
JA – Yes. I agree. Relationships are quite important.
JM – Am I right in thinking partnerships?
JA – I would vote yes.
SZ – Yes.
JM – In terms of the equivalence mapping, I know google cloud is here now and are maintainers. We need to recruit more CSPs to do that mapping more horizontally
JA – The success for this standard is, are we able to map services to capabilities and capabilities to features. The best way would be that, is that they do it themselves. CSPs would be the definitive source of truth. Having them participate in the taxonomy working group would be ideal.
JM – So, maybe we take the first RDS service….
JA – Well, you must use 2 diff services for validation. We looked across 2 CSPs we to validate commonalities. Each CSP has specific implementation details. When you try to normalize threat models, you need to view more than one RDMS model.
RM – I agree with that. We build most with one desktop agent, but we are not able say definitively it was enough. We definitely need at least two
JN – Actually, you need to do all of them. There are differences between all the platforms. You will find each platform has specifications that do not exist, or they exist differently. You need to understand differences before you can migrate.
RM – Have we thought about giving badges when they conform?
JM – I do not know if we are as advanced as that right now. We need to find away to attract the other CSPs into the project to begin those conversations.
JA – For overall success CCC will be tied to threat model. Then we certify a version of service, e.g., v1.0 against the version of the standard.
JM – Do you think this is doable in Q1? A certification of a service in Q1? Is that achievable? Right now, I think Google would go all in on that. One cloud certification would get the other CSPs on board.
JA – We need more than one CSP engaged. Azure and AWS might need a little convincing to come to the party. And regulators want to solve the problem, they just do not know how. I think they should join as well.
JM – The OSCAL working group has been talking about a catalogue that contains definitions. https://github.com/finos/common-cloud-controls/issues/54 This goes deeper into the practical implementation of OSCAL and MITRE as well. Maintainers? Any ideas how we set expectations across OSCAL and MITRE in Q1?
JN – Two people from our organization are working on those streams. They have deep knowledge of OSCAL. From what I understand, implementation is pretty straightforward.
JA – This one is easy to get caught up in. The control must demonstrate the control has been effective. There is a large gap b/t the definition of the outcome and the implementation. The tooling is going to be a trap that could easily sidetrack us for a while. The outcome of the control is what we have to problem solve.
JA – The aspiration, of course is for it to be automated and repeatable. The tooling to do that may be CSP specific. We can have a set of human beings to validate. I would not want NIST or OSCAL definitions to get bogged down. If the CSPs were contributing, we could plug those in.
JM – I do not think they wanted to write it but investigate the best tools to use.
RM – Google ran a test script for their relational db. Is there mapping between the logical controls and test controls.
JA – That is how I see it working. CSP number one gives one, CSP two has none, CSP three has a little of both.
JM – Do you think that call to action should be stated?
JA – Not Q1. But in the future.
PS – I am trying to concentrate on the taxonomy. I think there’s value in doing an example base, end to end, a simple example in OSCAL of what that looks like. Keeping it light should be the goal. Defining the first service and using that as a template to go forward.
JM – MITRE is engaged in the CCC project now. Is there anything we need to focus on in Q1 around that?
JN - I think to the level they have agreed. What we want to do is to write the content. I think a lot of value for them is more broad contributions. If we identify a new threat, or a new category, we will likely introduce new cloud focused threats and mitigation's. We have identified several in the past. They have agreed to take input from us because we run cloud programs globally. We are a source of truth. First quarter, as we create content, there will be participation and they expect they will consume some stuff from us, and we can ask more questions from them.
JM – So the MITRE relationship will grow as we focus on delivering a service. From what I understand everything from Q1 will be RDS from end to end. Do we want to state to the CSPs?
JA – Let us frame it differently. Let us identify services that have that equivalence that will lead us to the CSPs. We want to start with service capabilities. Do these services meet these capabilities?
JM – When is this going to come back so that we can chart the progression of the work done? Quarterly? It is good for working groups to be accountable.
JA – Let’s meet as open as required. Issues and outcomes will dictate how often we meet. Meetings will be driven by the outcomes of various outcomes.
JM – This should be answered by maintainers.
PS – We should meet regularly for now. We have done a lot of background work. We understand the goals. We need to get a cadence of where we are going, does it align with the goals of CCC? We do that well as working groups but as a we need to do the same for the project. A checkpoint would be nice. Not every week though.
SZ – I agree. If we can put a quality cadence as a checkpoint. If other issues come up, we can schedule something.
JM – So quarterly checkpoints and escalations in between if needed?
JA – Yes. I am happy to participate whenever. In these early days I want to make sure we are on the straight and arrow.
JM – We have the “All Hands” that happen monthly as well. When is this going to come back so that we can chart the progression of the work done? Quarterly? It is good for working groups to be accountable.
JA – Let’s meet as open as required. Issues and outcomes will dictate how often we meet. Meetings will be driven by the outcomes of various outcomes.
JM – This should be answered by maintainers.
PS – We should meet regularly for now. We have done a lot of background work. We understand the goals. We need to get a cadence of where we are going, does it align with the goals of CCC? We do that well as working groups but as a we need to do the same for the project. A checkpoint would be nice. Not every week though.
SZ – I agree. If we can put a quality cadence as a checkpoint. If other issues come up, we can schedule something.
JM – So quarterly checkpoints and escalations in between if needed?
JA – Yes. I am happy to participate whenever. In these early days I want to make sure we are on the straight and arrow.
JM – We have the “All Hands” that happen monthly as well.
Date
December 12th 2023 - 9am ET / 2pm GMT
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/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