By security practitioners, for security practitioners innovate | novacoast federal | novaSOC | novacoast
By security practitioners, for security practitioners

Building a Privileged Access Management (PAM) Strategy

Privileged Access Management (PAM) provides a secure methodology for authentication, authorization, and auditing usage of escalated access privileges.

Implementing PAM can be no small task. A robust PAM strategy matches an organization’s size, objectives, and practices.

How should new and existing PAM implementations be evaluated? Kris Zupan, a Director of Security Services at Novacoast explains below. This article is based on Kris’s fundamentals and best practices for building and managing Privileged Access Management.

Kris is one of the founders of the PAM space. The PAM products on the market today are either directly derivative or inspired by his work in securing privileged access 20 years ago.

Most PAM Concerns Are Straighforward

In general, customer PAM issues boil down to two things:

  • Understanding their use cases
  • Understanding their PAM processes

Why? Their PAM use case is generally where the issue lies.  The PAM solution in place may be solving a use case that no longer exists and not solving the use case that does.

How Did PAM Begin?

20 or more years ago, most companies developed homegrown solutions for PAM. It was generally implemented due to compliance requirements, an audit finding, or something specific to the business. The solution they have was implemented years ago. It’s worked and that’s all they know.

If you’re in a larger company, do you know how many PAM solutions you are running? Knowing what they are and if they are being used effectively is imperative.

The most important question, from a PAM Assessment perspective: is your PAM solution is solving your PAM problem?

How Do You Know Your PAM Strategy is Still Working?

Most people might think that a checking their PAM Strategy is working means logging onto the PAM system to see what it’s doing. That’s not the most effective way.

The first step in any PAM Strategy is to understand what the use cases are because the issues are usually here.

Your PAM solution may doing what it’s supposed to be doing, the problem is the use case it is solving for may be 15 or more years old. It may not be addressing the use cases that you have right now.

The next step is to understand your PAM processes. Often after you understand your PAM use cases you discover you’re solving these without using a PAM tool. The PAM process may be controlled through an administrative process that is controls based or another way of controlling your PAM process that has nothing to do with your PAM solution.

Once you understand your PAM use cases and processes then you can begin to analyze your PAM solution. That’s when you can assess if it is actually addressing your PAM use cases and your PAM processes.

Typical Use Cases for PAM

  • Break glass
  • Business as usual privilege – system access
  • Business as usual privilege – middleware access
  • Business as usual privilege – application access
  • Vendor access
  • Jumpbox scenarios
  • Scripted / programmatic access
  • RPA access
  • DevOps access
  • Cloud
  • Vaulting
  • Service accounts

While it’s easy to search the internet and find several different use case lists, this is a list the highlights the usual root causes when businesses have PAM issues.

A critical point to remember is that the PAM use case means finding where people use privilege and how are they doing it.

Is Break Glass a Common Use Case?

Most agree that it is. An interesting thing can be seen when looking at penetration testing where the testers discover that the administrator credential on 100s or 1000s of machines is exactly the same. The issue is not new, it’s a problem that’s been around since the very beginning.

What’s changed is that threat actors have gotten better at exploiting it.  

Do You Need Root Access?

In a mature environment, you shouldn’t need a root account on your Unix systems. There are many other delegation systems, such as SUDO and commercial delegation tools.

The only time you should need Root is when the box is in distress. Some of these are common distress types where Root would be needed.

  • When you need Single User Mode
  • When it’s lost network access
  • When it’s a Windows box
  • When it’s fallen off of Active Directory

As you go through the list of use cases, you may see many that didn’t even exist when you got your PAM tool. DevOps and RPA Access are excellent examples. It’s a good idea to go back a deeper look at these.

PAM Use Case Process

When you begin a PAM Strategy use case process, you begin with discovery meetings with the groups involved with the use case you’re analyzing. For example, you will meet with requestors, approvers, reviewers, provisioning, compliance, and governance.

What you need to learn from these meeting comes down to, what’s working; what’s not, and what’s on their wish list.

Once discovery meetings are done, you’re ready to meet with the team managing the PAM. Find out what their challenges are right now. When meeting with these groups you should focus on learning the following information:

  1. Challenges
  2. Wish list – what do they want to get out of their PAM solution?
  3. Allocation of resources – if someone says PAM is hard, find out why they think so. There may be opportunities to refine and remove some manual processes.
  4. Manual processes

