Cloud Alphabet Soup - CNAPP

Well, hello, and welcome to another KuppingerCole webinar. Our topic for today is Cloud Alphabet Soup, or specifically CNAPP, Cloud Native Application Protection Platforms. My name is Alexei Balagansko. I'm a lead analyst here at KuppingerCole .

And today, I'm joined by a colleague of mine, Mike Small, another analyst. Welcome, Mike. Great to see you. Great to see you, Alexei. Welcome to all the participants. Right. So before we jump into the discussion, a few words about housekeeping rules. So every participant is now muted. You don't have to worry about that. We will run a couple of polls during the webinar, where you will be able to cast your vote, if you will. And we will discuss the findings right after that.

There is, as usual, time allocated in the end of the webinar for your questions and our answers. But you are very welcome to submit your questions at any time using that specific tool in the CNAP control panel. This webinar is being recorded. All the slides and video recording will be posted on our website. And everyone will get an email with a link. So without further ado, let's just jump into our first poll. Can we please have the poll activated? But basically, the question is very simple. Which security challenge do you believe is the biggest issue for your hybrid multi-cloud environment?

Is it just still not understanding all the real risks? Is it the complexity of your existing infrastructure? Is it too many shared responsibilities? Or maybe it's all in the tools and capabilities, or just kind of even having the tools in place and not having enough visibility and transparency to them? Let's just give our attendees a minute or two.

Mike, do you have any predictions for the responses? What do you think is the biggest issue?

Well, I think my view would be it was to do with inconsistent tools. Right, right. Can we actually see what's going on? Because I'm sharing my screen, and so I cannot actually see the results so far. So Oksana has shared the screen, and I can see that at the moment, A is getting 45%. Complexity of the environment is getting 10%. Managing shared responsibilities is 10%. And inconsistent tools is 17%. And it's currently changing as people are voting. I almost feel like I'm at a horse racing game.

But we can already see that the first option is actually getting much more votes, many more votes than anything else. So I imagine that a lot of our attendees, and which actually reflects very well to the rest of the vote, I imagine, are still struggling with even understanding the scope and the complexity of the challenges they are facing.

Well, good news for everyone. This is exactly what we are talking about today.

So yeah, we are, of course, explaining the solution for this issue. But of course, we will start by talking about exactly why we are struggling with understanding the real risks and what those risks are. And of course, how do we fix that challenge?

OK, so I am back sharing my slides. And let's just jump into the first section. I think it would be a great idea if you start talking about those risks and issues.

Yes, OK. So this comes from the race to digital transformation. And perhaps you could put the next slide in. First of all, the cloud is an amazing thing. And when I was developing software at scale, I wish I had had the cloud. Because what I found most of my time was concerned with was trying to get the resources that I needed to develop and test the stuff that we were developing.

Now, several things have happened. The first thing is that people who develop software have figured out ways to do it in a much more reactive and responsive way to meet the needs of the business. And so the way in which software is developed now is a much more responsive approach. But in order to do that, you need to have tools and capabilities that support that. And in effect, the cloud has come to the rescue here.

Because whereas when I was developing software, I could wait three months for a piece of hardware to be delivered and commissioned, now I can get a server in microseconds, providing I have a credit card. And that this has completely and radically altered the way in which people can develop and deploy new applications and create new business models and create new kinds of services. So this is great, but it also brings some new concerns. So perhaps we could have the next slide, please.

So when you look at surveys that we have done in the past, some of the biggest challenges, which in a sense come over to what the risks are that are perceived by the people that watch our webinars, is to do with the risks of credentials, secrets, and identity. That if you can get hold of identity, then you can pretty much take control of things. And that's especially true of privileged accounts, because the bad guys, the threat actors mainly, in fact, look for privileged accounts in order to get hold of things.

And these, to some extent, come from a poor design where security is not properly taken into account in the first place, or that cyber hygiene is not properly implemented. Now, that's all very technical. And if you go and talk to a businessman about those things, the board of directors, most of them, aren't really sure what you're talking about, because their view of risk is different. Their view of risk is a business-oriented view of risk, where if they invest something, they stand to make a return, but in fact, have the hazard that they might lose their investment.

