Privileged Access Management (PAM) solutions are regarded as the common practice to prevent identity threats to administrative accounts. In theory, the PAM concept makes absolute sense: place admin credentials in a vault, rotate their passwords, and closely monitor their sessions. However, the harsh reality is that the vast majority of PAM projects either become a years-long project, or even come to a halt altogether, preventing them from delivering their promised security value.

In this article, we explore what makes service accounts a key obstacle in PAM onboarding. We'll learn why vaulting and password rotation of service accounts are an almost impossible task, resulting in leaving them exposed to compromise. We'll then conclude with introducing how Silverfort enables identity teams, for the first time, to overcome these challenges with automated discovery, monitoring, and protection of service accounts, and streamline PAM onboarding process in mere weeks.

The PAM Promise: Protection for all Administrative Users

The concept of PAM is extremely simple. Since adversaries seek to compromise admin credentials to employ them for malicious access, the natural thing to do is to place hurdles in their attempts to succeed in performing this compromise. PAM provides an additional security layer that includes both close monitoring of admin connections via session recording, and more important, a proactive prevention layer in the form of vaulting admin credentials and subject them to periodic password rotation. This greatly reduces the risk of a successful attack, because even if an adversary does manage to compromise admin credentials, the password rotation would render them invalid by the time he'll attempt to use them to access targeted resources.

So in theory, everything is fine.

The PAM Reality: Long and Complex Onboarding Process that can Take Years to Complete

However, what identity and security teams encounter in practice is that deployment of PAM solutions is one of the most resource-exhausting processes. The fact is that very few PAM projects go to the full length of accomplishing the target of protecting all the administrative accounts within the environment. What usually happens instead is that challenges occur sooner or later, with no easy solution. At best, these challenges just slow down the onboarding process, stretching it over months or even years. At worst, they bring the entire project to a halt. That way or the other the implications are grave. On top of the heavy investments of time and efforts, the core purpose of PAM is not achieved, and admin accounts don't get the protection they require.

While there are various reasons for the difficulties PAM deployment introduces, the most prominent one regards the protection of service accounts.

Service Accounts Recap: Privileged Accounts for Machine-to-Machine Connection

Service accounts are user accounts that are created for machine-to-machine communication. They are created in two main ways. The first, is IT personnel that create them to automate repetitive monitoring, hygiene, and maintenance tasks instead of performing them manually. The second way is as part of the deployment of a software product in the enterprise environment. For example, the deployment of an Outlook Exchange server entails the creation of various accounts that perform scanning, software updated and other tasks that involve a connection between the Exchange server and other machines in the environment.

That way or the other, a typical service account must be highly privileged to be able to establish the machine-to-machine connection for which it was created. This means it's no different than any human admin account in the protection it requires. Unfortunately, onboarding service account to a PAM solution is a close to impossible task, making them the biggest hurdle in the way of successful PAM deployment.

The Visibility Gap: There is No Easy Way to Discover Service Accounts or Map Their Activities

It so happens, that there is no easy way to get visibility into service accounts' inventory. In fact, in most environments you can't tell the full number of service accounts unless strict monitoring and documentation of creation, assignment and deletion of service accounts were practiced throughout the years – which us hardly the common practice. This means that full discovery of all service accounts in an environment is achievable only with significant manual discovery effort, which is beyond reach for most identity teams.

Moreover, even if the discovery challenge is resolved there is still a more severe challenge that remains unaddressed, which is mapping the purpose of each account and its resulting dependencies, i.e., the processes, or applications this account supports and manages. This turns out to be a major PAM blocker. Let's understand why that is.

The PAM Implication: Rotating Service Account's Password Without Visibility into its Activity can Break the Processes it Manages

The typical way service accounts connect to different machines to perform their task is with a script that contains the names of machines to connect to, the actual commands to execute on these machines, and most important – the service account's username and password that are used to authenticate to these machines. The clash with the PAM onboarding happens because while the PAM rotates the password of the service account inside the vault, there is no way to automatically update the hardcoded password in the script to match the new one the PAM has generated. So, in the first time the script will execute after the rotation, the service account will attempt to authenticate with the old password - which is no longer valid. The authentication will fail, and the task the service account was supposed to perform will never happen, breaking also any other processes or applications that rely on this task. The domino effect and potential damage are clear.

The PAM Service Accounts Catch: Caught in Between with Operational and Security Concerns

In fact, most identity teams will, considering this risk, avoid vaulting service accounts altogether. And that's exactly the impasse – vaulting service accounts creates an operational risk, while not vaulting them creates a no lesser security risk. Regretfully, until now there hasn't been an easy answer to this dilemma. This is why service accounts are such an inhibitor for PAM onboarding. The only way to satisfy both security and operational requirements is to launch a painstaking, manual effort of discovering all service accounts, the scripts that use them, and the tasks and applications they perform. This is a gargantuan mission and the main reason to the months and even years length of PAM onboarding process.

Overcoming the Challenge with Automated Service Accounts' Discovery and Activity Mapping

The root of the problem is the traditional lack of a utility that can easily filter out all service accounts and produce an output of their activities. This is the challenge Silverfort aims to simplify and solve.

Silverfort pioneers the first Unified Identity Protection Platform that natively integrates with Active Directory to monitor, analyze, and enforce an active access policy on all user accounts and resources in the AD environment. With this integration in place, AD forwards every incoming access attempt to Silverfort for risk analysis and awaits its verdict whether to grant access or deny it.

Leveraging this visibility and analysis of all authentications, Silverfort can easily detect all the accounts that feature the repetitive and deterministic behavior that characterizes service accounts. Silverfort produces a detailed list of all service accounts within the environment, including their privilege level, sources, destinations, and activity volume.

With that information available, identity teams can easily identify the dependencies and applications of each service account, locate the scripts that run it, and make an informed decision regarding the service accounts and choose one of the following:

• Place in the vault and rotate passwords: in that case, the newly gained visibility, makes it easy to perform the required adjustments in the respective scripts to ensure that the passwords they contain are updated in accord with the vault's password rotation.
• Place in vault without rotation and protect with a Silverfort policy: sometimes the usage volume of a service account would make the continuous update too hard to maintain. In that case, password rotation would be avoided. The identity team will use instead a Silverfort auto-generated policy to protect the service account, alerting or blocking its access when deviation from its normal behavior is detected.

In that manner, Silverfort shortens PAM onboarding process to mere weeks, making it an achievable task even for an environment with hundreds of service accounts.

Are you struggling with getting your PAM projects on track? Learn more about how Silverfort can help accelerate PAM projects here.