The Future of Cloud Security

Welcome, everyone. Thanks for joining us for our webinar today. I'm John Tolbert, Director of Cybersecurity Research at KuppingerCole, and today I'm joined by one of my colleagues, Mike Small, Senior Analyst.

Hello, Mike. Hi, thank you very much for having me. And we're also joined by Andy Schneider from Palo Alto Networks.

Hello, Andy. Hi, John. Thanks for being here. And our topic today is The Future of Cloud Security. So I know that sounds quite broad, but we've got some interesting points, and we are also interested in hearing your questions and thoughts as we go. So a few details here at the beginning. Everybody is muted centrally, so there's no need to try to mute or unmute yourself. We're going to do two poll questions, and we'll talk about the results of that a little later in this session.

And as I mentioned, we're going to take questions and try to provide some answers, and we will do that a little bit later. But feel free to use the Livestorm Control Panel to enter your questions into the Q&A blank at any time. And then lastly, we are recording this, and both the recording and presentation should be available in a couple of days. So we have kind of a short agenda today. We're going to do this more as a discussion rather than a presentation. We do have some slides to kind of keep us on track, but we're going to talk about cloud security challenges, and then we will do the Q&A.

But let's start with a poll question. It would be interesting to find out, what do you think are the biggest security challenges of your hybrid or multi-cloud environment? We've got five choices for you. Just understanding the real risks, number one, complexity of the environment, managing the shared responsibilities for security, inconsistent tools and capabilities, or lack of transparency, or lack of transparency. Or lack of transparency of controls. So feel free to answer that, and we will discuss this a little bit later.

So there are probably many different kinds of problems that you can have with cloud security, but we thought we would just pick a sample incident scenario to go over. And this one, I think, is fairly common. You may discover that an attacker uses, let's say, phishing or something to get access to an account. Maybe they identify a role that's been misconfigured. Maybe it's a backup kind of role that gives them access to both storage and compute.

This attacker then might use that role to create new EC2 instances, maybe in a less monitored virtual private cloud, and then attach an IAM instance to that. And from there, they can use all the different tactics across MITRE ATT&CK to you know, beyond the initial compromise, to look for assets, do privilege escalation, lateral movement, find information that they maybe want to exfiltrate.

You know, in this case, maybe it's something like an RDS database. The problem arises in a traditional SOC, where you may not see all the relevant alerts for this. Maybe the only thing you see in your enterprise SOC is simply an alert about a download from S3. But CNAP or the cloud security tools, on the other hand, have a better opportunity because they have access and understanding of the telemetry that each of these different steps may generate. What do you all think? Mike?

Yes, well, I think this illustrates the basic problem that we see here, which is that the on-premises or conventional enterprise SOC is blind to what is happening in the cloud. And equally, the cloud security tools don't have the access to the things that the incident response team have about how attackers in general operate.

So, they see a picture of the cloud, so they see a picture of the cloud, which is not communicated to the normal SOC and incident response. And so, potentially, things don't get picked up. And at the end of the day, what the SOC sees isn't enough to give you the information that you need towards to be able to respond to a cloud-based attack. And on top of that, the cloud has, or your use of the cloud probably has an enormous perimeter, which is going to make it even easier for the attackers to try and find a way into your enterprise. Andreas?

It's absolutely that problem that you have disconnected, you could say, security views on that. You have like the, I would call it the traditional SOC that might see even part that you mentioned, John, that the attack started even earlier with phishing.

So, you might see phishing attacks. So, maybe the attacker is in there with an internal account.

Now, if you look at the CNAP space, they might not see that the attacker is still in there. So, you might remediate incidents that you see in the cloud, like a misconfiguration.

So, you might remediate that IAM role, but the attacker is still in there and might still do harm. And that's what you could say the cloud SOC is not talking about and is not seeing.

Whereas, the traditional SOC might just see, oh, there was a phishing and not much harm is done. And I think it makes it even more complicated as attacks speed up, also due to cloud, due to other aspects. You cannot lose that speed in your defense, wherever you are. But it's like a typical problem. We started siloed in, we started siloed in, you could say, in the cloud to speed up there to catch up with capabilities that we had in the enterprise.

