Panel | Cloud Infrastructure Entitlement Management (CIEM): Managing Your Cloud Scale Risk with an Identity Defined Security Approach

So, yeah. Sorry, let's kick off. So you obviously know who I am. I won't go through all that again, but Brady, pat, Patrick, you can introduce yourselves. Oh sure. I'm Mike Kaiser. I'm director of security director strategy and standards at sale point I'm I'm. Yeah. Patrick Parker, CEO, and co-founder of empower ID And I'm Mike Small and, and Analyst with co Cole.

Okay, great. Well, let's kick off with a, one of the obvious questions, but what is the number one challenge that we have in managing cloud? I know that's kind of like a ridiculous question in a way, but Patrick, I mean, I would say the number one challenge would be intelligibility or understanding what's out there and who has access to it. And what does it mean that they have that access?

I mean, I think just wrapping your arms around it and, and I have a longer version of that, but I'll say that for another question. Yeah. But just in a simple, simple case, it's just understanding what people can do with the access that they already have. And is that okay? Yeah. Okay. Mike.

Oh, right, right. Well, They're too much, Mike. Okay. Just call me Kaiser.

Yeah, I would, I don't disagree with Patrick. I, I think it's actually, we're realizing that the advantages of cloud are also some of the dangers of cloud. So it's the understanding what's going on, but at speed and scale, things are getting out of control really, really quickly. And I think it's a challenge, very ephemeral environment. Okay. Mike S O okay. So as the Analyst, I think the challenge is more than just identity.

Like so many other things in the it world, the cloud was introduced as the answer to all of the complexity that it was going to be much simpler and it was going to overwhelm everything. In fact, it has just become another degree of complexity in an already complex environment. And so to me, the number one challenge is managing with that added complexity, which introduces cost. It introduces security challenges, it introduces management challenges and within all of that is the problem of identity. Okay. Thank you. Do we have any questions from the, the audience?

Ah, yes. Oh, sorry. There's two of you at the same. Okay. The lady behind you actually put her hand up first and then you Actually asked couple questions. The question is what the, Sorry, I didn't quite hear, Is there a way to find out what, what it was he's entitled to Okay. Before writing the access. Okay. You mean in, in a C I E M yes. System. Okay.

Well, that's a good, yeah. How do you find out what a person or an identity is entitled to? Yes.

And, and one thing I've been thinking about that, it just kind of hit me the other day. Is, is it, is it really more complex or not?

We, we all say it's more complex. The cloud has 40,000 permissions.

You know, everything got a lot more complex, but did it really make it more complex or is it like within the news when you, you hear about things happening now, you think they happen more frequently, but they were really already happening at the same frequency. It's just a reporting issue. So with cloud infrastructure systems now, like let's say in a single system like Azure, you can see and manage the permissions for Kubernetes, for network devices, for computers, for applications, those all still existed and had permissions without the cloud. It's just that you didn't see those permissions.

So now they're all in one system and it's like, wow, it got complex. But really, it just got more manageable because they're all in a single control plane where you, you see everything that exists and you actually can control it and report on who has access to what through one system.

But that, that just made it more visible. It, it, it more manageable before it, it existed. It's just that you didn't have a way to connect to all those systems in, in individually. So you didn't really, it was out of sight out of mind, but yes, you can report. Now it's easier because instead of connecting to every system, to see what someone has access to and trying to manage every system, which is impossible and too expensive now it's Sur does all those systems surface up their control into one system, the infrastructure provider. So you can report understand and manage it.

But of course, it's gonna look more complex because now you're seeing what was hidden from you before. Okay. Let's just, let's take your second que do you have another question?

Oh, no. The lady, sorry she had, did you have a second question question? Okay.

Well, let's take your second question, but direct it to Mike Kaiser. Yeah. So Did we answer your first question?

Oh, alright. Two for one.

Was it, what was your question? So how do we know what they're entitled to, or was your question? How do we know what they have access to So Well, can the systems do it? I think also is it possible Two of them, right. So I think with the reporting, we can find out what the person is entitled or what is the access that the person has. Right. But what is he allowed to do? So is he meant to have the access?

Is, is the access given to him right? Or not? How do we find out? Is it the why question?

Why, why do they have that Access? Why do they have the access?

