“It’s The Service Accounts, Stupid”: Why Do PAM Deployments Take (almost) Forever To Complete

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^[2].