Panel | Improving the Security Posture with Cloud Solutions

So, this panel is entitled Improving the Security Posture with Cloud Solutions. So, I'll ask both of you just very quickly, because the word secure or the phrase security posture can mean different things to different people.

So, what would you say is your definition? In my definition, security posture is the ability of a system to detect and react on a given security issue or accident or security level, you can name it. And I would probably put that a bit broader, sort of in the sense how we would use it in the bank. Our security posture is really looking across all of our assets and systems, how well we are protected. But that also includes people and skills and capabilities, how well we are protected against the threat that we are seeing. That's what we sort of interpret as being our security posture.

Okay, I've done this the wrong way around. I should have asked you to introduce yourselves and where you're from.

So, let's do that. Carsten Fischer, I'm the Deputy Group Chief Security Officer for Deutsche Bank. My name is Stephan Schulz. I'm a solution engineer at F5 and I'm responsible for our security area for our region. Okay. And unfortunately, Michael Schrank, who should have been on this panel, is not well today. The next question then is, we're not talking about securing the cloud. We are discussing cloud-native problems that assist with cybersecurity, right?

Yeah, so that's why I said I would look broad at this. I know the topic is cloud, but I don't think I can look at a security posture cloud solely.

So, I think Hendrik said yesterday in a forum that he believes all of Deutsche Börse's services will be in the cloud in the future. I hear him. I think for Deutsche Bank, I will not be able to see that before I retire. Because you have just a complex infrastructure that it will not be cloud only.

So, it will be a hybrid of everything. That means always my security posture needs to go across. To your point, though, I would try as much as possible to be able to have my security tools sitting in the cloud and serving the new world in the cloud as much as the old world on-prem. And only where I'm not able to cover my security posture properly or to protect my bank properly with a tool that is cloud-based, then I need to go back and say, okay, fine, I'll use on-prem solutions for on-prem. But I see that as being the exception.

I think most providers of security software that is running in the cloud, be it a SaaS or something that you have directly as a product on your native environment, have fully understood that it's not all about cloud. So, they're in most of the cases also able to protect your on-prem environment. And in your industry, there's sometimes a perception that financial services is more conservative about cloud usage. Is that right?

So, I think any regulated industry will always need to be mindful about the fact what is written in the regulations and then sort of look at those regulations, how you can comply with that. You can call that conservative, I would probably call it in line with regulations, or maybe both. But I think the old school thinking, I remember 10 years ago, our first CISO sitting with the MS in Singapore and the statement of the head of that unit was very clear, cloud only over my dead body. I'm glad he's still alive and Singapore banks are using the cloud.

So, both can work. I think that conservative thinking around we cannot touch the cloud as a bank, I think that has gone away. Regulators do understand that the cloud environment by default is likely more secure than a lot of the on-prem environment.

So, that's why I struggle a bit with the word conservative. I know how you meant it. I'm not a retailer who can do anything without being regulated, but that doesn't hinder me to make use of the cloud. And what about from a vendor viewpoint? What feedback do you get?

I mean, you obviously have a whole range of customers. At least you tell me you do.

Yeah, we have, for sure. I'm one. I can just add to this that we have customers around the globe which are using, mostly it's a hybrid world.

So, we have both. We have still our on-premise applications and devices and environments which need to be protected with solutions we already have since years.

But also, we have new technologies, new applications, and everything needs to be fast, needs to be agile. And mostly, there is a cloud environment much more flexible compared to an on-premise environment.

But still, the important thing here is that even if you have a good security policy or enforcement points in place on-premises, you need the same in any other environment, especially if it is in a cloud environment. This is something we just realized or we can see in our customers. In most cases, it's very difficult to have the same or consistent security level across all your environments. This is something we try to address. That we provide a solution which is able to use the same or consistent security level, consistent security policy in any environment.

And that makes it easy for the responsible people to understand we have a policy in place. We have enforcement in place. We have transparency. We can see all the data. We can see what happens in our applications. And we are able to move and react on demands which can be that they have to use a different cloud location, a new cloud location or a cloud provider or just move the application to somewhere else.

So, we still can follow with this and we can apply our consistent and our security portfolio we have. So, it's always the same, always and mostly hopefully easy for the customer to use it. I mentioned yesterday and other people mentioned the EU Cyber Resilience Act which I believe is supposed to be coming next year. And within that, there are some new regulations, one of which is the Disclosure Act or the Disclosure of Vulnerability.

And I'd be interested in your viewpoint, Carsten, as a user, a customer, if you think that's a good or a bad thing, particularly when you're dealing with the complexity of cloud. Is it fair? I think disclosure of vulnerabilities is a really good thing because if you don't disclose them, you can't fix them. I think that disclosure they are talking about is going probably beyond my appetite, who I want to disclose that to. But that's okay. We need to do that right now as well. There are some US regulations that have just been published that sort of are forcing us to call those things out as well.