What, what, why does this person who does this job and the company actually have that access? Is that the question? Yes. And is it right? Yeah.

Well, Patrick, It's a, it's A complicated answer. Let me explain why Patrick, Oh, sorry. You know, deciding whether or not the right access has a couple of facets.

One, you can do it from the, what call the math perspective, right? Like, is this person like someone else? Is this person not like someone else. Right. The reason that's important is because if they're like other people, then it's normal and we're kinda all about making sure things are normal because that's when people are doing things that are expected, right. There are no outliers, you know, you drift quickly into like machine learning, talk here. But the other part of it is the business question.

Like, I can tell you all day long that Patrick has access to Salesforce because Patrick is just like everybody else on his team that doesn't tell me why his team has access to Salesforce. Right? That's a question that involves business policy and someone with knowledge of the system. And so it's always been a problem. I would say, making those two worlds meet of like the math and the tech versus, okay, we do it this way, but why does it matter to our business?

It's really hard to inject that information into systems in a way that's usable by machines and also intelligible to humans at the same time. Thank you.

So, so could, could I just ask absolutely. Your question was about C I E M. Yes. Yes.

And in, in a sense, the challenge is always what you asked, which is why does somebody or something have a permission with people? It used to be understandable because the person had a role and you gave them permission. That was the theory. Now with C I E M or, or the problem is that the elements of the infrastructure themselves have entitlements.

And those entitlements ultimately come from the way they were developed and whilst they should come from the security requirements and often in, in order to develop something so that it works, you make sure that your elements have as much permission as is needed because if they don't, they don't work. And here is where the challenge is that you have to set some kind of policy because those resources will be created on the fly dynamically and a, a vast velocity.

And so you, you need to really be able to understand at the infrastructure level, why different things need those permissions in order to operate. Right? Yeah. Thank you. Okay. Thank you so much for your question, sir. I'm sorry that no problem. So actually I also have two questions.

Oh, By the way, we're not expecting people to ask questions in pairs. Okay.

So yeah, one question you have to have two, Or you could it, so next one is three questions. Oh yeah. Okay. Sorry. Alexei shows our interest in this topic. And for me, the first question is about the review of the seeing entitlement. So yesterday there was also show that when we extract the entitlement from the cloud, most of the extremely technical, this technical name, or it's a bunch of Jason code and for the reviewers, they have no clue.

You know, what, what they're seeing. Of course there was also mentioning that, you know, the visualization is one way and also notice that the AI was not also mentioning there. So actually the first question is, are there any special reasons, is it because of the gap of the product so far? Or is it because of AI doesn't feed in that area or there's, are there any other better ways so that we can allow our, let's say business, people who have no clue on the infrastructure to review it, or we say, Hey, you know, business, please step aside only the it, people should do that. How do you see that?

In my opinion, I think we've just been thinking about it wrong, honestly, because we've all been struggling to just try to say these people are, the HR says their sales people and then directly mapping them. Well, we do these activities in Salesforce, give them these permissions. So you're doing, there's no layer in between where, so you're going from a business role. Sales HR says, HR says you're in sales directly to a technical access entitlement.

Whereas, and that's brittle because today you're doing Salesforce tomorrow. You're doing HubSpot. What really you need to get to is you're missing a whole layer in the middle, which is the business. People understand what are the activities that sales people do. And you can model that salespeople onward cup, they create purchase orders. They create opportunities. They do these activities. So they understand that layer of HR says these roles do these activities. And then the technical experts today use Salesforce. They know to do this activity. It needs this permission.

So then they operate at the bottom level that says, well, these are the activities. Here's how they get delivered as entitlements in the system today. Then as if the organization understands what people can do, they can re-certify in, in an intelligible way without understanding the technical entitlements. And then there's, it's called like an anti-corruption layer in microservices that layer in the middle allows your business model to not have to change as you change systems.

So what sales people do and the activities they perform is something that the bus you don't have to change every time you add new systems or change systems or permissions change, you're just changing the mapping of how those activities, what are the entitlements that allow someone to do those activities. So adding that layer then allows you to have understandability or intelligibility when you're looking for access, when you're reviewing and seeing what people can do. And doesn't make sense when you're finding outliers and anomalous access.

