So it's that dangerous time just before lunch, but this is an important talk. And when I was asked, how would I classify that talk, we had intermediate, beginners or advanced.
I said, this is beginners because everybody should know. So that was my starting point. So getting rid of standing privileges is a call to action. And if you think, I know everything what you wanted to say, yeah, you can leave. But I think it's interesting because it's really everything on that slide. So what I will talk about is what and why. What are standing privileges? Why not? Why should we get rid of them, if possible? I want to present a vision. I am without standing privileges. How to get rid of them, how to eliminate standing privileges and a call to action, start acting today.
I have two quotes from an anonymous Kupinger-Cole analyst. I won't say the name. Access is power, grant it wisely, revoke it relentlessly and let no privilege outlive its purpose. And that is a key summary of what we really want to achieve, getting rid of those standing privileges. When we don't need them, we don't have them. So what are standing privileges? They are the key under your doormat. These are assignments of access rights that are persistent, that are always active, that are not time-bound. And they are assigned to all identities you can think of.
The classical AD user up to NHIs and modern systems, they are assigned with standing privileges, often too much, too many entitlements. They are static, often non-contextual. And they are rarely rebuked or revoked. This is not a technical issue. This is a process issue. But if you think in your own architecture, that might be the case as well. They are usually detached from current tasks or roles, maybe because the maintenance was not as good enough as you wanted it to be. And of course, all of this is a high-value target for attackers. And the main issue is this is not a glitch.
That is by design. It's the design of standing privileges. And that's why I'm talking about getting rid of them. If you think of traditional old-school IAM systems, you can think of them like this box review 2009 and some access rights hardwired. What they lead to is operational friction and misalignment, because people don't have the access that they need. That might be good or bad, either if you need something or you don't have it.
If you have this standing access rights and they are overly assigned to you, it's most probable that you don't only have that access in that system, but also in that system. And that means you allow lateral movement between systems once you are breached. And the question is, how easy is that? So this leads to privilege-driven data breaches. If things don't work as you want them to be, you end up with shadow IAM. We have been talking about shadow IIT.
But if you hand over the power about entitlements to cloud system administrators to developers, and you do, you end up with shadow IAM, because they maintain their stuff themselves. This leads to increased audit failures. And audit failures lead to regulatory exposure due to compliance gaps. So that is one key risk. So excessive access is a primary driver of IAM risk. And standing access is one key driver of excessive access. So what's better? What's the vision? And that is what Martin talked about in the keynote yesterday as well. An IAM without standing privilege is quite easy.
So we look under the doormat and take away the key. So you picture a world where access expires by default, not by exception or by audit season. We had that in the panel before. That marks a foundational shift from persistent entitlements to just-in-time access, or like the headline, from always-on to on-demand. That is the starting point where we want to go to. So access is granted dynamically based on real-time need, only when you need it. So there is no chance to use access that you have been assigned because you don't have it at that time. No residual, no dormant privileges.
And if you get access, that is controlled by context and additional risk signals. So it's not only yes or no because Matthias has that attribute or should have that role. Think of it as an attribute. That is the starting point. So that helps in creating zero trust. We had that in the panel before. And it's designed also for a frictionless user journey. So no longer waiting for an access right when you need it because you will get it when you need it. That relies on good policies, et cetera, et cetera. But that is the vision. But this is not the full part of the vision. Now comes Martin.
He doesn't only want to take away the keys, but he wants to run over the keys with this machine and to make sure that they are no longer available. So accounts have no inherent access, only empty shells. If you hack an account and you want to use it, there will always be another decision-making process to give you the access, not just because you have a role. So we shift to dynamic binding. So we check at runtime. Dynamic access management and access governance was the topic before. So the idea is to speed up. Zero standing privileges must become the standard, not the exception.
I know this is a difficult journey. I know that this is not very simple. And I like the very bold statement at the end. We think that any software that relies on standing privileges should be considered as inherently security critical because it demands for that. And it should be considered as conceptually non-compliant because it asks for standing privileges. And we think standing privileges lead to over-assignment of access. And that is a violation that you want to avoid. I know this is a way to go. Way to go? How to get rid of it? Very quickly.
Just to name the technologies, I said it's an introductory presentation. So let's talk about how you get there. At least start the journey. Only when needed, so just in time access. You get the keys only when you really need it and at runtime. And you choose the right key at runtime. So just-in-time access replaces persistent entitlements with temporary permissions that are task specific. So only when needed, duration bound, purpose aligned. Not I have admin. But I need admin at that time. You know that from Pam, that's where just-in-time comes from.
Why not use it also in critical business environments or for every access that you have? So that's the first start, first building block, one step to use when you move to zero standing privileges.
Next step, automation-driven, task-based, time-bound access. There is this nice little robot that hands you the key when you need it. You ask for it, here's my sign, and hand me over the key. And I give it back when I don't need it anymore. So automation is essential for doing that at scale. And really, who really wants to have still an admin department in access management that assigns roles to people if you can do it in a more modern way? Intelligent automation is the key. And this access can be triggered by anything that demands for access. For example, an ITSM having a ticket.
A CICD chain that demands for temporary access along the chain to say, OK, I need access to that cloud, to that GitHub, for whatever, but just for a second, not for the whole day. So this, on the other hand, really eliminates bottlenecks and reduces administrative burden because you do that once in a proper policy definition. I'm not saying it's ABAC, it's PBAC, or whatever, but it's policies that do the decision-making process, not an admin who does the role assignment. That leads to dynamic roles. I could really quickly go through this.
But whenever you don't have the chance to get rid of these roles being assigned and provisioned to a target system, you at least should make sure that you have an automated dynamic process that assigns a kind of dynamic role concept to your users so that you can say, OK, this role has changed. He's no longer in the company. He is on sabbatical. Remove this and do it really quickly. And the more agile you get, the better. So using more than one key and creating your specific dynamic key is in this way of pictures. Policy-based access. Policies power granular, context-aware access.
So one key element to move away from standing privileges are policies. And if you look at that door, you see it's generated because there's a typo. But nevertheless, delivery entrance, A, is what we want to have. Access only from 7 AM to 9 AM. That's the policy definition. When? What?
Yeah, open the door. That's easy. And why? For delivery. That's easy. And you get the access when you are the deliverer. So that's quite easy. So that's a policy on that door. So you enforce fine-grained condition-based access rule. And you allow for real-time context, device, location, behavior, and time, 7 AM to 9 AM. So that's a policy. And if you assign access based on policies like that, you get away from standing privileges. So you embed the least privilege principle into your business logic into a policy. That's the idea. So getting away from standing privileges.
And that, of course, is even more scalable. Automation was one key. Putting that into the application logic or into a system that's co-located with your application that does the decision-making processes for you, that's the key to move forward soon.
Finally, AI, of course. We need AI, but not necessarily AI. We need some mechanisms that actually supervise the process that you're doing. Because sometimes the policy will not fully be complete or correct. And then it needs to be fixed. This is something that is very usual. But you need to find it, not just ignore it. That's the idea. That's why this guy still looks under the doormat and looks if there's still a key, if there's something missing, or if access is wrong, if something is rogue. So real-time behavioral monitoring. And this is always connotated with a bit of negativism.
But we are looking at the real-time effects of a policy, for example. We need to flag that from expected baseline access behavior. Maybe we have this in our ITDR solution. And we interrupt misuse in case something really escalates. And we need to feed that back into the policy creation process or policy maintenance process. That is where these mechanisms really, really do help.
Finally, dynamic access reviews supported by technology. So this nice little robot is helping that nice lady to really do your access review when it's necessary. That means continuous and risk-driven. Not audit season, not 10th of December, and you get an Excel sheet to fill out. That's not the way to move forward. But to do that whenever needed, and only for those who need manual intervention and manual control. So shifting away from static certifications to risk evaluations removes lots of these items on that list already, because they are no longer something that is automatically maintained.
And the policy is well-assessed and well-controlled and audited, leads to less manual entitlement checks. So you can automatically revoke dormant or overprivileged access. And you'd use the analytics also for creating that list. And while this, on the one hand, helps increasing the security, it makes you much more audit ready, because you do that over time. You have the machine help you wherever possible. It should not help you where it should not help. But you reduce the manual review, and you reduce the manual review fatigue.
Who likes to open this mail with this Excel sheet on the 10th of December? Nobody. So that were some tools to use to get away from standing privileges. This won't be the full solution, so you need to do the conceptual shift. So start doing that. That's your plan to the right. The rationale is to the left. The longer standing privileges persist, the greater your exposure. You are at risk, full stop. This is not just a security gap. It's an operational liability, because you will be held liable, you will be held responsible, and you might pay fines when you are over-entitled.
So access discipline is the key. The good thing is you can start just as I described. We don't have to do that. Start just as I described. We don't have to get to zero standing privileges tomorrow. Not necessary. You can do this without a rip and replace. You don't need to overhaul everything, but you should start. You should start with high-risk areas. You should project basics 101. You should start with high-risk areas, demonstrate quick wins, and expand from there. And every step you take is a step towards higher security and closer to adaptive risk-aligned access.
And what do you need to do? Inventory and assess privileges. Start with high-risk roles. Leverage automation wherever you can, and that could be this dynamic role concept that I've mentioned. Implement just-in-time access wherever possible and where the tools are available. We have this nice guy from Styra with open policy agent. That would be a starting point to use that. Layer in anomaly detection. That won't be the first step. That is a later step that supports you in identifying what's going wrong.
First, you need to understand what's right. And then establish these continuous risk-driven access review cycles. That would be a good project plan. Just write dates to that and start with doing that, and get away from your standing privileges because you get away from all these risks that you have right now. But this is only the beginning. So this shift in perception, this shift in conception is the end game. So zero standing privileges is really a strategic target. And summarizing that with the four key takeaways.
First of all, we need to understand that persistent entitlements are systemic, are systemic risk, and violate least privilege. We need to replace that with dynamic just-in-time access and get away from those legacy standing privilege models. And I know that will be a lot of discussions with auditors because they know what an entitlement model is. But maybe we can move that somewhere else and keep the same model. Authorization must additionally rely on real-time identity signals, session context, and behavioral risk.
So really understanding, is Matthias really doing the right thing, although he should have that access? Is he using it properly? And finally, that sentence, zero standing privileges must become the default non-negotiable security baseline. And then you can put all the keys that I've shown and that are lying under the doormats of this world just into that waste paper basket. Final slide.
Again, this non-named anonymous Kupinger-Cohen analyst, zero standing privileges isn't radical. It's responsible. And in our opinion, it's inevitable. So if you have questions, I'm happy to discuss. And here we go. Thank you.
Thanks, Matthias, for sharing an introduction on this very important topic. I believe the different premise that you presented are extremely useful. But we all live in an existing environment where IAM infrastructure is probably well-established in the organization with many different dependencies with very high demands from the business for it to be available, deliver the service it's supposed to be delivering. And so I'd like for you to pinpoint, perhaps, these dependencies, if you have some in mind, to be achieving the five points, or maybe more, that you had on one of the slides.
And let me give you an example to make my purpose a little bit more tangible. You mentioned about signals. Those signals are many times based on data points that obviously needs to be available, needs to be consistent, needs to be standardized so you can make use of them. Same applies for your policy definition. A policy is based on a set of attributes or other things that it needs to calculate to determine what's the outcome or what's the output. So what is your views on those different precondition or prerequisite to achieve the bold statement of zero standing privileges?
Of course, this was a provocation. I know that. So the idea is we have existing infrastructure, as you said. We have dependencies. And we just had a presentation two sessions before about, can you get rid of AD, and will you stay with a hybrid model? And then you stay with roles and groups and everything like that. I do get the point. The question is, how do I, in the long term, restructure my architecture, my infrastructure, to get away from these burdens? I know this is not a simple story. I know it's not an easy way.
And I know that everything that you said, including, and this is one of my favorite topics, data quality, if you base great policies on bad data, you end up with bad policy decisions, of course, because you need to. So maintaining proper data quality, having proper signal data maintenance, and understanding what that means, is of high importance. Nevertheless, I would stay with that. I don't have the time to lay out these five, and I would love to.
But the idea is really to make you aware that maybe you for the next application RFI process that you are doing, you should really move away from applications that demand for a role concept, and probably move more to a system that supports the mechanisms that I just explained. I know there will. I'm in that job for 30 years now. I won't see that light at the end of the tunnel when I leave this job. I do know that.
But nevertheless, if you remove 30% of that, and reduce your attack surface by that, and your audit readiness by that, then I have achieved everything that I wanted to achieve for today. Sorry, but that would be my answer.
All right, thank you, Matthias, for the session. And I think we will meet again in one and a half hour here for the next session. So thank you, and have a good lunch break. Enjoy your lunch. All right. Thank you.