So, I don't think this is a big difference to what we have seen. I do see a change of how we look at vulnerabilities though. That's why it may not be 100% fair because in the past, we've always looked at vulnerabilities around like the score is 10. What we forget is that the score is made by human beings and then by vendors who are selling their software.

So, if you have a vulnerability that is high, you will likely try to make it even higher. Because if you don't, there may be a liability issue at your end one point in time.

So, there are different aspects going into a vulnerability judgment, what I think we need to overcome. And we had seen yesterday in the presentation that was done around how do you look at your attack path. We have seen from Deutsche Börse, I think in this room yesterday from Sobilla, how they have looked at vulnerabilities and try to make sure that they judge it. We hear from law enforcement troops in the US that they are going away from looking at you have a 10, you need to remediate that more towards, is that critical for your environment and do you need to focus on that?

So, if we do it on this basis, I'm absolutely fine. I am though conscious about the fact that more European driven regulators are still thinking in the sort of narrowed view around like if it's a 10, you need to remediate that.

Now, if it's sitting on my taxing booking system, I don't need to remediate that at all, even if it's a 15. So, this is why those regulations and I mean, we are all feeding back into this process obviously. But I think they're always falling short a bit on that risk-based view. What do I want to solve?

Yeah, so it shouldn't just be if it's a vulnerability but it's not, you would say… Critical for my system. Yeah, yeah, okay.

I mean, I think one reason they did it was because they were, well, the EU usually focuses on customers, privacy, et cetera, which is a good thing but… By the way, we do that as well as the bank. Okay. Good to hear. Good to know. The other thing was that some people say, well, if we say there's a vulnerability, then it encourages hackers to target us. Is that realistic, do you think? It's a yes and no, I believe. At this point, this vulnerability is discovered or is exposed and it might already be a bit late because someone else was already on it.

Exactly, yeah, just because you found it. But still, if there is something which looks attractive, it will attract people and they will try, of course. And I mean, to be honest, in this time, it is not that hard to try a vulnerability, to look for it and just try out what is possible and what is not possible. You can use even an AI engine already for this. You don't have to have a good understanding of how to hack or how to interact with a system to use a vulnerability. It's very easy.

If someone tells you there is something which is critical and allows you to get access to, like in our case, to our system, for example, and our customers have not patched it, have not fixed the vulnerability, then it's attractive for some people and they will try, of course. A lot of red team are, in the meanwhile, not using vulnerabilities. I remember looking at Alex who did that.

We have, in the past, even given the guidance to our red team, don't leverage vulnerabilities because we wanted to find out where we have weaknesses despite the vulnerabilities because we know we have vulnerabilities. So then the question comes back to the point you made and I made earlier. If I have a fully segmented network, if I have my crown jewels macro or micro segmented, why would I care about vulnerabilities of 10 or 9 in the surrounding that may not impact my crown jewels at all?

That's the attack path thing we have seen yesterday by one vendor, but I know many vendors are working on that same problem because that can then show you, okay, this is what I need to protect. Then we're talking because then we're saying the vulnerability is on that stream. I want to be remediated. So that's why I think the regulation is good, but it's probably a bit premature in an environment where we haven't yet finally clarified how to deal with all those vulnerabilities. Just one comment to this.

Even if there is no direct impact to a system based on a given vulnerability, as soon as someone gets access to any system or to any environment, they can look for new things. And this is a nice phrase for this lateral movement, just to see what is possible, even if there is no direct way to your crown jewels, but there might be a way in the future. But that's what I mean. So then you have segmentation in place. Then you have detection controls in place. Then you may have some boundaries in place. You may have some blocking in place. And that's what I would call security posture.

But I would also then call it, that's my risk appetite. If my risk appetite is saying, I don't want any lateral movements, good luck. Nice try. Good luck. This is a 3 million investment and a high 3 million investment every time, probably every year. There is nothing like zero risk for security. And I'm happy to pay 5 euros for this, but there is no zero risk for security. So it's all about your risk appetite. And then things like an attack path, things like crown jewels will help you.

And then you need to determine, do I allow that lateral move and sort of work on the basis that I'm able to detect it, not necessarily to prevent it. And somebody is moving from my taxi booking system to my canteen booking system to my room booking system. That may be absolutely within my risk appetite.

Yeah, maybe. If they are able to move towards my high value payment system, I have a different risk appetite for my high value payment system. Different story. Okay.

Well, okay, anyone got a question for the guys here? We have a microphone.

If not, I'll just carry on. You guys, any questions?

