Want to be part of these groundbreaking discussions in finance? Save your seat for the next Open Source in Finance Forum in London, 26 June. Don't miss out!
This discussion underscores the collaborative effort between financial institutions and cloud service providers to address challenges in cloud adoption, emphasizing regulatory compliance, risk mitigation, and automation. Simon Zhang from Bank of Montreal and Naseer Mohammed from Google highlight the need for common cloud controls to navigate issues like vendor lock-in, cybersecurity inconsistencies, and resilience guarantees. Through FINOS, initiatives include developing a service taxonomy, threat-aware controls, and automated assessments using OSCAL to ensure continuous compliance monitoring. Overall, the talk emphasizes proactive collaboration and regulatory adherence to overcome hurdles in cloud adoption within the financial sector.
Join experts from across financial services, technology, and open source to deepen collaboration and drive innovation across the industry in order to deliver better code faster at Open Source in Finance Forum - London.
Simon Zhang: [00:00:00] Okay. Thank you everyone for coming here. So my name is Simon Zhang. I'm from the Bank of Montreal and I'm on the buyer side. Then there's a sell side. Okay. So two of us will be introducing the common cloud control together here. Get a little bit deeper dive into it. Probably heard a lot of these names in the morning already.
Naseer Mohammed: Okay. Hi folks. I'm Nasir Mohammed. I'm a security engineer at Google. Super excited to be here. And I'll be walking over the Common Cloud Framework approach we are taking. I'll give you some more details on that.
Simon Zhang: Okay, good. Thank you. BMO is not a very big bank. So just in case some of you did not know that, I will just show it a little bit.
BMO is a Canadian bank and it's called the Bank of Montreal. So but we have very strong U. S. presence. And I think so two months ago we just finished. The integration conversion of Bank of the [00:01:00] West and that one doubles our presence in U. S. to four million customers and now we have 23 No, 32 states in U.
S. So in that sense, we are the top 10 in North America right now, and we are number eight in U. S. banking alone So in that sense So maybe, so that's why the U. S. regulators always come to us as well. So we are every day working with Federal Reserve, SEC, OCC, everything like that. So we are all, again, we are all a Canadian bank.
We have a global presence and you saw Kim just show this one a little earlier. Okay, so we as a Canadian bank CSO and financial institution here, so public cloud is really our very major point. So we are Cloud Strategy, we have been on this journey for seven, eight years already, [00:02:00] and we always pursue multi cloud.
So that in this way here, so we see the benefit of the cloud offering and offer a lot of the agility and we love the innovation happening in the cloud. However, we as a financial institution here, we also see the challenges. With the cloud providers there, And this, the shared responsibility model here, it is not same across all the cloud providers.
And also, we know we have a skills, skill set and the challenges, and the more important is the regulatory requirements. That challenge is really big to us. I see many people are nodding their head here. So if you are in the bank, in the financial industry, you will face the similar challenges we are facing here.
Okay, just on the cloud side here, you see here the cloud risk is really highlighted in many different areas. U. S. Department of Treasury highlighted this one here, so CSP [00:03:00] effort did not fully satisfy the financial institution's risk management needs. So that's what this says. And another example from United Kingdom here, it says the operational resiliency framework, it's really needed, need to be included in the
our CSP provider there. If you see the ones from the European Union there they strongly says that we need to have a uniform requirement for the security of network and information systems. So the, and the next one you see here is from the authority of the Singapore here. So they clearly says the similar messages.
What I'm showing here is just a sample of the example, how the, each government, each areas are talking about the need to have a common control across our CSPs. Okay, so in a summary here, [00:04:00] what I want to say here is financial services industry has our own special needs. And we need to have the cloud providers here to stand up here so that we can.
We are meeting the risk control requirement from our regulators. As you can see here, we are operating mostly in the global market here. So we have the US here, OCC, federal Reserve, and many others. And in Canada, the, A fee is the one that, that overlooking all the regulators. Here in Europe, you see here that Europe banking authority, and in the international sites, we have a base with many others.
All those are the. Regulators give us a lot of control requirements. We have to meet them. So in this way here, so the cloud provider here, so they do give us something like called financial services cloud. I mentioned the one here in Salesforce here. It is a company, big, make a big at the canoes outside there, they say, I have the financial services cloud.[00:05:00]
And it make this one got a lot, lots of attraction to our, to the business our site here. So what we want to do here through FINOS, this one here have the common cloud control across all this major cloud providers. So that's where we are here. And the FINOS address this one to, to some of the challenges here.
So first we've been talking about a lot is the concentration risk vendor lock in. This one here, if one of the cloud provider is having an issue, how can we move our workload around? We are still safe, still secure. How about the cybersecurity controls? Are they in, are they consistent across? And if, what if some of them are, doing something that we are not aware of?
The worst case here is cloud providers, they want to demonstrate the so called competitive advantage. They want to do something different from their peers. In this case, we as a financial institution here, so [00:06:00] we are having bearing all those consequences. So those are, I think, the things we come here together as an open source to a foundation here.
We work together with a partner here with our, peers. So that's, I think, the message here. So I will pass over to Nasir talking about how within us is going to address this.
Naseer Mohammed: Thank you, Simon. Hey, folks. Again reintroducing myself. I'm Naseer Mohammed. I'm a security engineer and I joined FINOS.
I'm super excited when I hear open source controls and assessment come together. At Google, I work in automating controls and controls testing. In this session, I'm going to walk through and give a walk, walk through of the approach we are taking at FINOS to, common cloud controls. So the very first step we're doing is establishing the top box there, the common services taxonomy.
What that is basically a generic way [00:07:00] of categorizing and grouping cloud services in a CSP agnostic fashion. Thereby what happens is like the CSPs, as in when they're coming up with services. They can now correlate to the common service taxonomy. Now once we have the service taxonomy defined, that's the top box, the second step is to take each service in the taxonomy and come up with controls.
Typically when we define controls we think about controls from a capability point of view, right? We take a service and we say, hey look, let's have authentication controls, authorization controls, configuration management controls, and things along those lines. At FINOS what is exciting and what which I like in here is we are taking a comprehensive cont approach over defining controls.
We actually assess the cloud service from the taxonomy which we have defined from a threat point of view. So we work with [00:08:00] analyzing threats that are posed to the service and then we come up with what is known as a threat model for a cloud service. The threat model will give us all the threats that we are aware of to date that are applicable to the cloud service.
Now we take those threats and then we define controls as mitigations to those threats. And we do this through all the services that we have defined in the, services taxonomy, right? So that's our step two, which is controls catalog. By end of step two, we will have a well defined set of controls that maps to the services that the cloud providers are offering.
We won't stop there, so the thing that makes FINOS interesting is that just by having the controls catalog it's good, but it's not really it, it won't help you like really evaluate that controls. And that's where the third step comes in, which is [00:09:00] basically the assessments of these controls.
Now when I say assessments of this controls, what does it mean? So when we say, when we define a control in a control catalog, we are also defining how this control can be validated. Is this control really working the way it is supposed to work? The cloud services, cloud service providers are providing us offerings and we want to make sure that these offerings are working the way they are supposed to work.
And that's where the assessment comes into picture. Now again the challenge for us at FINOS is for us to write these assessments in a CSP agnostic fashion. So when we write this assessment should be executable on any CSP we have. For that, the way we want to address that is by using a abstract testing language.
It's called Gherkins. So we'll write our test assessments in Gherkins that goes along with the control. And now, [00:10:00] with this test assessments, what happens is this test assessments can now be executed on the CSPs, validating their control. For us to make this happen, we are leveraging R scale and subsequent slides I'll walk through how that really works through.
But once we have these three steps, what you will get is a continuous controls assessment. An automated approach of assessing our controls in a continuous fashion. That's what our goal is, right? It's not going to be a point in time compliance. It's going to be a continuous compliance assessment based on the automated approach which we are having.
You might want to quick skip there. Sorry.
That is me being lazy and not installing the required updates. Sorry for that. All right, cool. So that's the high level overview folks. Let's go to the next slide. So in here, it's all focused more [00:11:00] on the service taxonomy working group, which we have at FINOS. Like I said the whole idea of service taxonomy is to have a cloud services provider agnostic taxonomy.
So we can write our controls. Leveraging this taxonomy. So an example in here is RDBMS is what we can call in FINOS as a service that cloud services provide. Now when we go to cloud services, AWS might have RDS, Aurora, Google might have Spanner, and Azure might have their own offerings, right?
And these offerings will be increasing, or and we will have more offerings going forward. There will be offerings that will be duplicated also going forward. We don't want to be tying ourselves to those offerings. What we will be focused on is the service taxonomy. That way we work at a level of abstraction.
We go to the next level. Yeah, so now once we have the service taxonomy defined, we take each service in the taxonomy, and then, this is what I [00:12:00] was talking about, wherein we are taking an approach which is coming up with the controls that are threat aware, threat informed. What I mean by that is, you take a service and you assess what are all the threats that are applicable to the service.
Now, when I say how do we how do we know what are the threats that are applicable to the service? Who is defining that these are all the threats that are applicable to the service? This is where we intend to work with MITRE and MITRE is an organization that defines all the threats in a standard framework fashion.
So as and when the threats are emerging, MITRE will define the threats in their threat catalog and then our group will be assessing the service, the cloud service and see how this threat applies to the service and we come up with a threat model. Once we have the threat model go back, sorry.
Yeah, so once we have the threat model what we [00:13:00] do is like we write mitigation, mitigating controls and we come up with a control catalog. And on the other side, what you're saying is MITRE also provides us some guidance on the defend defend attributes of how would you write your control countermeasures for defining these controls?
Naseer Mohammed: Once we have the controls, then we'll go to the next slide, which is, yeah. So we have the control to define these are threat aware controls. Here is where we will define assessments. Like I said, the key technology which we'll be using behind the scenes in here is OSCAL. OSCAL stands for Open Security Controls Assessment Language, which is a machine readable language.
So let's say you have GRC systems, which you have, you can plug in. Your GRC systems can read into these assessments, and your assessments could be evaluated by your engines, which you output. Now, The assessment plan will be developed by FINOS, which will document how exactly are we going to test the controls.[00:14:00]
FINOS will also provide engines to test these assessments. The third party vendors can come in and plug in here and also they can provide, they can ingest the assessments and they can execute the assessments using their assessment engines. At the end, what is basically an automated approach for providing compliance assurance.
Wherein once you have this catalog defined, the CSPs or your tenants on the CSPs could be evaluated for compliance and you'll get a report. And the report will say, tell you exactly how the controls are performing. The key point which I'll end with in here is that when a control fails. With this approach, you don't, you not only know that the control is failing because of so and capability, but also you would know the control is failing and here is my threat.
And now you can make a risk based assessment of how critical it is for you to fix this control. Because you know the [00:15:00] threat that, that opens up the vulnerability for you if the control is not in place. All right. So with that I'll give you a quick overview of the working groups, which we have formulated.
We have a service taxonomy working group in FINOS that service taxonomy working group works with the MITRE catalog, which is where we define the threats and the controls. I am a moderator for that particular working group. And then we have a parallel working group that leads the OSCAL.
These three working groups have been established. And if you go to the next slide. These are the two working groups which we are working on establishing. I am super excited to be part of FINOS. I'm a new member of FINOS. I do see once those things fall in place, we will have an automated way of validating controls.
With that, I'll pass to Simon for call of action.
Simon Zhang: Yeah. So FINOS at the Common Cloud Control here, so far we have 133 [00:16:00]participants. And we have volunteer at self identified and the voted to have the nine maintainers and the shear shows the maintainers the company they're representing here.
So some of, I think both Naseer and myself, we are in, we are one of the nine maintainers. I think there are some more other maintainers in the room here. If you are maintainer, maybe you can raise your hand. Thank you. Yeah. So here, I think, as you can see the maintainer here. So it's part, it's combination of the provider side and also the sales side.
So we want to join force together. Okay. If you go to the next page here and the FINOS in this case really is, I think the common cloud control working in that it's an open that open source approach here. But we're working in a fully collaborative open ecosystem. So what I think you've probably heard this one here, we are working closely with the NIST [00:17:00] and the MITRE framework there, so we're working closely with them.
And also we are also working closely with another one that our project is a common financial structure. So these are all the ecosystems we're working together, moving this whole framework and whole project forward. So I think here, maybe I will say here, I will say in the room here, many of you are the members and if you are not a member here, welcome to here.
And I think here, so I want to introduce here, I think we have been getting to here to this stage here because of we have a great facilitator and this, and here, Jim's helping us moving things forward. James is just here supporting us and getting things moving. So if you have any questions, anything about, about about the common cloud control, reach out to us here or reach out to James.
We'll all be making things moving forward. Okay? So here, I think a very important thing here is how do we move the things forward? [00:18:00] As we can say, we are working in an ecosystem here, compliance financial institute, compliant financial infrastructure, CFI, sorry. It's the one that has been moving the things forward ahead of us.
So we are teaming up with them here, and there will be a breakout session that by Eddie, and and he will show us how all the things are working in the, in this kind of the auto machine machine readable, automated fashion. So we are teaming up together with them. Please join the session.
The session will start at the two o'clock, two o five. I don't know whether Eddie is in the room here or not.
Naseer Mohammed: I would that folks will conclude. Thank you so much. If you have any questions, we are here. Yeah.
Are there any questions? Anything? Yeah.[00:19:00]
Maybe introduce yourself. Yeah.
Hello.
Audience Member: Hi, I was just saying that a lot of the services for cloud providers, the control plane is almost a black box. There's no SLA on it, and you're really unable to get a resiliency guarantee. It comes up during, the virtual onsites and tech risks. Is there going to be any future focus on that as a threat?
The idea of having a single point of failure. Even when you talk about some software service providers you could be running it in a different cloud, but. Control planes all in one cloud in a single region and now Bob's your uncle. Is that part of the charter of this eventually or do you see that coming into play to provide like a full picture of that type of thing?
Simon Zhang: I would, yeah, so very good point about, it's about a control plane in the cloud providers. This is an issue that we all have been facing. I [00:20:00] would like, so far we have not been focused on this one yet, but I would like to add this one into the piece. Because I think we do, you do experience some of the things.
Everybody know the AWS in late 2021 has a major control plane failure. We cannot afford this type of failure in our financial institution. One thing we can do is that we will build the residency redundancy failover ourself. However, we do want to have the cloud provider in the same way as AWS. Stand up on that one.
Thank you for the question.
Naseer Mohammed: To add to what simon was saying, also the multi cloud Initiative kicks in here where regulations like dora and eba, They want to avoid the concentration risk. You want to spread out to multiple clouds also. I think that dovetails into this discussion nicely. Yeah. Okay. Thank you.
Any other questions? I think that's it. very much Simon and Naseer. Thank [00:21:00] you.