In fact, the risks that we are talking about are what are described in risk terminology as hazard risks, where if you're selling something, if your systems are hacked, if you lose your data, then you can be fined as well as losing your reputation. And later on, we will describe how a global business ended up being fined $1.2 billion for data violations. Data breaches are always incredibly a problem. Most of these that are reported are related to some form of personal data.

But in fact, intellectual property is another thing which is very expensive if you lose it, because you lose your competitive edge. Potentially, if you are a digital supplier, you may well find that you have to completely recreate your whole edifice, because what has been stolen is how your thing works and how it is configured. And business continuity is the final thing that business people understand in terms of business risk, that over the last two or three years, there has been a massive explosion in the amount of ransomware and denial of service that has been put on organizations.

And in a way, this is, if you will, the downside of digital transformation, that whilst it's a great idea to use digital technology to remove your help desk to automate your systems and to make everything based on IT, if the IT goes, you've nothing left. So the days when you could just put all the stuff in a bus and move them to another location are no longer the case when you are using digital as your main way of delivering service. Next slide, please. And so this is where I think my...

It's me, isn't it? So the challenges for the...

Oh, maybe, Mike, we should kind of try to do it interactively, to me, to you, right? So, yeah, maybe I will take over the next slide and say the biggest challenge, of course, the root cause of all the cloud-related uncertainty is, of course, the shared responsibility model.

So, yeah, I mean, cloud has been with us for almost two decades. And from the early time, we were always told, well, you should move everything you have to the cloud because cloud is inherently more secure than anything you could do locally because clouds, of course, are run by a high number of specialists, especially in security. They have tons of security controls everywhere.

And, of course, they know much better how to secure all that infrastructure they operate, which is, by all means, true, but it's unfortunately not the whole truth. As this slide indicates, there are parts of the entire cloud stack which are indeed secured by the cloud service provider because they are obligated to do so. Unfortunately, there are other parts which are completely your own responsibility when you are using the infrastructure. And this especially means that you are still responsible for all the inconsistencies and inefficiencies in doing that part of your job.

So, yes, the CSP is responsible for the low-level infrastructure, the networking, the clusters they're running for their services and so on, but you are still responsible for securing the data, the business application logic you have created, and, of course, a lot of your own compute, storage, and networking infrastructure is kind of on the higher level. It's still your responsibility, and you still have to manage all those additional tenant controls. So what is the biggest challenge of that?

Well, obviously, as soon as you are going and, as I say, multi-cloud is the new norm nowadays. Only very few companies can afford even having everything run in the same cloud service provider. You have to deal with multiple inconsistent, incompatible, and just very, very different technology stacks. Each cloud service provider has their own sets of APIs, their services available, their security controls, identity frameworks, monitoring and management controls, and you have somehow to learn each one of those.

You have to manage, monitor those capabilities, and in the end, you are still legally responsible for all the issues, and this is simply too complicated. It is especially complicated when just kind of running all these things at scale introduces some unexpected challenges. For example, it's so easy to run everything in containers, for example, or some other ephemeral workloads which would pop up whenever necessary and then wind down when they're no longer necessary. That's the beauty of Elastic Cloud.

It saves you tons of money, but it also introduces massive challenges in maintaining visibility across those resources. Capital One was a very publicized example of such a breach. They thought they were doing everything right. They were keeping their sensitive data encrypted in basically in AWS F3 buckets, and by all means of compliance regulation, that was enough until it wasn't.

We don't want to go deep into technical details, but the hackers managed to gain external access to a virtual machine through a misconfigured firewall, and from that virtual machine, they would be able to elevate their privileges, and they would be able to access the files which were encrypted and decrypt them simply because they could also access the keys, for example. And in the end, it led to a pretty strong compliance violation fine.

Again, kind of $80 million fine is by far not the biggest one. We have examples of companies being fined for over $1 billion, and yes, that example we used in an earlier slide was actually a Chinese company, but, well, hackers know no borders, right? In the end, the market, of course, has tried to respond to this demand. They offer a ton of different specialized security tools specifically for cloud environments, and this is exactly what we call the cloud acronym soup.

