Myths of Least Privilege Management (POLP)

All right, so I think the first session, and I'll let everybody settle down, but before I start, when the first session, I think set the example, Hans did a good job of setting his least privilege even possible. What does it mean? Do we make a compromise? I'm going to build upon that. I'm gonna give you a futuristic view of what is possible and start with what's wrong with the, how we do least privilege today. So before we get started, my name is Ashish Sha.

I'm one of the co-founders of a company called Andromeda Security, where we focus on both human and non-human identities, security, permissions, management, just in time access and so on. We're not gonna talk about the company here at all. I'm just gonna focus on this topic. So let's get the definition right. I don't think we, we have any problems with what a least privilege means. This is my version. Let me know if anything is missed here. But you should have access to the minimum set of privileges. No more rights, a minimum set of permissions.

I'm sorry, the privileges. Then minimum set of resources only when required, not standing and only for the required duration, right? Anything missing here? I'm gonna make this interactive.

So peel, please chime in, make we'll, make it interesting. Okay, I'll, I'll tell you one more thing that's missing here.

I'll, I'll come back to that in a minute. Why is it important?

Again, Han set this up already, but depending on who you ask, between 70, 80, 90% of breaches are identity related today. Okay? But that itself is not the problem. The problem is that they have excessive privilege and this 95 number percent number is primarily around the cloud. I think on-prem, slightly smaller, but for the rest of the conversation, I'm gonna talk about cloud and SaaS 'cause that's where the problem is worse. And an average cost of a breach, according to IBM is about four and a half million dollars.

I think that's under reported MGM at a hundred million dollar breach, the cost to the breach was a hundred million dollars, right? So we clearly understand it's important. We clearly understand what it means. Why haven't it got it right?

Yes, we know it's hard, but I think we are also looking at it in the wrong way or we are trying to solve it in completely, I should say. So how are, what are the two ways we are trying to solve the least privileged problem today? First is a term called CIEM or Kim. How many people know what Kim means? A few. So I'll say cloud infrastructure, entitlement management. What that means is typically you start with a role. Everybody gets certain set of permissions and then periodically you removed unused permissions.

It's good, right? If you don't need something, you take it away. So what's wrong with that?

Well, it's a good start, but there are a few challenges. First, it's a manual approach. It's a reactive approach. You start with a role.

You have, let's say a hundred permissions in a role and a week later, two weeks later, a month later, you prune some down. Somebody has to do it manually, which means it's error prone. And during that window you had excessive privilege, which means you're not in the least privilege during that window. And this is an ongoing process. That's the first challenge. What's the second challenge? It includes risky permissions. What do I mean by that? If using a permission frequently, once a day or twice a week, but it's a high risk permission.

Let's say it's a delete permission to a, to your cloud infrastructure or an S3, right? Permission. You are using it frequently. So you should keep it right, because that's what least privilege means.

No, because that's what leads to the business impact. So my definition or my recommended definition of lease privileges, it should include not just usage, but also risk. Okay? What's the third challenge with this approach?

Okay, I bring everybody down to lease privilege. If I need more, Hans talked about it. How do I get more? I open a ticket, wait for some time and I get it. And that's the whole reason why people don't have least privilege today because they're worried. What if I need more? I have to wait for it. So gimme everything. I might need it a day, another day, right? That is the problem.

Okay, good. I got a chuckle.

Alright, what's the second approach? Zero standing privilege and ask for everything when you need what you need. Sounds great, right? Your identity gets compromised. No impact. There's nothing in your identity that it can do. What's the challenge here? I think it's impractical because the way we do that is it impacts productivity, especially in a cloud and SaaS because the whole point of cloud is agility. You ask for something, you wait for an hour, your manager's on vacation or maybe on a coffee break, you're waiting for an hour, two hours. That itself is too long in cloud.

You want right away. That's the first problem with jit as it imp, it's implemented today.

Second, equally important, the people who approving have no context. We talked about rubber stamp all this conference, right? It's very true.

Oh, Ashish requests it. He always ask for it. I'm gonna just give it to him. What if my identity was compromised and that compromise Identity is asking for it. You are host.

In fact, that is the SEC third challenge as well. There are a lot of JIT tools out there, or some of them where you can create rules if Ashish asks for a certain role or certain set of permissions between 8:00 AM and 6:00 PM on weekdays automatically granted it's interest, right? It's a business logic, but it's very static logic. It's not dynamic logic. An ideal least privileged solution needs to address that.

