Hello, everyone. It's good to be him Berlin. Good to see you all again, a lot of friendly faces. So while we're here to talk about model measure, manage how we can get to a more autonomous security model in this, in this multi-cloud world. So what famous phrase attributed to one of the founder of the business management, Peter Drucker born in Vienna in 1909, is that if you're not measuring it, you're not managing it. So the idea is that progress is not made without setting a goal. And without continuously measuring the direction that you're headed to see if it's headed in that direction. So from an identity and security perspective, what are we measuring? So an overall goal would be that we would be more secure and we would be less risky, but being risky, what is meant by risky is risky. Something that is crystal clear, that we all understand easily.
What risky means. We all agree on the definition of what it means to be risky or not, or is it something that's more many shades of gray? It's not really simple. If you ask two people here, what it means to be risky, you'll probably get at least two different answers. And again, what does it mean to feel secure? How is a company or an organization? Can we feel secure from the cyber threats? When, as we all know here as professionals, that given enough time, we're all going to get hacked. We all have been hacked or we're all currently in the process of being hacked. So how can you feel secure and safe given that you know, that we have to work from a posture that we assume breach that they're, they're not outside these invisible imaginary walls, and we're trying to keep them out. That that's really a myth that a balloon that we popped many years ago, that we assume they're inside the walls and they're actively working with malicious intent.
So I guess the goal would be that you're not gonna keep every hacker out. The goal would be that if they're good enough, they're gonna get in. And it's more like containing a fire on a ship. The ships are designed so that you, if you do have a fire, which is an inevitability over time that it'll minimize the damage and it'll contain it to only a smaller portion. So you give them less access to data, less, less ability to do damage once you are compromised. Okay. So let, let's dive in. We're here to talk about multi-cloud. Why are we talking about multi-cloud because multi-cloud is as all of you know, here probably from working industry, that it is a reality, almost every organization of any size at this point is using more than one cloud provider. So why is being, multi-cloud such a topic of discussion?
What, why, why does it make us more complex? Let's let's dive into some of the numbers and see what, what are the stats that are keeping our CSOs up at night and having them cry out against complexity on the stage here. So the, the four major cloud providers, if you add up the permissions that they have available to grant to the admin, and these are common, these are stats, you'll see a lot 40,000 permissions. So a huge number of permissions as to what people could be doing in these cloud platforms. Now, another challenge is that 50% of these permissions are high risk. So almost anyone with admin permissions are, is risky in a cloud environment, because most of the things you do, creating applications, you have access to data server, machine access, database access, it's all pretty much risky stuff. And 95% of the identities that have admin access are overprivileged. So we don't, we don't, there are too many permissions. These cloud systems aren't as well understood. Our skills are just catching up. So we typically give cart blanche access or too many permissions in order to let them get their job done and not block pro productivity. And, and that causes that people are over permissioned and they rarely use the permissions they have. So the permissions are there that if a hacker compromises their account, the hacker could use the permissions, but the person doesn't actually need those permissions to get their job done.
And this is predicted that by next year, 75% of all security failures will be caused by this poor permissions management, too many privileged admins, too big, a target too, not well understood too many people involved, and it will get compromised. And then because they have so many permissions, they'll be able to do a lot of damage. So the challenge with that is we can't really hire our way out of us. We can't hire experts. We can't just staff up and, and, and work harder. There's a big skills gap. There aren't enough people out there to hire on the market. We're all seeing this with the great resignation and the biggest area of concern or the biggest gap is in cyber security. So the PE there, it's hard to hire people and there aren't that many people that actually have these skills that you would need to solve it from that perspective.
So the question is, what can we do about it? What, what are some, some ideas about how we can help solve this challenge or at least mitigate the risk? Well, one idea is might just feed to run around and panic. This is probably what I thought of. That was my first idea, run around panic and say, what do we do? What do we do? What do we do? The house is on fire, but this what the situation is really not without precedent. If we look back and we compare, it has had an experience dealing with complex systems. SAP is a beast of a software that has a huge number of permissions. And you can do a lot of very, very risky things in it. Like, you know, creating purchase orders, approving your own purchase orders, putting the money in your pocket, doing things that cause reputational damage to the company.
So it's not without precedent. The cloud's scary. It's a new type of permission. It's a new type of infrastructure. It's a new type of risk, but it's not without precedent as far as managing it. So getting back to the point is model measure manage. So the idea is that you're not going to reach a secure state, unless you have a clear view of what that secure state looks like. So you need to model, what would it look like if we were running things well, and we felt that we were within the benchmarks of a secure organization and then measuring is measuring your current position. How far away from that nice, comfortable point are you and measuring it continuously to see that you're, you're, you're making progress in a direction that's heads toward where you're trying to get to. And then I would say manage, but I crossed that out because at this point we saw there's a skills gap.
There's a cyber skills gap. It's too hard to hire people. That's not, you have to do it, but that's not gonna be something that's gonna sustain you in the short term is, is to hire you way out of it. So we really need to automate that as much as possible, leveraging new technologies, automation, hyper automation, bots, and AI. So if we're gonna model risk as a destination that we want to get to, so we know where we're headed and everyone can have the mission of getting us there, how do we define and model risk? It? A lot of people will say, it's just very simple. This is risky and that's not risky. Well, it's not really, it's a lot more granular. It's a lot more flavors of it than that. If you look around at different vendors and different organizations and how they define it, there's really no.
One's agreeing as to what is risky and what is not, and how to define it. The only thing that everyone really agrees on, which is super simple is orphan accounts are bad. Yeah, that's it. Orphan accounts are bad. That's basically, that's what you get. If you look at everyone's publishing a different variation of the paper about orphan accounts being bad. So yet it is bad to have orphan accounts. And that's something that's easy for everyone to try to clean up beyond that is where it really gets fuzzy. And it depends on who you talk to. And everyone's really siloed and silos. As we heard on the stage here, silos lead to bottlenecks and blind spots. If we're looking at a silo, if we're working in a silo, we're not thinking broadly, we're not seeing the what's out there. So, good example, if you look at, in this example, who is actually riskier, is it the user and employee that can create privileged users in Azure?
That is an activity they can perform that is risky. Is it the user who has access to all your payroll data and could choose to share it on, on Reddit or Facebook? If they wanted to, that's not a risky action. That's risky access to risky data. And then the third is someone who, as I mentioned, could create purchase orders and approve them and put the money in their pocket. Again, we see these as completely different silos within the organization, but all of these things happen through it, systems and software that we're supposed to control. So seeing them as being completely different and unrelated is, is really adding to bottlenecks and blind spots. Because if you look at it, risk is really one of two things. It's the, the things that you can do, which if you do them are risky. And if someone else does them using your identity, that would be very risky.
And the data you can access the type of data, some data just by having access to it. It it's a risk in itself that it could get spread. You could lose control. So the old method of flagging, Hey, these groups, or these roles are risky and everything else isn't is really a brittle model because you have to keep flagging them. It lacks any context, how are they risky? Why are they risky? Are they super risky? Are they slightly risky? What, what, how would they, they be risky? So it's really a bad way to do it. You need a lot more context to this and a lot more depth because so if we know basically risk is the data you could access or the things you can do then with these new cloud platforms and their 40,000 permissions and, and a lack of skilled people, how do we understand what is risky?
They all have their unique security models. We can't expect everyone to understand the permissions of fine grain permissions. And what's the meaning of them, especially can't expect business users and managers to re-certify complicated access. We say, well, let's just because if you look at the permissions as the business user, if I see my salesperson can manage virtual machines, that immediately make sense to me. And it makes sense that it doesn't make sense that they shouldn't be able to do that because that's a risky action. If I see that they get these permissions, I don't really understand. I might rubber or stamp it and say, it's okay. Well, they say, well, let let's do what we always did. Let's have groups where we name the group. This group is risky and it does this. And this group is not risky, but quickly you lose control as to what that group really grants access.
That that's a, a blind spot. I could name a group, doesn't have any risk at all. And then I could add that to give me global access on an Azure tenant and the, you know, the manager's gonna rubber stamp it every time it comes around for re-certifications. So you can't trust names, you can't trust naming conventions. And we really lack a way to share or communicate between disciplines. The, the seam systems are monitoring what people are doing, but they're communicating on a system by system basis in a way that doesn't necessarily make sense to the business users, the risk auditors in a way that doesn't make sense to the AI, that's gonna try to automate it. So what we lack really is a shared common set of terminology and semantics about what it means to be able to do something or to be doing it or to, to have the access. So these are called functions. So functions are things you could do. We saw managing virtual machines as a function, creating a purchase order of the function. So this is really where you're merging the business world of traditional E R P and risk with the, the, the Kim dream world of managing cloud infrastructure. They're all just things you could do, and they all could be risky or not risky, but we're only gonna understand the risk if we understand the meaning of the access and what it means from the business perspective.
So tying it together. If we have this common semantic, then we could see that Dave has functional level access, that he can manage application passwords. And we can assign a risk to that. Is that a risky behavior? We can see if he's using this function or if he has it and he doesn't need it. We can see how he gets it, because we understand how this access could be acquired, which permissions would allow you to do it. So even if the group is named low access, we know he can do this function because the group grants, the rights that would allow you to do it. And then top closing the loop back, we can have steam systems or systems that are monitoring your activities that say, yes, we saw this in the event log. And that means he was doing this action, which means that he was performing this activity.
And it, of course by nature it's cross system. So you're doing the same things in AWS, as you're doing in Azure, as you're doing in Google, why not have the same terminology? So you can bubble it back up and have the same risk score, the same analysis in the same meeting. So really CLO closing the loop. So if now we kind of understand what could be risky, which is understanding the data people can access and the things they can do. How do we model a better world? What are some principles? So you've all heard about zero trust. You'll hear a lot about it this week, and you've probably heard a lot more than you want to hear about it from what the CSOs comments, but there are other things out there is also zero standing privilege. The idea that having access permanently when you go home at night or on the weekend is risky.
You're not using it. So it shouldn't be standing around waiting for a hacker to compromise it. So we can reduce our tax surface. If we can automate or optimize the reduction of this permanent privileged access and privileged access or risky access. Again is something we can talk about as functional access or data access. So automating this, you say, well, starting from the top down high risk access that people shouldn't have this, you should use your traditional engines to detect and to prevent and to remove traditional risk engines, segregation of duties, engines, or any type of automation that it can discover that you somehow got permissions, which mean you can now do these, this risky access, which is not appropriate for your job. It should raise an alert. It should get routed to someone. It should get rolled back until someone decides that that's okay and they wanna mitigate that risk.
The next step would be high risk access that you don't use. This is where all the vendors are pushing right now is trying to understand what's risky access. And then what do you use or not use? So you can have a self tuning system that's constantly reducing your attack surface in an autonomous faction, by creating smaller and smaller roles that just have enough access for what you need to do and not what you don't need to do. And then of course converting that to just in time, what we call optimization is removing permanent privilege and making it just in time. So anytime you need it, you can click a button and activate it. And then it's going to expire in a few hours and then you can reactivate it. So when you go home at night, you go on vacation or the weekend, you don't take that access with you.
So how do we measure progress? How do we track as an organization if we're getting better? Well, humans are visual primates. We, we respond better to seeing things. We can process a lot more data. So really being able to track are we progressing toward a zero standing privilege type of organization? How, what percent optimized are we? What percent of the access is not permanent, that is risky. So giving them a few measures, dial something they can look at and see, and try to move the needle. What, how do we move the needle? Well, as Martin mentioned, how can you do it better on one of his podcasts, it's all about policies, policies, or, or what allow us to define how we want things to be, what should happen and what we don't want to happen. And then the policies are the, we, we map that out and we say, this should happen, and this should not happen.
So we can say again, no orphans. So then an automation can make sure that if it detects an orphan, you have a process to try to eliminate it, or no permanent admins or only permanent admins that at a very low percentage, and that have an exception request. So defining your policies then allows you to clearly state these policies would move us toward a more optimal state. Let's try to automate it as much as possible because we don't have enough people. So again, how do we get it done? We have a skills gap. So really automation is gonna be the key. We need to try to engineer our way towards simplicity. So I brought this up in my last keynote last year, someone's gonna bear the complexity in a system. So the, if we engineer our way out of it, then we don't have the complexity to be dealt with with, by lots of humans, we can make a better mouse trap.
And since, since that talk, this has come out. So basically we've gone to the scale now that it's not a better machine, that we can click the buttons on. It's a better machine that clicks its own buttons. We don't have enough time or people let's have it be completely automated. So now we're moving into the bot world with intelligent bots, interacting, identifying risk, and trying to do things on their own. So we call this a Sentinel from the, from the matrix, but basically humans, humans work better with a clear mission, a clear directive, and with fewer things to worry about bots can be the same way. If you have special purpose spots, like the optimizer that only cares about one thing continuously looking for people that have permanent risky access, engaging them, trying to get them to give up that access and convert it to just in time access, having individual bots with a mission where they're constantly reporting their progress and automating things at that level is really one of the ways we can get out of this in the short term, without hiring the people that we don't have. So really leveraging more intelligent automation to, to help us get, get through this and that that's it.