There are just so many acronyms you have to learn now just to understand what exactly they can actually do and what kind of risks they are addressing. SIEM are specialized tools focusing on infrastructure entitlement, basically to understand who is allowed to access which resource and enforce compliance.

CWPP, Cloud Workload Protection Platforms. It's basically about securing your applications in the runtime phase, running on virtual machines, containers, perhaps, or even serverless architectures. You have to know what's going on, whether some workload was compromised. CSPM takes a completely different angle on the cloud security posture management. It's basically looking into all the resources you have and measures the riskiness, the risk scores for each of those resources based on vulnerabilities, access rights, compliance, and so on.

So, basically, you need a CSPM to always know what's going on around your cloud deployment. And, of course, we have the long tail of many more and even more specialized tools. Kubernetes Security Posture Management, Cloud Data Security Posture Management, Cloud Network Security Controls, Cloud Access Security Brokers, Cloud Native Extended Detection and Response Solutions, Cloud Application...

Sorry, Cloud Attack Service Management tools. And I've even heard about Cloud Native SIEM and SOAR solutions, which are basically security analytics platforms. How do you manage not to drown in this crazy soup?

Well, the ideal approach, of course, is to have all those tools delivered in a consistent platform, which would not just work seamlessly across multiple clouds, but would also provide you centralized visibility, centralized management, reporting, compliance, risk assessment, and, of course, constant monitoring of everything that's going on across your entire cloud deployment. The question is, do we need another acronym, TouchSolutions?

Mike, I think you can talk about that now. Okay, so this is what has led to this growth in these Cloud Native Application Protection Platforms, or CNAP. And so we have been studying these, and this is ultimately going to give you a view of what the results of that study were. So when you look at the security issues around cloud, actually, they're very similar to the security issues around any form of IT delivery. As Alexei pointed out, the problem is that each of the cloud service providers has a different technology stack and a different set of tools and APIs to manage the security in that.

And so when you look at what you need in order to, in an integrated and consistent and coherent manner, to manage the security of all of that, then these are the things that you should think about. I mean, it's pretty obvious that the benefit or one of the major benefits comes from having a single tool that gives you a consistent way of managing the security across multiple clouds.

The second major area is to do with identity and access and managing not only the identity and access of the cloud service administrators, which are indeed quite complicated because many large organizations have cloud usage by business division. So you have business division administrators. And in addition to this, in order for the virtual infrastructure to work, the different components of that infrastructure have to have access rights.

It's these access rights that means that your virtual machine or your bare metal machine is yours and not somebody else's because they're all in this gigantic network of virtual resources. The same is true of cloud storage. And in effect, what the Capital One problem illustrated was that a virtual machine was given lots of access rights by the developers because that makes sure that it'll work. And those access rights allowed the virtual machine to have permissions to decrypt data in a storage device.

Now, you have inside a cloud your own internal virtual network. It's a software-defined network, but it's still a network. And all of the things that we know about networks and have known for many years about networks still have to be managed. You have to be able to control the kind of traffic that can get to different servers or where it can get. And you need to segment networks to make sure that different components can only be accessed in the ways that they should do. When you use your virtual machines, when you use your bare metal servers or whatever, they have operating systems.

They have configuration. And all of those things are your responsibility as the user. You have got to make sure that that is correctly configured, that patches are applied, that you've basic things that you should do, which you've always had to do, whether it was Linux or Windows or whatever. When you use container-based development, which is an amazing sort of technology that makes it easy to deploy and scale at scale applications, you need to manage the pipeline for how these containers, which contain everything that you need to run that application, are in fact managed and deployed.

And that then includes things like the application security itself. And indeed, it is now said that many of the threat actors now target poor application development. Applications are still being deployed using well-known and easy-to-hack and easy-to-rectify coding issues that can lead to things like SQL injection and so on.

Now, as regards the posture management, the problem here is that whereas people previously had a way of displaying how secure their real infrastructure was, how do you show where your posture is related to compliance and related to security of your cloud infrastructure that you're using? So these are all the things that you need to be able to look at.

