From Shadow SaaS to Shadow AI: Closing the Unowned Security Gap

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole Analysts. And so is Matthew Gardiner. He is for the first time in this podcast. So first of all, welcome with you. Thank you for having me. Great to have you. And before we start, since you are the new kid, although really experienced, really seasoned, can you tell us a bit where you come from and what you're doing at KuppingerCole?

Yeah, I came up through the ranks of engineering and product management. Eventually, about 20 years ago, I came over to cybersecurity.

Actually, my first company was around identity. So that sort of put Kupinger on my radar screen many, many years ago. And then up until about four or five months ago, I've been working at cybersecurity companies and product management and product marketing and decided to shift gears. Fortunately, my friends and colleagues at Kupinger took me on board. And so I'm now a new analyst here and kicking off my first video cast with you. So I'm breaking new ground every day.

Yeah, exactly. Amongst others. Yeah. And we want to talk about, first of all, something that you've written and already published as a blog post. And this also touches upon the topic that we want to talk about. There will be more research later. We will talk about that. We want to talk about something that has lots of names, especially four-letter acronyms, which we can choose. We will talk about that also later. A ton of those. Right.

For me, at least for the start of this episode, it's SSPM. So before we start, what does the acronym mean and what is the problem statement? Why do we need that?

Yeah, so basically SSPM is currently the most popular explanation or acronym for this market. SaaS Security Posture Management, the PM being the posture management part. The main problem really is this Shadow SaaS or Shadow AI or essentially the use and in some cases misuse of all these sort of easy-to-access applications now out there in the cloud. What used to be called Shadow IT, but we'll talk about sort of how that has sort of morphed into Shadow SaaS and Shadow AI. Right.

And when you mentioned Shadow IT, this is something that we knew when somebody has their own database running under their desk. But Shadow AI, Shadow SaaS, it's a different game. It's a different beast. Right. When it comes to risk.

Yeah, I mean, totally. Shadow IT is a sort of concept of, you know, the business unit or an individual has some sort of IT service that they've put together or purchased without the involvement of the IT or security teams of who knows what's going on. What's really happened over the last, you know, four or five years is that we realized that Shadow IT actually was kind of hard to happen because, you know, pre-cloud.

Yeah, sure. They could contract, you know, some business unit in the business could contract without IT. But when they went to deploy it, unless they're putting underneath their desk, they need servers from somebody. They need training.

They need, you know, maybe local software installed. So it's hard to keep secret from the IT and security team. But it still happened with the, you know, the evolution that we're now deeply into of cloud and SaaS applications. People can sign up for things and start using them. And IT sometimes never finds out about it. And so that's what's sort of Shadow IT is now morphed into Shadow SaaS and probably even more recently Shadow AI, where who knows exactly what the end users are sharing or using the service for and what data is leaving the enterprise, etc.

So it's, you know, it's sort of made Shadow IT, which was a concern for more than 10 years. Shadow SaaS and Shadow AI have now ratcheted that up by a factor of 10. Right. But that means that SSPM is also crossing over the line towards CASBs when it comes to identifying unsanctioned or not sanctioned connections to the outside world. And especially, as you said, if it's AI, if it's SaaS platforms where, yeah, the intellectual property of a company or GPR relevant data is stored without the knowledge of the company. That's also an issue.

That is one of the additional problem statements when it comes to SSPM. Really making sure that, yeah, it's even data leakage prevention, right?

Oh, absolutely. I mean, CASB obviously is a pretty big market already and has been around for years.

And that, you know, that sort of CASB, you either have network level visibility into what's going in and out of your enterprise or you have an API based integration into the apps to sort of see how they're being used and what data is leaving the enterprise. So a lot of the CASB vendors have sort of leaned into SSPM features like posture, which is exploitable misconfigurations, kind of like vulnerabilities, whereas CASB was more built around real time activity and more threats, really, or data leakage. But those worlds are very close together.

But, you know, there's some argument that they're also splitting apart, which maybe we'll get into. And as you've mentioned, so SSPM, you've mentioned shadow AI, you've mentioned shadow IT, and you've just mentioned misconfiguration. And I think that is an interesting part because usually you would think if I license a software as a service, I just use it. There's not much configuration. There's not much that I can do wrong.