But now, we lack bringing them back together. Yeah, that makes me think of a couple of words that get used a lot in security these days, like visibility, observability, and correlation. And we'll get into this more in a couple of minutes.

But yeah, I think it's interesting to point out that there are different sets of data that come from these different sources. And if you're operating in two completely separate SOCs, then that can lead to a lack of observability or a lack of visibility, which then makes it hard to correlate.

So, a little bit more about the two SOC problem. Another selling point many vendors use when they're talking about SOC tools is having a single pane of glass. But I think for those of us who've been in SOCs before, we know there are many single panes of glass, which makes it even a little bit harder to manage, even with just on-prem resources that you're trying to secure.

So, let's talk about, you know, the traditional but modern SOC. What are some of the major tool categories that we see in there?

First up, you know, EPDR, Endpoint Protection, Detection, and Response. This is a union of older endpoint protection type tools, what formerly was known as antivirus, plus EDR, the detection and response tools that have been bundled for a number of years now. The idea is to provide both protection and the ability to go back and look for signs of compromise, and then, of course, remediate those at the endpoint level. These all depend on agents, which, you know, you can contrast that with NDR, Network Detection and Response.

That's about looking at things at the network layer because many times, you know, sophisticated attackers are able to go in and clear out EPDR logs or logs from other systems. So, maybe the only place you have to look for signs of attack are on the network. And that requires a great deal of protocol level understanding in order to be able to do, like, encrypted traffic analysis so that you don't have to expose yourself to greater threats by decrypting the traffic. We see those two combining into XDR.

This has been a movement, you know, for the last four or five years to bring those together, the endpoint network capabilities, to make it easier for organizations to consume and manage. It seems that XDR is more popular among, let's say, mid-size, mid-market enterprises. Then we've got all these other tools that we know and love for many years, like email gateways, secure web gateways, even data loss prevention tools, identity and access management, and then SIEM and SOAR.

SIEM, of course, is designed to take in logs from all these different systems, you know, generally in Syslog or CEF format, and then, you know, correlate and try to surface the things that are of interest to SOC angles. Lastly, here we have SOAR, security orchestration automation response. This is sort of the thing that sits at the top level and tries to understand what it sees coming into the SIEM, and then also provide API-level connectivity back to all of these other security components so that SOC analysts can then manage responses in these underlying tools.

So, again, you know, you've got a wide variety of different tool sets, many panes of glass that SOC analysts wind up utilizing every single day, and what you may find noteworthy here is there's really not that much mention of cloud. So, I ramble long enough. You guys jump in here and tell us about your perception of the modern SOC. Happy to start, if that is okay, Mike. From my point of view, this is just like you see just a fraction. Even that is just a fraction of different disciplines where you can or should ingest data.

You have all those vulnerability management, application security that you could also ingest to get more context, and the cloud just has a lot more data. So, it's just massive if you pull out all the data from the cloud.

So, there you have, again, similar things like the workload, like the endpoint. It's a similar thing like the workload, the configuration.

So, that's a posture, all the log files, also the telemetry that comes out of that. An on-prem CM is very often just not scalable enough to just handle all those peaks.

So, the idea is still the same. You process as much data as possible. This would be ideal, and then you could cross-correlate amongst all of that. This is usually easy to set up for five different sources. If you have 20 different sources, it becomes messy.

So, integration and everything becomes very complicated. So, I believe it's just an evolution of the modern SOC that you think about having a big data lake instead of trying to ingest things.

So, it's just a more modern architecture like we do in fraud detection or if we do data science, everyone would say, create a data lake, throw in as much data as possible, and then run. It could be structured or unstructured, by the way, and then run machine learning on top of that. This is really working well in the cloud because we can handle those peaks with scalability, scaling up and down. It's not working well on-prem, but machine learning is not new, but it really works well in the cloud.

So, for me, the modern SOC is more an evolution of existing architectures where we make use of the cloud, make use of data lakes and modern technologies to actually achieve the same what we wanted to achieve in the past. Mike?

Yeah, so it's an archaeology. An archaeology of technology that evolved over time and that has led to an immense complexity. And as Andreas was really saying, the problem is being able to get all of the data about what is going on across your enterprise and across your cloud. And the hope is that you would be able to get it from these distinct walls that you've set up around you that you hope is going to send sensors or send data to.