No, okay. We talked a lot, obviously, about the cloud. One of the questions is, will cloud solutions be held back by legacy and on-prem applications? Would it be better to strip everything out if it was possible and to build entirely cloud-native infrastructure? Yes. Yes. But is it possible? Give me the pot of money and I'll do it tomorrow.

Look at, and I can only talk about financial institutions, but looking at Alpha, you can probably tell a different story from the industry as well. But if I look at our infrastructure, then that starts with a mainframe. A lot of banks are using mainframes for their big scale business. I know people are dreaming about mainframe in the cloud. I'm not visionary enough to see that in the next few years, so it will remain being on-prem.

I can now start investing millions and moving that away from the mainframe into a cloud environment, or I can accept the fact that it's sitting on my on-prem and making sure that I'm protecting it. Guess what? Mainframe security tools are usually not serving anything else but mainframe, so I need to do that anyhow. So that may be something that I accept.

If I have, I don't know, 10 Windows 2008 operating systems that are sitting there and I now need to go through the transformation of moving them to 2012, 2016, whatsoever, I may use that as an opportunity to say, let me rethink. Maybe I can rebuild them in the cloud and save the money of that transformation to just another Windows platform to, oh yeah, let's move them natively into the cloud. So it all depends on what we are talking about.

And again, then crown jewels, do I need my taxi booking system in the cloud? Okay, the first question should be, do I need a taxi booking system? Can't I buy that as a SaaS?

Okay, fair. But it's those kind of things. That's why I think it's too blunt and too broad to say, let's just move it all to the cloud. If I don't have a business case, I wouldn't even touch it.

Okay, and what about your customer feedback? Yeah, exactly the same. So we have customers, they are 100% cloud native and they are perfectly fine in this virtual environment. And we still have customers on-prem and this is then fine as well. And maybe in most cases, there's a reason behind it. But we as a company allows our customers to use both worlds. We provide everything they might need to interconnect them securely. And as I mentioned before, to provide them the possibility to reuse their existing experience that our solutions can provide in any environment.

And this maybe is also a good way to use the best environment for my application, for my workloads, just based on the use case. So we provide everything which makes it easier for them to move application by application or leave it where it is. It doesn't matter for us. We can provide our solution for all environments. Okay. That's our experience. One very final question and probably have to be quick. What are the major trends in development areas that CISOs or not just CISOs but senior people, what should they be looking to invest in, in terms of cloud-based security tools?

And I don't mean vendors. I mean just technologies. Go ahead. From our point of view, what we can see with our customers is that they need solutions which can be used in an easy way. It has to be agile. It has to be very fast. And just based on the demand they have. And for this, there's only one good solution from our point of view, which is any kind of SaaS service. So we provide a platform or it's a platform with different solutions and our customers can use wherever they want.

And they have a single configuration portal or place where they can find everything, either if it is reporting or any kind of information about the system itself. But also any information about any ongoing security issue or is there any protection available or not for those applications. So it's easier for them to have it in one place and usable on every location. Instead of building their own solutions just on-prem or in this specific cloud environment, you always have to learn the specific solution.

And it is easier for them to use one solution which is usable at that time and how long they need it as a SaaS service, for example. Okay, great. Sold. Sold. Pretty much.

No, I wanted an ecosystem rather than 10 different tools. I wanted to be in the cloud SaaS native whatsoever and not sitting on-prem. And I wanted to be able to connect to the other ecosystems. I won't buy a SaaS tool if it doesn't connect to Microsoft M365, because then I can't use it. I cannot worry about whether the SaaS tool is now making a decision on conditional access or Microsoft does, because I couldn't care less. I want a tool to take a decision on conditional access. And if they can't agree between the two of them, I may not use either of them.

So I'm looking at this very, very, very thin thinking. It needs to be, as you said, agile. It needs to be fluently. I need to be able to use it. It needs to be in the cloud and it needs to fulfill an ecosystem. And if it's falling in between those, then I really need to think about whether I buy it. I was shocking somebody yesterday from the vendor community who was trying to sell a tool to me because that tool is so much better for that use case than all the other three tools that are out there.

And it would be my decision whether I go with the best tool in the market or I accept an 80 to 90 percent. I think she was a bit shocked about my comment that I go with the 80, 90 percent if it's part of an ecosystem. But that's what I hear a lot from CISOs nowadays saying, I don't want the 120 percent tool if it's a standalone and I need to embed that into all of my other tools. I want the vendors to embed that. Exactly.

Okay, fantastic. Well, that's it. End of time. Thank you so much for answering those questions. Thank you. The conference hasn't finished yet, so we still have some panels and a session in Plateau, which is the main big room. So see you there.

Thank you, guys. Thank you.