And when you're seeing system is reporting what people are doing, because again, that migraine data, the access or the activities needs to map up into something that makes sense to the business and that isn't system specific. So doing this in Google, doing this in Azure, doing it somewhere else, it needs to all mean the same thing and makes sense to the person's manager, not to the Google expert, the Azure expert, etcetera.

So, yeah, I I'm sorry. I, I know I'm on the panel, but one thing I forgot to say in my speak talk was I think that you we've forgotten about roles and responsibilities, and that's why you have the, you know, the litter scoop and the, and the pastor scoop being used for the same thing. And I think we need to somehow bring that back in. Sorry. I'll now step out the panel.

So yeah, your question though. Yes. And if I understand you correctly, so are you implying that there's two steps review? So from the business's review, from the, let's say from the, let's say from job roles to the functions or the works they're really doing, and the second tier of the review is bad technical people to say for these functions, they need to have access to this three bucket read and write in that share directory. So and so forth. That what you're implying. Yeah.

And, and PWC, KPMG, all those guys, Ernston young, they get paid like before we come in with the IGA product, typically they've been done two years of this type of consulting for our customers where they have spreadsheets about each business role and what are the activities they perform. So they could IGA and Kim dream, they could all be involved in this earlier to help out, to help model the access and activities. And then when you actually connect the systems, then it's just automated fulfillment of the ability to perform those actions because of the mapping into the technical entitlements.

Can, can I put my two pen in here? Yes. Because in a sense, we've been here before and I remember surveys Oxley.

And so, so there are two different perspectives on the answer to this one is it's really about why do you care? Is it because of compliance? You're not speaking or is it because you really are concerned about technical risk?

Because, because if it's compliance, then it ultimately comes down to what do you actually have to do to get PWC or KPMG, or one of the big auditors to give you a tick in the box. And ultimately, and, and this is taking me back to the 1990s, a lot of people. And I was a developer at the time, and we were trying to develop technical solutions and KPMG, and these people came along and said, all that matters is if the boss signs that he is responsible and that, that is correct, that's all you need.

So, so in a, in a sense, there is a fall guy. So if you have a fall guy, then that that's fine.

However, if you want a technical solution to the technical problem, the technical problem inside the system is still immensely complex because you have all of these little things which may not be directly related. They may have permissions that they need to operate that are not specifically related to the job they're doing at a business level, but they actually have to have access to this S3 bucket or to this other thing. And that is much more complicated to be able to, to control.

And, and that's where, if you will, the complexities coming out, it is through the, the polyglot world that we're, we're, we're now creating. And that's my humble opinion. There's Well, and there's a underlying philosophy here or underlying thought process that's going on. And if you are with, if you listened to Paul's talk before he's talking about using things like containerization or these kinds of approaches to identity and access, what, what you're kind of doing is creating frames of reference at every level, right?

Whether you call it business roles or technical roles or entitlements, what you're kind of doing is saying in the scope that you are responsible for, whether it's entitlements on AWS or whether it is birthright roles at the top level, from what you know, you know, what it matters to the business. And you're deciding in that scope, it's almost like we're, we're pushing some of this decision and some of this information out further, and in the past, we've done it on discreet layers.

The cloud is so fast that that maybe I'm not drawing any hard and fast conclusions here, by the way, in fact, I'm kind of doing the opposite. And so I'm saying there's an approach to say we're delegating identity and access responsibilities closer to the edge. And it rolls up back to the top as well. In other words, you might be responsible for these entitlements down here, but the person above you is responsible for, you know, the role that encompasses those entitlements and so forth. And so on.

What that ultimately means is that instead of a ready for controversial statement, instead of feedback, versus a back versus R back, holy wars, you kind of need all of it at the same time for different parts of your organization. Roles are not dead. Roles can be helpful in the right context. Aback attribute based is super helpful again, in the right focus context. And so it's kind of all conglomerate there. If we're gonna push this down, maybe I it's contr to say, Okay, thank did that help.

Yeah, of course. Fantastic. Thank you very Much. Can we take the mark to the back row please? One more time. Yeah. Yeah. We have 10 minutes.

Yeah, please, sir. Well, I had the sensory the same question, so good was already answered in big part, but still shouldn't we, when we give access to system or people have a more abstract or more semantic and business, meaning to why you have access to something, because like for the SD bucket can be an exception. You need access to this, but why, so I will still, when giving access to something, have it defined on more abstract on upper level.