Now, the problem and the problem which was articulated ideally by Andreas is that you've now got all this data. And the next problem is, how do you know what is abnormal? And this has been a significant problem which machine learning has started to make a difference to, but it is still a problem. And what is normal and what is not normal, because there is an awful lot, a very large amount of noise in this. And if you're not careful, that noise has everyone running around all the time trying to solve problems that don't really exist.

So, you have to get the data. You have to be able to analyze that data to really understand what is happening and to do that in a way which eliminates or reduces, in any case, the false positives. One of the interesting things that comes out from this, I believe, is that it is the identity signals which are tending nowadays to be the most useful ones to try and understand when you really are under attack. Because I think it's generally understood that the bad guys don't hack on, they log on, having stolen something. And by the way, that's absolutely true.

And if we look at the movement within artificial intelligence, so having agents where you give an agent the authority to do actions on your behalf, it is underlying as an identity that has maybe privileges like you have. And there might be 20 agents in the future or 30 agents attached to your one human identity that do certain actions like calendar entries, booking a trip, doing payments. I would be careful with that right now, but you could say there are plenty of things and there are identities underneath.

So, the amount of identities will definitely massively increase in the near future already. And then identities become the key tool for security, definitely.

Yeah, well said. So, we've described an on-prem data center SOC. Let's talk about the cloud SOC, because they can be quite different.

Mike, would you like to take the lead here? Yes.

So, the cloud is interesting, and we'll talk about why the cloud is different, I think, a bit later on in the presentation. But what has happened with the cloud is that you have this shared responsibility model.

And so, some of the things that were really important in the on-premises world have changed in terms of responsibility. So, the responsibility for the infrastructure that your cloud runs on lies with the cloud provider, whereas the responsibility for your use of the cloud lies with you. And this has caused an awful lot of confusion.

And so, you can almost, again, here is another archaeology, that the first thing that happened was CASB. And CASB appeared because people or organizations were using the cloud, but the organization didn't know they were using the cloud.

And so, the interesting thing here is that this is just the same as Gen AI now, which is that organizations are using Gen AI, and they don't know that they're using it, or they don't know that they're only using the ones that have been approved. So, CASB grew up as a way of saying, let's see who is using cloud, who is using what cloud, and providing some controls over it. And that went so far. But in fact, within the cloud, you have this ephemeral set of virtual resources that are all running away. And each of those, in a sense, has its own security problems.

And part of those security problems come from the fact that for the components to run correctly, they have to have identities, and they have to have access rights. And so, that led to cloud workload protection platforms, which were taking a two-point view.

One is, is the operating system bit and the application bit running correctly? Is it, in fact, free of vulnerabilities? And has it been configured safely? But that isn't sufficient, because you also needed to make sure that the actual virtual machine itself and its identities were correct, and its access rights were correct.

Otherwise, you can get the problem that we started off with, which is a machine, surprisingly now, has access to only your resources, but it should only have access to the resources that it really needs. And if it has more access, then you can use that as a jumping off point to get somewhere else.

And that led to, effectively, a number of other tools, which have grown up, and I call them alphabet soup, where, in effect, all of the different virtual components, from storage, to network, to databases, and so forth, all actually need to be managed, not only from the point of view of access and vulnerabilities, but also from their own identities. And that's all to do with the infrastructure as a service. And that then surfaced up as this thing called Cloud Security Posture Management, which was giving you an overview of your security posture in the cloud.

Now, that's good for infrastructure as a service, but nearly every organization is now moving to software as a service for many of the main things like enterprise resource planning, office automation, and so forth. And those themselves pose problems because they provide access to data. And so you need to have a look at that. And finally, last but not least, is this growing use of Gen AI, which is creating new vulnerabilities, and it's using data in ways that it hasn't been used before. So it's creating data vulnerabilities, and you need defense for all of these.

I would even add that for the Gen AI part, it is mostly cloud, but you could also run your own models on-prem, where you then add a next layer of complexity. So I've seen that with a couple of customers that built their own internal models for business use cases. That makes it even more complex, but I fully agree with Mike. I think there is some beauty in the cloud that it is way more standardized than what we have on-prem. And even if you do it correctly, you would formulate your infrastructure as code, sort of with infrastructure as code.