Okay, so we talked about the problems. Is there a solution? We are trying to have that solution. So what's the right way to do that? So I'll make a few claims. The right way to do lease privilege is first, it's a combination of standing privilege and just in time. And my definition of least standing privilege is includes both usage and risk, usage, frequency and risk. What do I mean by that? And it's dynamic.

I, I'll, I'll, I'll, I'll talk about each of these points as I go. Only frequently used lower risk permissions should be in a standing privilege. Let's dissect it at a time. If I'm doing it regularly and as long as no risk, low risk. And you can define the guardrails of what risk means to you. As long as you can quantify it, you can say that the the, the baseline is even if my identity is compromised, I can live with that because there is nothing high risk in my standing privilege. If I can achieve that, then I've achieved true least privilege.

Second, it's dynamic, which means you can't have human intervention. You need a system. And this is AI is your friend, your machine learning is your friend here where not just gen ai, gen ai, there's nothing to do with gen AI in general. Machine learning algorithm is your friend, where where you're building you are you. You are looking at the frequency of usage. You're building a usage pattern. You are looking at the actual activity logs. Most of the tools. So they don't look at activity logs. Most of their traditional applications don't have good activity logs.

But modern applications cloud do. So leverage that, build a pattern of usage and build a pattern of risk and automatically maintain it, dynamically maintain it. Then you achieve lease privilege. The benefit here is that even if your identity was to be compromised, you can sleep in peace because it won't affect your business. So that's part one. That's your dynamic standing privilege. Lease privilege. What about just in time? Everything that is either high risk or infrequent you're doing once a month should ask for it when you need it. But how do you address the productivity problem?

Well, this is where machine learning and AI come in again, build a behavioral model. Build a usage model. When Ashish asks for a privileged access, has AI say, have I done it before? Have my peers have done before? Am I coming from the same location, same geography, James, same device. Am I asking for a duration that is within the norm? Then automatically approve it because the approver, the manager frankly doesn't have more context. Why slow you down when it follows a pattern? That's where you, when the risk is low, go for the productivity, go for speed.

But when the risk is high, when it is anomalous, then slow down. Do send it for an approval. But give the approver context what's wrong, what that person should look into. Double check before you're approving it so that two things happen.

First, the number of requests going to the approval is dramatically low. One 10th or one 20th of the request anomaly you get because all the common requests are automatically approved already. So you have more time, you're not overburdened.

And two, the system should tell you what to look for. Out of these 10 checks, these five look okay, these five, don't double check those. That's the way to achieve security when the risk is high. And now the benefit is that you can achieve both security and agility today. It's either or, you can do both. This is what I think we think is the right way to do least privilege. And this is where I think there's a lot of opportunity for especially modern applications in cloud for us to build these kind of models and remove the human element right now, is this too good to be true?

In theory, it looks great. What are the practical implications? Let's look at some of those, right?

First, how do you build risk models? What is the, what should the risk include?

We, we have taken it and ramad, we have taken the first attempt at that. We think that includes it. It needs to include posture. What's your organizational status? What's your what? What's your MFA status?

What, what, what? What your overall state is? Are you about to be terminated? Are you moving within the organization? All the traditional configuration, posture, related risk, behavioral risk. What's your location pattern? What's your access pattern? What activities you're doing? Normally you are spinning up VMs. Now suddenly you're downloading data, you're about to be terminated and you are downloading a bunch of database items. Those kind of behavioral analysis. And then building a risk model of individual permissions. Did you notice a W S'S 17,000 fine grain permissions, 17,000.

You have to attach risk to that. You have to look at the PII data versus non PII data. You have to look at production environment versus dev environment. All of these have to go into building a truly effective risk model. So it's hard, it's not easy, but it can be done. But this is how you build effective risk models for your identities, for your assets. How do you scale? As I just said, right? There are 17,000 app permissions, just AWS, you add Azure, you add GCP, add SaaS applications, and eventually on-prem. This is not easy. How do you look at millions of logs?

Because to true, to build a true behavioral model, you have to look at actual activity locks. That's hard.

Doable, yes. Hard, but I think we'll get there. And then finally, this is my favorite as well. We just talk about human identity so far. What about non-human identities? What does it mean to have least privileged non-human identities? It's yet even possible, right? There is no, there's a machine who's asking for it.

Well, I would say it's possible for infrastructure as code terraform, Ansible, because you can request it through APIs, but not possible for other machine identities. So what you have to define for what your organization, what, what, what or least privilege would mean in terms of what? Of what permission it should have and not have. So I'm gonna leave you with these considerations.

