A Survivor’s Guide to Tackling the “New PAM”

June 07, 2024

Queue the horror music – your management team has asked you to do something about privileged access. Privileged Access Management (PAM) can seem like a daunting initiative. You might find yourself asking questions about who needs what level of access and how long they should have that access. It’s also important to consider how many resources and staff members will be needed to deploy and maintain this PAM solution. But with the right partnership, it is possible to create a rewarding and ultimately risk-reducing PAM strategy that feels more like a familiar routine than a complex task.

As an engineering fellow with over 20 years of experience working in IT and cybersecurity, including 10 years of experience facilitating identity security projects here at Optiv, I am eager to share trusted advice that I have learned over the years when it comes to PAM. For organizations who do not have a formalized PAM approach in place or do not know where to start, this blog post will outline what you need to know to quickly and effectively deploy PAM technology and services to form a sound strategy that works for your unique business case.

What Makes PAM So Scary?

PAM, in its simplest form, is centered around storage of an account credential. It may seem simple enough, but over the last 5 years, the prioritizations for PAM adoption and usage have been changing. We cover these changes in more detail in “The Continuing Evolution of Privileged Access Management.” Organizations are increasingly grappling with the question: “Why do we need to have standing/persistent privilege?” And, more broadly, “What does privileged access even mean for the company?”

When trying to answer these questions, security practitioners and business leaders alike often perceive PAM as scary due to the unknown security posture of the environment. Adding to the scariness is the sheer volume of available PAM options. We are now in a completely different world than we were 5 years ago. To effectively implement a PAM solution, there are several steps required. Organizations need to make key decisions about which product or products they will implement, along with any applicable use cases. This can often be easier said than done, as people tend to underestimate the complexity of PAM as represented by the product stack and the abundance of product options they can choose.

To illustrate this point, let us pretend that we have two teams in a mid-sized business. One is highly technical (i.e., the engineering team), and the other is not (i.e., the marketing team). Both have privileged access depending on the internal definition of “privileged” that the company has landed on. This is where the use cases come into play. Both the technical and non-technical teams need PAM services, but they may also need different requirements. On the one hand, the marketing team may want the ability to log on to sites and do other business-level activities without being heavily impacted by the “loathsome” security team. On the other hand, the security team needs to protect the crown jewels, which may include information and other areas that are often accessed daily for the purposes of performing business functions. How does one protect these types of accounts in this new world of PAM? There is often a fine dance between mitigating potential risk and meeting the perceived needs of the business to maintain operational speed.

Why Has PAM Evolved?

The dance has been further complicated due to the evolution of PAM from a single solution into a complete ecosystem of products. The constantly changing definition of privileged access for each company is one of the primary reasons that PAM has evolved. As that definition has changed, the impacted audience has also changed. As we have shown, PAM is not just an issue for technical teams; it’s a significant concern for the entire business. So, what does that mean to the security team?

Whereas organizations used to approach PAM solutions by just vaulting and storing accounts, they are now moving to a state in which they are making accounts out of thin air when needed. This is known as just-in-time provisioning, which is slowly becoming an enormously powerful option for reducing the overall footprint of privileged access in the environment. The need for standing privilege has been questioned more often as newer just-in-time solutions have been developed.

For instance, let’s say a developer needs access to a server once a year for some form of maintenance or for the occasional troubleshooting effort. Traditionally, this would involve creating a privileged personal or shared user account that would then be applied to the local administrator group of each of the application’s servers. Due to the nature of this account, it would then need to be managed/rotated and would often be disabled by the infrastructure team due to lack of activity. This process would often involve the account owner having to open a ticket to re-enable the account.

With recent PAM offerings, that use case is easily handled by providing the user access when they need it through a just-in-time solution. Assuming this is the only privileged access needed by this developer, there is no need for a persistent assigned personal or shared privileged account. Do this process enough times, and the footprint for privileged access and the associated risk of those accounts shows measurable improvement. The elimination of this need for persistent privileged access, as a necessity, is one of the largest drivers of the PAM changes we have seen.

The final area where we see PAM evolving is in the secrets managements space. Secrets management is often overlooked in the traditional PAM conversation, because there is often more of a focus on user credentials rather than what the applications are doing. Threat actors can compromise a medium-sized business’s application secrets, such as passwords that are unmanaged, unrotated or unchanged. These threat actors can then gain initial access to a less secure medium-sized business and eventually attack a larger organization such as a bank.

