Brief Intro

In PAM 101 we introduced the concept of privileged access management and talked about why we have this. Then we talked about some of the challenges with privileged access management in ‘A problem called privilege.’ Most recently we’ve talked about challenges with the market approach to PAM and how this is largely driven by analysts and a handful of vendors with large portfolios who are seen as established players in this market.

There is nothing wrong with those vendors at all, they all have well-built products that solve real problems are used by hundreds and thousands of customers worldwide.

What I find interesting though is I can almost guarantee that everyone reading this who has been involved in a PAM project will be able to identify with the challenges that we’ll speak about in this blog. Not only that, but many will also be a source of frustration.

So, if we all know of the same challenges, hit the same problems and get stuck at the same junctions, surely this points to a problem that’s bigger than just the technology or specific vendors.

I personally believe our approach to PAM is wrong, I think we’re now misusing technology which was designed for a different purpose and in a different time to which we work in now. If this blog resonates with you too, maybe it’s time for something to change in how we think about PAM and tackle the many challenges that exist.

Afterall, a wise man once said ‘Insanity is doing the same thing over and over and expecting different results.’

This blog starts looking at some of the technical challenges with PAM and in particular in this blog we’re going to focus on Password Vaults and Session Management

What is a password vault

A password vault is actually a really simple thing. It’s a secure storage area for you to store data objects (passwords) in.

There honestly isn’t much more to it than that, we often like to over complicate our descriptions by saying something visually appealing such as:

 ‘Imagine a bank vault, inside you have a series of safes. You can store passwords in these safes and then only the people with a key, can access the contents of those safes.’

Technically a vault could be, a server, a database, a flat file system, a spreadsheet or anything else for that matter. What really matters is that it’s secure and you can control who can access what objects.

Of course, there are features and functions of Vaults that could be used to distinguish between them

• Access Control
• Rotation
• Policies
• Custom connectors
• Discovery
• passwords, keys & secret support
• Many more

Why do we have them?

Well, the original intention of password vaults and what we use them for today, are two very different things and this is what causes some of the challenges we see with PAM today.

If we go back to the good old days in IT where we had our own data centre’s, physical servers and very little in terms of automation, we’ll be in a time when this is started.

I once worked on a transformation program which was the largest in Europe at the time. It was moving from an NT4 world into Active Directory which was a big thing back then. As part of that process of standing up this whole new domain, we had to provision in the region of 100,000 servers. Yes, one hundred thousand. It was big!

We used a build program to do the operating system install and set the default config, including the administrator account.

We had 100,000 servers which all had the same username and password for the default administrator account. Obviously, the default admin account has all permissions and is the account that people screw their faces up when they think about it.

But everything back then and still today, has some form of admin account.

Now obviously we all know this is a bad thing. Whether we’re worried about insiders or outsiders, we have to admit, there isn’t much defence in place when every password on every system, for the most highly privileged account is Password1!

So Password vaults were born. The first of which came around in 2001 and in those days it was designed to onboard and manage shared accounts. Crucially it was not designed for personal accounts, or even service accounts.

I can honestly say in those days, every project where those vaults were used, were successful. What do we mean by that?

When the goals were simple, people succeeded, and our goals were simple

‘I wanted to ensure that the administrator and root had unique passwords across all 100,000 severs’

Boom.. success!

What’s Happened then?

Well, the reality is, Vaults were both successful and popular. New vendors entered the market and really built on it, propelling PAM’s importance at the same time.

A mixture of fear,  scaremongering, clever marketing and market positioning now tells us that privileged accounts are all evil and should be stored in a vault to stop the bad guys getting in.

Afterall, Hackers don’t hack in, they log in.

The key thing here though, is that the world seems to have gone slightly mad with the fact that vaults should be used for everything.

I can pinpoint the exact parts in vaulting projects where they’ll stall and then fail. As mentioned previously, this tells me we have an industry problem and to be frank. We’re doing too much with vaults and not achieving our program goals.

Lets talk about goals for a minute

Why do people do PAM? Throughout my entire career in this space I’ve heart the same two goals mentioned time and time again. Yes, of course there are more, these are just the common ones.

Point 2 has now expanded beyond humans and rightly so, the risk of non human identities is ever growing and is a far greater problem for most now.

But let’s just think about the things we can control and manage for now…. Think about the two goals mentioned.

We simply want to reduce risk

If we put in place a password vault, discover the accounts that we can, and then onboard them into our vault.

• We don’t reduce the number of accounts – we just onboard them
• We don’t reduce the risk, we just centralise it in a vault

What are we actually achieving apart from some rotation and access control. Let’s face it, we could do that manually and many smaller companies do this successfully.

The bigger problem

Vault projects all stall at similar places, the problem is, there are many places which tells me we have to change our approach. To keep this short and concise, we’ve bulleted them and if there is interest in the comments in any of these areas, I’m happy to drill further into them.