So the question is, should we like for the CIM, you have access to like the SD buckets or some services in Kubernetes, how to make it for a system, how to make it more abstract. So I don't give you access to a pod. I give you access to services. So in this way, I know why you need that. So you're, it's About a business Level constraint on the why they need access. Yeah. Yeah. Is that learn the why? Okay.

Okay, Patrick. Yeah.

So, so the, the why, I mean, the, why is some system that connects to your authoritative data sources that define what people do and then your business users have to define what they should be able to have access to. So that, so the why is really at that level, the, you know, what, what are, what are these people in our company going to be doing? What are they allowed to doing? What's appropriate, what's inappropriate. And then that, can Speaker 10 00:21:05 I try your question industry?

Okay, let me try and rephrase it. I think what they're asking Patrick is typically what we've said is, okay, this dev should have access to this as three bucket bucket. They don't wanna do that anymore. We wanna say this dev is responsible for this function. Therefore something looks after the fact of what they might need access to. True.

And, and there's another aspect to the functions. There's the actions you can perform. And then there's also the data classification. So what types of data should you be allowed to have? So functional access is things I can do, but functional access can also be, should I have access to PII? Should I have access to European customer data? Should I? So it's also, you have to take both sides of it.

So it's, can I create an S3 bucket? Can I add a file? Can I delete a file? Those are actions or functions, but then also, can I, should I, as an external in China have access to European, this bucket that has this type of data. So you have to have both aspects. Yeah. Just a quick sign up. Cross ideas was an old company, 2012 that tried an approach. Kind of like what you're talking about, what they tried to do is they tried to coin a new phrase called business activities.

And, and what they said was it doesn't the roles don't matter. The entitlements don't matter. It it's this activity like you, your job is to do purchasing and that, that can work.

But it, it gets really complicated, really fast, cuz it's hard to standardize from org to org and it gets kind of into a hot mess situation. But it's an interesting concept. Speaker 12 00:22:47 Yeah. Along those lines. So it's actually now the complexity or the new journey coming from that we, we coming from an age of way to naive access. Right. We have an HR system and we granted admin access for all HR people. Right. And they could do everything right. And the same we did for microservices. Right. They could do so many things. CI systems could deploy to any service, super risky.

Right. So it's actually now our journey, they've be taking those security concerns way more seriously and go to way more fine GRA stuff. And actually what is the consequence for then, for H eight tools? Right. Because I think we failed and granted broad access just because we had no tooling to do otherwise. Right. Yeah.

Mike, sorry. Do you wanna take, go ahead.

No, I wasn't. I was gonna say, yeah, I don't, I don't think you're wrong. I think what you're gonna have to see is you're gonna have to see vendors and the systems catch up because really, like I said before, right?

If the, the promise is speed and scale of cloud, If you have speed and scale in your, your IGA system, your access controls, whatever else, they should be able to handle ephemeral things that appear and disappear in seconds. Right. And they can't today. Right. So we're gonna have to catch up technologically on that front right now that doesn't address our, how does this relate to the business problem? Because if something's here for 30 seconds, I'm not gonna go consult with my manager and say, who who's, you know, what job function is this doing? That's not gonna make a whole lot of sense.

Right. So I, I think you're not wrong.

I, I think the, the speeding scale, hasn't quite filtered up to some of these larger systems yet. And it, and the ideal world it does. And then all your decisions are as close to real time as possible. And so now you don't have access to that resource except when you need it and when you're using it. But that's, you know, that's the pie in the sky ideal kind of vibe.

Oh, Thanks a lot. Okay. So we've got a few minutes left now.

I was, I was going to say that Well, yeah, carry on. One more thought is that if you go back to the 1970s, all of this was encapsulated. Yeah. This was encapsulated in the principle of least privilege, which was actually about, it was written as part of project Mac. And it was actually not about people. It was about modules and modules having just the privileges that they need in order to do what they do. Now. It's a very simple principle, but it's actually quite hard to implement in a complex system. Okay. Thanks point, please say. Yeah. Speaker 13 00:25:40 Yes, yes.