Again, as I said, it's not easy, but it's doable. And we at andro, we have taken, we are doing some of these today. If you're interested in how we are doing it, we'd love to show you a demo. But I think as an industry, it's important for us to rethink least privilege with a mindset of risk and usage with a mindset of automation, intelligent automation, not just static automation. That's all I had. Short session questions. So anyone questions? Please Either you understood everything or nothing. We have a few questions from the online.

Yes, please. That's great. In your opinion, what are the differences between least privilege and need to know? Principle Least privilege and need to know principle least privilege. I think we define you should have access to what you need when you need, right? Right. For the right reason, for the right duration. Need to know, in my view, again, there might be a legal definition in my view, need to know is whether you are allowed to even have, so we, we have a concept called eligibility. Should you even have allowed to access to that? Let me give you an example.

Let's say my least privilege says I have these permissions to these set of applications and resources. If I need more, then I have to be able to ask for it. If I don't need to know something, if I, then I shouldn't even be able to ask for it. That's one way to differentiate between the need to know where even on a just in time basis, I shouldn't have be able to access to that. Whether it's an SOD reasons, whether it's legal reasons, whether it's pri, privacy reasons.

So least privilege I think is a subset of what you need to know and what you can have as a standing privilege and what you're not supposed to know. You shouldn't even have a just in time access to that. That's how, in my layman's term, that's how I would, I would, I would put it. Thank you. There's a few more questions. Sure. Why are excessive privileges more prominent in SaaS than on-prem and what is the root cause for it? So SaaS and cloud, I'll combine them. I think there are two reasons why. One is there is explosion in identities, especially non-human identities, right?

And explosion in permissions. If you look at that M times n ma matrix, right? You have lots of identities and human identities typically are bound by the size of the organization. Non-human identities typically are three to 10 x depending on who you talk to on premises, you have a fewer set of permissions or entitlements. Cloud have an order of magnitude higher. You combine these two, any kind of manually managing these is what leads to excessive privilege.

And so I would argue that it's a, the problem is worse in cloud and SaaS because we are still using the on-prem, like manual permissions assignment when the scale of identities and the scale of permissions is an order of magnitude hire. That's why, and that's why I think this, the, the problem has is, is is of most important in cloud and SaaS to be solved first before, before on-prem. Because the, and and, and frankly, I I, it, I'd be remiss to not mention identity is the perimeter. I'm dropping the word new. I think it's no longer new. I think it is the perimeter.

Whereas on-prem you have at least a physical perimeter in cloud and sa you don't. So that also makes it worse. Thank you. Would an employee whose regular job includes working with high risk data have to request access like everyday according to your model? That's a great question, right?

It, I think the, the, the, according to the proposal I have, you need to define what your risk appetite is. And yes, if this request, the high privilege request falls outside, that is domain, then yes.

However, if you can make it almost instantaneous where the only additional friction you're ask adding is to request that once, and you can request a three hours, five hours, six hours. But as long as that person doesn't have to wait, then it's okay. I think that's a trade off you have to make as an organization in terms of risk versus of friction, right? If you have to wait for an hour or half an hour, then it, it's, it's not acceptable. But the only friction is I just have to ask and whether I'm using teams or Slack or, or whatever it is tool that I'm used to and I get instantaneously why?

Because AI said yes, I'm that same person and everything is fine, then yeah, I think it's acceptable. Again, that's, that's, that's, that's a decision that organization is to make What's your risk versus reward and and friction. Perfect. There's two more questions. Yes. We have three minutes.

Sorry, go Ahead. So risk based and automatic decisions require that you have already fully identified and whether each and every access, right? Is it realistic to do this fully or would it be better with something in the middle?

No, that's a great question. I think there is always a middle ground, right?

I mean we, we saw earlier in the first session, Hans mentioned our least privileges North Star. So what I propose is a north star. Now is it easy? Is it doable? I think it's doable in cloud and to some extent modern SaaS applications because everything is well defined in terms of API, everything is well documented.

So yes, in all the modern environments, it is possible as you go towards more towards legacy, no, it's not practical. So you'll have to have some kind of middle ground. But I think as we go in the next five to 10 years, as new applications come around, it should be, it should be possible. Perfect. Thank you. And last question is, how does the concept of Zero Trust integrate with your least privilege Approach? I've deliberated to not use the word zero trust, but this is a zero trust for identity in some sense, right?

By by, because by definition you are not trusting anything to start with, right? So yes, zero. This is very much aligned with what a zero trust principle should mean for an identity and access. Okay. Okay. This was awesome. Thanks a lot. Great. Thank you so much. We are right around here. If you have any questions.