And if so, then it's the vendor. But that is completely false.

No, totally. I mean, there's a shared responsibility model on any cloud, obviously. And in the world of SAS, the enterprise owns from the application on up. Who is using it? What permissions do they have? What configurations do I have turned on for my different users? Role based access control. All that the platforms will generally support, but it's on the enterprise to configure it the way they want to use it. And this is all presuming these are sanctioned apps.

There's a whole world of unsanctioned apps where the user is just using their corporate email, signing up for an application and starting to use it. Some of them are free. Some of them, they can use a credit card. Some of them, the business unit will just purchase directly without IT or security involvement. So there's all sorts of like, you know, can you monitor the sanctioned apps to make sure they're configured and being used correctly?

And then what about the whole world of unsanctioned apps, which are generally sort of by definition invisible to the IT and security team unless they start really looking? For a moment, stay with the sanctioned ones.

But still, you can do a lot of things wrong when it comes to connecting to those. I guess in your research, you have seen experiences and figures and examples. So what are the incident patterns that are most common when it comes to, I don't know, misconfiguration or, as you said, just overly privileged roles, authentication, mishaps? What is it that you see? You're hitting all the good ones.

I mean, one way to think about it is you have identity-related misconfigurations and then you have sort of this sort of general cybersecurity-related misconfigurations, which kind of makes it interesting in that the world of cybersecurity and identity are interrelated. And in this space, they're very clearly intersected. For example, you know, you might have an identity provider providing single sign-on, but how are you sure that the sanctioned app users are using the identity provider and not just logging in directly?

So if they're logging in directly into a given SaaS application, is their MFA being enforced there? Was it even set up? So they're sort of, in that case, they're potentially bypassing sort of a basic security control of MFA if they're logging in directly. Another example of sort of this misconfiguration is, you know, setting up like a Teams chat or a Slack chat with the outside world.

You know, is that something you want configured that way? Then if, you know, you can receive inbound chats from who knows who in the Teams and Slack. Another simple one is like login failures. Like if someone's trying to hammer Salesforce, like a malicious actor trying to hammer Salesforce to try to crack the password, usually you want to have like a three-login failure or something like that so that they can't just keep trying. If you're not the one administering Salesforce, then how do you know that's been configured? So we can go on and on.

But the point is that, and one final comment I'll make is that in many cases, these business applications aren't even being configured and managed by IT. They're being managed by the business unit. So you have these sort of non-security focused people setting up permissions, either identity or application permissions on their own. So as a new feature comes out, they turn it on. How do you know what the impact is of that?

And, you know, it hasn't been scrutinized. And of course, with a SaaS app, a new feature could come tomorrow. Any given hour, you could get a new feature.

You know, there's no like release cycle that anyone can really rely on. So also from a topic perspective, if you look at us as Coupling, this clearly sits somewhere between cybersecurity and identity. So this is just a short side note. We just published our research compass documents, one for cybersecurity and one for identity, where we look at what we will do in the next 12 months when it comes to our research, our leadership compasses. So there was a bit of a discussion between John Tolbert and me to say, okay, who gets the leadership compass?

And I got it, which is nice, but it could be in both. I haven't checked that. It's in mine. That's good. So I wrote the IAM one. So it's really an interesting topic because it's really a crossover. Everybody says identity is cybersecurity.

Yes, it is. But SSPM is special in that case. That forces the issue by literally having the same problem essentially being addressed by a new solution area. Right. And as an identity person, I would say when it is, in the best case, a sanctioned service that you're using, and if we apply all the usual scrutiny when it comes to access governance and when it comes to making sure that people only have the access that they need for their job and nothing more, this is a problem for SaaS apps and for these apps. And so periodic audits, recertification, that's an issue with SaaS, right? Yeah.

I mean, if you go back to that comment on the new feature can come tomorrow or the new user misconfiguration can come tomorrow. So the fact you did an access certification yesterday becomes quickly moot. So the need really is for continuous monitoring and to find what's called drift. So you had it in a good place or a place, you know, and then two weeks later, what place are you in now with configurations or misconfigurations or identity?

And so what you really want, what organizations really should need or do need is continuous monitoring so that when something goes awry, there's a drift, a flag is set and, you know, the team can react and, you know, address the issue. If we go back to what you said before, and I hinted at that as well. So there are lots of four-letter acronyms around that. And you are, as the expert, as the analyst who's covering the topic, you're still thinking over what is the right term to use for this category, for this market segment of products. What is the choice? Where can I choose from?

