Full Transcript:

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 Mohammad: Okay. Hi folks, I'm Naseer Mohamed. I'm a security engineer at Google. Super excited to be here. 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. Just in case some of you did not know that, I will just show a little bit.

BMO is a Canadian bank, and it's called the Bank of Montreal. But we have a very strong U. S. presence. And I think so two months ago we just finished the integration conversion of Bank of the West and that one doubles our [00:01:00] 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, again, we are 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 have been on this journey for seven, eight years already, and we always pursue multi cloud [00:02:00] 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 happen in the cloud.

However, we as a financial institutions here, we also see the challenges with the cloud providers there. And this, the shared responsibility model here, it is not the same across all the cloud providers. And also, we know how 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, many different areas.

U. S. Department of Treasury highlighted this one here, so CSP effort did not fully [00:03:00] 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 say that we need to have a uniform requirement for the security of network and information systems. So, and the next one you see here is from the authority of the Singapore here. So they clearly say the similar messages. So what I'm showing here is just a sample of the example, how each government, each areas are talking about the need to have a common control across our CSPs.

Okay, so in a summary here, what I want to say here is [00:04:00] financial services industry has our own special needs. And we need to have the cloud providers here to stand up here so that 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, you know, the OSFI is the one that, that overlooking all the regulators here and Europe. You see here that Europe Banking Authority and the, in the international sites, you have a base with many, many others. All those other 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.

And it [00:05:00] 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 these major cloud providers. So that's why 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 con, 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 we are bearing all those [00:06:00] consequences. So those are, I think, the things we come here together as an open source 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 FINOS is going to address this. 

Naseer Mohammad: Thank you Simon. Hey folks again reintroducing myself. I'm Naseer Mohammad. 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 gonna walk through and give a walk walkthrough of the approach we are taking at FINOS to implement the common cloud controls. So the very first step we're doing is establishing the top box there, the common services taxonomy.

What that is, is basically a generic way of [00:07:00] 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 control 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.

Right, 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. 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 like, you know, 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're 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, 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 [00:10:00] now, 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 RSCAL, and in 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. I'm 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 [00:11:00] all focused more 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 RDVMS 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, and we will have more offerings going forward. There will be offerings that will be deprecated 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, [00:12:00] and then, this is what I 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 know, 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 this service. And we come up with a threat model. Once we have the threat model, uh, go back, sorry.

Yeah, go ahead. [00:13:00] Oh, use that one. Sorry. Alright. Yeah, so once we have the threat model what we do is like we write mitigation, mitigating controls and we come up with a control catalog. And on the other side, what you're seeing is MITRE also provides us some guidance on the defense attributes of how would you write your control countermeasures for defining these controls.

Once we have the controls, then we'll go to the next slide, which is, yeah. So we have the controls defined. 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 [00:14:00] you have built. Now, The assessment plan will be developed by FINOS, which will document how exactly are we going to test the controls.

FINOS will also provide engines to test these assessments. The third party vendors can come in and plug in, 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 you see 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 so, capability, but [00:15:00] 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 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, we 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 this things fall in place, we will have [00:16:00] 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 participants. And we have volunteer at self identified and the voted to have the nine maintainers. And Nasheer shows the maintainers the company they're representing here.

So some of, I think both and the Nasheer 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're a 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 forces 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 the, [00:17:00] it's open the open source approach here. But we're working in a fully collaborative open ecosystem. So what I think, you probably heard this one here, we are working closely with NIST.

And the MITRE framework there, so we are working closely with them. And also, we are also working closely with another one our project is Common Financial Infrastructure. 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, James helping us moving things forward. James is just here supporting us and getting things moving.

So if you have any [00:18:00] 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? As we can say, we are working in an ecosystem here, Compliance 

Financial Institute, Compliant Financial Infrastructure, CFI, sorry, is the one 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 automation machine readable automated fashion. So we are teaming up together with them.

Please join the session. The session will start at 2 o'clock. 2:05. I don't know whether Eddie is in the room here or not. 

Naseer Mohammad: And with that, folks, we'll conclude. Thank you so much. If you have any questions, we are here. 

Simon Zhang: Yeah.[00:19:00] 

Are there any questions? Anything? Yeah.

Maybe introduce yourself. Yeah.

James McCleod: Hello? 

Audience: Yes. Yeah. Hi. I was just saying that a lot of the services for cloud providers, kind of 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, you know, 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 Yeah. You know, you could be running it in a different cloud, but control planes all in one cloud in a single region. And [00:20:00] now Bob's your uncle. Is that part of the charter of this eventually? Or do you see that coming into play to provide it like a full picture of that type of thing? 

Simon Zhang: I would. Yeah. So very good points about it's about a control plane in the cloud providers. This is an issue that we all have been facing. I would like you know, 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, stand up on that one. Thank you for the question. 

Naseer Mohammad: To add to what Simon was saying, also the multi cloud initiative kicks in here.

Regulations like DORA and EBA, they want to avoid the concentration risk. You want to spread out to [00:21:00] multiple clouds also. I think that dovetails into this discussion nicely. 

James McCleod: Okay, thank you. Any other questions? I think that's it. That's it. Thank you very much Simon. And Nasheer thank you. Applause.