Building a Privileged Account Management (PAM) Strategy

Kris Zupan is one of the founders of the PAM space, and the products on the market today are either directly derivative or inspired by his work in securing privileged access nearly 20 years ago. In this article he shares some history of the evolution of PAM along with his recommended strategy for building out a successful implementation.

What is Privilege Account Management?

Privilege Account Management (PAM) is the process of identifying, managing, and releasing privileged accounts. Privileged accounts, and what determines whether or not an account is privileged, could be an article by itself. We will use a basic definition which is the following:

“Any account that gives the ability to affect confidentiality, integrity, or availability of a system.”

This includes the built-in system account, like root on Unix or administrator on Windows, but can also include “sa” accounts on database servers and any other account that fits the criteria.

How did PAM begin?

The early days of networked computing—the mainframe era—was centralized and had but a few system accounts which could be easily identified. As distributed computing matured in the late 90s, there were suddenly thousands of individual systems with individual system accounts. The manual processes of account and password management simply could not scale to meet this new need. 

There was also this new thing suddenly being introduced in the business world called the Internet, which changed the way companies connected to each other and the rest of the world.

Evolution of PAM

In the early 2000s most companies were building their own solutions since there was nothing available commercially. Commercial PAM offerings started to appear around 2003 with companies like e-DMZ Security (acquired by Quest), CyberArk, and Symark (now BeyondTrust) being the early players. They all provided the same basic function of automating the management of privileged accounts, and provided a check-out/check-in capability for shared accounts. The main question they answered was individual accountability: who used a shared account at a particular date and time?

Privileged session management (recording and controlling RDP and SSH sessions) started to appear around 2005. This allowed the activity with a privileged account to be reviewed, so besides knowing who used a shared account at a particular time, it answered the question of: what did they do?

The products matured and gained better interoperability with Active Directory and other identity stores and were able to discover accounts and provide better automation. Application-to-application (A2) functions evolved as well as expanding platform support.

The main reason for these tools was compliance. In a mature organization, the built-in system accounts like root or local administrator were rarely needed and used. In most cases, system administrators had another method of gaining privilege and the shared system accounts were only needed if a system was in distress. The compliance issue was that even though a root password may not be needed, policy required the password to be changed on a regular interval. Therefore, many early PAM solutions were compliance tools that rotated a lot of passwords that were rarely retrieved.

The products made incremental gains through the rest of the 2000s. The PAM space had its next dramatic change around 2012 as APTs and malware started to become a major disruption for business. The privileged accounts that were being used for day to day activities and services were beginning to become the target.

Companies decided that they wanted all privileged accounts to be managed by the PAM solution. This changed PAM from a compliance tool to a security tool. Suddenly PAM availability became critical. In many organizations, any privileged access now involved interaction with the PAM tool.

We are in the middle of the next major evolution as PAM solutions are tasked with integrating into cloud solutions, RPA tools, devOps streams, and most recently, having to deal with a primarily remote user base. The vendors have responded with cloud solutions, A2A capability, and analytics to help provide solutions.

PAM Strategies

For the nearly 20 years that I have been helping companies implement PAM, the following is the approach that I have found to be the most successful. It can be summarized as follows:

1. Identify your PAM use cases.
2. Prioritize the use cases.
3. Implement the use cases in a phased approach.

Sounds simple, right?

There are probably plenty of people reading this article who have lived through PAM implementations that took years. Or failed. Or took years to fail.

Most likely these failures were due to trying to boil the ocean, as they say. The successful implementations set scope and expectations, knowing that a PAM implementation will be done over various iterations and should build on the momentum of success.

So let’s look at the 3 steps in detail:

1 Identify your PAM use cases

Here is my list of common PAM use cases and their definition:

Break glass​

This is the basic PAM function of providing management of the built-in administrative account on an asset. Examples are root on Linux, Administrator on Windows, or sa in a database server. All assets have this account. The break glass function is required when a system can’t be accessed through normal privileged access. Examples are a unix system in single user mode or a windows member server that has lost its directory connection. This account is generally only used in emergency situations.

Business as usual privilege—system access​

This is the standard mechanism for system privilege access. This includes the requirement for patching and other system related maintenance that requires a privileged account to accomplish. This is normally done by providing an account that has the necessary privilege to perform the task.

Example: an account in Linux that has sudo or other delegation rights to perform actions as root. Another is an account on Windows that is in the local Administrator group. This type of account is generally used every day to perform system maintenance requirements.​

Business as usual privilege—middleware access​

This is the standard mechanism for middleware privileged access. This includes the requirement for middleware patching and other middleware related maintenance that requires a privileged account to accomplish. This is normally done by providing an account that has the necessary privilege to perform the task.

Example: an account in Oracle or other databases. This type of account is generally used every day to perform middleware maintenance requirements.​

