Lessons Learned From More Than a Decade in Privileged Access Management (PAM)

May 20, 2022

• Privileged access management (PAM) is a program, not a project. This means PAM is never “done;” you need to constantly optimize and maintain your tools.
• Over-privileged users and long-past-stale credentials are more common than you might think (you probably have a few in your own organization). Both of these can leave vital systems open to compromise.
• Implementing a PAM program means change and change often leads to resistance. Involving affected personnel early in the process can not only reduce resistance, but it can also end up making your program more effective.

Part two in a Series

Privileged access management (PAM) programs are on the digital front lines of the fight against external threats. Every application, website, database and environment contains passwords. Zero Trust methodology has helped start the battle, but a more formalized global methodology within toolsets is still quite a ways off. However, starting your PAM program – yes, program not project – is more important than ever. When we look at PAM, we need to think about long term programmatic ways to protect not only the business but yourself as well. A methodology like Privileged Access Management as-a-Service (PAMaaS) can help you kick-start that program.

You may be asking why this is important and how it affects your business. Yes, you may have separate password policies for admin accounts and normal accounts that personnel use to perform their day-to-day jobs. However, whenever I ask personnel and admins to be honest about how many of them have set their daily personal accounts to the same password as their admin accounts, typically 75% of the users in the room raise their hands.

What about your non-human service accounts? How have you structured your application accounts and who knows their passwords? I’ve been in organizations where an application account has been in use for a decade, the credentials are known by everyone within the organization and the account was last updated only at its creation. The account then was used in undocumented locations because it had the elevated permissions to perform the task at hand, granting personnel unauthorized or over-privileged access. This is a deeply rooted issue that a well-designed PAM program can uncover and resolve.

How long has it been since the organization has changed the password to the Domain Administrator account? Most of the time the answer I receive is never! That means the master account to most of the domain structures is sitting open to compromise. Who knows the local administrator account password to servers within your company? Are all the local administrator passwords across all servers the same? Typically, about 50% of the room answers that they know or have known the password in previous roles and say that the passwords are the same across most of the infrastructure. Again, this allows users to over-permission themselves, and also allows outside attackers to move laterally within your system with no audit trail.

These are just a select few questions I have asked over the past decade while deploying PAM systems. These are all issues that a PAM program can uproot and resolve. Yes, it’s an investment of time, resources and money; however, the payout is tenfold for organizations. Not only do you help elevate your security posture to new standards, but you also make those new standards easier to maintain. PAM also allows for quicker and more efficient audits and strengthens the outer and most vulnerable ring of your cyber defense.

Deploying a PAM program methodology like this does require change. Unfortunately, change is often met with resistance, making it feel like an uphill battle. One of the ways to combat this is to give people the opportunity to be vocal and present during the discovery and design phase. Giving them the chance to express themselves and the troubles they potentially see helps minimize resistance and can actually improve the effectiveness and security of a tool by allowing its adaptation to their needs.

This is also a great discovery tactic to truly see how deeply rooted some of the accounts within your organization are. As stated above, most of the time service accounts are ill-used. Providing over-privileged access to users broadens your attack vector from the inside. This can be minimized by working alongside teams to understand where accounts can and should be separated. Again, allowing staff who will be using the tool to get involved in the rollout of the PAM project pays off in the long term because it allows users to easily adopt a more secure posture and helps them understand why and how a PAM program benefits them.

Once you’ve rolled out your PAM program you also need to properly maintain it. In the past, PAM tools had the reputation of being bulky and resource-heavy. With the adoption of cloud technology, this is no longer the case. Systems are now designed to effectively deliver with a minimal footprint. However, that footprint must still be maintained. Solutions being left on autopilot for far too long has been a constant issue I’ve seen in the field. As we saw during the pandemic, companies were forced to run lean staff and stretch them thin across multiple tools, preventing them from focusing on the proper maintenance schedules or training needed to keep the system relevant. This in turn deprecates the end user experience. Even with cloud solutions in play, local connector servers still must be patched and maintained on a regular basis, whether this is at the OS or application layer. This requires that staff be available to accomplish these tasks. These PAM solution champions are go-to people who should be up to date on the training, offerings and interface changes. With a lean team, this knowledge often falls to the wayside, causing them to be ill-prepared to handle questions that the organization may bring to them. This can lead to mistrust of the toolset and program.

As noted above, effectively deploying a PAM solution takes investment in both technology and your people. It also bears repeating that organizations need to think of PAM not as a project but as a program, one that must always have a driver in the seat.