Due to some of these concerns with secrets management noted above, medium-sized businesses are also finding that they need the same protections as larger businesses, especially when seeking to adopt or scale their SaaS platform and identity solutions in the cloud. But they typically lack a high number of specialized staff to manage all the different parts required for PAM in the secrets management space. As DevOps development, key management systems in the various cloud providers, containerization, API calls, etc. are valued in this space, there was an increased need for specialized secrets management solutions that shifted their focus from user identities to machine identities. Like with the human-specific use cases that influenced the evolution of PAM, the application side of the equation has been driven heavily by regulatory and the risk of clear text credentials in any code. With this shift, the secrets management side of PAM is not just a people/user conversation. In their blueprint, CyberArk has Secrets Hub to handle Azure, AWS and Google Cloud credentials for applications (API keys, etc.) as one of the first delivery areas. Whereas security teams used to shoehorn all their privileged access use cases into one PAM solution, they now have different use cases around these products.

The evolution of PAM can be summarized by looking at the drivers for this need. We now have a myriad of tools because there is not really a one-size-fits-all approach that can be successful. External drivers, such as regulatory drivers due to increasing risk and the growing number of places where privilege access now exists, have elevated the need for the different types of PAM products we are now seeing in the market. The complexities of starting to address privileged access from a holistic/program perspective can seem overwhelming. But with the right partner, it can be manageable and successful. When you are doing this type of deployment, due to the complexity of the PAM conversation, you need a partner that can not only speak strategically, but also advise tactically to how you can effectively deploy this solution for your unique environment and use cases.

Tackling the “New PAM”

When looking for a PAM solution to tackle the “new PAM,” you have various options that fall into four major areas:

Privileged Single Account Access

• Approach: The standard LAN account is used as a privileged account.
• Advantages: This type of access provides a seamless experience for users whether they are IT or non-IT focused. There is essentially not much for the user to learn or change, as they always have access. It has the least influence on business process. This option doesn’t require privileged cloud or other more advanced PAM options and can be optimized with just-in-time solutions.
• Challenges: This access is considered the least secure and allows for a larger attack surface. If a threat actor gains access to a credential, then that account is fully compromised. It cannot be managed or in rotation, as it must always be accessible. This type of access challenges the core principle of separation of duties.

Privileged Secondary Account Access

• Approach: A privileged account is either personally assigned, or a shared account is created for the separation of duties.
• Advantages: This is a traditional access model with the least friction for availability for end users. It gives persistent access to the credential. So even if a network goes down or a just-in-time privileged account fails, the user typically always has access to that credential.
• Challenges: There is added complexity due to the need to manage/rotate the account, and it often involves adding another persistent account to an already exposed environment. This can lead to a single account having persistent privileged access to hundreds of servers.

Privileged JIT Provisioned Account Access

• Approach: The user is only privileged when needed, rather than indefinitely by default. This option can involve a combination of the elevation of the LAN account and/or the dynamic provisioning, permissioning and removal of a temporary account.
• Advantages: This option is ideal and easiest to use for small and medium-sized businesses, including those who have never deployed a PAM solution before. JIT provisioned accounts are often simpler and require less of a learning curve for the end user than a full-blown PAM solution. They lend themselves well to the single LAN account scenario, as well as eliminate the need for a separate account. Solutions are designed to be minimally invasive, as they are often targeted toward a much wider audience than strictly the IT team. In some cases, there is no need to create an account, as the primary LAN account is what is used to elevate access based on some pre-defined criteria.
• Challenges: This approach requires a full understanding of privilege in the company to effectively deploy and does require user training to allow proper use.

Privileged Application Access

• Approach: This strategy provides privileged access to non-human accounts when necessary to allow communication between applications within the company.
• Advantages: This access allows a true separation of user from application identity.
• Challenges: Full integration requires understanding where all the credentials for the application live. This can be very time consuming depending on the quality and timeliness of the application’s documentation. It can also be costly and complicated for a smaller business.

Each of these options has different deployment requirements. For instance, let us say that a company wants to focus on removing the persistent footprint of privileged human access in the environment. If this is the case, then the traditional PAM solutions would need to be augmented with something else like just-in-time provisioning.

We often see that companies are breached for something as simple as a credential left in the wrong piece of code and not secured. Because of a desire to protect the company’s crown jewels from such credential-based cyberattacks, vendors are starting to prioritize the application credential space. This space often provides the most visibility and the quickest return on investment (ROI). Planning for your type of deployment is just as important as deciding which PAM option to purchase. It can influence the success of both the initial deployment and overall long-term program.

Remember, in the absence of a defined PAM program, there is always a defacto PAM program that will be defined the minute a privileged credential exists. A trusted partnership with a vendor and a service advisor like Optiv can walk with you through the myriads of options, sort out the fear uncertainty and doubt (FUD) and provide a holistic strategy with the appropriate process and products to make your PAM program a success.