Why Do PAM Deployments Take (almost) Forever to Complete?

Privileged Access Management (PAM) solutions are considered common practice for preventing identity threats against administrative accounts. In theory, the concept of PAM makes a lot of sense: place admin credentials in a vault, rotate their passwords, and closely monitor their sessions. However, the harsh reality is that most PAM projects remain projects for years, or even stall completely, preventing them from delivering the security value promised.

In this article, we explore what makes service account is the main obstacle in PAM orientation. We’ll learn why vaulting and rotating service account passwords is a nearly impossible task, thus making them vulnerable to compromise. We’ll then conclude by introducing how Silverfort enables identity teams, for the first time, to address these challenges with automated discovery, monitoring, and protection of service accounts, and streamline the PAM onboarding process in just a few weeks.

PAM’s Promise: Protection For All Administrative Users

The concept of PAM is very simple. Since adversaries seek to compromise admin credentials in order to employ them for malicious access, the natural thing to do is to place obstacles in their attempts to successfully execute this compromise. PAM provides an additional layer of security which includes close monitoring of admin connections via session recording, and more importantly, a layer of proactive prevention in the form of admin credential vault and is subject to periodic password rotation. This greatly reduces the risk of a successful attack, because even if an adversary manages to compromise admin credentials, the password rotation will invalidate him the next time he tries to use it to access the targeted resource.

So in theory, everything is fine.

The Reality of PAM: The Long and Complicated Onboarding Process that Takes Years to Complete

But that’s what identity and security teams deal with in practice implementing a PAM solution is one of the most resource-intensive processes. The fact is that very few PAM projects achieve the target of protecting all administrative accounts in an environment. What usually happens is that challenges come sooner or later, with no easy solutions. At best, these challenges only slow down the onboarding process, extending it for months or even years. At worst, they stop the entire project. One way or another, the implications are serious. On top of a heavy investment of time and effort, PAM’s core goals are not being achieved, and admin accounts are not getting the protection they need.

While there are various reasons for the difficulty of implementing PAM, the most prominent is the protection of service accounts.

Service Account Recap: Privileged Accounts for Machine-to-Machine Connections

A service account is a user account created for machine-to-machine communication. They are created in two main ways. The first, is IT personnel building it to automate repetitive monitoring, cleaning, and maintenance tasks instead of doing them manually. The second way is as part of implementing software products in the corporate environment. For example, an Outlook Exchange server deployment requires the creation of multiple accounts that perform scanning, software updating, and other tasks involving connections between the Exchange server and other machines in the environment.

One way or another, a typical service account must have elevated privileges to be able to make the machine-to-machine connections it makes. This means it’s no different from any human admin account in the protection it requires. Unfortunately, getting service accounts into a PAM solution is a nearly impossible taskmaking it the biggest hurdle in the way of a successful PAM implementation.

Visibility Gap: There’s No Easy Way to Find Service Accounts or Map Their Activities

Incidentally, there is no easy way to gain visibility into service account inventory. In fact, in most environments you cannot know the full number of service accounts unless close monitoring and documentation of the creation, assignment and deletion of service accounts was practiced for years – which is hardly a common practice for us. This means full discovery of all service accounts in an environment can only be achieved with significant manual discovery effort, which is out of reach for most identity teams.

Moreover, even if the discovery challenge is solved it still exists a more formidable challenge that remains unaddressed, namely mapping the purpose of each account and the resulting dependencies, that is, the processes, or applications that this account supports and manages. This turned out to be the ultimate PAM blocker. Let’s understand why this is so.

PAM Implications: Spinning Service Account Passwords With No Visibility Into Their Activities Could Break The Processes They Manage

The common way a service account connects to a different machine to do its work is with a script that contains the name of the machine to connect to, the actual command to run on this machine, and most importantly – the username and password of the service account used to authenticate to this machine. . The conflict with PAM onboarding occurs because while PAM rotates service account passwords in the vault, there is no way to automatically update hardcoded passwords in scripts to match the new passwords PAM generates. So the first time the script will be executed after the rotation, the service account will try to authenticate with the old password – which is no longer valid. Authentication will fail, and tasks that are supposed to be performed by the service account will never occur, as well as crashing other processes or applications that depend on these tasks. The domino effect and potential damage is clear.

PAM Service Account Catch: Stuck Between Operational and Security Issues

In fact, most identity teams would, given this risk, avoid service accounts altogether. And that’s a dead end – creating a vault service account creates an operational risk, while not creating a vault creates no lesser security risk. Unfortunately, until now there is no easy answer to this dilemma. This is why service accounts are a bottleneck for PAM onboarding. The only way to meet security and operational requirements is to launch a painstaking manual effort to find all the service accounts, the scripts that use them, and the tasks and applications they run. This is a mammoth mission and the main reason for the many months and even years of the PAM onboarding process.

Addressing Challenges with Automated Service Account Activity Discovery and Mapping

The root of the problem is the lack of a traditional utility that can easily sift through all service accounts and generate output from their activity. This is a challenge that Silverfort wanted to simplify and solve.

Silverfort pioneered the first Unified Identity Protection Platform natively integrated with Active Directory to monitor, analyze, and enforce active access policies across all user accounts and resources in an AD environment. With this integration, AD forwards every incoming access attempt to Silverfort for risk analysis and awaits its decision whether to grant access or deny it.

Leveraging this visibility and analysis of all authentications, Silverfort can easily detect all accounts exhibiting the repetitive and deterministic behavior that characterizes service accounts. Silverfort generates a detailed list of all service accounts in an environment, including their privilege level, source, destination, and activity volume.

With the information available, the identity team can easily identify the dependencies and applications of each service account, find scripts that run them, and make an informed decision about the service account and select one of the following:

• Place it in the vault and dial the password: in this case, the new visibility is gained, making it easy to make the necessary adjustments in the respective scripts to ensure that the passwords they contain are updated according to the vault’s password rotation.
• Place in a no-rotation vault and protect with Silverfort policies: sometimes the usage volume of a service account will make continuous updates too difficult to maintain. In this case, password rotation will be avoided. Instead, the identity team will use Silverfort’s automatically generated policies to protect service accounts, warning or blocking access to them when deviations from their normal behavior are detected.

In that way, Silverfort shortens the PAM onboarding process to just a few weeks, making it an achievable task even for environments with hundreds of service accounts.

Are you having trouble getting your PAM project to work? Learn more about how Silverfort can help accelerate PAM projects Here.