So, I mean, the common language is, as we started in the top, is SSPM, posture management. But the PM is the problem in the sense that most SaaS application security or SaaS security is more than just posture. It's more than just vulnerability, exploitable vulnerabilities. It's also about, as we sort of talked about, real-time misuse or data leakage. And so what I think might fit best is just SaaS security.

I mean, it sort of becomes, I mean, the world of SaaS is gigantic at most companies. The majority of new business applications are SaaS-based, with some exceptions. And so ultimately, over time, from the average company, most of their applications are going to be SaaS-based. So it makes kind of sense that there be a monitoring or a security management system specifically tuned for SaaS. But of course, keep in mind, it's not uncommon for organizations to have hundreds of sanctioned and then many multiples of that, of unsanctioned.

So you have a world of hundreds, maybe a thousand at big companies, of cloud-based applications that are in use. And so it sort of makes sense that you have a specialized, comprehensive security solution looking at both the threats as well as the posture.

And thus, if that's the case, then I think we need to move on from SaaS posture management to SaaS security and make it a little bit more abstracted up another level to keep a space for sort of the threat detection and response part of the security equation. Right.

And if I look at what you described right now, if we focus on SaaS or even on SaaS-provided AI, maybe for the future, is this maybe a bit too narrow to say, okay, it's not only the SaaS part, it's also infrastructure as a service, it's the general cloud to have a broader market segment to cover where this becomes an important but only one capability? Yeah.

I mean, it's always the issue with market adjacencies, is should they remain relatively independent or should they blur into each other? And so I guess if I had to answer right now before the leadership compass and the deep research I'm about to do, which is always better to leave things open, right now it seems that the world of infrastructure security, you know, CNAP, and the world of SSPM or what could be SaaS security will probably remain separate because there are sort of literally different levels of abstraction or points of interest into the security controls.

Basically saying the Wizards and the Orcas and the others in the CNAP space are plenty busy trying to keep track of Google Cloud and AWS and Kubernetes and all the tech that is relevant for deploying your own applications in the cloud. And then the world of SaaS has its own complexity because if you have hundreds of sanctioned apps or dozens or hundreds of sanctioned apps, you have dozens or hundreds of APIs into those sanctioned apps and you have thousands or tens of thousands of users in those apps. So that world is complex enough as it is.

And so it sort of makes sense to me that those worlds stay separate. But, you know, does it also make sense maybe to abstract another level up and you have a cloud security platform someday? Maybe. But I think for right now the world of CASB and SSPM are closer than the world of CNAP and SSPM. But they're all certainly adjacent to each other. And we've talked about a few of the capabilities that are obviously within SSPM, but I think the sheer breadth of the capabilities, when it comes just to securing SaaS platforms, it's quite immense.

So if you could explain more about the additional capabilities that are in these products that clearly justify having this leadership compass later, but also just justify having that first blog post. What are key capabilities that I should expect from such a platform?

Well, one, again, you talk about sanctioned and unsanctioned. So sanctioned is the APIs. So every API is somewhat different. One of the challenges that the solutions in the space have to deal with is different levels of visibility and access. So what they try to do is normalize it. So they want to do, there's a certain class of misconfiguration, and that misconfiguration may exist in five SaaS apps. They want to abstract it up to that one class, but then be able to dive down into what specifically is the misconfiguration. So maybe a certain access setting perhaps normalizes up.

On the unsanctioned side, it's a whole different ballgame, because literally you don't have visibility. There is no connectivity to the application you don't know about. So the first step is to gain visibility of the applications in use by your organization. And so by hook or by crook, there are multiple ways that, essentially scanning for actual usage, which means looking at email to see what email is coming in from a SaaS application provider into your users. And then it flags perhaps like, oh, I didn't know we're using that given application.

Some approaches are browser, installed in the browser so they can see the user browsing things and logging in to places that you didn't know about. So then you're like, okay, now we see, we have visibility into the unsanctioned apps, which may again be in the dozens or hundreds. What do you do about them? What's the governance process? How hard do you want to come down on your users? Do you want to say, no, you can't use them? Do you want to have them become sanctioned? So if there's wide enough use. And then it's sort of a third category, the sort of OAuth permissioning.

