Solving the Toughest Challenges of Privileged Access Management

Home » Blog » Solving the Toughest Challenges of Privileged Access Management

The standard way of addressing security issues that stem from an organization’s privileged user accounts is with a privileged access management (PAM) solution, which can be a very effective tool against threats that target admin credentials. However, when it comes to fully implementing PAM there are often significant challenges around onboarding, operating, and maintaining the solution that can prevent the product from reaching its full potential.

In this blog post, we will discuss the top five issues faced by identity teams when undertaking a PAM implementation project, and suggest ways that each of these issues can be addressed with a Unified Identity Protection platform.

Challenge #1: Undetected Service Accounts and Shadow Admins

It may seem obvious but before PAM protection can be placed on an admin account, the PAM administrator must first know about that account’s existence. In reality, however, this is much easier said than done. The reason is because of two types of accounts that present a serious challenge in terms of being easily discovered:

  1. Service Accounts – These machine-to-machine accounts often have privileged access so that they can carry out critical tasks in a network without the need for human interaction. The problem is that these accounts are often created without proper documentation, making them unknown to identity teams working on a PAM project. Furthermore, there is no utility that can filter out all service account activity within an Active Directory (AD) environment — essentially rendering these accounts invisible and thus not onboarded to the PAM solution.
  2. Shadow Admins – Sometimes standard users can inadvertently be assigned high access privileges without the identity team being aware of this. A common example is a user account that is not a member of a privileged admin AD group yet has the privilege of resetting the password of an admin. But because the user account has not been identified as privileged it also won’t be included in PAM.

Challenge #2: Service Accounts With Unmapped Dependencies

The cornerstone of a PAM solution is its vault, where the credentials for all privileged accounts are stored, and a key protection that PAM provides is the ability to regularly rotate the passwords of all accounts stored within the vault. This hampers an attacker’s ability to use any compromised credentials they may have acquired by limiting the time during which those credentials are valid.

The problem with password rotation, however, is that it cannot effectively be applied to service accounts that have high privileges. The reason is because these accounts often access their targeted machines by executing a script where their login credentials are stored. However, there is no way to automatically update the password within this script using PAM (nor can this be done manually since the exact location of the script itself is usually unknown).

The upshot is that rotating the passwords of these service accounts using PAM would actually invalidate the password in the script, which would then prevent the account from performing its intended task. This, in turn, could lead to a cascade of problems across the network as any critical processes dependent on the service account completing its task would fail as well. Due to this risk, identity teams often refrain from onboarding highly privileged service accounts to PAM, thus leaving them exposed to compromise.

Challenge #3: Admins That Bypass PAM

As the saying goes, a chain is only as strong as its weakest link and this applies to a PAM solution as well. Because PAM products are robust and sophisticated tools – built to protect admin accounts from compromise with measures such as password rotation, the use of vaults, and session recording – the resulting login experience for admins can ultimately be more cumbersome.

The problem is that because of this, admins will sometimes choose to bypass PAM altogether in the interest of efficiency — using the PAM solution only to extract their new password and then logging in directly to the various servers and workstations they need to access. This practice, of course, completely voids the very protection that PAM was intended to provide, exposing a critical security gap.

Challenge #4: Protecting Access to PAM Itself

As powerful a solution as PAM is, it does have an Achilles’ heel: it cannot protect itself. This means, of course, that if an adversary were able to compromise the credentials of the PAM they would then have access to the credentials of all privileged accounts stored in its vault and therefore any resource in the environment — a potentially catastrophic scenario for any organization.

The attack surface for malicious access becomes particularly evident when considering that there are multiple ways to access a PAM solution:

  • via web portal: used for credential retrieval as well as administrative tasks
  • via proxy access: used by network admins to connect to various systems using vaulted credentials
  • via API: used for automated tasks and by service accounts

With so many different ways to access PAM, this means that any single point of exposure – for example, a service account whose credentials have been compromised – could in turn lead to a compromise of the entire PAM system itself.

Challenge #5: Accounts That Can’t Be Vaulted Immediately (Or Ever)

Fully rolling out a comprehensive PAM solution can be a massive undertaking, a project that often takes months or sometimes even years to complete. And during this process, any privileged accounts yet to be onboarded to the PAM product remain exposed to compromise.

As well, since service accounts often have dependencies that are extremely difficult to map, these privileged accounts can remain outside of PAM protection indefinitely, due to the issue mentioned previously around the concerns of breaking any critical processes of these accounts with password rotation. This means these privileged accounts would remain exposed as well.

How Unified Identity Protection Can Complement PAM

Unified Identity Protection is a new category of security products, built to provide real-time protection of the identity attack surface through continuous monitoring, risk analysis, and the enforcement of access policies. By integrating directly with all identity providers, the platform is able to get full visibility into every incoming authentication and access request within the environment, whether on-prem or in the cloud.

This is means that a Unified Identity Protection platform can solve the challenges of PAM through three core capabilities:

  1. Account Discovery –By having complete visibility into all authentications, the platform can analyze every account, including its privileges and specific behavior — easily discovering all service accounts (since these display highly predictable behavior) as well as uncovering any shadow admins (through examining the access-control lists provided by AD).
  2. Multifactor Authentication (MFA) Policy Enforcement –The platform can also apply MFA policies to privileged accounts in order to secure all access in real time. This means that admin accounts would only be able to access resources when the source of the destination is the PAM itself (and furthermore could also require MFA on this very connection).
  3. Service Account Protection – By continuously analyzing the activity of every service account in the environment, access policies would be triggered whenever a service account (whether unvaulted or not) deviates from its standard behavior, thus extending full protection to every privileged account in the environment.

Accelerate Your PAM Journey with Silverfort

Silverfort’s Unified Identity Protection platform protects enterprises against any identity-based attack that uses compromised credentials, allowing identity teams to get more from their PAM investment by solving its inherent security challenges.

Specifically, Silverfort can help with PAM onboarding by automatically discovering all service accounts and shadow admins as well as mapping all dependencies of service accounts. As well, Silverfort can better protect access to the PAM itself by enforcing PAM-only access on admins as well as requiring MFA. Silverfort can also complement PAM protection by securing service accounts through the configuration of access policies and by protecting any admin accounts that happen to reside outside of the PAM.

Ready to learn more about how Silverfort can empower your PAM solution? Read more about this here.


Stop Identity Threats Now