• Discovery – You can manage what you can’t see. In general, vaults tell you everything you already know which is a great start, but it’s also the easy part. What about everything else? That’s where your risk is
• Service Accounts -Most PAM solutions will tell you they can manage service accounts. What most really mean is they rotate a service account password. There are so many challenges with this, so see our follow up blog on service account management.
• App Accounts -You know those pesky hardcoded, embedded credentials that we all have all over the place. Well, they need management but most of us tend to replace them with another set of credentials for the front door of our vaults, in order to retrieve the actual credentials we want for the app. Kind of like leaving the house with the keys in the front door. And don’t get me started on discovery.
• Approach to onboarding -Why do we need to discover and vault all accounts? In the days when we all talk about zero trust and other industry buzz words, get rid of the damn privilege and issue it only when needed. We live in a world of entitlements and roles, let’s use them.
• Centralising on a single vault -We should not have a single vault solution (with replicas) we should have many vaults and leverage vaults which are in the right location for our purpose. AWS secrets manager is in a far better place to create, manage and provide a token for a function in AWS than your PAM solution is. We should also have many vault solutions in place as it should be the de-facto standard for providing secure credentials should they be required. The challenge here is not with using multiple vaults, it’s the visibility and control.
• Moving beyond IT Admins -Traditional vault solutions were designed for IT admins and not for business users. When I say design, I don’t just mean the front end user experience which sucks for business users (I’ll explain why below.) But technically the architecture of these solutions doesn’t support business users either.
• User Experience – We are now more technically savvy than ever in our personal lives and most of us will use some form of password vault even it’s its not called that. Do you use your phone to store passwords? Or an app such as Keeper? The user experience of these solutions is second to none and we now expect this consumer driven user experience in work. Yet, we’re greeted with something that looks like it that sofa from 20 years ago that we keep refreshing by putting a throw over the top of it.

Privileged access management was never designed or intended to take things away from people. It was meant to be an enabler and allow users to do things securely.

If you’re considering….

Switching vaults…. Stop

There is little value in swapping one vault for another. They really are a commodity and pretty much all do the same thing. There are exceptions and we’ll talk about those in our blogs around business password management and service accounts. But if you’re just swapping vaults in the hope of achieving something different, you won’t see those results I’m afraid.

If you’re swapping for other reasons, so as commercial, renewals. Then that’s a different story.

The likelihood is, the vault itself isn’t the problem. It’s what you’re doing with it and how your users interact with it that’s the problem. There is no point in throwing away investments, but there will likely be things you can do to optimise your success and provide a better experience to your users.

Session Management

Session management as a concept is again straightforward.

If I have a user, who can access a server from their laptop using a credential they know, I’ve created a trusted path between an untrusted device and a critical trusted device. This presents plenty of opportunity for a malicious person to hijack that pathway and get to the critical assets.

So basically, walking straight into a secure building, without passing security, reception or anything else for that matter.

PAM vendors implemented session management which was really a posh was of saying proxy, so that there is no direct connection between laptop > server and no credentials transmitted which could potentially be sniffed.

At the start. A session management server was basically a proxy which enabled IT admins to connect with servers using RDP or SSH. Vendors had slightly different approaches to the technology they used.

At the start, all of them wrapped this protocol inside HTTPS so that you basically did RDP or SSH in a browser window.

As you can imagine, this went down like a lead balloon with administrators who all had a preference on their tooling whether, SecureCRT, Microsoft RDP, Devolutions, PuTTY, MobaXterm etc.

The vendors agreed that user experience was important so they all (for the most part) allowed people to bring their own RDP and SSH clients whilst still maintaining session recording.

So what about now?

We live in a different world now, I can’t remember the last PAM project I was involved in where someone just wanted RDP and SSH to servers. The reality is our users are diverse, their access and requirements are diverse, and we live in a world of freedom, choice and personalisation.

The majority of access is now into web apps, or thick clients which these old school proxies were just not designed for. Imagine telling your users that in order to log into AWS console they will:

Our users have the clients, browsers, apps already on their desktop. Taking all these away is the problem, and forcing them through a terrible experience telling ourselves its more secure.. It’s not. That’s why we have access management.

Session Recording

I mentioned in a previous blog about the countless times I’ve seen session recording as a mandatory requirement in RFx’s.

I actually can’t remember a single RFx that didn’t have session recording as one of the top requirements. Funny really, as I can count the number of customers I’ve ever seen use it in my career, on my fingers.

Yep, less than 10

Session recording is great for highly regulated environments where there may be a requirement to randomly look at the activity on a subset of systems. I’ve seen this with several banks and some secret squirrel type places but outside of that. I’ve never seen anyone look at this activity.

I think this is now one of the biggest gimmicks with PAM. Why would we want a video recording of activity?

We have activity logs, security tools to gather, centralise and alert on logs. What does a video add to that? Its not like it’s a birds eye view of the user, at their desk, typing things or moving the mouse. That would be a bit more interesting I guess.. But this just seems pointless for most.

Yet because the market defines PAM as vaulting, session management & recording we all say we need it

Key Takeaways

• Use your traditional vault to manage those default built-in accounts and you’ll see success. Moving beyond that is where you’ll hit problems
• Managing just the default built-in accounts with your vault means that you’ll almost certainly reduce risk in your environment. You’ll automatically move into a world of just in time and zero trust as a byproduct
• You should have more than 1 vault, and that’s ok
• Changing vaults is for the most part, completely pointless.
• You generally don’t have problems with vault technology, you have access problems based on a poor user experience.
• How do you mange what you can’t see? Visibility is critical for reducing risk.
• User experience is critical to the success of PAM projects

Enough rambling for me – join us in the next blog where we’ll be discussing business password management