And then you can already find misconfigurations in the code before it's even deployed. So we have a lot of, I would say, advantages from a security perspective, but the ephemeral nature of the cloud makes it also very complicated. If I run a serverless function to do something, this is actually spinning up a real server once it is being run, but it's just there maybe for one minute or for one and a half minute, and then it disappears.

Doing real, you could say, runtime security in such an environment is very complex, because you might not even know the server name, and until it ends up in any SOC or any system to analyze something from that, the server from that function already disappeared already. So there is a next layer of complexity in there, but I personally think that from a security perspective, we have way more advantages in the cloud if we leverage all the acronym technologies in there. It's a bit too many, to be honest, but we have way more capabilities in the cloud that sometimes we have on-prem.

Yeah, I think one of the interesting things is that the cloud SOC really grew up from the perspective of trying to prevent security problems rather than to respond to active threats, so that nearly all of those tools that you see there are tools that are doing some of the things that you, Andreas, were talking about. They're inspecting code. They're looking at the definitions of the virtual resources that you're using to find and help you to remove vulnerabilities.

So typically, the CSPM, the CNAP sort of world or the cloud world has been around the notion of code to cloud and cloud to code, where everything is defined formally in code, and when you find that you have a problem, then you have to rectify the code, which is good as far as it goes. But they are not specialized to deal with responding to incidents as they occur, which is what the incident response teams in the enterprise have.

So what you don't see in there is all the stuff to do with playbooks and how you're going to deal with an event and who you're going to involve and all that kind of stuff. It's just code to cloud and cloud to code, and we'll keep it clean, which is good, but not sufficient. Yep.

Oh, one quick observation is, you know, if you look at the acronyms here, you've got a couple of them that are about posture management and another two of them that are more or less about discovering, you know, maybe unauthorized activity or unauthorized use of cloud services so that there's a sense of discovery and posture management and maybe a little less so on the on the how to react to actual events, which, you know, you do see in the traditional SOC. So let's assume that, you know, lots of organizations do have two different SOCs. What are the problems associated with that?

Well, we've mentioned the visibility angle. Mike's talked about identity-centric attacks. They're on the rise.

I mean, really, when you think about cloud-based resources outside a bit of configuration, as a customer, you don't have that much control over the physical aspect or no control over the physical aspect and very little about the underlying operating system configuration. So really, identity is the only control plane you've got in the cloud in many cases. We've kind of mentioned a bit about the inconsistent detection. It takes a lot more effort to correlate these attacks.

I think Andy made a really good point about the ephemeral nature of some of these things like workloads and serverless functions that, you know, if you're coming at this from a traditional SOC perspective, the thing that may have caused your problem no longer exists by the time you get the alert. So how do you how do you track that down? So then we wind up with things like increased, you know, mean time to detect, mean time to respond, which also, of course, increases the risk. And there's just a number of different related problems here.

In the interest of time, I'll let you all talk about it a little bit more. Andy? Like I mentioned, so I'd like to highlight two things. So in our unit 42, that they are doing like incident response and those kind of things, threat intelligence, threat research. And in there, in our global incident response report from 2025, they also analyzed the 25 fastest percent of attacks that they've seen. So like just saying that's the mark of 25 fastest percent. And in 2024, these were five hours for the attackers to get in and in the end exfiltrate data.

So the mean time to detect and mean time to respond for the 25 fastest percent is something around five hours in 2024. So if we assume things get faster, that's the trend that we see. Five hours should not be your bar. It should be way less than five hours to actually remediate 75% of the attacks. If you want to achieve 80% or 85% or even 90%, it goes way lower. And now if you have disconnected SOCs, I believe it's logically not possible to achieve that number. If you have blind spots, if you have to hand over an incident and say, oh yeah, we saw, like we mentioned in your first slide, John.

So, oh, there was a phishing attack. We see that. What did you see? Even that human communication between two teams might take too much time to really get to those numbers. That's why I believe you can't have two SOCs for that. It helped us in the last years to really build good cloud security, but it doesn't help us anymore. We have to bring them together. There's a good example how Model Libre is doing that. They are starting with help desk social engineering, like spoofing voice attacks, something like that, to actually get a domain account reset, also the second factor reset.