Now, that's a long list. And so what I'm going to do in the next few slides is dive down into some of the more important ones of these. Next slide, please. So when we look at cloud entitlement, we have to remember the whole of this virtual environment that's a cloud is managed through identities and entitlements. It's the identities and entitlements that distinguishes your part of that infrastructure from everybody else's. And within that, you have to use all the different things that you used to be able to manage for physical premises and ordinary administrative users.

And so some of the risks that come from this are weak authentication. Now, in a sense, if somebody can, a cloud by its very nature tends to be accessible on the internet. So your administration of the cloud is going to be accessible on the internet.

Well, do you think that it is good enough under those circumstances to have all your administrators for the cloud only using usernames and passwords? Well, I don't. Because clearly, usernames and passwords are well-known as posing a problem. So you should have some form of stronger encryption than that. Another major issue is to do with what we call orphan accounts, which are accounts that no longer have an owner and are no longer being used. These occur when people move, when people change jobs, when people leave the organization.

Now, all of this stuff was stuff that you had tools galore to do with identity governance. But suddenly, you're now faced with having to integrate your cloud into that. So that was simply talking about authentication. The other problem is authorization. And since most of these accounts that we're talking about are administrative accounts, then you need to have a way of limiting the scope of those administrators so that they cannot exceed the risk that's involved by giving them access to the whole of your organization's cloud infrastructure.

You need to be able to have delegated administration with people only able to administer the very things that they need to do. And so these are things that, again, we're all used to talking about, like the principle of least privilege, separation of duties, and how can you audit whether or not the right people have the right access that they need, and no more. And finally, the new thing that has come with all of this is, in fact, the access rights that the infrastructure has.

And here, as we were talking about earlier on, service elements themselves have to have access rights. And if you do not do things, then sometimes those service elements will have global access rights to the whole of your infrastructure. And that may be good to enable the developer to test things, but when you deploy a service, you need to make sure that those access rights for those service elements are no longer excessive. There is also the interesting issue, which is that this is related to the network part, because all of this virtual infrastructure is interconnected.

And some of these access rights are more at risk because of the potential for attack paths. And so you need to be able to think about entitlements, not only in terms of the individual elements and people, but also how accessible the elements that you're talking about are. Next slide, please. So the network is the network. It's now this virtual network that the cloud service provides you, your organization, with as a software-defined network. And once again, I'm talking here not about how well the cloud service provider secures that, but what you have to do. And this is just another network.

So do you know what its topology is? Do you know what is connected to what? Is everything connected to everything else? What should be connected? And how do you deal with the fact that you may have more than one cloud service? How do you connect to the cloud services? Is there a secure connection between the cloud services? So all of this kind of issue is something that you need help to be able to visualize. And only when you understand what you have can you start to then put in the kinds of controls.

And these controls basically boil down to routing points, which usually are some kind of a control point where you can say whether or not different kinds of messages or different kinds of protocols can pass related to different applications or different services. And so again, you need to have a way of managing the policy of all of this. Because what will happen, again, is all of this stuff is dynamic. And if you have configured an elastic service, then your network will logically remain the same but may be configured with different connections to give you the kind of scale that you need.

And so all of the considerations that everybody's been talking about, like identifying the accesses and identifying the accessors as well as the protocols to give you a zero trust, is essential. And the only way that you can start to deal with this in a dynamic environment is to have it based on a policy rather than trying to make sure that you simply manually configure every individual router or firewall or web access firewall when you have scanned it. Another issue is to do with certificates.

Now again, there's lots of ways in which certificates can be used. But in fact, in the network, they are a critical component of the security of secured connections using TLS. And many organizations are completely out of control in that they have loads and loads of self-signed certificates. They don't know where those certificates are. They don't know when they are going to expire. They can't be sure that they're using strong encryption algorithms. And you don't know what their certificate route is.

So if you're going to use the cloud network and you are going to use TLS within that, you need to have a good way of managing those certificates so that you can cycle them correctly and know where they are, when they were signed, and when they need to change. Next slide, please. So cloud compute services are exactly what they say they are. And the interesting thing is that you get a virtual bare machine, you get a real virtual machine, or you can have a specific kind of virtual machine like VMware. But all of these virtual servers contain an operating system, and they need to be managed.