First of all, I, I normally don't ask question, but I felt compelled to, because I was so resonated with the, the comments and, and the answers. I like to share a couple of comments. First of all, I think I hear a lot of comments about complexity, but I find it very often that people actually meant sophisticated. Being sophisticated is not necessarily a bad thing. It is complex, but it's more advanced.

I mean, not as late as the eighties data access in my mother's office is still who has the key to the filing cabinet, but now we're able to control this digitally. And that will become a sudden, this is a problem that we need to solve. I've lived through the age where on-prem ad was the biggest vulnerability and we haven't solved that problem yet. And now everyone's saying cloud migration let's move everything to the cloud, but still they're moving virtual machines from data centers into is the machines are still domain joined natural movement.

Speaker 13 00:26:44 We're still exposed to the same vulnerability. And I think cm is another manifestation of there's so many technologies, which does things very differently. Like operating system, windows, Linux, they have different security architecture and windows introduce Microsoft exit directory to kind of do things consistently and Linux literally can't move literally. So therefore it's less perceived as a vulnerability. And now moving onto the cloud, every vendor is trying to make, make their own kind of kingdom.

They build various levels capabilities at various levels so that you don't need to go anywhere else. But then in the multi-cloud organization, this is a trouble for us, cuz we're constantly having I'm the service owner for patent, by the way, I'm constantly having discussions with AWS service owners. Why are we joining machines to the domain? And then the guys say, no, we don't have to because we have the IM users. Speaker 13 00:27:49 We have the AWS access management. We can do anything within AWS and then Azure, something entirely different.

Microsoft is trying to bridge the gap with the Microsoft arc buts guys. No know there's no way you're gonna use SCCM to push stuff onto my virtual machines.

And, and therefore I'm, I'm stuck in the middle and I have a problem. I, I don't think there is. There's gonna be a quick answer, but where is the future going? Are we gonna have different cloud owners in the organization? Do things there differently. And every user who needs to consume these services need to have separate identities or separate accounts or are we gonna see a single plane of glass where the cloud becomes abstracted? I just have one identity. I can access that. And all the R bag stuff, as long as I don't care how it is done, right. It can be perpetual.

It can be calculated in real time. As long as the end results gives me the least privilege, then everyone's happy. So where are we going with this? I think we should sign. We should say, come to my session on Speaker 13 00:28:58 Come, Come to my session on Friday morning, which your company again? BP. Okay. Right. So yeah. Where are we? I was gonna say, come, come to my session on Friday morning. Oh wow. That's okay.

Patrick, quickly sum up the future. The future.

I, I would say, I mean, in my opinion, it's just an opinion. I see. Say that the, the cloud vendors are gonna become more specialized. Everybody's trying to do everything in the cloud. AWS is trying to do the full stack and you're gonna have SAS vendors and other people that develop applications that where they use those, they build their apps on AWS services or on Azure services. But where I see Microsoft heading is how they usually win is tying in windows, desktop authentication into the cloud Linux authentication into the cloud.

So I, I see my, as you're probably becoming for the enterprise infrastructure, the cloud of choice, and then you'll use the other vendors, clouds for special computing like machine and machine ML, AI. But that's just my, I think enterprise, infrastructure's gonna go into the cloud. They're gonna win again, like they did with active directory windows because they are, they're making it easy. You can actually in Azure control who can log to Linux machines and windows machines and all that through one security model one API one. So it's a pretty Ingen ingenious strategy.

I mean, and they, they have a history of pulling it off. That's that's my Okay Patrick. Thanks Mike. Go back and look at 2006 with security policy and Zamal we tried this before, right? We tried to abstract security policy for the entire enterprise. We weren't ready. The translation of policy down multiple levels is too hard. That's one. So just background research two, I think you're gonna have to abstract the security models from these cloud providers. Otherwise you can't do things like separation segregation of duties and actually reduce risk. Right?

And so I need to kind of know those connections and those interconnections, in my opinion, that said much like space, like outer space cloud is, is huge. And it's really easy to underestimate the size and the scale required. So I don't want to underestimate the idea of being able to see everything and manage everything in a hybrid cloud environment is super challenging. So I'm not saying we're gonna have it, you know, like that, especially at in real time, but I think you're gonna have to do something like that. Fantastic.

I think actually this has been the best panel that I've heard at the event so far it's Cuz of the questions when they.