That has nothing to do with the cloud. That is, you could say, on-prem and 2FA security. But then they pivot. Once they have a domain credential, they pivot to the cloud. Might be AWS, might be Google Cloud, or any other cloud. And once they're in there, then they do actions in the cloud. But in the end, their goal is to exfiltrate data that might live in the cloud. It might live somewhere else in your data center.

So, if you only have those siloed views on that, or even, let's say, a siloed network view, a siloed infrastructure security, and siloed cloud security, you will never achieve less than four hours for meantime to detect and respond. So, that's why they have to converge. Yes.

So, one of the interesting things is, if you look at this from the perspective of how cloud tools grew up, it is that there was a great concern, first of all, about whether or not the cloud service provider's services were going to be secure, and that then pivoted to compliance and auditing. And so, in a sense, a lot of the tools that grew up around the cloud were really focused on giving you a good picture of saying how well you had your controls implemented.

And so, this is the CSPM, the DSPM, and so forth, which is good. It's good to know you have some controls, but it tends to misdirect away from the threat, because simply having a good set of controls is not sufficient. It's necessary, but it's not sufficient. You also have to be able to deal with the threats in action.

And so, what I would assert is that the principal output of the cloud tools as they grew up was about being able to say, we've got control of the cloud, rather than to say, well, we can actually manage when a threat runs through the cloud. And yet, the tools give you an immense amount of visibility that you don't actually see in the other environments. For example, they give you this perspective of paths to risk. This is fairly common of being able to recognize the connection between a weak access control and a set of network connections that lead you back to an exposure to the internet.

So, compliance is not sufficient in itself. What we need is we need to have incident response capabilities.

So, next, let's talk a little bit about the specific cloud security challenges we'll see from a cloud SOC. Mike? Yeah.

So, in a sense, you can sort of work your way around all of the stages that are involved in a SOC, which starts off with the telemetry, the data that's coming in. And in the past, you were able to say, well, I could evaluate the security of my environment, not only by looking at the telemetry that's coming in, you could also do a static sweep.

Well, in a world of dynamic infrastructure with ephemeral resources, it's no good. You can't do a scan because the thing only existed for such a short period of time. You have to clean it out in the first place. When you've got the events, the cloud probably has the information that you needed to be able to understand the context of that event. But the cloud tools don't tell that information to the other SOC tools.

So, you know, if we go back to our original problem, the SOC did not see the fact that there was a vulnerability, which meant that a particular virtual machine had an excessive privilege and also had a way of connecting through to the internet. So, without that awareness of these misconfigurations, it's very difficult to make any sense of the events that are coming in.

Now, equally, at the same time, the strength of the kind of conventional SOC is that these highly refined tools, which are constantly, if you're subscribing appropriately, ingesting cyber threat intelligence from the community, telling you about what the indicators of compromise that are going around at the moment, so that you can understand things. But these typically didn't get included in the cloud SOC. And without that, it's very difficult to understand whether or not what you're seeing is an anomaly or a real threat.

And that then makes triaging these events that come from the cloud very difficult. Equally, having actually decided that this may have something to do with the cloud, there's probably two different teams involved. One is the cloud team, and the other is the enterprise SOC team.

And so, you now have two groups of people that have to work together, and they may not even have common communication systems, certainly may not have a common vocabulary, and all the problems that go with that. Now, where, in fact, you do discover something which is related to a cloud error, a cloud misconfiguration, then the way that you need to remediate that is through code, which takes you back to the cloud teams and the DevOps teams who have to remediate the code, which actually expresses the virtual resources that you have and their vulnerabilities.

So, in summary, you've got all of these problems through lack of integration with the cloud. So, Andreas?

Yeah, there is not much I would add that Circle perfectly explains it. And I've built cloud security teams in the past.

And, for example, leaving out the threat intelligence was a typical problem that I've seen. And that we were unable to really bring those data in our traditional SOC into our CM.

So, we ran it by force because there was no choice separately with all the disadvantages that you have. And it was still not the biggest issue because we had more time available. A few years ago, we had days, maybe even weeks, to analyze and remediate incidents.