The entitlements of the virtual machine itself needs to be managed so that you know who owns it, you know what rights it has, and you know whether or not it is currently in use. And incidentally, the cloud service providers make lots of money because every time you have a virtual machine there, even if it's deployed, if you're not using it, you're still being charged for it, probably. And so being able to know that you have dormant virtual machines is important, not only from a cost point of view, but a dormant machine may not have been patched.

If it's not actually up to date, it probably hasn't been patched. Then so on and so forth. Operating systems have lots and lots of vulnerabilities, which are well-published by MITRE. There's no vulnerabilities and exposures that you need to have a proper patching regime and a way of enabling that the things are patched and that they are configured correctly. And there are lots of well-known ways you should not configure your machine, for example, like having root generally enabled.

Now, so all of this, again, comes back to a different way of approaching how you look at this security. When you have stuff on-premises, when you have physical servers, what typically people would do is they'd say, well, once a week, we'll run a scan for the CVEs.

Well, that's not going to work in the cloud, because in the cloud, everything's ephemeral. Everything's dynamic. And servers get spun up when they are needed and taken down when they're not. So once again, all of this needs to be manageable in a way that is policy-based. Next slide, please. And this takes us on to the development pipeline, where if you're using containers, you have a series of risks related to the registry and the access controls on that, whether or not you understand what the lifecycle is and how, in fact, stuff is being transported.

Each image is, in fact, a replica of everything that is needed, includes the OS, third-party packages, as well as the code. So you need to be able to manage this in this virtual environment to make sure that your code doesn't contain well-known errors and that there is nothing happening that is degrading the containers whilst time is passing, i.e., has somebody been not updating it or including risks or vulnerabilities that they shouldn't have done. And you need to be able to manage this when it is actually running. What is running?

Are there any threats that you can see about how those containers are behaving? And how do you decide which vulnerabilities you should focus on? And next slide, please. And finally, we need to look at compliance posture. And so being able to get a simple view of what your risk is for the way you have your cloud services deployed, where you can look at those risks either in terms of their financial impact or in times of their severity, and to relate them to your regulatory obligations and also how well you are complying with best practices and frameworks is something that is incredibly useful.

And to be able to do this not just for a single cloud but across multiple clouds. And so with that, I'm going to hand back over to Alexei, who will take us through the next section. All right. So now that we have outlined the challenges and all the various technologies which such a potential solution actually has to provide to address the challenges, we come to the actual findings of our market research.

I mean, obviously, Kuping.co has been covering various aspects of cloud security for years. We've done separate research on topics like container security and cloud entitlements and cloud security posture management and a lot of other in-depth analysis of specific segments. But now that this new acronym CNAP is gaining traction, we have decided, yes, we need to address it in a more holistic way, if you will, as well. So what we've done, we've produced another leadership compass, which is our term for an in-depth multi-vendor market comparison. And I would go through its methodology quickly.

So we rate products and vendors in a specific market segment across multiple categories. So for a product, we check, is the product secure on its own? And how well does it address multi-factor authentication and segregation of duties and zero trust and so on? Or what functionality does it deliver? Does it actually, is it actually able to cover all those functional requirements we have outlined at the beginning? How well are all those included parts integrated together? How easy is it to deploy and operate? How well does it play to other services?

Because in the cloud, it's almost never possible to control everything from just one tool. And finally, how easy is it to actually use on a daily basis, either for an administrator or a security analyst, for example? We also look at each vendor's financial strengths. Is it profitable? Is it backed by capital? How well is it connected to ISVs and resellers and global representatives in sales and so on? How many customers do they have? How visible is their presence around the world? And finally, how much do they invest in innovation?

How quickly can they address changes in the market or impress the customers with something nobody else can offer? And for all those calculations, we identify four categories of winners, of leaders, sorry. So first of all, product leaders are those who deliver the best functionality. Market leaders are those who have the most customers and partners. Innovation leaders are those companies which might still struggle with getting the market traction, but what they do is so amazingly innovative that they definitely have a bright future.

And finally, we weigh and normalize all of three into overall leadership. And for this particular leadership compass, we have a really interesting list of vendors which we actually covered, analyzed, rated, and have a tangible verdict on those. As you can see, some of these vendors are like veteran security vendors which have tons of solutions across the entire security market like IBM, Apollo, Alta, or Microsoft. We have companies coming from endpoint security routes like Checkpoint or CrowdStrike, for example.

