PAM 101: Redefining Privileged Access Management for a New Era

What do we think PAM is?

I’ve heard PAM explained in so many different ways and to be honest you really can understand each and every one of them. It means different things to different people, so to get us all on the same starting point, we created PAM 101 to give our interpretation of PAM.

Lets start with the definition of privileged: “Having special rights, advantages, or immunities”

Based on that definition, we could say the following about PAM:

Privileged Access Management (PAM) simply means controlling who or what is allowed to access infrastructure, applications and workloads (in fact, anything), for how long and what level of access they or it has in order to reduce risk.

So if that’s a definition of PAM, how would we embark on a PAM Program?

1. Hire people in the know
2. Come up with requirements
3. Speak with analysts
4. Research vendors and offerings
5. Approach vendors for demos
6. Complete RFx processes
7. Perform vendor selection
8. Potential POC/POV
9. Purchase
10. Deploy

Sounds so simple when you put it like that, but each one of these stages is difficult.

1.    Hire people in the know

No brainer, if you want to be successful then you hire the people who will make you so. I don’t think the PAM world is any more special than any other space. Experience and war battle wounds will help you avoid some of the common pitfalls that exist in PAM (there are many.)

One of the best RFP processes, that had zero bias I’ve seen was ran by a guy at a UK based Energy supplier, we actually hired that guy who now heads up our advisory practice because that journey is exactly what we want to take our clients on.

2.   Create Requirements

I’ve lost count of the number of RFI’s/RFP’s I’ve seen over my career. It’s the joys of working for software vendors, you’re going to see a lot of them. The trend I’ve seen over the last 3 – 4 years though is the majority of these RFx’s now resemble a feature list.

In fact, in over 80% of RFx’s seen over the last few years, I can without hesitation, tell you which vendor they’re skewed towards, or created by. That’s nothing to do with my skill or knowledge, it’s the fact we’re now at that stage where we’re even seeing names of vendor products or specific unique vendor terminology being used in RFx’s.

So how do we create requirements? Right now, from my experience, I can tell you I’ve seen the following:

• People going to analyst companies for templates
• People going to vendors for templates
• People re-using material from previous roles
• People searching the internet from templates

When was the last time anyone wrote an RFx from the ground up? I’m sure there are definitely people out there who have, so not to knock people or there jobs, just trying to make point of one of the major market challenges we have.

Do you write this as a requirement?

• Your solution must offer privileged session management and session recording
• Your solution must include a password vault to store privileged credentials

Or do you write this?

• The solution must be able to connect users to resources in a secure manner with little friction to the user experience. (Then list resources)
• The solution must have the ability to generate credentials, tokens or certificates for access to resources in real-time (just-in-time access)

3.   Speak with Analysts

So you call an analyst, read the reports and try to find out as much about PAM as you can to validate your requirements. In Europe, we tend to look at the big 3 analyst firms.

1. Gartner
2. Forrester
3. Kuppinger Cole

I’m actually enjoying some of the commentary and insights from Simon Moffat of The Cyber Hut right now, and think he has a good writing style. Something I need to work on alongside making this thing look pretty.

Before we start this, I’ll say this isn’t about knocking analysts. They have a really hard job and are often stuck between a rock and a hard place as they’re customer facing but need vendors to spend money to enable them to do their jobs.

Have you ever read the qualification criteria for the PAM MQ or Critical Capabilities as an example? It’s freely available online for all to see, so no secret here.

To be considered as a vendor for this report you need to have the following:

• Privileged account life cycle management
• Account discovery and onboarding
• Privileged credential management
• Session management & remote access
• Secrets Management
• PEDM (Privilege elevation and delegation management) UNIX/Linux
• PEDM – Windows and Mac OS
• Just-in-time
• CIEM

There are also revenue targets, customer targets and geographic targets set as qualification criteria.

So, to be clear, to be considered to even go in this report, you need to have all those capabilities in your portfolio.

Which means any niche, new vendor that comes to tackle an area of PAM has no chance of gaining recognition or validation which is critical for growth.

As mentioned, I don’t blame the analysts for this. The reality is there is strong group of PAM vendors in this space who have helped define the market and they have a large share of the revenue in the market between them. You simply can’t change the game on them as this is what they’re worked so hard for.

The best way of resetting this is really for some of these reports to be retired. A few years ago, we had this with the IGA MQ and I think PAM has got to that point where we need to do the same.

Not just to introduce new vendors, but really to have a different take on PAM as those capabilities listed above are really just approaches to deal with privileged problems, but there are many more.

4.   Research Vendors and Offerings

Ok, so we’ve got our old requirements and we’ve spoken to analysts and got our skewed view of a handful of vendors in this space, and we decide we’ll have a quick check in our favourite search engine just to be sure we’re really looking at the right vendors.