Business as usual privilege—application access​

This is the standard mechanism for application privileged access. This includes the requirement for application updates and break/fix actions that requires a privileged account to accomplish. This is normally done by providing an account that has the necessary privilege to perform the task.

Example: an account in an application that has privilege to an underlying database or filesystem. This type of account is generally used when an unscheduled application fix is required that can’t be done through the standard change process.​

Vendor access​

Vendor access follows the same constraints as the use case in which the vendor is providing (system/middleware/application BAU). There are additional considerations since vendors are generally outside the control of the organizations and may have additional auditing requirements. A PAM solution can also help isolate the connections by proxying access to prevent direct system access.​

Jumpbox scenarios​

Jumpboxes are an architectural model that has been used for years to provide a gateway into a protected environment and to reduce network complexity. Example: a machine that allows access to a SCADA environment, which is normally very isolated to the internal network. The jumpbox is available on the internal network and then through routing or firewall rules, has access into the protected network.​

Scripted/programmatic access​

This use case involves scripted access to a privileged account.

Example: a script is designed to run a query against a database at scheduled intervals. Since the calling script needs a database credential, the password is typically stored on the calling system. While this password may be protected and encrypted, it still causes a problem because the credential can’t be changed without changes to the scripts.

The problem is worse if the credential is a system level account that is doing restore/dump type operations and has high privilege. This use case also covers A2A functions where the call may be in compiled code and used to query data based on the application call. In all cases, the fact that the credential can’t be changed means that the developer who created the calling process knows the credential.​

RPA access​

RPA processes are used to automate tasks. The RPA process is in most cases impersonating a user (like a support chat bot) and many times a privileged user in order to access the necessary information to complete its task. Many RPA solutions have their own method for controlling credentials, but organizations usually prefer that the credentials are managed by the PAM solution. The PAM solution can also ensure the RPA credentials are limited in lifetime.​

DevOps access​

As DevOps processes mature, more attention is paid to managing the devops secrets that are required. Many of the current DevOps platforms include a credential manager, but organizations usually want to control this with their PAM solution. There are offerings from various PAM vendors that will integrate with solutions from Hashicorp or other technologies.​

Cloud ​

This is an overly broad use case but can be broken down into 2 main components:

1. Cloud assets. This covers Windows or Linux assets that are hosted in AWS/GCP/Azure/etc. For most environments, they’re managed in the same way as on-prem assets utilizing the site-to-site VPN. The main distinction is the elasticity requirement.​
   
2. Cloud consoles. This is the admin console for the cloud environment.​

Vaulting​

A vault is the basic PAM function of securely storing a credential and providing a workflow for the credential to be released. This use case implies that the PAM solution is not managing the credential. Examples are any privileged accounts that can’t be automatically managed.​

Service Accounts​

This use case defines the situation where an account is tied to a Windows service, scheduled task, or other process. The account could be a local account or a directory account. When the account password is changed, Windows requires that the stored credential for the service or scheduled task is also updated. For this reason, many organizations do not change the service account passwords​.

Not all of these use cases will apply to every company, and you may find additional ones not on the list. The key takeaway is to first understand how privileged accounts are being used in your environment.

2 Prioritize the use cases

You can’t do everything at the same time. Determine which use cases to implement first. Here are a couple of suggestions:

• Start with break glass. The root/administrator or other built-in accounts are not normally used for day-to-day activity. Typically there should be very little operational impact to managing these passwords. Also, they are easily identified (sid500/uid0). Finally, they are a major path for lateral traversal during at attack so managing these passwords provides a very direct security benefit.
  
• Leave service accounts for later in your implementation. This is typically the hardest part of PAM. Service accounts are often running on various systems, have multiple dependencies, and cause significant issues if the service stops or can’t restart. Save these for later in the implementation once you have some experience with your PAM tool.

3 Implement use cases in a phased approach

Once you decide on a use case to implement, break it into meaningful phases. After thorough testing and validation of your architecture, select a scope that is achievable. The momentum of completing a phase will help make users more comfortable with tackling the next phase.

In successful PAM implementations, there may be many phases, but by scoping the activities you gain the security benefit of each phase before starting on the next.

Summary

PAM is still solving the same problem 17 years after it originated, and will likely be doing so for the next decade at least.

It was said that the password was going to be obsolete in the early 90s. Tokens, certificates, smart cards, LDAP, biometrics, SSO, SAML/federation…all of these were going to usher us into a world without passwords. And for normal user access, this is coming true. But almost every solution mentioned requires a network or an external device/reader. When the system is in distress and those components don’t work, guess what still does? A password.

There are plenty of other benefits to passwords. Someone can force your thumb onto your phone but you can still decide to not tell them your password. The point is: accept that passwords are not going away in the near future and the best bet is to use PAM tools to manage the passwords that must remain—privileged passwords.