PAM Without Pain: A New Approach to Securing Privileged Access

Great to be here. So I think it's really an exciting time to be in identity security. So much is happening. But I think that as an industry, we have a problem. The journey of solving identity security today is too complex for most companies. And every year I come here and I talk about why one element of identity security is too hard and how we can rethink it. Last year it was non-human identities, and the year before that it was MFA. This year I decided to pick up on privileged access. I think it's probably one of the most complex.

And I think that organizations have been trying to tackle it for many years with very minimal success. I think it's one of those areas where we need to think about, is there a whole different way of doing it? So let's start from why is it even so painful? I think that this problem has been always painful, but it's only becoming more complex. And part of it is because we have so many silos of identity. We have Active Directory, and Okta, and Entra, and Ping, and all these different environments. And it includes human and non-human identities.

And the level of complexity is only increasing, and that's before agentic AI, which is a whole new type of identity. And within that very fragmented infrastructure, there are many blind spots. One of these blind spots is around visibility and security posture. There's a blind spot around multi-factor authentication. It's a very critical control, but many of our legacy systems don't even support that. There is a blind spot around non-human identities. How do you even find them and secure them effectively? Many people are trying to solve this problem now, but it's still very hard.

And then also, there's a problem with privileged access. And I think that's one of the biggest, because privileged access is the place that attackers focus on. If I can compromise a privileged account, I can basically win, take over the network. And this is also one that we've been trying to solve for the longest, for decades. Who here implemented or went through a PAM project in their company? Was involved in one, even? Who here got to the end of it, was actually able to protect all the admins, all the privileged service accounts, rotate all the passwords, and without exceptions, right?

Congrats. Actually, very impressive.

It's hard, it's really hard to do. And I think that it's time to ask, why is it so hard? And are there things that we can do to try to make it simpler, for most companies to be able to get there? So let's start with, why is it so difficult? The first challenge, I think, when you're trying to protect privileged access or privileged users, is discovery. How do you even know who they are? I have small kids, so this is my actual house. That's what it looks like every day, and then my daughter can only fall asleep with one specific toy. It's hard to find those accounts and understand who they are.

I'm not just talking the tier zero, but the broader set of privileged accounts. And then even more complex than that is figure out what are they doing, how they are being used. So if I don't know that, if I don't know which systems are using them to connect to which systems, I'm not going to be able to solve that. Because any change that I'm going to make to this account, I'm going to break something. And I think everyone who went to a PAM project know that. The fear of breaking something is huge.

And sometimes you wait months to try to get approvals, and you pray that you're not going to break the business. In addition to that, or maybe because of that, it's just very slow, right? You need to move very carefully and kind of go system after system, account after account. And what we are seeing, and other surveys are also showing, is that only 10% of organizations really get to that finish line. And it's understandable, it's a very heavy lift. But even with that, some people might ask, okay, maybe that's good enough. Maybe we don't need to protect every Privileged Accounts.

We'll protect some of them, and maybe some will be left behind, and that's okay. At least we increased our security. I think that everyone who has been on the attacker side, and I did cyber offense before this, knows that as an attacker, it's enough that one of the Privileged Accounts is not protected, that's where I'm going to go, right? So some protection in the world of Privileged Access means no protection. I can always find the one account that was out of scope, and we all know it's way more than one. The majority of accounts are out of scope.

And then our entire fancy security program collapses because of these exceptions that exist in every company besides yours. And now, the other problem is, even if we try to protect some of the accounts, admins are just going to use the other ones beyond what they're intended for, right? And the reason is very clear, it's just, it's very annoying. It's very annoying for an admin to use those tools, to change those accounts, use the dedicated account for every purpose.

It's much easier to do everything I need to do with my domain admin account, and that's what a lot of people do, they abuse those accounts beyond what they need to do. Means that they're kind of all over the place, and you can find them very easily as an attacker. And then the last thing, and I think that's a very important one, we're seeing it in many breaches that we look at, is that it's actually possible to bypass the PAM solution in many cases. Because in most companies, you can check out the credentials from the PAM solution, the next time you just access the server directly, right?

We've seen it in some of the biggest, most famous data breaches of the recent years. Attackers never had to actually breach the PAM, because they could just find those accounts and use them around it. Are you all feeling a little depressed now? So that's it, good luck.

No, I'm kidding. So I'm going to talk about a solution, or an approach, okay? It's just a different approach that I think can help solve some of this problem. I'm not necessarily suggesting that this is a full alternative to PAM. What I'm going to show you is not a PAM solution, and I think there's still a place for PAM. But I think that we need a different approach in order to solve what's left after we get stuck with PAM. And in order to do that, we thought about what can be the technological achievement that you need to do in order to make this possible.

And we came up with something that we call Runtime Access Protection. You don't need to remember the acronym. I know there are too many acronyms these days. But the idea of it is the most important part. The idea is to enforce protection on the identity infrastructure itself, okay? So if you have Active Directory, or Entra, or Okta, all of these places where you manage your identities. What if we could apply the privilege controls on those directories? Whether they're legacy or modern, and do it in a way that will be transparent for the users and for the systems, right?

It sounds a bit too good. So let me quickly explain what I mean, how it works, at least as a concept. So if you have users, all service accounts, by the way, that are authenticating to different things. They use some type of identity infrastructure. By the way, there's also a way to apply this to local accounts, but we can talk about it if we have time. And imagine that whenever they're trying to log in to the existing identity infrastructure, let's take Active Directory as an example.

The directory will be able to communicate with another solution that takes care of all these enforcement of security controls, such as MFA, just-in-time access, auditing, and all of that. And that solution can do many things. We're going to talk specifically about privilege access security today, but theoretically, it can do many things. And only once these controls are applied, allow the authentication to finish. The reason why this approach really changes the game is because the endpoints and the servers don't need to know. The users don't need to know.