You’re going to select the top 3 or 4 vendors in this space, because well… no one got fired for buying the number 1 or 2 right?

A quick search on ‘Privileged Access Management’ will indeed bring up the top vendors listed in these analyst reports as well as sponsored adds for those vendors whose marketing budget allows.

Great you feel validated

5.   You approach vendors for demos

You reach out to these vendors instantly setting off happy ears across the vendor space.

‘Excellent, you want a vault, session recording, some least privilege’ Yeah, we can do that.

So you embark on demo’s, which to be frank, all resemble each other. For you, it’s pretty simple as all the vendors can meet those requirements so it’s almost job done and time to hand this off to purchasing for pricing negotiations.

For the vendor, they’re nervous as hell thinking what actually differentiates them from anyone else in this space.

You have to follow process and go through an RFP, but do you really want to write it? Or do you get some help with the requirements from the analysts and perhaps asking 1 or 2 of the vendors if they have a template 

6.   The RFx

You copy/paste all these requirements into your template and then send out to vendors. Happy ears start wiggling again at how easy this is as it’s mostly their features in the list.

It’s one of those processes you have to go through for due diligence and also lets be honest, protection against bad decisions. But if you’re starting from bad data, then are you really protected?

7.   Vendor Selection

When it comes to scoring, lets face it, they all do the same thing and in a pretty damn similar way so we feel bad and have to create some difference in the scoring.

• You may rate the UI differently
• You may have some bias towards people or products
• You may have heard some things which sway your mind
• You may have previous experience with products
• You may just pick the top 2

Either way, you whittle down the vendors usually to 2 and have a preferred which you may start negotiations with whilst trying to keep the other in a holding pattern just in case things don’t work out (or unless you want to play the vendors off against each other to drive down the price)

8.   The POC or POV

Proof of concept or proof of value, whatever you want to call it we feel the need to see how something works in our environments. We’ve had demo’s showing it’s capabilities, we’ve had responses in writing confirming it meets out requirements but we still want to test it just to make sure.

In all fairness, this is good to gain user input, especially on the user experience which is critical to adoption.

9.    Ready to purchase

Get your best negotiating shoes on and get ready to rumble. I probably have the least to say about this, as it’s like a dark art but obviously we all know software companies are quarterly driven, so the best to time buy is end of Q or if you can hold off, end of year.. Everyone loves a December 29^th sale

10.   The deployment

Hold on to your hats and get ready for the never-ending journey that’s about to begin.

On your journey to delivering

• A password vault
• Session management and recording
• Some least privilege

You’re about to discover

1. You can’t vault all passwords
2. You can’t discover all passwords
3. If you try to vault all passwords, you’ll never reduce risk
4. If you try to vault all passwords, you’re going to piss a lot of people off
5. If you try RDP/SSH through a web browser, you’ll piss people off
6. If you have to do RDP through a web browser to launch a web browser, that’s just stupid
7. You put session recording as a must have and now have to pay for that storage
8. Session Recordings are fun to watch (for the first day of deployment, after which you forget all about them until you get the storage bill)
9. No one wants you to deploy agents to their machines
10. No one wants to work with you to remove their rights

Ok, it got a little cynical and a little sarcastic but this is a typical journey for many but you can see the following:

1. If you start with bad or old data, you’re not setup for success
2. Think about your requirements carefully and reframe them to outcome based rather than technical. You may be surprised at what you find.
3. Engage your user community early – You can have more security and a great user experience.
4. Engage a partner – yes, we offer consultancy in this area and obviously love talking about PAM. There are also lots of other great partners out there too.
5. Analysts are aware of smaller more niche vendors but they’re not likely to make the big reports any time soon due to qualification criteria which is largely driven by the pace setters in the market.
6. The market is often defined by major players within it! it doesn’t mean it’s the only option

For me personally, I think the market in PAM has gone a little stagnant and needs resetting. The best way to do this is retiring the reports that define the market and then look at it again with a fresh pair of eyes. It sounds so simple, but I assure you it’s not. There is a lot of revenue at stake for both vendors and analyst firms and lets face it, everyone is here to make money

I think there are lots of problems with PAM, over the next 11 days we shall be introducing a new one each day.

Once we get to the end, we’ll discuss ‘if we started from ground zero to build a solution to manage privileged access, what would that look like.’

I call it the grand idea, in fact it’s a product I wanted to build but ultimately talked myself out of it as I kept telling myself:

• I’m not someone who would run a company
• I’m not technical enough to be a CTO
• I don’t understand how to get funding
• I love talking about PAM and that’s my sweet spot (Should probably become an analyst)

Fear is an interesting thing though, and maybe we’ll do more of a personal blog about that at some point

For now, enjoy the reading