Analyst Chat #76: Do we really need Cloud Infrastructure Entitlement Management (CIEM)

Welcome to the KuppingerCole analyst chat. I'm your host. My name is Matthias I'm senior analyst and lead advisor at KuppingerCole analysts. My guest today is again Martin Kuppinger. He is the founder of KuppingerCole. He is the principal analyst here at KuppingerCole. Hi Martin.
Hi. Yes. Pleasure to meet you again today. We want to cover a topic that has just, um, in the last year hit the news hit the IAM related press. Uh, it's a term, a terminology, and a follow to accurate four letter acronym that is newly designed, and that has been also adopted by some of the IAM IGA vendors already. We want to talk about a term that's called CIEM. Um, it's called, uh, cloud infrastructure entitlement management. And we want to take a bit of a perspective here, um, as a first start, what is your initial perspective on CIM market?
You know, I think as analysts, we are seeing so many new themes, so many new passwords popping up. And the question always is what is behind that? When I first looked at CIM, I had a couple of sorts. The one is, um, or the ant, they are probably all centered around one thing. It is not really that new. So we have a field we are covering in Pam for dev ops. Spirit's about how can you give prevalent tools, um, sort of at runtime to people which need to manage certain things in infrastructure. So some of the technologies here and it's part of an established field, we have discussions that as casual as customer years ago, about how could you implement trust and time provision trust in time, sort of cramping up access. I'm working on the field of, um, dynamic authorization management or policy based access, which provides access at runtime at a certain point, the term of ephemeral certificates as one element for, for creating X moral from a technical perspective is around for quite a while.
And so th th the obvious question, even if you take a little bit of, oh, there's AI in the looks at, should I really give to, so that's a risk factor in it at the end, it still means, um, it, it is something which we have seen before, where we see it, we'll use where we see a need for getting better, but does it deserve to be seen and treated as a separate technology question, mark? And I think that's the other part we should discuss today. If we consider this being, um, a relevant evolution, I I'm absolutely there, we need to be better in trust in time access. And that's what it's about at the core, but you need to do it for everything, not trust for cloud infrastructure. So having a natural points will usually, and that's how it is positioned hard to term, because it is definitely wrong. We need to see this as an evolution, but as a part of what we are doing already and getting better, they're not just saying, oh, next technology. And then you have a ton of PSU of different tools, and that has to help anyone,
Like one definition that I've seen around really narrows it even more. It narrows it down to software as a service solutions that do this point solution that implement this point point approach. So it's really as a SAS solution that is managing cloud access risk at runtime. And it does this by managing entitlements and even taking care of data governance, but really in this narrow aspect of being as a service and focusing on cloud infrastructure. So it's really just one part of what we all the IAM guys considered to be provisioning. Um, run-time provisioning, risk-based AI supported and provisioning, but in the end, it's, um, it's, it's provisioning that needs to be guided by an overall I am infrastructure, right?
I think it's part of what you do. So how do you crime X at the end ever seen me do it, identity access management as a bug who has access to what? And we are working on approaches that help us to create as X when it's needed and only when it's needed. So it is part of that story. And, and I see them really some interesting innovation I've been waiting for for many years. So, uh, what are wondrous doing? There is good. It is great. There are a lot of interesting things and a lot of helpful things where the customers have been waiting for years. And that might, for instance, compliment that might even in some areas replace existing solutions, but we shouldn't have to treat it as an isolated approach. We should see it as an evolution of what identity management as a whole.
So something we have been waiting for. And going back to your point around as a service models, uh, yes. So if it's a S I'm with you, um, when it comes to the delivery model, I think we should be a little bit more open at the end. Customers want to have some tries, and if you have a modern software, uh, we can deliver it in various forms. So it can run sort of the same and the containers, um, in a private cloud or public cloud, most vendors do that. There are vendors which only do software as a service from the public cloud, which also has its value if they are big enough, strong enough. But, um, we shouldn't limit it to saying, oddly debt is the way to do it. Um, I believe, yes, it must be available as a service, but there must be a little bit more flexibility in this.
And I personally would say the entire thing is nothing else than one of the many facets, which are covered very well by our overarching king approach of the identity fabric. So it's one element in a bigger picture, and that's the way we should look at it. And so my concern really is, um, that with new technologies to pops up something, you, then you have another deployment and that other one, at some point, you try to convert it again. So let's better understand how this works with the rest and place. It rightfully at the point where it adds well, you to what you have. And there is well you in these approaches. And some of the things, some of the new vendors in that space are doing, but it's, as I said, it's, it's part of a bigger picture. And I don't think it serves a separate acronym for itself.
Exactly. And if we look at, um, providing access to cloud platforms, then usually organizations have been looking very deeply into what these cloud platforms do for them. What are the services that they run there? What are, what is the workload? What is the criticality of such a workload? If you now then put the provisioning engine into a cloud service, then you add more complexity, another solution that you need to apply scrutiny when using this software when choosing the software. So you add another point that potentially can be attacked, can be threatened. So it might be just, as you said, something that you want to run under more control on your side, maybe as a, as a microservice, maybe as a container deployed somewhere closer to your own control, not trusting in yet another software as a service solution, many organizations that we see in advisory do that.
Yeah. So I couldn't even lift the saying, okay, I go here for SSOs diploma. Sure. But the point I criticize more, it's really the cloud infrastructure. So we need this type of entitlement, but not only for the clock, so it can come from the cloud or not, but we don't need it only for the cloud. And not only for the cloud infrastructure we needed for SAS services, which is not cloud infrastructure. We needed for solutions that we have on premises, we needed everywhere. And again, that's the point there. So there's something really and well in that, but that approach is C E C I E the C I part it's way too narrow, um, for what we really need. And I think this is a risk also for these technology providers that this is seen as too narrow. There's more than cloud infrastructure, which needs a way more dynamic approach of granting and revoking entitlements. And we need also to add that all the management of entitlement, but also the governance aspect behind it, I believe that all right, ed, so pretty picture as to why they should places. That's one central part and one element, sorry, what customers are waiting for for quite a long time.
Right? So from our perspective, it would be one key building block within an architecture, but it's not necessarily an, an a market segment on its own. And as you said, it does not deserve necessarily yet another acronym. Um, it's something that needs to be well-integrated needs to be well, um, put into context within an identity fabric here.
Yes. I think the point is I'm already kind of winced that this technology will kind of verge was established, take our lunches and that space, it will become part of on one hand, Madi privileged access management focused solutions and are not on the other hand, the modern . So, um, um, it will be, uh, obvious conversions people that have served here,
Right? If you look at the, at the actual market, if you look at vendors that really also use this term, just because it's a term that's out there, and that of course has some hype around that, and that has a marketing buzz, they implement that mainly as part of an existing IGA solution and add the C I E M in addition to what they already deliver. And this is already well integrated. So it's one service within one platform.
Yeah. And I think the customer value does not arise by having an another technology, but, but by solving an additional business problem, that's proficient. Okay. So yes, have a look at that market, but don't do C L C I E M for the sake of CIM P put it into the context of your broader identity management picture. And yes, it is part of your identity management model, civilization strategy. It is important. Um, but it's nothing should be seen as yet another technology it's part of what you have and what you should have in the future.
Exactly. And it does solve a problem. It's also the integration of, for example, cloud plot platforms within existing ITA solution, because there have been gaps before, but as you said, it needs to be designed bigger, broader with a, with a, with a bigger picture in mind. So thank you very much, much. And for giving your perspective on this new technology term that is around there, which is not that new, um, and to put it into relation to what we are doing with the identity fabric. And if you have further questions, um, we are happy to answer additional questions, just get in touch with us at KuppingerCole. Um, just contact us via the website, or just contact us via our Twitter handles or the info at KuppingerCole dot com email address. Um, thank you again, Martin, for being my guest today. Thank you much. Yes. See you soon. Bye-bye