Today, if we go down to a few days, that's no longer enough, as I already highlighted. Great.

Now, we'll dive a little deeper on the cloud security challenges. One thing I would add, too, is that the nature of the data is different between what we have typically seen in enterprise SOCs, where we're looking at server logs and alerts from endpoint systems compared to all the API-level activity that you see at the cloud. And then expecting to have that same level of understanding from SIEM and SOAR probably isn't – it's not going to work.

So, Mike, would you like to describe this one? Yeah, yeah.

So, it's very interesting because it's all IT. And at one level, all the threats and the vulnerabilities and the issues are the same. But cloud is different for a whole series of reasons. And the interesting thing, which is perhaps a little aside at this moment, is that at the beginning, in the beginning of people using cloud, there was great concern in the customers that it was going to be the cloud – the cloud providers that were going to be the security hold.

Whereas, in fact, the evidence today is it's not the cloud providers. It's the cloud users who don't secure their systems correctly. And incident after incident is to do with cloud users not appropriately securing their cloud.

Now, why is it different? Well, the first thing, and I think we've talked about this before, is that the ephemerality, the way in which assets are created and destroyed on the fly, the way in which a serverless will exist for milliseconds before it's disappeared, completely is a complete no-no for the traditional message of we buy it, we test it, we scan it, and then we use it. You can't do it that way. It has to be right first time. And you have to put up guardrails to stop things from being wrong.

And that then leads on to the second major problem, which is in a virtualized environment, everything has to have an identity for your virtual machine only to be able to access your virtual resources rather than your competitors' virtual resources that may be running on the same server or within the same infrastructure. And these are all secured using non-human identities.

So, each of those assets has to have an identity, and it has to have access entitlements, and they need to be managed. And, well, when you're a developer and you're trying to make something work, and all of your components have to work together, it's much easier to make sure that you set everything so that it can access everything, whether or not it needs to do it, because then you don't spend your life trying to work out why that didn't work.

But the setup that you needed for access controls when you're developing things is not necessarily the secure one that you need for when you're running it. And so, this then, because of the very size of this, we've got the scale and complexity that is involved in all of this. And not only that, but although each of the different clouds, and most organizations are using more than one cloud, they all have excellent customer user entity controls. They have controls for you to secure them, but they're all different.

They all have different user interfaces, they have different APIs, and it makes it extremely difficult for the user to get a consistent view. Andreas? I didn't find it, but the part you mentioned with the identities and entitlements, I think, is critical. I don't remember the number on, for example, a hyperscaler like AWS. And by the way, you mentioned it correctly, so the hyperscalers are doing a good job.

So, it's us as users that usually fail, and it's rarely the hyperscalers. But the amount of, you could say, privileges a role can have, like an instance, like an EC2 instance of your virtual machine, is already, you could say, insane. I think it goes up into the hundreds and thousands, something around that.

And then, you could have different roles per machine, or multiple roles, to have a very granular setup. But even that little tiny, it looks small, the explosion of non-human identities, but that one is already alone, very big. It has the advantage, like, if I think into the data center, we didn't have that.

So, we didn't have the identities underneath, we couldn't run machine learning if identity behavior changed for non-human identities. But on the other hand, we now have so many different entitlements, privileges, roles, that can be assumed and attached to whatever the complexity, even in there, is massive.

And then, if you go to different hyperscalers, if you're a multi-cloud, it adds another complexity layer, because that is what the hyperscalers are doing differently. So, Microsoft or Google or AWS are doing exactly that part a bit differently. And even translating that into a common language is already quite difficult.

So, the challenge is very high in there. And that's also, it just highlights why the cloud is so different. It makes things easier for us. We can automate things much easier in the cloud. But those elements add a lot of new complexity that we haven't seen in the past.

So, let's talk for a minute about, does integrated security matter? I think this one's interesting because we have so many different kinds of tools that exist in the enterprise already for security. Some average numbers here from a study.

You know, nearly 30 different vendors, more than 80 different security tools. I've seen other studies that show, if you have a lot of security tools, other studies that show even higher numbers.

I mean, I think the complexity here is the thing that makes it so much more difficult. And especially when you look at all the different functions they have to cover.