We have companies which started with cloud native security originally like Aqua or Lacework or Sysdig. Some are actually involved in open source projects. So it's a really interesting and healthy mix. It shows that the market is actively evolving and there is definitely more convergence coming up. But so far, the competition is really interesting. And without further ado, let's just look at the leadership. So these are the overall leaders. Unsurprisingly, Apollo, Alta Networks, and IBM are leading the pack. I have to make a small disclaimer. This is not just product leadership.

It's the overall leadership. So these companies just have massive global market presence. They are leading the pack in that regard. The actual leader in capabilities was the company called Wiz. And the rest are actually forming a pretty tight pack. So just looking at overall leadership should not be the only reason for making a decision. First of all, the market is evolving.

Second, your requirements might be different from others. And again, the biggest challenge with the acronym soup is that different vendors have different understanding what should actually be included in a CNAP platform. So in the leadership compass, which I advise everyone to read completely if you are interested in the subject, we do provide a write-up for each current vendor. This is just a really shortened example of how we would rate each solution according to those eight functional axes on the spider chart, those capabilities which Mike has described earlier.

And of course, for each vendor, we would give out ratings, the numbers, highlight their strengths and challenges as well. And I have to address elephant in the room that some of the companies which we know and analyze and could even advise you upon for various reasons could not actually participate in the rating. So we have included them as vendors to watch. So we were not given the opportunity to assign a rating.

But yet, if you are interested in learning more about those solutions, feel free to contact us. And we will always try to answer all of your questions. And this is actually my last slide for the leadership compass because it's a really pretty long read. If you want to know more details, you should be reading the original report. It's linked in the presentation.

Of course, it's available on our website. So before we jump into the Q&A session, I would like to run another quick poll. And this time, the question is very simple. So how far is the organization basically on their journey towards CNAP adoption? Do you already have it mastered completely? Or are you even not, have not even started? Can we please have the poll activated? So there is also really interesting. We actually have quite a few respondents saying that they have fully adopted CNAP solutions for most or all of their cloud native applications.

Mike, was it something you have expected? No. I think that most, many are still considering it. A lot more are still considering it or evaluating it. And I think that's really where most, the majority are. That I see that still evaluating is, in fact, the one that is coming out the top.

Right, right. A partial adoption is probably where people are starting to roll it out. And it's the problem. People have bought into bits of the acronym soup. If you ask the same question, how many people are using CASB? I'd say a lot of people have got CASBs deployed. If you say, how many people are using CSPM? That has been something that was much more widely taken up, particularly because it was attractive because you could sell it to the senior management as a way of helping you to see how compliant you are.

CNAP, again, some people will say, well, we're using Kubernetes. And there's a lot of tools around Kubernetes. We're only in one cloud environment. So why do we need all these other things? But as soon as you start to move to more than one, then you get the need for this.

Yeah, that, by the way, is an interesting question, I believe, was asked earlier as well. So isn't Kubernetes just a solution for all our multi-cloud travels? Because it works everywhere. It has a pretty secure internal configuration, if you will. So why not just use Kubernetes for everything?

Yeah, and that's one of the questions. Can we please switch back to the presentation?

So yeah, we have reached the end of our slide deck. Short summary, just to reiterate what we were talking about before. There is a lot of digital risks with multi-cloud adoption, a lot of security challenges, a lot of tools to potentially address those challenges in a siloed, disjointed way. And the need from the general public to actually combine those tools somehow in a consistent, convenient, and simple enough solution has led to the emergence of this whole idea of the emergence of this whole CNAP thing. But of course, CNAP, again, is not the only response.

Again, some will just say, OK, we will only use one cloud, perhaps, or we will stop using cloud at all. Others would say we will stick to Kubernetes or some other lowest common denominator across multiple cloud platforms. So why would we choose CNAP and not all the other potentially easier solutions?

Well, I think that's an interesting question. And so first of all, if you are only using one cloud, then you will find that all the big clouds, Google, Azure, AWS, and IBM, they all have a rich set of tools.