One of the great values of the SaaS app is you can interconnect them so that you can share data with another third-party application. And so in many cases, the end user themselves can permission the application to share data with that third-party application. And so now you have, maybe it's a sanctioned app, but you have an unsanctioned permission on the backend.

And so again, it's those sort of three buckets of like sanctioned misconfiguration, unsanctioned application usage, and then the permissioning through OAuth, which again is another thing for which a lot of organizations don't have visibility and creates this sort of unmanaged risk. So we get from the citizen developer to the citizen access manager, so they really decide what to share with what?

Yeah, exactly. Obviously, that's the philosophy of the cloud in a way, is that you don't want to stand in the way of the use, the business use of an application. But you have that risk and data leak problem that, since most people are talking about AI right now, there's concern about sharing code with Gemini or OpenID to get a review or sharing a sensitive financial document to get a review of it. Do I think those organizations are going to misuse that information? I really don't, but technically it's a data leak.

And so if you have to report data leakages of a certain type, that has to be reported, right? Because it's went off to outer space, basically. So it's like a lot of things, it comes down to control. There's lack of control. And I don't mean that in a harsh way. I just mean these are business organizations with sensitive data and business processes. You can't have it just do whatever because you're violating your governance policies. You're probably violating regulations. You're certainly putting your organization at risk. It's a sort of unmanaged, unmanaged risk.

So it's sort of wild and crazy in a lot of organizations. And security people are increasingly aware of this problem, but up until fairly recently, there haven't been a class of solutions that make it relatively straightforward to address. Now that there are, we're doing our leadership compass. Right. And before we come to the leadership compass, a quick hint, because you said OAuth and the configuration part, but sharing unexpected data with an outside service is today much easier when people just paste it into, as you said, into Gemini or in OpenAI or JCPT or whatever.

That is the same issue, but even more easily accessible. So I will do a podcast episode soon with our colleague Alexei. And we want to talk about just best practices, the do's and don'ts of using external AI. So some kind of quick lesson for what should you do with an AI? How does it really make sense and where shouldn't you use it? And where does it make no sense when it comes to sharing data? So this is just a quick hint because this is closely related. And sometimes it's just in the hand of the end user, even if it's a sanctioned AI and even if it's a corporate account.

Yeah, just make sure that you do it right. Usually the best approach is to, if there's a lot of use of something sort of unsanctioned, is to make a sanctioned version of it and then proper configuration and management of it. And so I think that's the game we've been playing in security forever. The technology moves faster than the security controls. You can't be the organization of no because these applications are extremely useful. You just got to facilitate a better way.

And then like a lot of organizations will set up a private version of those chat tools that are sanctioned now and presumably better configured and managed. But it's a whole new, you know, we've sort of talked about it. It's a whole new world where a lot of the, quote, administrators of these applications are not in IT and security just because there's so many of them and they're so specialized.

You know, the finance or the legal or accounting department can administer them technically. But like we sort of talked about earlier, they don't have necessarily the security lens in their mind. So they don't know necessarily when they're turning on a new feature, what the implications of that are. But does the IT and security team want to administer hundreds of applications?

You know, that becomes impractical. So there's sort of like this, there needs to be a sharing model where the security team can have oversight, guidance, be able to put the necessary controls in place to comply with the organizational governance and regulatory without getting in the way of the actual business being run. So this is not the first time we've had to deal with that, but I think it's gotten more intense now because it's, you know, the world is so open and so many applications and so many users.

And even all these automation processes that are connecting all these SaaS applications with each other. So having a task, having communication, having Slack, I don't know, SharePoint or Dropbox or whatever that you're using. And they are all interconnected. Do we really understand where data goes? I don't know. I'm not quite sure. Coming back to the leadership compass, this is planned for later this year. So where are you in the process right now and when will it be published?

Basically, we are about to kick it off formally. We're in the process where we're doing an expression of interest right now where we've asked, there's 36 vendors I've discovered that have more or less a solution in this space. And so we basically asked them like, hey, we're about to kick this off, do you want to play? And so those are rolling in right now. So assuming everything goes smoothly next month, meaning March, we will kick off the formal process with a questionnaire and a market definition and invite the 36 and or more, if I discover more in the meantime, take part.