And then, of course, you wind up with some duplicative functions amongst all these different security suites that you purchase or use. Andy, what are your thoughts on this? I remember that's from a study from IBM that they did together with us. And I think the general problem that we see, or that everyone knows, if you run, for example, a POV or a POC with any tool out there, it's like a small environment and you integrate maybe three, four, five different tools and see, oh, that's working fine. It adds a lot of value to my organization.

Now, the reality is, once you go into production, you see, oh, I don't have just three, four, five tools. I have, so that is the number out of the research, 83 tools. That is massive. And so integrating those is so complex that in the end, at a certain point, you no longer add any value. Even if you add a new tool into your security stack that on the paper would really help you, reality is it doesn't help you at all.

The complexity really kills your, you could say return on invest, even if it's a word that I would choose carefully, but I assume that also the security teams will face a lot of cost pressure the next, so this year and the next year. So more tools and more features actually don't help. Sometimes it's better to have less tools, even if you don't have all the features, but with less complexity, you get way more value out of that. So that's the outcome of that research. And I can just say, I felt that in the past.

If you are able to bring tools down to five to 10 different vendors, and you could say platforms, it really helps reducing complexity, adds more security than trying to throw another tool and another other tool on top of it. So there are some kind of economic calculations behind it. But the more tools you add, at a certain point, you even reduce the outcome of that, because you create frustration, friction, and all those things in your security teams that will lower your outcome, even if you add, theoretically on the paper, more security on it.

Yes, duplication and also gaps that you're not aware of, but ultimately, it's complexity. And that's why I call it cloud alphabet soup.

Yeah, complexity kills security. It's just like this. So let's talk a little bit now about CNAP, Mike.

Yeah, so here is the view of how CNAP is trying to bring some of that complexity down by providing a common platform that covers the major areas of vulnerabilities and fixing them within the cloud. And so, CNAP typically consists of a number of different functionalities, which cover cloud storage security, cloud infrastructure, and entitlement management, workload protection, and cloud security.

Kubernetes privilege management, sorry, I'm going to say it again, showing you the connection between vulnerabilities, misconfigurations of identities, and the internet, and is evolving into cover areas to do with AI security posture management. And effectively, what this is trying to do is to identify vulnerabilities before they get into operation. And since this is all defined by code, then it's scanning code, and it's putting guardrails in what code can be deployed. It's trying to understand the misconfigurations that are related to non-human identities.

And there is usually a very close integration with Kubernetes and container-based development environments, because the most common way that new applications are being deployed in the cloud is as container-based and using Kubernetes and the standards that surround that. So they are going to try and control the CICD pipelines to make sure that you don't deploy code with vulnerabilities in it. They will then also usually do things to help you to detect drift in containers. So if threat actors come in and start to modify things, this will be picked up.

And the latest thing that these tools are now covering is looking at the specific issues that are related to the use of Gen AI, both in terms of its impact on data, as well as who can access it, and the specific vulnerabilities that Gen AI brings with it. Okay. In the interest of time, we've got two more topics I want to hit real quick.

Andy, would you like to talk about Gen AI? Absolutely. There's also a question from Alfred. Just for you, Alfred, I already started typing, so you will get my reply in a few seconds. But moving to the Gen AI part. We talk about two areas for Gen AI. One is the normal Gen AI usage. One of our research has shown the most used Gen AI tool is Grammarly. That's the top. And what we also see is, if we look into the companies we work with, that there are around five to ten sanctioned AI tools out there.

So, like the Copilot, GPT, Grammarly, and so on. But if we look into the network, what we see in the traffic, we see around 60 to 70 different tools being used regularly.

So, it's a bit of history repeating that we had with SAS tools coming up. We now have the same like Shadow. It's no longer Shadow IT. We call it Shadow AI.

Also, the MIT has done a good study around that called the Gen AI Divide, but they can come to the same result. So, the enterprise adoption is slow for Gen AI tools that the end users use, so our employees. And with AI, it's a little bit different.

So, we have a lot of new AI tools coming out. So, we have a lot of new AI tools coming out. And with AI, there comes a bit of like problems with it. If you translate your patent, you give away your patent at the text of the patent, and it might be translated by a model, and you are even not aware of the model. And that model might be provided maybe by a third party that just wants to get access to data.