Break Glass Use Case Questions

Risks that the Break Glass use case address include the following. Looking at it broken down in this way helps to better define why you are using it.

Risks addressed
  • Lateral traversal
  • Individual accountability
  • Availability
  • Restoration

In this use case, lateral traversal is the big part, followed by individual accountability. This use case addresses these risks.

  • Types of assets: All
  • Types of accounts: System
  • Types of users: System
  • Types of access: Break glass

Break Glass is applicable on every system because each one has a break glass account. It is pretty straightforward.

  1. Inventory of all assets
  2. Method for discovering new accounts
  3. Method for determining the correct users for the accounts

When you are looking at implementing this use case, these are the bare minimum requirements.

What’s more, if you know you want to manage the Break Glass accounts on every asset, then it’s essential to know what that means.

Once you’ve done the assessments needed to find problem areas in your Break Glass use case, make sure you know this information.

What questions should you be asking to get the information you need?  Here are a few excellent examples:

Questions to Ask
  • Does an accurate inventory exist?
  • What is the current onboarding process for these types of accounts across each asset type?
  • What is the current access process for these types of accounts across each asset type?
  • What is the current password rotation process for these types of accounts across each asset type?

Knowing the current process is going to let you know how accurate your inventory is and that determines your current state.  The true measure of your PAM solution isn’t how many accounts you have in it, it’s how many accounts are being effectively managed.

Best Practices
  1. MFA/Strong authentication should be required before accessing privileged accounts.
  2. Every asset built-in system account should be managed
  3. Every asset built-in system account should have a distinct strong password
  4. Incorporate into the build/provisioning process
  5. Use discovery to ensure all assets are cataloged

Strong authentication must be in place when you intend to keep your privileged accounts all in one place.

If we say it’s bad to have the same administrator account across many machines, then if a threat actor can use that administrator account to get into the PAM solution and access the passwords that aren’t the same your situation is much more critical.


The only real difference between models is whether the account is enabled or disabled at rest.

Disabled at rest:

Not susceptible to brute force attacksRequires an action (normally network based) to enable the account. Can be a problem if machine needs to be isolated or disconnected.

When it comes to Break Glass, these two models are pretty much all that’s out there.

While many favor having the account disabled if it’s being properly managed and the password is being rotated it’s unnecessary.

Zero Trust in Break Glass

From this perspective, the Break Glass account should all be managed. Some action should be needed to be taken before anyone can use a Break Glass account.

If you know the root password, just because you know it, then that is not Zero Trust.

Sessions in Break Glass

Sessions is a new feature in PAM. However, it’s not included in Break Glass.

Vendors in Break Glass

This use case can be used by any PAM vendor because it’s where PAM started. In most cases the differences will come down to ease of discovery, how well the vendor scales, and integrations.

Existing PAM Solution Strategy

Existing PAM solution questions include these:

  • Coverage and verification of coverage – if you have an inventory, you should compare it against what’s in your PAM solution.
  • Validation of stored credentials/accuracy – most current PAM solutions have the ability to validate, consider it as an accuracy number. If you can successfully validate 90% of the stored credentials in your PAM solution, it means your use has a 90% chance of getting a good password. This is a critical metric that you should make sure you’re finding.
  • Utilization
  • Resiliency
  • Governance / Entitlement review

Common Outcomes from Assessing Your PAM Strategy

One of the more common take-a-ways from assessing a PAM Strategy is when a company has more than one PAM solution. Often, they don’t even realize it.

Some companies implement multiple solutions to handle different use cases. If this is your company’s situation, make sure you understand where they are and if you’re trying to standardize the architecture it will present challenges.

Another is that the solution is not being used effectively. Some of the causes include:

  • Uneven coverage
  • Not managed effectively (80% fail rate)
  • Users bypassing system (backdoors)
  • No MFA

When you get to the root of the issue, it’s that they have a PAM product, but not a PAM solution. It’s likely that the PAM product was brought in, it’s working, but no one has looked at it in detail in a long time.

Previous Post

Going Upstream in Search of Secure Linux

Next Post

Cyber Threats Associated with Russia’s Invasion of Ukraine (updated)

Innovate uses cookies to give you the best online experience. If you continue to use this site, you agree to the use of cookies. Please see our privacy policy for details.