And if that runs smoothly, then probably by mid to late summer, we'll publish the leadership compass, the first one we've done in this space. And maybe it'll be called SAS Security by then. But to ease people's understanding, we're more or less referring to it as SAS Security Posture Management because that's the most popular term right now. But I'm leaning towards calling it something else just to be a little bit more open to the, as I mentioned, the threat detection and side of the equation, which would seem to be increasing in importance.

But also that means if there are vendors out there who would by chance watch this episode, they can reach out to you and to say, yeah, please put me on the list. Yeah, I'm mg.cool.com. So feel free to send me a note. Like a lot of these leadership compasses, we're not trying to exclude people.

I mean, we do put forward a market segmentation, basically, or a market definition, and no one fits perfectly into it. So there's always that, how much of that do you provide? But as the first leadership compass, as we always try to do, we try to be open-minded. We'd always rather people participate, give us their point of view, their experiences, their customer, what they're seeing in the real world. And then we incorporate it into the overall research because it's never a one-size-fits-all in this market. You have platform vendors. You have standalone vendors.

You have some vendors that are specialized in more detection and response side of things. You have some vendors that are more specialized in the posture side. It's still early days in this market. So we don't want to rule people out. We would rather stay open to people that have emerging businesses in this space.

As usual, when you're getting close to the end of this podcast, if you are watching this video and you are interested in that market segment and you're not a vendor, and if there are any questions that you think are relevant for including in the analysis for Matthew, just leave a note when you're watching on YouTube, just in the comment section to say, okay, can you ask for this? Or if you don't want to put it on YouTube, just send a message to Matthew to say, okay, please have a look at this. This is really just forming. And so this is a new leadership commerce that we're doing.

And I think it's interesting also to be able to influence the analyst. Why not to say, okay, this is interesting. Have you thought of that? And maybe Matthew has or not.

Yeah, if you're a security person, you're probably, you're either involved in this problem already or you're aware of the issue and maybe your organization hasn't bitten off, trying to solve it. This is always the classic problem. If you have visibility into the problem as a security person, you're almost compelled to do something about it. And so it's a whole new domain. And most security people are not unbusy. But the reality is it's, I don't know how you can ignore the space anymore, really.

I mean, not that we're ignoring it, but I don't know how it doesn't bubble up into high priority because cloud's a thing. SAS is dominant, going to become more dominant. AI is essentially pouring gasoline on the SAS world. The fire has been lit. As a security person professional, usually you may not have the solution, but you want to be underway when the executive management starts sniffing around to this problem or they start seeing breaches that are tied back to essentially to this problem space. You don't want to be caught flat footed. You want to have a plan basically in place.

And so hopefully taking part in a leadership compass or communicating with me about what you're doing about it now, what you'd like to see in a solution, we're always happy to hear from you. And hopefully when the leadership compass is published, you'll take advantage of it. And in the meantime, there's a blog that I wrote that sort of goes over this at a high level. And then my colleague, Mike Small, published what we call Buyer's Compass on the SSPM market that's been published for a while now. So we do have resources to help you right now, but more coming. So you stole my final question.

I wanted to ask for the blog post and the link to that. For people interested in your blog post, what should they search for on the Coupang.co website? So the blog is entitled, From Shadow SaaS to Shadow AI, The Growing Security Gap No One Owns. Hopefully that's catching people's attention. And it's off of our blog site. Right.

Okay, perfect. So, Matthew, thank you very much for being for the first time my guest today, especially with that voice. You should moderate that other than I. So that's really just nice. And I'm really looking forward to having you soon again, I think we have something planned about also an interesting topic. It's about AI slash SOC and how that plays together. So that will be interesting as well. You have nice topics, I understand. So you joined for the interesting parts here.

Well, I think all we do is interesting, but yeah, there's always more interesting things to do in security. Fortunately, a couple of them have been thrown my way and I'm learning a lot as I do it and enjoying writing about it and hopefully helping people out there get a better handle on it. That's ultimately what we do as analysts. That's why I'm here. So without further ado, thank you very much. Great to have you in the company. Great to have you on the podcast and looking forward to having you soon again. Thank you very much. See you and bye bye. Microsoft Mechanics