So, you give it to some kind of black box. It gives you the translation, but it stays within that black box.

So, there are a lot of new risks coming with Gen AI. But obviously, the Grammarly example shows there's a lot of potential in it.

So, we write better text. So, I'm a non-native speaker.

So, if I write English text, Gen AI can help me really writing perfect English text or even French text or other languages. So, obviously, that helps a lot.

Now, that's the usage part. We can tackle that with some kind of Caspi technologies. We just look at AI-specific traffic. The prompts are more dynamic, so it's no longer patterns that we can look at.

So, it's really difficult if you look at a prompt because the prompt can always look differently and can be in a different language. And the reply from a model can also be in any language, and there are also all the time.

So, there is a lot of complexity for us from a security perspective. Where do we do security? Where do we find harmful prompts? The second is actually the enterprise models.

So, if the company puts all their knowledge and intellectual property into models to find a new vaccine or find the cure for cancer or whatever, those are the models that also need to be secured. Because if someone via phishing gets into your network and can ask the model, give me all your intellectual property, this should not happen.

So, the traditional identity and access management is no longer that binary. It's like how you can convince a model giving you access to data that it should not give you.

So, there are new threats that make it extremely interesting for everyone in security. So, I'm super excited because it helps us.

Now, the cloud can help us. The cloud also has disadvantages.

So, the AI element just accelerates everything extremely. I think from a company's perspective, it's on the complete right side. I would always think about worst case scenarios and think about business continuity. That is really essential. Always with that, what if and being creative. What you also have to always take into account is that attackers use those models to get quicker.

So, I'm not a developer, but I can build a perfect looking web app in minutes. So, I can use a vibe coding tool for that. It is really improving the speed dramatically, but attackers can do the same.

And now, if we go to our defense side, Gen AI or AI in general can really help us improving the defense. So, reducing the mean time to detect and especially the mean time to respond there.

So, we can actually get better. One good example is most companies have this report phishing button.

Now, what actually is happening is that the SOC team members are usually flooded by false positives. So, I don't know that guy. This is phishing. It was actually our new CEO and no one watched the news that we have a new CEO.

So, those things can actually happen, but Gen AI can help finding out if there were really true positives in there or if people reported false positives. So, we can improve the time in the SOC and the repetitive tasks in the SOC with Gen AI to make the job more interesting in the SOC itself.

So, Gen AI adds new risks, new opportunities in there, but I'm extremely excited. It makes it very interesting for all of us.

So, we've got like a minute and a half left. So, each of you take 30 seconds, talk about the future of cloud security here. I'll start really quickly because I already mentioned it in the beginning. I would change my paradigms and think about I need a complete data set. I need complete and full data to really run machine learning. The more data I have, the better.

So, underneath, and that is also for a bit like the explanation, we have the architecture to have one big data lake. So, for our cloud, that's Cortex Cloud. For our CM-SOR, that's the XIM. For our XGL, that's all sharing the same data lake. And then we massively run machine learning on top of that. That then really helps to get rid of the basic tasks that are usually a problem. And no matter if it's unstructured or structured data, you of course need to integrate everything from the outside, but it's no longer I have to reduce the amount of interest.

It's on the contrary, it's we want to have as many data as possible to really being able to run machine learning effectively. And that's for me how our future SOC needs to look like. Yes.

So, my few words would be reduce complexity, look for a common platform that covers everything, and read the white paper that John and I have written, which describes in much more detail our view of the future of cloud security. Thank you, John.

Well, thank you. Yep, we're up against the top of the hour. We didn't get to our second poll question. Sorry about that. I think it was a viable discretion.

So, the results of the first one really quickly, 36% said complexity of the environment was the biggest security challenge. 29% said understanding the real risks. 21% said managing the shared responsibilities. And then inconsistent tools and capabilities and lack of transparency of controls came in with less than 10% each. But definitely very interesting. It's a discussion that merits further conversation. As Mike mentioned, we do have a paper out about this, as well as some other reports on CNAP, CSPM, Gen AI defense, and a number of other relevant topics here. Hope you all enjoyed this.

And please come back for the next one. And thanks to Andy and Palo Alto for being here today.

Thanks, John. Thanks, Mike. Thank you. Thank you.