They all continue to authenticate to the same old directory, with the same old protocol, not knowing that there's something else being enforced in the backend. Now, once you can do this, and this is a very different paradigm, right? Because I'm not actually onboarding the accounts anywhere. They're still in Active Directory. I'm not onboarding them to any other solution. I'm not forcing users to log into any proxies. I can now do a bunch of things that are new, that couldn't be done before. And those are mainly three things. One is discovery.

So discovery, I mean, there are ways to do discovery today, but what's new here is that you can now finally understand where the accounts are being used, okay? So think about it. Not only connecting to different servers and finding accounts, but looking at the actual authentications that go to the directory to figure out where the account is being used. So this account is used from these two systems to connect to these ten other systems. Those are the dependencies, that's where the account is used. By the way, you can now also onboard it to your traditional PAM solution using this information.

So this information is a great start, because you can now really understand where it's being used. By the way, you will probably find that a lot of the usage is outside of where the account was intended to be used. You'll see tier zero accounts that are used to do other things that they shouldn't be doing. So all of this mapping is a good start. But then the next thing is where I think it's really becoming different, is a concept that I refer to as fencing for privileged accounts, which basically means that you start enforcing that. You only allow the account to be used from here to there.

So think about a privileged account that should only be used by me to connect to a certain system, let's say the domain controllers or any other sensitive resource. What if I only let it be used like that? Meaning that if anyone will try to log in from another place or to another place, the authentication will just fail. Although this is a domain admin account, theoretically it should be able to do everything. But at almost like an identity firewall level, you only let it log in from here to there. This dramatically reduces the potential of lateral movement.

Because if I can log in with this account only from A to B, where it's intended to be used, then nobody can do anything else with it. So I completely shrink the attack surface. And what this means is, let's say that the computer or a privileged account is always logging in from computer one to resources A and B. I can simply block any authentication that goes to different resources or coming from a different source, right? It sounds super simple, but it's not possible today with current technologies.

Today, with the way PAM was designed, it only works if I log in through the PAM. Okay, nothing technically prevents me from logging in directly to the server.

I can, if I have the credentials, I can just log in directly to the server. Nobody can stop me. And as an attacker, that's how attacks happen, right? Somehow I find the privileged account because it's cached somewhere or because it was left outside of the PAM or because of some reason. And no one can stop me from logging in directly to the resource. With this approach, it becomes impossible. I cannot access anything that this account was not used for.

Now, the next thing is also a different approach, and this time to just-in-time access. The concept of just-in-time access is not new. But think about how you're trying to do it today or have been trying to do it for many years. What if there was a different way to do it? Imagine disabling and enabling the account in the directory itself.

So again, I'm using the example of Active Directory. Imagine that I just disable all the privileged accounts. And only when someone is trying to use them, if they can prove who they are, if they can provide whatever other verification steps that they want, maybe it's give me a reason, maybe it's have a manager approval, whatever it is. I then enable the account in the directory on the fly, right, on demand. So accounts are not there anymore for attackers to find. They're just disabled. In the directory itself, they're disabled.

And I dynamically enable them for a few hours when someone needs them. This is a whole new approach to just-in-time access because I no longer need to onboard the users anywhere. I don't need to create accounts on the different systems. I simply enable and disable the account on Active Directory. As an example. So with that, or with these examples, right, because there's more things that you can theoretically do with this approach, you can potentially make privilege access security simpler.

And I think that's our goal, not just us at Silverthorpe, but as an industry, I think it's our shared goal. Because I've been having a lot of conversations with people here and also in other events, and it's very clear that identity security has become so complex that only the most advanced companies are able to get there. And even that is with a massive investment of time and people. And we got to a point where a simple, average companies have no chance. And even the very advanced companies are spending an enormous amount of resources in order to get there.

I think that whether it's this approach or any other approach, I really think that we as an industry have to think about this problem from scratch. Come up with new ideas, and I think that this is a start in that direction. So we have a couple of minutes left. If anyone has questions, happy to answer them. And feel free to connect to me if anyone wants to talk more about this. And thank you very much. So as I said, we have a few minutes in hand. I haven't got any questions from the audience yet. So if you've got a burning question, please try and pop it in now.

But for me, I wasn't able to see your graphics and stuff. But give me a point of clarification. Do you see your approach as being like a complete replacement for PAM? Or is this something that's complementary for use cases like just in time or NHI? That's a great question. I think that PAM still has its place. I think PAM solutions are a good idea. It's just that they can be used for the most critical accounts, the ones where you can actually do all the effort of onboarding the accounts there and managing them there and paying the cost that comes with it.

So I still think that PAM should be used where people have been realistically able to use it. I think that where this approach starts is where PAM got stuck, basically. And I also think that the nice thing about this approach that we presented today is because it creates almost like a floor, like a minimal level of security for all the accounts. This is not just for privilege. This is for any account.

Because it creates this floor, this minimal level of security, you can now start applying extra protection, knowing that all your accounts now have at least this minimal level of protection that you cannot fall below. So you already have all these controls in place. Now you can start onboarding users to PAM and do other advanced things like session recording, things like that, in places where you need that. So I think it is complementary in a way.

Okay, we do have a question now. I like the approach of managing privileged access. Does this solution answer only privileged accounts in AD? What about specific privileged accounts in applications?

Oh, great question. I'm using AD because I think it's a very good example. If we talk specifically about our solution or the approach in general, it works with anything, right? So all the different cloud IDPs, cloud infrastructure, all the major SaaS applications, and so on.

Okay, well, we don't seem to have any more questions. Thank you very much. Head code. Thank you very much.