And those, logically speaking, are highly integrated with that cloud and highly integrated with each other. So if you're happy to stick with one cloud, you may well find that the cloud itself provides the CNAP that you need.

However, that isn't necessarily true for all organizations. So there's all kinds of reasons why organizations find themselves using more than one cloud. One of the most common is mergers and acquisitions. So that company A is using AWS, acquires company B that has a standard for using Azure, shall we say. And suddenly, you find you've got applications built in both. Other companies are, in fact, paranoid.

And to answer the question of, I think it was an earlier question, which was to do with why would you have a multi-cloud environment, well, to give you a real example, that some years ago on a Friday, some hospitals in Britain got a note which basically said that the service provider that is providing your IT services is, in fact, now in bankruptcy. If you want to continue using the IT, you will have to pay us, the administrators, this sum of money by 5 PM on Tuesday, or it will disappear.

So there's all kinds of other reasons other than technical reasons why a cloud service may not be available. And at a business level, you don't care whether it's because something set on fire, whether it's because the internet is down or whatever. It's that it just doesn't work. And so businesses commonly will adopt multi-vendor strategies to avoid locking to a particular vendor for all kinds of business reasons. So those are some examples. And on top of that, of course, some vendors will just say we want to have the best of breed functionality in every field we need.

And this is why we, for example, want to, I don't know, run our workloads on AWS. But we want to have the databases from Oracle Cloud and business analytics from Azure. And why wouldn't they? So there is actually a whole market of tools specifically for that, how to improve and optimize multi-cloud deployments from this perspective. It has nothing to do with security or anything. It's just kind of making sure that it works seamlessly for the developers, for the line of business applications, and so on.

So yeah, I guess sticking to just one cloud is rather an outlier, not the norm nowadays. One other question we have is, are you suggesting that Synapse actually aggregates all of that cloud acronym soup? And why is it a solution for that?

Well, in fact, I would have to stress that no, that is absolutely not what we are implying. In fact, every time we talk about acronyms, we say don't look at them. Don't look at labels. Look at specific capabilities. Acronym soup is a problem because it replaces real challenges, risks, and solutions with meaningless labels. And the more labels you have, the easier it is for you to overlook something which you would expect a solution to have just by looking at the label. And in fact, it doesn't. This is why we are doing this leadership compass reports. We do not look at the labels.

We look at specific capabilities. We ask technical and non-technical questions. We apply our expertise. And this is why we always include those spider charts. So whenever some vendor would call themselves a Synapse provider, you can always go back to the spider chart and say, yeah, well, you are actually lacking the entirety of SIEM, for example. Maybe for somebody else, that's good enough, but not for me. And that should be the way.

Yeah, and just as an interesting addition to what you've said, I think that for the end user of all of this, what matters is the use case. And different use cases require different sets of capabilities. And so not only do we have this leadership compass, but we also have another tool called OpenSelect, which will soon be updated to include this, which allows you to look at different use cases and help to understand what capabilities you need in those different use cases and match particular vendors to those.

We have another follow-up question, which says basically that the cloud native application protection platforms do not cover SaaS applications, which still have to be managed with KSBs, for example, which is absolutely true in a sense that, well, a SaaS application is not your cloud workload. It's someone else's cloud workload, right? So maybe the vendor who actually offers you a SaaS application is using a SIGNAP platform themselves. It's just in the modern shared responsibility model, they don't have to give you any visibility or control into that. Maybe it will change in the future.

Maybe there will be some more interesting new compliance requirements, for example, regulations. But so far, yeah, we have not included KSB into SIGNAP because KSBs are, well, they have slightly different use cases, as you just mentioned.

Yes, and indeed, to sort of expand that a little bit further, there is another set of acronym soups around Secure Access Service Edge, where KSBs seem to have somehow or other moved into that area as part of this. And I can see that there was one other allegation that I was advocating on-premises.

No, I wasn't. I don't know how you got that idea. I think the cloud is an amazing way of doing things, but you have to manage the cloud in the right way for the cloud. So it seems that time is now up.

So yes, if you have any further questions, I suggest you visit our website. Some links are on the screen now. And with that, again, thank you very much. Looking forward to seeing you in the future webinars and have a nice day. Cheerio.