Licensed for Distribution

This research note is restricted to the personal use of Zaqueu Cabral Pereira
([email protected]).

Guidance for Privileged Access Management

Published 28 February 2022 - ID G00754682 - 82 min read

By Homan Farahmand

Initiatives: Identity and Access Management for Technical Professionals

The privileged access threat landscape is growing with a higher risk of cyberattacks and
business consequences. Security and risk management technical professionals must
architect privileged access capabilities to avoid exploitation scenarios and resist advanced
persistent attacks.

Overview
Key Findings
Privileged access management (PAM) is a high-priority cyber defense capability. PAM
requires a comprehensive technical strategy based on a zero standing privilege (ZSP)
operating model. Key success factors include visibility and control of privileged accounts
across all assets.

Traditional PAM controls such as credential vaulting and session management are essential,
but not sufficient. Adopting just-in-time privilege approaches and managing machine
identities are imperative, while implementing privilege task automation and advanced
analytics are preferred.

Broader coverage of PAM controls for cloud platforms, DevOps, microservices, robotic
process automation (RPA) and operational technology scenarios requires robust secrets
management (with secretless brokering) and cloud infrastructure entitlement management
(CIEM).

PAM is applicable to all local and remote human-to-machine and machine-to-machine

privileged access scenarios. This makes PAM a critical infrastructure service due to risk
aggregation related to storing sensitive credentials/secrets as well as performing privileged
 operations in different systems. As such, PAM capabilities require thoughtful high-availability
and recovery mechanisms.

Recommendations
To deliver effective privileged identity and access management (IAM) capabilities, security and
risk management technical professionals should:

Develop a risk-based approach to plan and to implement or enhance PAM controls and their
breadth of coverage by creating a PAM control coverage matrix that aligns with the
organization’s cybersecurity framework.

Implement core PAM capabilities by deploying solutions that cover intended use cases while
driving a zero standing privilege operating model. That includes governance, discovery,
protection, monitoring, auditing, and just-in-time privilege elevation and delegation.

Implement additional PAM capabilities by extending the deployed solutions or integration

with other security management tools. That includes remote support, task automation
(especially in DevOps pipeline and infrastructure-as-code use cases), change management,
and vulnerability assessment and remediation, as well as secrets management, secretless
brokering, and cloud infrastructure entitlement management. Integrate PAM solutions with
security information and event management (SIEM) and IT service management (ITSM)
tools.

Architect resiliency for the PAM solution by using high-availability design and advanced
disaster recovery processes, such as a hot or cold site versus simple local backup and
recovery. Also, plan for recovery scenarios using reliable break-glass approaches.
Problem Statement
This guidance updates Guidance for Privileged Access Management, which was published on
17 September 2019. The key changes include:

Refreshing of the content based on the latest trends and research findings

Updating PAM tools categorization to:

Include cloud infrastructure entitlement management (CIEM)

Formalize remote privileged access management (RPAM)

Recognize the important of just-in-time privilege (JITP)

Extend secrets management with a secretless broker capability

Providing guidance on deployment model options (manual vs. light vs. full)

How to Use This Document

The sections in this document provide guidance to answer key questions as shown below:

What is privileged access and why is PAM so important?

See the Privileged Access Overview section.

What are PAM use cases and why is PAM so complex?

See the Determine PAM Use Cases section.

How do I assess the current PAM controls, coverage, operating model, and deployment
model?

See the Define PAM Requirements section.

How do I develop a PAM architecture strategy for core and advanced capabilities?

See the Develop PAM Architecture Strategy section.

How do I achieve PAM infrastructure resiliency?

See the Ensure Resilience section.

Privileged Access Overview

Privileged access bypasses standard controls to execute privileged operations that are above
those of a standard access. This usually puts the target system — or systems, such as
infrastructure as a service (IaaS) — at higher risk.

Privileged access happens when an entity (human or machine) uses an administrative account or
a credential with elevated rights to perform technical maintenance, changes, or address
emergency outages (privileged operations) in an IT or digital system. This can be either on-
premises or in the cloud. Privileges in this context are technical, which is different from high-risk
entitlements related to business processes. Privileged access management (PAM) controls
ensure authorized use of privileges (including any related mechanism such as privileged accounts
or credentials) in authorized target systems for all relevant use cases.

Privileged access risk centers on proliferation privileges (such as persistent privilege), potential
for human error in using privileges (such as administrator mistakes), and unauthorized privilege
elevation (techniques that attackers use to gain higher-level permissions on a system, platform
or environment). In most cases, attackers infiltrate and search a network within an on-premises
or cloud environment with unprivileged access to elevate their permissions to follow through on
their objectives. The most common approach is to take advantage of system weaknesses,
misconfigurations, and vulnerabilities. This allows an attacker to elevate their privileges by
accessing accounts such as system/root level, local administrator, user accounts with admin-
like access, or user accounts with access to specific systems or performing specific functions.
A more comprehensive list of privileged elevation tactics can be found in the MITRE ATT&CK
Privilege Escalation section.

Traditional PAM tools ensure that privileged users, applications and services get just enough
privileges (JEP), just in time (JIT), to reduce the access risk. This can happen through:

Appropriate session management (for human use cases)

Secretless brokers (for machine use cases), or

Elevation and delegation (for endpoint use cases)

PAM controls have recently been extended with advanced analytics tools, such as CIEM, for
managing privileges in the cloud (especially multicloud IaaS scenarios). This is increasingly
important, considering cloud infrastructure’s dynamic environment with high volume and
velocity of privileged access. CIEM tools monitor the cloud platforms continuously to identify
any misconfiguration that leads to excessive access, and deploy policy guardrails to remediate
unmitigated risks (Figure 1).

Figure 1. Overlaying Standard Access Controls With Privileged

Access Controls
PAM has evolved to become a core cyber defense capability to implement control that can be
deployed both on-premises and/or in the cloud for all computing environments. The key
benefits are:

Enhanced cyber defense: Compromised privileged credentials can be a primary attack vector
or a critical enabler for attackers seeking to move about in breached networks in a hunt for
valuable assets or launching a ransomware attack on endpoint devices.

Regulatory compliance and insurance: Regulatory bodies and auditors usually focus their
attention on the PAM controls that organizations implement to mitigate privileged access
risks. Failure to address these concerns can result in penalties and critical issues to
remediate. Also, cybersecurity insurers require PAM controls as part of their policy.

Business enablement: PAM tools enable change management in a safe, structured and
orderly manner. Organizations looking to become more agile (for example, using automated
DevOps pipelines) will appreciate the automated controls that PAM tools offer to secure and
minimize privileged access.
PAM should be prioritized as a cyber defense mechanism. It plays a key role in enabling zero trust
and defense-in-depth strategies that extend beyond mere compliance requirements. Some
organizations may choose to deploy a minimum set of PAM controls to meet their compliance
obligations in response to an audit finding. However, these organizations remain susceptible to
attack vectors such as service accounts, privilege escalation and lateral movements. Although
minimalistic controls are better than nothing, expanding the PAM control coverage can mitigate a
broader number of risks to defend against complex cyberattacks.

This guidance introduces an approach and underlying framework based on control and
coverage mapping to outline the overarching PAM requirements and architecture strategy.
The Gartner Approach
PAM Architecture Strategy Development
Technical professionals should develop or enhance their PAM architecture strategy in four
steps (see Figure 2).

Figure 2. Architecting Privileged Access Management for Cyber

Defense
-

These steps are:

Determine PAM use cases: First, define privileged access risk categories based on threat
intelligence and describe the relevant use cases that require protection of privileged
accounts and their credentials. These use cases usually include different scenarios for both
human and machine subjects. The common use cases cover administrative scenarios for
servers and endpoints, locally or remotely, internal or external, and either in data centers or
cloud environments. The use cases also consider all nonhuman scenarios for machine
identities in one system accessing other systems for connectivity (microservices) or
enabling automation (DevOps infrastructure as code). Cloud operations are also a key focus
for better visibility into infrastructure entitlements to ensure alignment with access control
policies.

Define PAM requirements: Identify privileged access risk, key controls, and their coverage
areas such as different platforms and computing environments. It also includes privileged
access availability and plans for recovery from accidents or disasters. It is important to
define the expected effectiveness of controls for each coverage area to determine practical
approaches to drive zero standing privileged access. That usually requires adjustment in the
 operating model to introduce user segmentation and adapting controls for each group, such
as general admin versus developers). Organizations should decide on their capabilities and
deployment model, using light or full-featured PAM tools; for example, using native platform
capabilities with extensive in-house customization versus using commercial off-the-shelf
(COTS) PAM tools. In the case of COTS PAM tools, the delivery model can be on-premises
using vendors’ software, in the cloud using an as-a-service platform or in a hybrid model.

Develop PAM architecture: Develop/enhance PAM controls as part of the target solution
architecture. The resulting solution includes the required core/advanced capabilities and
specifies which features and functions require integration with adjacent security or service
management tools. The architecture should be practical and feasible as part of the available
commercial tools, considering the variety of technical modules from one or multiple vendors.
This includes tools for privileged access session management, privilege elevation and
delegation, secrets management and secretless brokers for machine identities, remote
privileged access management, cloud infrastructure entitlement management, and just-in-
time privileged access tools.

Ensure resilience: Implement functions and features to simplify the deployment of the PAM
solution while ensuring availability, recoverability, performance and scalability.

PAM Tools and Delivery Model

PAM solutions automate privileged access controls and provide granular visibility into how
privileges are used in target coverage areas. PAM solutions can be implemented more
effectively using COTS tools. These technologies typically help organizations to:

Discover privileged accounts on systems, devices and applications

Control access to privileged accounts, including shared and emergency access accounts

Delegate, control and filter privileged operations that an administrator can execute

Manage credentials for administrative, service and application accounts

Ensure required levels of authentication and authorization for privileged access

Isolate, control, monitor, record and audit privileged access sessions, commands and actions

Eliminate hard-coded passwords and credentials by making them available just in time

Elevate privileged commands in operating systems on different platforms

Automate privileged tasks to hide privileged account credentials

Leverage analytics to identify and remediate privileged access vulnerabilities

Provide reporting and auditing for all privileged access use cases
Gartner maps PAM tools into six categories, as shown in Figure 3.

Figure 3. PAM Tool Categories

These categories have evolved as the predominant focus for technical professionals:

Core product categories:

Privileged account and session management (PASM): Privileged accounts are protected by
vaulting their credentials. Access to those accounts is then brokered for human users,
services and applications. Privileged session management (PSM) functions establish
sessions with possible credential injection and full session recording. Passwords and other
credentials for privileged accounts are actively managed, such as being changed at definable
intervals or on occurrence of specific events. PASM solutions can also manage (rotate)
credentials for service accounts.

Privilege elevation and delegation management (PEDM): Specific privileges are granted on
the managed system by host-based agents to logged-in users. PEDM tools provide host-
based command control (filtering) and privilege elevation for servers, the latter in the form of
allowing particular commands to be run with a higher level of privileges. PEDM tools must
execute on the actual operating system (kernel or process level). For UNIX/Linux PEDM tools,
 directory bridging functionality is often included to allow users to log into UNIX/Linux
systems with their Active Directory (AD) credentials.
Remote privileged access management (RPAM): External IT workers use their own endpoint
devices to identify and authenticate themselves remotely to gain (VPN-less) access to a PAM
gateway in the organization perimeter network. The gateway provides authorized access to a
PASM tool to perform privileged operations on target systems. Many PAM vendors have full-
featured remote privileged access tools (as an add-on or integrated into the main PAM
solution). Additionally, other vendors provide features, such as desktop sharing, credential
vault, self-administration and universal access methods for remote privileged access, even
though they do not provide the full capabilities of a PAM solution.

Adjacent product categories:

Secrets management: In this category, secrets (such as passwords, OAuth tokens, SSH keys,
certificates and other credentials) for software and machines are programmatically
managed, stored and retrieved through APIs and software development kits (SDKs). Trust is
established and brokered for the purpose of exchanging secrets and to manage
authorizations and related functions between different nonhuman entities such as machines,
containers, applications, services, scripts, processes and DevOps pipelines. Secrets
management is often used in dynamic and agile environments such as IaaS, platform as a
service (PaaS) and container management platforms. Secrets management products can
also provide application-to-application password management. Secrets management
capabilities can be extended with secretless broker functionality that manages authorization,
connectivity between machines, and injecting secrets to authenticate a machine to another
machine. Some secrets management tools have native secretless broker functionality and
some rely on other stand-alone tools.

Cloud infrastructure entitlement management: In this category, cloud access risks are
managed via admin-time controls to govern entitlements in (multi-) cloud infrastructure
environments (i.e., IaaS). Privileged entitlements define access to cloud resources, service
access privileges and cloud management permissions. CIEM tools use analytics, machine
learning (ML) and other methods to detect anomalies in account entitlements, like
accumulation of privileges, and dormant and unnecessary permissions. CIEM enables
enforcement and remediation of least-privilege approaches by recommending and deploying
policies. Most CIEM tools provide integrations with key IaaS platforms such as Amazon Web
Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure.

Pseudo category:

Just-in-time privilege: Administrators gain just-in-time privileges to perform privileged

operations through one or multiple mechanisms as built-in functionality of
PASM/PEDM/RPAM tools, native platforms tools, or as a stand-alone tool. The mechanisms
include the JIT dynamic group/role, membership/assignment, JIT token, or JIT session.
PAM solutions can be provided in multiple form factors, such as:

Software: Software package for on-premises deployment

Virtual appliance: Software package installed in a virtual appliance

Hardware: Software package installed in a hardware appliance

Cloud-hosted: Instance on cloud IaaS platforms

Service: Cloud-architected delivered from the cloud (single tenant or multitenant)

See the Magic Quadrant for Privileged Access Management and Critical Capabilities for
Privileged Access Management for an in-depth PAM market definition and vendors.
The Guidance Framework
Prework
The following sections discuss Gartner’s approach to develop PAM capabilities.

Determine PAM Use Cases

Privileged access is complex; it is delivered across numerous platforms and environments,
each with their own requirements and technologies. Figure 4 shows the key use case
categories and their underlying attack vectors.

Figure 4. Key Privileged Access Use Cases

These use cases are:

Administration (human-to-machine access): These use cases include administrative access

to servers and infrastructure components, local admin access to endpoint devices, and
remote access for external users. PASM, PEDM and RPAM tools (including their native JITP
features) provide solutions to address administration use cases. JITP stand-alone tools can
partially (depending on their coverage areas) address some of the administration
requirements.

Connectivity (machine-to-machine access): These use cases include operating system

managed service accounts, and embedded credentials for connectivity of applications to
databases or other applications and infrastructure services, as well as services and/or
microservices. PASM tools and legacy application-to-application password management
(AAPM) are typically used for on-premises use cases, and full-featured secrets management
solutions are used in the cloud.

Automation (machine-to-machine access): These use cases include embedded credentials

in scripts or DevOps pipelines to automate operational processes as well as shared
credentials that are used by software robots. Secrets management tools provide solutions to
address automation use cases to avoid embedding credentials in code.
 Cloud (infrastructure entitlements): These use cases include discovery and mitigation of
excessive access and permission misconfiguration in cloud infrastructure. CIEM tools
provide solutions to address IaaS use cases, while PaaS and SaaS use cases may require
more advanced features of secrets management, PASM and JITP tools (for example, using a
browser plug-in for SaaS applications). Some of the CIEM tool vendors are planning to
expand their coverage to PaaS and SaaS use cases.

Define PAM Requirements

General PAM requirements are shown in Table 1.

Table 1: General PAM Requirements

Requirements Controls Objectives by Design Approach

Governing Managing privilege This is usually done by IGA or ITSM

privileged assignment, periodically tools, but some stand-alone PAM
account reviewing and certifying tools offer partial functionality as
privileged access, and well. The key features include
ensuring segregation of privileged roles and policy
duties. management, access
request/approval, and privileges
review/certification.

Enabling Providing controlled access PAM controls should enable

privileged access to a resource without automatic session establishment
without any exposing the credentials, for human and machine use cases
credential because they could be used to a target resource, with credential
exposure to retain access or be shared injection to avoid exposing a
without permission. credential. Other examples include
federated authentication, short-lived
token or SSH certificate.

Enabling Controlling when users can PAM controls can elevate privilege
privileged execute tasks that require and delegate the access to execute
operation privileges above standard a particular command/program with
execution on users. elevated privileges.
endpoints or
servers
Managing Enabling machine accounts PAM controls should manage (e.g.,
credentials for to access internal or external rotate) all service account
machines (e.g., system resources. credentials and, in some cases,
service accounts) restart services as needed while
minimizing the impact on
dependent applications or services.

Removing hard- Enabling programs or PAM controls should provide an

coded services that need alternative to embedded static/stale
credentials in credentials to operate credentials, for example, through
code correctly when authenticating API calls or by securely injecting the
against other resources. credentials into the application, its
protected configuration files, or a
machine-to-machine session
through a secretless broker.

Enabling secure Ensuring proper PAM controls should provide a zero-

external users nonemployee access into the install access method that uses
remote access organization’s resources on a high-trust authentication and jump
temporary basis. servers that support a curated
access environment. Key features
should include external users’ life
cycle management and just-in-time
privileged access using robust
session management.

Linking change Allowing change control Change management and control

management approval for executing systems such as ITSM should be
with privileged privileged operations. linked to PAM systems so that
access approved changes will
automatically allow privileged
access for personnel to carry out
these approved changes.

Enabling Controlling approval before PAM controls should have an

workflow execution for exceptions. embedded (direct) or integrated
approvals for (indirect) workflow capability that
exceptions can track, report, and grant or deny
exceptional access approvals.
 Enabling Providing out-of-band access PAM controls should allow
emergency to systems during a crisis, preapproved users to access
privileged access whether the PAM system is credentials in an emergency (the
to resources and available or not. PAM system is available to release
break-glass emergency credentials when
procedures following normal operational
processes is not possible) or
following break-glass procedures
(the PAM system is unavailable).

Preventing Discovering privileged PAM controls must discover, enroll

unmanaged accounts in target systems and manage privileged accounts
privileged that are broadly distributed or and their credentials.
accounts have never been changed.

Managing Mitigating excessive access, PAM controls must discover

privileges in the orphan access (not used privileges in the cloud environment,
cloud anymore), or recommend policies, and deploy
environment misconfigurations. them in the cloud environments to
establish guardrails for privileged
access.

Reporting on Determining what a user did PAM controls should have the
privileged activity during a session. The ability to record video, keystroke
for audits and objective is to have a clear logs and application activity in a
compliance trail of any changes made reportable and indexed format for
and potentially provide an forensic analysis.
alert regarding any
inappropriate activity when
using privileged accounts.

Source: Gartner (February 2022)

These requirements can be further defined by:

PAM controls and coverage

PAM operating model

PAM deployment model

PAM Controls and Coverage

Technical professionals should:

1. Define key PAM controls in alignment with the organization’s cybersecurity framework

2. Define key PAM coverage areas to ensure that key controls can be adapted to each use case

3. Develop a PAM control coverage matrix for planning and prioritization

The control and coverage matrix will be a powerful tool to plan a two-dimensional roadmap for
maturing PAM controls and expanding their coverage overtime in a well-thought-out roadmap.

Figure 5 shows a sample PAM control coverage matrix for platforms and environments.
Technical professionals should review the effectiveness of capability and processes of each
control against each applicable coverage area to ensure acceptable management of privilege
access risk.

Figure 5. An Example of PAM Control Coverage Matrix

PAM Key Controls

PAM key control should be defined in alignment with the organization’s cybersecurity
framework.

Table 2 shows a simplified mapping of PAM controls and solutions to the National Institute of
Standards and Technology (NIST) Cybersecurity Framework 1 as an example.

Table 2: A Simplified PAM Control Map

Cybersecurity Function Definition Example PAM Example PAM

Control Solution
Function

Identify Develop the Privileged PASM:

(Risk) organizational access
Privileged access
understanding to governance and
request, workflow
manage administration
and approval
cybersecurity risk to
Privileged (native)
systems, assets, data
account
and capabilities. Account discovery
discovery and
(ad hoc and
onboarding
continuous)

IGA or ITSM
integration
Privileged access
request, workflow
and approval

CIEM:
Discover cloud
privilege
assignments
Protect Develop and Privileged PASM:
implement the credentials
Access control for
appropriate management
privileged
safeguards to ensure
Privileged accounts and their
delivery of critical
access for credentials
infrastructure
applications
services. Privileged task
and services
automation
Privilege
elevation and
PEDM (on local
delegation
systems)
management
Privilege elevation
Privileged task
and delegation for
automation
local admin
Integration with
adjacent
systems RPAM:
Remote admin
access for external
IT support staff

Secrets management:
Access control for
secrets

DevOps CI/CD
automation
Privileged task
automation
Secretless
brokering

Access management
and Light PASM:
Curated admin
environment for
jump servers,
including high-trust
authentication
Detect Develop and Privileged PASM and PEDM:
implement the session
Session recording,
appropriate activities management
privileged activity
to identify the
Privileged monitoring,
occurrence of a
access logging, reporting and
cybersecurity event.
reporting and auditing
auditing

CIEM:
Detect cloud
excessive privilege
vulnerabilities

Respond Develop and Privileged PASM and PEDM:

implement the access
Configuration to
appropriate activities analytics and
respond to events
to take action on a response
and alerts such as
detected
detecting
cybersecurity event.
abnormal activity
and raise alerts or
shut down access

CIEM:
Remediate cloud
excessive privilege
vulnerabilities

Recover Develop and Ease of Operating model

implement the deployment and
High availability
appropriate activities availability
to maintain plans for Disaster recovery
resilience and to Break glass
restore any
capabilities or
services that were
impaired due to a
cybersecurity event.

IGA = identity governance and administration; ITSM = IT service management; CI/CD = continuous
integration/continuous delivery
Source: Gartner (February 2022)

See the Develop PAM Architecture Strategy section for more detail on each PAM control, as
defined in Table 2.

PAM Coverage Areas

PAM coverage can become overwhelming when considering different design contexts that may
impact the architecture, underlying solutions and integration needs. Technical professionals
should particularly be careful when scoping PAM initiatives to ensure that the expected
coverage and outcome are achievable. One way to help with scoping is to consider different
layers of requirements, as shown in Figure 6.

Figure 6. PAM Layers of Requirements

Table 3 shows Gartner’s definition of the three contextual layers for PAM control coverage.

Table 3: PAM Coverage Layers

Coverage Layer Description Example

Credential state Credential at rest: A A good example is a product that

credential is at rest when uses a password (or secrets) vault.
it is stored in a repository. When privileged users want to use
PAM controls typically a privileged account for a
protect privileged privileged task, they gain access to
credentials at rest using a the credential. When the task is
credential vault. completed, access is removed
again. In most cases, the
credential is never exposed to the
user and/or it can be reset when
the vault is used in conjunction
with a privileged session
management tool.

Credential in motion: PAM controls typically

A credential is in protect privileged
motion when it is on credentials in motion
the wire, in memory or using encryption and
in a token. This state checksum validation such
can arguably include as injecting the credential
the authentication into an encrypted
process as well. session.

Credential in use: A PAM controls typically

credential is in use record the sessions or log
when it is being the events and operations
utilized in a session performed. PAM controls
or, in case of can also limit the use of
nonhuman accounts, credentials by controlling
an active API call. the lifetime of a session
(just-in-time privilege via
a token).
 Platform A privileged credential Examples are applications,
can belong to different databases, servers, endpoints,
platforms or systems. network devices, directories and
Covering a wide range of virtual machines.
technologies can become
particularly challenging
because PAM controls
must enroll and cover all
of these systems
operationally.

Environment Privileged credentials can Examples are on-premises data

be in different centers, cloud providers (IaaS,
environments. Each PaaS and SaaS), software-defined
environment has its own environments (network or data
unique characteristic and center), container orchestration
integration requirements such as Kubernetes, or DevOps
that may influence how tools.
PAM controls are
implemented.

Source: Gartner (February 2022)

In a larger organization with a more complex technology landscape, prioritization is key to cover
higher-risk platforms and environments, as well as low-hanging opportunities, to quickly reduce
the attack surface. Technical professionals may have to use multiple PAM tools with other
security measures such as network segmentation to protect critical systems and their
privileged accounts in different coverage areas.

PAM Controls Maturity

A maturity roadmap is a common strategy for setting expectations during the planning phase.
This can help with granular scoping of a deployment plan. Figure 7 shows a typical example of
a PAM maturity roadmap.

Figure 7. An Example of a PAM Maturity Roadmap

PAM Operating Model
This section discusses how the least privilege principle can be incorporated within the
operating model.

User Segmentation

Privileged access management operates based on enacting the least privilege principle. The
least privilege principle ensures that a user account is provisioned with minimum entitlements
that are essential to perform its intended function. The idea is to minimize the attack surface
related to privileged access and operations. However, the least privileged access may require
different treatment for different user groups.

Figure 8 shows an example of applying the least privilege principle to different user segments.

Figure 8. An Example of Applying Least Privilege for User

Segments
Technical professionals should use the least privilege principle to eliminate unnecessary
access for privileged users, including:

Removing personal administrative privileges from all user standard accounts where it is
practically possible.

Enabling just-enough privileged access for authorized users to perform their tasks by:

Reducing where administrators can go, to limit administrators’ access only to a small
number of necessary systems and applications.

Limiting what administrators can do, to limit administrators’ access only to necessary
operations and data.

Managing the exceptions that, for practical reasons, users or administrators may require
extra privileges to perform their tasks.

Zero Standing Privilege Model

Implementing a zero standing privilege model drives the least privilege principle through
temporary (instead of persistent) privileged access. This is typically implemented through JIT
privileged access. The traditional PAM practice has been all about discovering and vaulting
privileged accounts. However, even with all accounts identified and vaulted, the possibility of
compromise still exists. Although privileged accounts and their passwords are managed by the
PAM tool, they still exist. While risk of compromise in this model is minimal, it is still possible
due to the continued existence of a privileged account in the environment. In a ZSP/JIT model,
no privileged account exists and privileged access is only temporary and is assigned or created
and removed on demand through elevating normal accounts, through creating ephemeral
access, or by leveraging other JIT approaches.

Technical professionals in complex organizations usually find that a hybrid approach of

traditional PAM and JIT is the best approach for them, while a few may find a JIT-only approach
achievable. Gartner defines three foundational capabilities for capturing the key elements of a
modern JIT/ZSP approach:

JIT access request: There must be a set of processes and workflows that manage both
privilege access requests and fulfillments for an environment (including employees,
consultants, vendors and potentially software). For a JIT approach to be successful, some
elements of adaptive access or predefined approval policies should be applied to help reduce
complexity and friction. For example, risk scoring or predefined approvals can be used to
automatically approve access for a defined task in a defined window for a defined user
access request.

JIT access mechanism: There must be a mechanism to allow privileged task execution for a
normal (nonprivileged) user for a defined amount of time, on a defined resource (or set of
resources), for a defined set of tasks. Alternatively, the ability must exist to create one-time
(ephemeral) privileged access with certificates or other mechanisms that have the same
restrictions listed above.

JIT access monitoring: There must be an ability to record and monitor all activities
completed with the temporarily elevated access during the time of privileged access.

Using JIT helps get organizations closer to the goal of implementing the principle of least
privilege through eliminating or reducing standing privileges. Access is only granted for the
time needed, such as:

Implementing an approved change request

Responding to an outage, or troubleshooting

Fulfilling a help desk task to support a user

Regular maintenance

There are multiple mechanisms to implement JIT for privileged access. Many of these
approaches are complementary, and most organizations will choose at least two or three of
these approaches in combination:

Basic JIT:

Group membership: These groups grant access to administrative privileges. Users receive or
lose privileged access by virtue of the tool adding and removing them from that group.

Privilege elevation: A normal user is temporarily granted privileged access for a defined set
of tasks and for a defined period of time.

Dynamic access: providing time-limited access to privileged accounts.

Advanced JIT/ZSP:

Account creation and removal: This is automatic creation of a privileged account for a period
of time and for a specific task, and the account is deleted when the assigned task is
complete.

Enabled/disabled administrative accounts: Administrative accounts that exist in the network

or on devices — such as domain admin, local admin and root — can be enabled and disabled
to provide JIT access.

Security tokens: An ephemeral, one-time access account is created for a specific task,
device and person.

PAM Deployment Model

As shown in Figure 9, there are three deployment options in addition to the no PAM scenario:

Figure 9. PAM Deployment Model Risk

These options are:

Manual PAM: In this option, privileges are often assigned to user accounts or unmanaged
shared accounts. The PAM controls are either manual or built on native utilities in different
platforms and environments, possibly with some homegrown custom code. The coverage is
ad hoc and there is no systemic privileged access risk mitigation across the enterprise.
Organizations are seriously exposed to PAM borne cyber attacks through a wide attack
surface.

Light PAM: In this option, organizations leverage purpose-built point solutions that offer
some PAM controls for some use cases. Examples are JITP tools offered as stand-alone
solutions or as part of the operating systems or cloud platforms. In some cases, privileges
are assigned just-in-time. However, in most cases, the privileges are still assigned to user
accounts or unmanaged shared accounts. The PAM controls are applied inconsistently either
manually or built on native utilities in different platforms and environments, possibly with
some homegrown custom code. The coverage is broader but still ad hoc and there is no
systemic privileged access risk mitigation across the enterprise. Organizations are still
exposed to PAM borne cyber attacks but with a reduced attack surface.

Complete PAM: In this option, privileges are mostly assigned to managed shared accounts.
The PAM controls are built using capabilities in COTS PAM tools. The coverage expands
 following a well thought out roadmap to implement systemic privileged access risk
mitigation across the enterprise. Organizations are much less exposed to PAM borne cyber
attacks through a smaller known attack surface and possibly zero-day vulnerabilities.

Technical professionals should evaluate the residual risk associated with each option carefully
to understand consequences and consider compensating risk mitigation strategies in case of
manual and light PAM deployment. It is not practical to short-cut implementing PAM controls.

Develop PAM Architecture Strategy

This section describes PAM capabilities which are grouped into core and advanced.

For a more comprehensive list of each capability’s requirements, see Evaluation Criteria for
Privileged Access Management.

Core PAM Capabilities

The core PAM capabilities establish the foundational PAM controls, including:

Governance and administration

Discovery and onboarding

Credential management

Session management

Elevation and delegation management

Logging, reporting and audit

Privileged Access Governance and Administration

This capability provides features and functions to formally manage privilege assignment,
periodically review and certify privileged access, and ensure segregation of duties based on a
set of policies. It is important to note that privileged access provisioning or deprovisioning is
not a core PAM solution capability. Therefore, privileged access assignment may require
integration with other tools to perform governance and administrative tasks either for
persistent or temporary privilege assignment.

Example architecture approaches are:

PAM and IGA integration

PAM and ITSM integration

PAM and IGA Integration

Technical professionals can consider bidirectional integration (for example, using REST API)
between PAM and IGA capabilities, typically for persistent privilege assignment. In this case,
the PAM system is a target system for the IGA system.

An IGA system provision users in the PAM system with appropriate admin-time authorization.
When integrated, the IGA tool governs the user and administrator identity life cycle. However,
PAM tools control administrators’ access to privileged accounts. PAM tools can also inform
IGA tools which accounts and/or entitlements are privileged and which accounts are
application or service accounts. Usually, no person should have privileges on a standing basis
unless there is a very rare exception. Bidirectional integration provides greater visibility into and
control over privileged accounts in their environment. This control can help the IGA system to
manage the segregation of duties (SoD) for administrative access use cases in some of the
systems. This type of integration is possible in most PAM and IGA tools (see Figure 10).

Figure 10. Example PAM and IGA Integration

The key advantages of this model include:

Integrating identity life cycle management with privileged controls: This is to ensure
consistent, policy-based privileged access management and decisions. For example,
different identity life cycles exist for employees, contractors, or third-party technicians or
 vendors that may only require one-off access, and these life cycles are best managed with an
IGA tool.
Establishing risk-ranked privilege/entitlement data in an entitlement catalog: The
entitlement catalog stores entitlement risk scores that can be reflected in privileged account
risk scoring. An example is to integrate a PAM tool with entitlements and entitlement
metadata in the IGA entitlement catalog. This provides a more holistic risk evaluation and
allows privileged accounts to be included in the IGA access request and approval process. A
benefit is avoidance of segregation-of-duties violations.

PAM and ITSM Integration

Technical professionals can consider bidirectional integration (for example, using REST API)
between PAM and ITSM capabilities, typically for just-in-time privilege access that is requested
by an administrator or a change request. Some PAM tools implement workflow features for
administrative users to request access, and for authorized approvers to grant this access
through service desk and ticketing tool integration. Service desk tickets usually contain change
control authorizations or incident reports that document outages or anomalies that need to be
rectified. Most products integrate with some ITSM systems out of the box and/or provide APIs
to validate administrative access requests by cross-checking between systems (Figure 11).

Figure 11. Example PAM and ITSM Integration

Privileged Account Discovery and Onboarding

This capability provides features and functions to identify and onboard privileged accounts and
related credentials in all platforms and environments, including scanning of the environment on
an ad hoc basis or continuously. Identifying and onboarding all privileged accounts and related
credentials in all platforms and environments are critical for enabling PAM controls. However,
this is a major challenge because it is easy for privileged or default system accounts to be
forgotten and left out — especially when they are not standard operating system accounts
(such as internal accounts in databases or applications). This can be exacerbated by adopting
more platforms and deployment environments such as virtualized platforms, containers and
software-defined infrastructure, DevOps and cloud services.

In such a dynamic environment, systems and accounts can be easily created or destroyed
before enrollment in PAM controls. The correct “fix” would be to create processes that include
PAM in the life cycle of every privileged account (i.e., as soon as a privileged account is created,
it is onboarded). However, at the same time, a PAM solution must be aware of the current state
and see whether any account fell through the cracks. Therefore, PAM solutions should enable
scanning of the environment — ideally continuously, but if that is impossible, then at least on a
recurring ad hoc basis — to discover privileged accounts and/or credentials and onboard them
to enforce PAM controls.

Organizations must first scan the system registries in the network and associated platforms
(such as in Active Directory [AD], configuration management database [CMDB], network
management systems [NMS], key management systems [KMS], Kubernetes, DevOps, etc.) to
identify privileged account and their credentials. However, not all privileged accounts can be
discovered through PAM tools’ discovery features. Organizations may need custom built or
manual means (for example, conversations with developer and other infrastructure teams on
how they use privileged accounts) to discover remaining privileged accounts. Using PAM tools
discovery is a good starting point which can be done both in ad hoc and concurrent mode:

On-demand: This approach requires running a separate task to scan the system registries in
the network and associated platforms to run an as-is analysis of the current environment.
The result is compared with the last known state to find changes. Most PAM tools follow this
autodiscovery approach, typically using a separate, external product to perform discovery.
The results may have to be manually imported and mapped to systems and accounts,
pending review and onboard, based on various policies.

Continuous: This approach works on a continuous basis where changes in systems registry
master data or other authoritative sources are detected as they happen and can trigger
automatic enrollment workflows within the PAM solution.

Privileged Credential Management

Privileged credentials management provides core features and functions to manage and
protect system- and enterprise-defined shared account credentials or secrets. These include
generation, vaulting, retrieval and rotation for interactive access to these credentials by
individuals, as well as brokering access to these credentials for application and service
connectivity.

Privileged credential protection is at the heart of PAM and ensures people and nonhuman
privileged users have access to systems without exposing credentials. These controls usually
reset credentials based on an established policy after each disclosure (assuming they are
disclosed and not injected, which would avoid disclosure) or periodically. People access is usually
interactive while nonhuman users have programmatic access to credentials.

Access Control for Shared Functional Accounts

PAM solutions should include a credential management system that uses a credential vault,
proxy or jump server, and session reporting and audit components. Sessions are established
with credential injection, avoiding disclosure of passwords (except in rare circumstances when
the credential really must be revealed). Figure 12 shows the common PAM solution architecture
approach for protecting shared accounts.

Figure 12. PAM Solution Architecture for Shared Functional

Accounts

The flow includes:

1. A user authenticates to the privileged account management server via the PAM login
interface. For a user to check out a privileged account, the user must first be authenticated
using a high-trust authentication mechanism (typically multifactor authentication [MFA]).
Afterward, the PAM server determines whether the user is authorized to check out an
account and determines which accounts are available to the user to check out:

The PAM server authenticates the user to the organization’s access management systems
with the provided user credentials (or using a federated single sign-on token). In most
cases, the PAM server can then leverage information about the user’s corporate identity to
determine which privileged accounts the user is authorized to use.

The PAM server then conducts MFA using the organization’s access management or
stand-alone MFA capability to ensure that only appropriate personnel are allowed to check
out the privileged accounts.

2. The PAM server authorizes the user. Once the user has been authenticated, information
about the user can be used to help determine which accounts the user is authorized to check
out. (For example, this may be an open change ticket attributed to the user and/or specific
attributes or group memberships of the user.) The information can also be used to determine
the granularity of the operations that the user can perform with these accounts.

3. The user checks out the privileged account from the password vault. The user selects the
account that is to be checked out, and the PAM server retrieves the password, along with any
other contextual information for that account from the secure password vault. During the
check-out process, the user making the request is often also prompted to document the
reason for checking out the privileged account. The PAM server opens a session for the user
to the application or resource as the privileged account and injects the credential without
revealing it to the user. Sometimes the PAM server cannot open the session for the user, and
the current password for the privileged account may be revealed. For example, a target
resource doesn’t support this kind of remote administrative access, password may need to
be used for interactive login on a console. In this case, the PAM server does not control the
session, so command filtering is not possible, and the user interacts directly with the
resource. Because the password has been revealed in this scenario, the PAM server will need
to change the password for the privileged account on that resource after the user either
closes the job on the PAM server. or when the PAM server “times out” and changes the
password automatically.

4. The session generally has a predetermined time to live, but the session can also be
terminated by the user when finished. Some PAM solutions support command filtering
during the session, only authorizing the use of specific operations during the privileged
session based on the authorization decisions made in Step 2.

5. When the PAM server controls the session, it records all activity during the session and
generates audit logs and reports. The events (such as who accessed the account and when),
 as well as all keystrokes or session I/O during the session, are logged, capturing all activity
that was performed with the privileged account during that session. Many PAM servers
support video playback of the session (or text input/output for SSH or screenshots). This
makes it easy to watch what transpired (see the Privileged Session Management section
and the Privileged Access Logging, Reporting and Auditing section for more details).

6. The PAM server closes the session. If the password has been revealed to the user in Step 3,
the PAM server generates a new randomized password or a new set of credentials for the
privileged account and resets them on the corresponding resource. It also stores the new
password in the secure password vault.

Privileged Session Management

This capability manages a privileged user session (in addition to credential management) for
human interaction sessions from initial authentication through termination of the session. It
provides core features and functions to isolate, monitor and record privileged sessions. In
some cases, it can ensure that users execute authorized operations in authorized systems. It
includes session recording/replay, real-time monitoring, protocol-based command filtering and
session separation. This is particularly important when there are strict requirements for
accessing a system or when third parties need access to critical systems.

PAM solutions should include:

Session recording: This is for auditing and forensic analysis. Typical features can range from
a simple searchable key or input/output (I/O) logging for text-based sessions (such as SSH)
to “over the shoulder” video recording of graphical sessions. For the latter, most tools provide
efficient compression, but real differentiators are found in the session playback functionality.
The most basic tools usually support only a 1:1 playback of the entire session. Other tools
will take regular screenshots of a session periodically. More advanced playback features
allow automatic skipping forward and backward, based on user activity. When protocols
such as Remote Desktop Protocol (RDP) are used, some tools can gather additional
searchable metadata events, such as applications executed, windows opened and text typed.
For SSH, many tools store input and output streams. Some vendors are now supporting full
optical character recognition (OCR), scanning entire graphical sessions with extensive
protocol support, and indexing for ease of discovery.

Real-time monitoring: This is for dual control or “four eyes” principle/session shadowing. In
addition to session recording, some tools support session monitoring and alerting in real
time. This allows for live monitoring of privileged sessions by administrators or managers,
who can intervene or even terminate the session if necessary. Some tools can generate
alerts or notifications when suspicious behavior is detected. These can be sent to a security
information and event management system, or supervisors can be alerted.
 Protocol-based command filtering for sessions: This is either to restrict what an
administrator can do or to raise an alert on suspicious or dangerous activity. Some vendors
tout this feature as being equivalent to privilege elevation and delegation management.
However, protocol-based command filtering tends to be less effective, especially when shell-
level operating system access allows an experienced administrator many different ways to
obfuscate and find a way around specific filtering.

Application session separation: This is for launching interactive local applications (mostly
Windows-based) in a remote, contained environment (such as a terminal server), rather than
permitting administrators to run them on potentially compromised endpoints. The additional
advantage is that this approach can prevent data leakage. For example, rather than giving
administrators direct access to a database through a database administrator account, they
would need to use a database administration tool on a terminal server. If these
administrators download data to a file, this file would only be stored locally on the terminal
server environment; any files transferred in or out of this environment must be tightly
controlled.

The architecture approaches are:

Implementation using proxy or jump server: In this approach, all traffic passes through one
or more control points for session management and recording. Users transparently log on to
target systems. Users connect to remote target applications and systems through this proxy
server, either via a web portal or by using standard RDP client applications to connect directly
from their desktop to the proxy. The privilege session monitoring proxy server isolates all
privileged sessions to remote machines. It can record all the activities that occur during a
privileged session and store them in the tamper-proof vault for monitoring and auditing. The
proxy server creates a single point of control for all privileged session activity that cannot be
bypassed. The proxy server can also be used for SSH command allow-listing or block-listing.
This gives technical professionals the ability to block unauthorized SSH commands when a
privileged user attempts to execute them on a target system. Auditors and security teams
can track privileged sessions through a unique interface and view recordings according to
authorizations.

Implementation using direct connections: In this approach, there is a direct connection from
the administrator’s workstation to the target systems, and credentials are injected into the
session on the workstation by using a local control. Recording then happens on the
administrator’s workstation and is forwarded to a collector (usually a locally installed agent
or a browser-based control). This can be beneficial in the case where a system is accessed
at a remote location that has very limited bandwidth. However, one major disadvantage is
that the approach in most cases relies on trust and integrity in the administrator’s
workstation in order to rule out that a compromised workstation will ultimately compromise
session control and recording. Achieving this level of assurance on third-party-owned
 workstations, compared with workstations operating internally, presents new challenges that
must be accounted for.

Privilege Elevation and Delegation Management

Privilege elevation and delegation management provides functions and features for enforcing
policies to allow authorized commands or applications to run under elevated privileges.
Administrators will log in using an unprivileged account and elevate the privilege as needed.
Any command that needs additional privilege would have to pass through those tools, in effect
preventing administrators from carrying out unsafe activities. The requirements and level of
support may vary by platform (such as Windows, UNIX/Linux or Mac). This is particularly
important for endpoint devices where technical professionals need to not only limit
administrative access for common users, but also allow those users to perform certain tasks
on a case-by-case basis. These controls usually require kernel access or integration with shell
and other commands to control access to system calls from user/application spaces.

PAM solutions should:

Elevate individual commands to allow authorized privileged execution, but not give access to
an unrestricted privileged session.

Monitor and record privileged activity centrally or on the systems, either upon login or during
execution of privileged commands.

The key components for elevating and delegating privilege are (see Figure 13):

Agent: An agent must be installed on all endpoints. The agent is the conduit between the
endpoint and the policy management service. Policies are distributed to and enforced by the
policy agent.

Policy management service: Various policy editing and policy management tools can be
used to control applications and modify privileges of applications using rules. Most vendors
support some combination of:

Microsoft Group Policy Object (GPO) extension: This is integrated directly into the Active
Directory (AD) structure without modifying the existing schema. This is only applicable for
Windows, or perhaps for UNIX as long as AD bridging is in place.

Server-based policy management: This is a central, server-based policy management

engine. The agents pull policy directly from the service.

Cloud-based policy management service: This is a central, cloud-hosted policy

management engine. The agents pull policy directly from the service.

McAfee ePolicy Orchestrator (McAfee ePO): This McAfee ePO extension allows policies
and events to be stored in the McAfee ePO framework.
Figure 13. Privilege Elevation and Delegation

The architecture approach may vary by platform. For example:

On Windows systems, control agents are kernel-based. Apart from being able to tightly
control who can run which privileged commands, the underlying tools are also an important
level of protection from pass-the-hash attacks. Windows tools that enforce privilege
elevation and delegation are deployed to establish PAM controls not only for system
administrators, but also for least privilege enforcement and application control such as
allow-listing.

On UNIX and Linux systems, controls usually integrate at the command level by shipping
replacements of shell, common commands and/or sudo to prevent shell escapes. Some
vendors, such as Broadcom (CA Technologies), offer kernel-based privilege elevation and
delegation tools for UNIX and Linux as an additional option. Others can filter system calls by
preloading shared libraries. Some vendors ship a replacement or extension to the popular
UNIX “sudo” command. These tools are often combined with, or include, Active Directory
bridging tools that allow authorized users to log in to UNIX and Linux systems by using their
Windows domain account.

Privileged Access Logging, Reporting and Auditing

Privileged credential protection and session monitoring mitigate privileged attack vector risks.
This capability records all single events, including changes and operations, as part of the PAM
operation. A single event is based on user, time, date and location, and is processed with other
events via correlation in a logical order. This is to monitor and determine the root cause of risk
events and to identify unauthorized access. However, it is also necessary to document
regulatory compliance for auditors, and identify intentional or unintentional actions that could
lead to a data breach. Therefore, privileged access logging and audit capabilities are important
in order to record all single events, including changes and operations, as part of the PAM
operation.

PAM solutions should include:

Logging:

Key infrastructure components that can affect the PAM tools runtime environment (for
example, AD)

Key applications/databases that could be used by a threat actor for surveillance or for the
exfiltration of data (for example, PAM server database)

Monitoring:

Key platforms to identify unauthorized privileged changes to sensitive resources such as

installing an SSH public key in the allowed keys file to bypass an existing PAM control

Logs for critical events that could indicate potential abuse of privileges

A typical architecture approach includes bidirectional integration with security information and
event management tools:

PAM-to-SIEM integration flow: Any and all activities that occur within the PAM controls —
such as user access to credentials, credential rotation, privileged commands or application
access — can be forwarded to SIEM solutions via log feeds. This enables security operations
center teams to gain greater insight into the privileged environment and to develop their own
alerts and reporting.

SIEM-to-PAM integration flow: Privileged access analytics capabilities can consume log
feeds from SIEM platforms to develop baselines for normal user activity and to alert on
anomalous privileged access.

Advanced PAM Capabilities

The advanced PAM capabilities expand the foundational controls to cover more use cases,
including:

Remote privileged access

Privileged access for applications and services

Cloud infrastructure entitlements management

 Privileged task automation

Privileged access analytics and response

Robotic process automation

Operational technology and industrial control systems

Remote Privileged Access

Remote privileged access provides zero trust access to external privileged users such as
vendors and professionals who provide support and/or perform administrative functions. This
is particularly important to prevent external users from sharing accounts and to ensure that
they identify themselves before accessing high-risk systems to perform privileged operations in
any system. The preference is to use VPN-less solutions without the need to install any agents.
External users should use strong authentication and be individually authorized based on their
entitlements. Some remote PAM tools may provide additional features, such as vendor identity
management and delegation, which enhances accountability in the process.

The architecture typically includes (see Figure 14):

A mobile application to authenticate users

A cloud service to configure and manage sites, tenants, vendors and users

An HTML5 gateway that is deployed in DMZ of a site to facilitate access to the PAM solution

A connector to enable integration of the cloud service to the gateway

Figure 14. Remote Privileged Access

Privileged Access for Applications and Services

This capability manages privileged access for machine use cases such as applications,
services, microservices, scripts, processes and DevOps pipelines in on-premises and cloud
environments.

Privileged access for applications and services includes key features such as:

Identifying and providing a credential to machine entities (such as via API)

Authenticating machine entities to other systems or services directly or via a broker

Authorizing the connection and injecting the required credentials

PAM solutions may have different modules for on-premises and cloud use cases. The two
common patterns are:

Application-to-application password management (AAPM)

Secrets management with secretless broker

Application-to-Application Password Management

Application-to-application password management (AAPM) allows an application or service to

retrieve the credentials or password from a vault through an API. It also allows elimination of
hard-coded and unencrypted credentials stored in the file system directly in a script or program.
AAPM presents a more secure form of delivering credentials to traditional on-premises
applications or scripts, when no other mechanisms exist to safeguard locally stored credentials,
at the cost of modifying the application. The modification is usually simple. However, testing
must happen for every application modified, which places a burden on developers.

The architecture approaches are:

Agent-based

Agentless

Agent-Based AAPM

An AAPM agent is installed on local systems and allows applications to access credentials by
using host-based access control mechanisms. AAPM tools are agents that allow applications
or scripts to gain access to application credentials through proprietary software development
kits (SDKs) and command line interfaces (CLIs). These tools are available as additional
modules to PASM solutions and, in some cases, are even available stand-alone, although
sometimes these modules are already included in the license of the base product at no
additional charge. AAPM agent-based tools usually provide a caching function that is kept in
sync with the main password vault. They can also implement local access controls for
applications that fetch credentials, such as application fingerprinting, environment verification
or one-time password.

Agentless AAPM

An agentless AAPM enables applications to call the API when needed to retrieve current
credential information programmatically (see Figure 15). An alternative to AAPM is to use a
“pull” mechanism where applications call an API when needed to retrieve current credential
information programmatically from the vault. This usually happens over an encrypted
connection to the credential vault in the PAM solution. The API and supporting SDK is typically
provided in multiple formats, including web services provided as SOAP/Web Services
Description Language (WSDL) and REST/JavaScript Object Notation (JSON), as well as
PowerShell. They run only when needed to enable client access. They usually support public-
key infrastructure (PKI), integrated authentication and other methods to operate with common
authentication environments, extensible programs or languages. However, care must be taken
to secure the communication between the application and the vault. Using cleartext credentials
to secure the authentication to the vault is not an option here, because this would violate the
principle of eliminating cleartext credentials.

The SDK and orchestration APIs can also enable newly deployed, as well as remote and offline,
systems running applications to register programmatically with the PAM solution’s vault. This
enables users to enforce password security policies immediately upon deployment of new
systems. The PAM solution centrally and continuously secures embedded passwords in web
application tiers, packaged software programs, line-of-business applications, custom programs
and more. It automatically changes embedded passwords according to rules that users define
for complexity and change frequency. It then synchronizes the changes across interdependent
tiers to prevent lockouts and service disruptions.

Figure 15. API Call to Retrieve Credentials From the PAM Solution

The flow includes:

1. The application programmatically makes a request to the PAM server to check out a
privileged service account. Applications often need to identify/authenticate themselves in
order to obtain access to data or to perform automated operations. By using the PAM server
and checking out the service account’s credentials, the application doesn’t need to have any
knowledge of the credentials beforehand. The application instead makes an API call to the
PAM server, identifying itself and requesting the required service account credentials.

2. The PAM server authorizes the application. The PAM system checks the API check-out
request and validates the application against the list of preregistered applications.

3. The PAM server determines which account the requesting application is authorized to use
and retrieves the necessary account information (including credentials) from the secure
password vault.

4. The PAM server returns the checked-out account credentials via the API. In response to the
application’s API request, the PAM server returns the retrieved service account’s credentials
 to the application. In some cases, the PAM server opens up the privileged session for the
application that has a time to live before the PAM server changes the password (or other
authentication credentials) for the privileged service account.
5. The application authenticates to the authentication directory (directly or indirectly) using the
checked-out credentials.

6. The PAM server creates a log entry. Events such as which application requested the check-
out of the service account, when the request was made and when the service account
password was reset are logged and reported.

7. The PAM server can reset the password at certain intervals, or upon demand if required. It
would then store the new password in the secure password vault, where it can only be
retrieved by an authorized check-out request.

Secrets Management With Secretless Broker

Secrets management has emerged as a set of practices and associated tooling to automate
secure creation, storage, retrieval and revocation of the secrets necessary in privileged access
and operations. This is common in multiple use cases such as cloud services, container and
software-defined anything, and DevOps pipelines. The term “secret” is used broadly to refer to a
variety of data types, including machine accounts and their credentials (including passwords,
one-time passwords, authentication tokens, private-key portions of certificates used in TLS
encryption and key material for symmetric encryption). Specifically, in the area of modern
application development and architecture (such as service mesh using microservices), secrets
management provides functionality to avoid embedding or hard-coding secrets data into source
code, build scripts, infrastructure as code and so on.

Secrets management functions can dynamically allocate whatever secret is necessary for a
given application, service or workload (such as a container or a Kubernetes cluster) to
instantiate and operate. Secrets management also provides the ability to periodically rotate or
revoke secrets. This capability reduces the potential risk of an attacker compromising longer-
living or obsoleted secrets or workloads to initiate an attack.

PAM solutions should have functions and features to support secrets management as part of
privileged access for applications and services and as part of task automation. This includes:

Cryptographically secure vaults. Tools may also support integration with hardware security
modules (HSMs) for higher security.

CLIs and GUIs to interface with vaults interactively, such as for administration purposes.

REST APIs to integrate disparate metadata formats, application platforms and native
authentication mechanisms. These APIs are particularly useful in hybrid or multicloud
scenarios.
 SDKs for inclusion in application source code to enable secrets management client
capabilities in custom applications.

Tooling to support the practice of secrets management can be found in a variety of forms,
including:

Cloud- and platform-agnostic offerings that interoperate with disparate technology stacks

Cloud provider implementations backed by cloud-hosted key management services (KMS)

The core secrets management functions can be extended with a secretless broker component
to simplify the integration mechanism. A secretless broker reduces the burden of changing
application code to make API calls to the PAM solution to retrieve the credential. Instead, the
application is pointed to the broker. The broker authorizes the access and retrieves/injects the
credential, similar to the session management capability, but for machine-to-machine access
(see Figure 16).

Figure 16. Using Secrets Manager With Secretless Broker

Some of the key use cases for secrets management and secretless brokers are:

Microservices workloads: Microservices workloads and automation using infrastructure-as-

code are now common. In all these use cases, privileged credentials will be needed for
connectivity and automation in container orchestration platforms such as Kubernetes to
identify workloads and authenticate them to other enabling systems.

DevOps pipelines: DevOps is the new normal for application development as well as
infrastructure and operations management and automation. CI/CD pipelines should be
secured by ensuring identification and authentication of each machine (applications,
services, workloads, software robots and so on).

In all cases, machines of any type require identification (machine identity), secrets (credentials)
and a policy (authorization) to connect and perform their intended functions. The key
challenges represent both microservices workloads and DevOps pipelines are:

Instances of hard-coded credentials

Credentials appearing in source code repositories

No credential rotation or highly fragmented approaches to credential vaulting

Technical professionals need to securely provide credentials in these scenarios using secrets
management and secretless brokers by doing the following:

Assigning unique identity to machines with automated life cycle management, including a
registration/decommissioning process to track, audit and control access to credentials. An
emerging framework is the Secure Production Identity Framework for Everyone (SPIFFE),
which enables secure microservices communication, machine authentication, and service
mesh extension and integration.

Replacing hard-coded credentials with API calls to a secrets management or point to a

secretless broker that authorizes and injects credentials at runtime where connection is
made.

See the following reports for more details:

Managing Machine Identities, Secrets, Keys and Certificates

Building Identity Into a Microservices Architecture

Cloud Infrastructure Entitlements Management

This capability provides entitlement management for cloud infrastructure services. Securing
privileged access (that is, following the “least privilege” principle) is a top concern for any
organization adopting cloud technologies. To help address the technology requirements, cloud
service providers and third-party PAM providers have started to address a broader range of
dynamic, ephemerous and very granular access definitions used by cloud service providers. In
an IaaS environment, privileged entitlements and operations can be divided into three logical
categories (see Figure 17).

Figure 17. Cloud Infrastructure Entitlements

These categories are:

Resource entitlements: This refers to permissions for accessing resources within a cloud
platform such as files, databases and workloads, including servers, containers and
serverless infrastructure. Each of these resources is accessed by either human or nonhuman
users to perform administrative functions. Entitlements define the actual functions, such as
reading or writing to a database or configuring compute resources. A privileged user with
resource-level entitlements may be able to configure an operating system environment,
manipulate a database table and configure network settings.

Service entitlements: These entitlements define privileges for cloud services or workloads,
including virtualization, storage, database and network services running as a service in the
cloud infrastructure environment. A privileged user with service-level entitlements may be
 able to start or stop a compute instance, create or clone database instances, and manipulate
PaaS functions such as graph or relational database services or load balancers.
Management entitlements: These entitlements define the permissions for controlling top-
level cloud accounts, management console for administration and user management tasks.
A privileged user with management-level entitlements may be able to manage security
settings, manage billing, and create other administrative accounts and top-level roles and
groups.

The wide range of privileges of these entitlement categories create unique challenges in
managing and protecting cloud infrastructure, such as:

Privileged accounts have long-standing privileges: Organizations are still using traditional
identity management techniques to secure privileged access through the use of static and
long-standing privileged accounts.

Difficulty monitoring and preventing misuse: Each cloud infrastructure has its own tools,
which makes monitoring account and entitlement usage across clouds difficult to analyze.
Furthermore, it is hard to detect, especially across cloud infrastructure, whether use is
appropriate or whether entitlements are being misused or not being used at all. Also, despite
the ability to create unique accounts, generic accounts and secrets are created and shared
across individuals, with the inability to establish accountability and proper audit trail of
privileged operations tied to an individual.

Limited visibility, governance, compliance and oversight: It is difficult to have a consistent,

comprehensive view of all access across all environments, including the ability to accurately
assess risk. Also, it is hard to demonstrate compliance to regulatory requirements and cloud
platform security best practices.

Excessive and broad-reaching access: Static accounts, roles and associated entitlements
are often more than what is actually required to perform a particular function. These
accounts and privileges increase the attack surface and increase the chances of misuse.
This is further exacerbated by the cloud, as potentially thousands of services can be
affected. For example, developers in early stages of the CI/CD pipeline typically use powerful
and overprivileged permissions for building cloud applications. This is because it’s practically
impossible to define IAM roles in a granular way given the construct of APIs provided by
cloud service providers (CSPs). One CSP management API may give access to other
different APIs that are not visible to the security administrator.

Inconsistently defined policies across cloud infrastructure: To further complicate the issue,
each cloud service platform has a different entitlement taxonomy (for example, AWS roles
are different from Azure roles). This makes it impossible to use native CSP tools to define
consistent policies across multiple cloud platforms.

Ephemeral cloud infrastructure entitlements increase complexity: Given the dynamic nature
of the cloud, entitlement assignments are more ephemeral, which further blurs the lines
 between managing assignment of privileged entitlements with PAM and IGA tools. In some
PAM tools, assignment of privileges occurs at the time of access (“just in time”), rather than
assigned during admin time using IGA tools. This is also because applications, server
credentials or even IAM roles are referred to as “identities.” Nonhuman machine identities are
much more common but ephemeral and hard to maintain in the cloud.

CIEM tools provide the key functions to address these challenges. The typical cloud
infrastructure entitlement remediation flow is shown in Figure 18.

Figure 18. Cloud Infrastructure Entitlements Remediation Flow

CIEM’s key features and functions include:

Accounts and entitlements discovery: Organizations must first have an accurate inventory of
their identities and entitlements across their cloud infrastructure. The following features are
essential in addressing discovery within cloud infrastructure:

Continuous discovery: Given that accounts and entitlements can be defined and
generated from multiple sources, dynamic discovery is essential. Discovery should be not
only time-based, but also, more importantly, event-based. Dynamic discovery in cloud
platforms is achieved through APIs and webhooks from cloud event and monitoring
services (such as AWS CloudTrail, Azure Log Analytics and GCP’s Cloud Audit Logs). Also,
accounts are not only defined within the CSP, but also by identity providers that may have
 unique access policies. Identities are also stored in traditional directories, such as AD, or in
cloud directories.
Encompassing all identity types: In cloud environments, human and, increasingly,
nonhuman entities require access to infrastructure services. This includes service and
application identities, software robots, DevOps tools and other infrastructure services
(such as containers, storage buckets and virtual network services) that must be identified
and tracked.

Analyzing all access policies: Policies may be directly attached to users, groups and roles,
and to cloud infrastructure resources. Discovery should also include analysis and traversal
of the entire permissions structure, including, for example, identity policies, resource
policies, boundaries, service control policies, ACLs and permission grants. An access path
can include permissions derived from organization policies, group memberships, resource
policies and permissions, which grant access to a resource.

Cross-cloud entitlement correlation: The differences in the IAM models across cloud
infrastructure complicates the account correlation process for evaluating appropriate
access. Organizations need a method by which accounts and entitlements across clouds
can be correlated and normalized into a unified access model. This will provide a 360-degree
view of access that enables calculation of aggregate access risk (for example, a single
administrator having access to management consoles of all their CSPs). It will also discover
toxic entitlement combinations (for example, an administrator who can create an identity and
can grant privileges to an identity).

Entitlements visualization: Given the large number of entitlements that organizations need
to manage, traditional table-driven visualization methods for viewing and analyzing this
information is not feasible. Also, a hierarchical directory representation of users and
entitlements will not accurately represent access relationships in the cloud, which are much
more complex.

Entitlements optimization: Usage data generated by privileged operations across cloud

infrastructure combined with entitlement data is essential in determining least-privileged
entitlement assignments. Given that events can generate large amounts of data, an
automated analytics and ML engine can aid in determining whether entitlements assigned
are dormant or improperly used. Furthermore, over time, an ML process can more precisely
make recommendations on appropriate access, whether removing or, in certain cases,
adding cloud infrastructure entitlements.

Entitlements remediation: Changes are often required as a result of entitlement optimization

or the change analysis process. In either case, an organization may prefer that security tools
not make changes directly, but rather trigger a change event containing the updated policy or
entitlement assignment. Most organizations should have a sanctioned process for
introducing changes in their IT systems, and it is equally important to use those processes
 for changes to the cloud infrastructure. Change tickets should be generated, assigned and
fulfilled using existing ITSM, IGA or defect-tracking tools.

Other options requirements are:

Entitlements protection: An important control for ensuring the overall integrity of the cloud
infrastructure is the ability to detect changes within all managed cloud infrastructure
environments and to remediate changes made outside of policy.

Entitlements detection: The analysis process should detect changes made outside of
sanctioned processes or changes that are deemed anomalous due to external factors, are
atypical or considered high-risk. As mentioned in the introduction, many outages are due to
operator error and therefore important to analyze, particularly those that can have a
significant adverse impact, which also implies the importance of knowing the risk level of the
entitlement.

See Managing Privileged Access in Cloud Infrastructure for more details.

Privileged Task Automation

Privileged task automation provides functions and features for automating multistep, repetitive
tasks related to privileged operations that are orchestrated and/or executed over a range of
systems. It uses extensible libraries of preconfigured privileged operations for common IT
systems and devices. The objective is to orchestrate back and forth between different activities
and ask for more information as needed while putting in guardrails by checking input against
policies and settings. This is like robotic process automation for IT operation processes that
require privileged access.

For example: The PAM solution should be able to spin up a container for each relevant IT
operation process and provide it with a one-time key and the necessary data to perform the
required tasks, such as the identities and devices involved. The script or code within the secure
container can only ask for appropriate keys and credentials from the PAM solution that can
verify the container (one-time) key and data before requesting the actual identity’s
keys/credentials from the PAM tool. The goal is to reduce the complexity and errors in
privileged operations and achieve higher efficiency.

Privileged Access Analytics and Response

Privileged access analytics and response is an emerging capability that employs machine
learning on privileged account activities to detect and flag anomalies, including baselining, risk
scoring and alerting. The objective is to better identify lagging and leading indicators that
identify privileged access anomalies to trigger automated countermeasures in response to
alerts on events such as:

Suspected credential theft

 Irregular access to machines at irregular times

Direct logins to privileged accounts that bypass existing PAM servers

Abnormal behavior (deviation in terms of keystroke cadence or passive biometric traits)

Unusual commands executed

Unmanaged privileged accounts

Excessive access

PAM solutions should:

Establish a baseline: The algorithms for behavior analysis are trained by using a history of
activities. Based on this training, an algorithm can build a baseline of a particular user’s
behavior and score new activities while they are ingested by sensors. Scores will indicate
whether a particular activity is normal or unusual compared with the baseline.

Score risk: Activities are scored by algorithms to measure the deviation from normal. A
single activity can be scored by multiple algorithms. Algorithm instance scores are then
aggregated to create a single score. Typical activities include:

Logon and logoff times and dates, including the number of activities in a given period

Location, host and applications, issued commands, and usage patterns

Keystroke and mouse dynamics

Periodicity of activities and percentage of active hours

Detect PAM control circumvention: The solution must identify when someone logs in with a
privileged account without going through PAM. This is not an “unmanaged” account, but it’s a
managed account, and yet someone could succeed to log into it without using PAM.

Alert: Alerts are triggered when the importance of activity reaches or exceeds a configured
threshold value. In that case, an alert is issued for a manual or automated response.

PAM solutions should be able to trigger automated countermeasures in response to these

alerts. Some PAM vendors have partnered with existing security solutions (such as SIEM) while
several other vendors have either developed or acquired the needed analytics technology.
Additionally, some vendors are leveraging synergies between privileged command delegation
and vulnerability management to further detect and prevent unsafe operations on potentially
compromised or vulnerable systems. Vulnerability assessments can also be correlated with
privileged activity for risk scoring (see Figure 19).
Figure 19. PAM and SIEM Integration

PAM solutions (as in-line controls) can grant or deny access to privileged access and/or
dynamically adjust access policies to request approval for working on sensitive systems.
However, technical professionals must evaluate the accuracy of such solutions and the time
required before these solutions begin to deliver value (following a learning period, if needed, to
develop a baseline of expected behavior).

The key responses include:

Terminate or suspend active suspicious sessions

Lock out privileged users that show abnormal activity patterns

Onboard unmanaged accounts upon detection

Trigger credential rotation on suspected compromised accounts or credentials

PAM solutions can also benefit from a standard framework such as OpenDXL (Open Data
Exchange Layer), which was developed by McAfee to automate the response based on
correlated events. The design objectives are to improve the context of analysis, simplify the
threat defense life cycle and enhance interoperability.

Robotic Process Automation

RPA tools allow the creation of software robots that emulate the rapid automation and
execution of repetitive steps and that interact with systems in the same way as humans. RPA
tools are designed to mimic the same manual paths taken by humans by using a combination
of user interface interactions or through applications by using connectors. This capability is
based on the requirement to access other applications in an automated fashion, frequently with
stored credentials that represent risk, such as credential theft and extended time to live.

Technical professionals need to securely provide credentials to these instances by protecting

credentials in credential vaults, when software robots impersonate other people and need their
credentials to access other systems. This can be combined with privileged session
management, using single sign-on to simplify the access and prevent exposing people’s
credentials to software robots. Some RPA vendors use their own native credential vaults, and
some are working with PAM vendors to integrate their offerings to use robust PAM features and
functionalities.

See RPA and Managing Software Robot Identities for more details.

Operational Technology and Industrial Control Systems

Operational technology (OT) and industrial control systems (ICS) offer challenges for privileged
access management. In OT scenarios, most people’s access happens between the human-
machine interface (HMI) and devices that feed data to and accept data from the HMI and
historian. From a communications perspective, protocol traffic in an ICS environment is not
always TCP/IP, but many times uses proprietary process control protocols like ModBus, thus
presenting additional challenges. Many OT and ICS environments are vulnerable from a network
traffic perspective because few of them have been designed with security in mind.

Many ICS and OT systems present additional challenges. They may:

Have their own, proprietary systems for identity and authentication

Be built on components that have not been patched for a long time

Have numerous known security vulnerabilities

Be using obsolete or unsupported components (such as Windows XP)

While a natural reaction would be to consider protecting these networks with an air gap (that is,
removing them from business networks or internet connectivity or through a segmentation
approach like the Purdue model), this is not practical. Additional complications arise from the
fact that vendors and maintenance partners need to access these systems, often remotely or
from third-party systems that could cause infection if compromised.
In terms of service and application account management, OT and ICS devices, sensors, gauges,
valves and so on can often not be supported through agent-based AAPM. Instead, all network-
based control and access is controlled via the HMI. Policy, device configuration, traffic flows
and operations are all primarily controlled from the HMI. So from a PAM perspective, all access
into the HMI itself is privileged access, and a good place for a privileged access control plane
for the environment. Leverage a PAM tool to integrate into the HMI for user access, password
management and so on where it is applicable.

Prevent direct third-party access to OT environments. Rather than allowing third-party

technicians to connect their own laptops to the OT environment, use RPAM and PASM tools’
privileged session management (PSM) functionality to connect third-party technicians to HMIs.
Use a combination of VDI tools to install and run specialized tools for managing ICS, and
provide access via PSM. Protect OT and ICS networks by using a combination of PAM tools
with specialized OT security tools, such as edge gateways.

See Market Guide for Operational Technology Security for more details.

Follow-Up
Ensure Resilience
This section provides more information on nonfunctional features to ensure PAM solutions’
resilience, including ease of deployment, integration, availability and emergency break glass.

Ease of Deployment

The ease-of-deployment key elements include:

Flexible deployment model: This is to match a variety of use cases. Examples are physical
appliance deployment, virtual appliance deployment, software-based deployment and SaaS
model. If the PAM solution comes as software, it must have scripts and templates to provide
automated installation and deployment of PAM software on one or multiple servers. This
includes out-of-the-box configuration of common policies, internal operating system tasks
and trusted applications, as well as logical grouping of applications, tasks and scripts.
Appliances come preinstalled by default. Policy rules can then be created to apply privileges
and block, warn or monitor these groups. In all cases, it is important to deploy session
proxies/gateways flexibly.

Rich set of connectors: On one hand, this is to automate the management of credentials for
specific types of accounts, and on the other hand, it is to launch target application clients
and open an active session. A connector is software that is typically allowed to be installed
in the PAM solution to do one of the following:

Actively manage (or change) a local credential (while keeping availability requirements and
needs for service restart under consideration)

Extend the capability of the PAM solution by integrating with other systems (such as SIEM
or IGA)
 Transferring data

Session management can also feature connectors as additional add-ons, considering the
different target systems and application launchers that require integration. The session
management tool should have the capability to customize application connectors and website
connectors with encryption. Additionally, the connectors should have the ability to support
privileged task automation, as described earlier.

Example features are:

Rich SDK and APIs: This is to enable operations on account objects by issuing commands.
The application SDK provides a variety of APIs, including Java, .NET, COM, C/C++, CLI and
web services. Web services should be able to be installed and used immediately without any
additional configuration. This solution should also include out-of-the-box web services and
an SDK. A web services SDK is a RESTful API that can be invoked by any RESTful client for
various programming and scripting environments, including Java, C#, Perl, PHP, Python and
Ruby.

Scalability: This is to scale for capacity expansion or accommodate for broad geographic
spread and performance. The solution should have a proven track record of small-, medium-
and large-scale deployments to cover the evolving requirements of dynamic organizations.
Scalability starts with architecture that allows integration with existing proven technologies,
such as Group Policy Objects or McAfee ePO. Additionally, scalability refers to management
overhead, which should stay consistent regardless of the size of the deployment. A hybrid
architecture is often necessary to accommodate niche scenarios or business units. Using
hybrid architecture should not require the use of multiple agents or different policy engines,
which will significantly increase management overhead.

Integration

This capability provides functions and features to integrate and interact with adjacent security
and service management capabilities. Examples include:

Multifactor authentication

Single sign-on

Enterprise directory

Group Policy Objects

IT service management

Security information and event management

Central logging services

 Vulnerability management

Policy orchestration tools

Identity governance and administration

External encryption services

Robotic process automation

Availability

The resilience key elements include:

Disaster recovery: The PAM solution is a critical system of an organization’s cyber defense
capabilities. Disaster recovery solutions must ensure service availability in case of total data
center failure or shutdown. For example, the proxy server and credential vault can be
replicated into a secondary data center or IaaS with failover capability.

High availability: The PAM solution must ensure that PAM controls remain available due to
any solution component failure, whether inherently in the tool or as an add-on in the solution
design. High-availability options should cover all aspects of the solution. This includes
network load balancing for web applications and services, clustering or data availability
groups for data stores, and multiple active/active nodes for all components of the solution.

Emergency and break-glass access: The PAM solution must have a secure fail-safe method
for accommodating access to the recovery of credentials/passwords if access to critical
privileged credentials/passwords is needed.

Emergency access: This is a scenario where the PAM system is available, but due to an
emergency, administrations require urgent access to privileged accounts/credentials. The
solution is often implemented using a PAM tool-native workflow/approval function or with
a ticketing system integration. Accountability is maintained through logs because
emergency scenarios imply approval (without needing to be explicitly approved) during an
emergency.

Break-glass access: This is a scenario where the PAM system is not available, but due to a
disaster, administrations require urgent access to privileged accounts/credentials. A
separate process and solution must be defined for these cases when the PAM system
remains down for a prolonged period beyond the return time objective (RTO). A typical
solution is to store a set of administrative credentials in a separate physical or logical
vault that can be retrieved and used in case of a disaster.

Break-Glass Deployment Considerations

Planning break-glass processes requires particular attention to some challenging scenarios,
such as:

Session management availability dependency: Different break-glass scenarios should be set

up. A normal scenario would leverage existing session management infrastructure, while an
alternative disaster recovery scenario requires pulling credentials directly from the vault and
bypassing session management infrastructure that may not be available in an emergency
scenario. Session recording and monitoring usually require connectivity through the session
manager proxy server to log activity and enforce segmentation. Technical professionals may
have to temporarily drop session recording and monitoring to reestablish connectivity. This
approach is not recommended, however, because it degrades the security posture,
specifically in case of a cyberattack. An alternative is to use solutions such as terminal
servers as a safer approach in a break-glass scenario. In either case, compensating controls
are needed for monitoring network access to provide further assurances.

Password management synchronization dependency: Break-glass scenarios can be

challenging without an independent password management infrastructure in an alternate
data center. When a password manager goes out of sync with a password that is restored
from a system backup, privileged access to the target system becomes an issue. This is
because the vault’s credential rotation mechanism has automated the rotation of passwords
of human, service or built-in accounts throughout the environment. Consequently, no one
knows the correct password. When this process fails, manual processes may be needed (in
the worst-case scenario) to restore privileged access to systems.

Application-to-application password caching dependency: When application, script or

configuration files access the vault via an API to retrieve the current password, they need to
complete the processing operation. The application can potentially cache the password for
continuous use or release the password when the session is complete. When applications or
the API components are not fault-tolerant, technical professionals must know the process for
rotating and refreshing passwords midcycle to recover from a failed operation.

Technical professionals should also plan for recovery from a break-glass event to restore
normal operations. This is important to ensure the break-glass process does not lead to
exploitation against the organization. This requires careful examination of all actions during
active break-glass processes to ensure appropriate use of credentials.

It is also important to identify what can be improved, either in the operating environment or the
break-glass process itself. Repeated use of break-glass processes may be the sign of a
systemic problem that must be seriously addressed to appropriately manage operational risk.

Password Rotation Deployment Considerations

Password rotation is a key function of any credential management capability. Password

rotation may need additional considerations as more complex use cases — such as AAPM,
container and software-defined anything, and cloud or virtualized environments — become
more common. This is to ensure PAM controls function as intended, without any disruption to
business operations.

These considerations are:

Creating dual accounts: This is to eliminate any edge case delays that may be encountered
during password rotation when using the single-account deployment method. Delays may be
incurred when a password is requested at exactly the time when the credential manager
service is changing that password. Creating dual accounts ensures that no delays are
incurred because a password that is currently used by an application will never be changed.
This is recommended in critical applications. The dual accounts solution uses two privileged
accounts (active and inactive) that have identical privileges to the system. The rotation of
credentials is done on the inactive account, which leaves the active account untouched until
the rotation process has finished. The application will continue to use the active account
until credential rotation has finished, and then will go on to use the newly changed account.
The password change process does not incur any delay in providing a password to an
application because it is always done on the inactive account, which ensures business
continuity. Once the inactive account password has been changed safely, the handoff
between the active and inactive accounts takes place by switching the status of the
accounts from “inactive” to “active” and vice versa. This mechanism can be expanded to
multiple accounts (i.e., an “account pool”) to cater for clustering or high-availability
scenarios.

Creating a single account with password change block: When using single accounts, an
application may request a password from the credential vault while a password change
process is underway. Typically, applications that handle password requests should ensure
the password is not currently in the process of being changed and, if it is, retry the password
request later. Therefore, the password change processes should be synchronized with cache
refresh processes through the credential vault. When the credential manager detects
passwords that are scheduled to be changed within a predetermined period of time, it marks
the passwords with a flag. If the credential provider detects flagged passwords when it
accesses the vault to refresh its cache, it will wait for the credential manager to change these
passwords on relevant remote devices and update the corresponding password in the vault.
Then, the credential provider will synchronize the passwords in the local cache with
corresponding passwords in the vault.
Risks and Pitfalls
Although PAM controls promise numerous benefits and strengths, organizations should
consider the following challenges:

Cultural resistance: Deploying PAM controls requires formalizing administrative processes,

which add additional steps to manage different systems. These steps can include additional
approval steps for using privileged credentials, checking out and checking in privileged
credentials, credential rotation, session recording, and activity monitoring, as well as
additional audits. All these additional activities can be seen as overhead by administrators
 who were once in full control of platforms or who feel that the organization no longer trusts
them with privileged access. Organizations need to carefully plan these changes and ensure
ample communication and training to make the transition less painful and more effective.
Single point of failure: Deploying PAM solutions may create a single point of failure without
adequate high-availability architecture and disaster recovery planning. For example, if
technical professionals deploy a single-instance database of the credential vault without any
high-availability configurations, there will be manual steps required to bring the data store
back online in case of a crash. Or, in the event of an entire system outage, extensive manual
intervention may be needed to restore the system from backup. If the PAM solution is hosted
in the cloud, and manages on-premises resources, then any loss of connectivity can cause
administrators to lose access, unless a local replica is available.

Significant integration to cover special cases: Deploying PAM controls may require dealing
with many special cases that require careful integration and testing — for example, if
technical professionals have deployed a single service account to be used both for an
application and for management console access. This is a bad practice and would need to
be changed to implement separation of duties with different accounts for application access
versus management console. However, remediating the situation may require extensive
reconfiguration and testing to reassign the credentials used for those components. Another
example is an application that is unable to retrieve passwords from the vault and may require
special treatment to its start/restart scripts as part of the password change process.

Dual control requires manual approval: Deploying PAM controls for critical or high-risk
systems may require approval for the credential check-out process. This is typically
implemented through a workflow that requires manual approval, which may cause delays. If
the approver is not available, then the process requires delegation and logging all the
changes to ensure auditability. All these additional steps will further delay the process.

Related Guidance
Technical professionals should broaden their mindset from compliance only to controls that
serve cyber defense and business enablement objectives. They must secure privileged
accounts to block adversaries at any stage of the cyber kill chain. This requires deploying
comprehensive layers of automated controls for all states of privileged credentials and broad
coverage across different platforms and environments.

The following guidelines are key to success:

Track and secure every privileged account: Discovery of PAM access is a complex but
foundational element of succeeding with PAM. The existence of any unaccounted privileged
access, for even a short time, carries significant risk. Discovery processes must be
continuous, because change is constant. Running a one-time discovery process using a tool
from a PAM vendor is good, but not enough, even when this happens on a scheduled basis.
One-time discovery tools will not find every privileged account, and the information rendered
will quickly be out of date when new systems, applications or privileged accounts are added.
Whenever privileged accounts are discovered, you must also inventory the resources those
accounts access, developing an understanding for what kind of resources require privileged
access and who owns those resources and is ultimately responsible for granting privileged
access to them. Information collection will be needed to develop governance for privileged
access and will also provide action-oriented data that will enable administrators to target and
remove inappropriate privileged access.
Govern and control access: Privileged access governance — understanding and
implementing appropriate PAM access — requires two things. First, it requires effective
identity life cycle processes to ensure that all changes in accounts with privileged access are
accounted for. Second, it requires proper tracking, accounting for every privileged account
and what that account can access. Once these steps are complete, plan to implement
recommended controls by using a PAM tool. Approach this with a plant-and-grow mentality.
Decide which kind of control you can successfully implement now, and which you want to
forecast for capture later. For example, start with basic PAM functionality, such as password
vaulting for all human users, and capture all service accounts. Once those elements have
been successfully captured and managed, move into application-to-application access.
Tackle enabling access that does not require standing access, such as privileged task
automation (normal users running scripts with privileged access) and workflow processes
for requesting just-in-time access.

Record and audit privileged activity: An effective PAM solution enables visibility of what
privileged users do and changes that have been made. A combination of tools (whenever
possible and feasible) establishes visibility. Privileged session recording, which can visualize
privileged activity, is provided by PAM vendors. It should be a critical part of your solution.
Depending on the type of session, this can be text input/output, keystroke logs, video
recording of graphical sessions or some combination. Scrutinize vendors for whether they
can record sessions, as well as how easy it is to quickly and effectively review activity.
Expending a great deal of time reviewing session recordings can be a mind-numbing and
ineffective exercise. Look for vendors that differentiate their products by providing users with
tools that more easily find unusual activity in logs and recordings. Ensure that you can output
logs to an enterprise user and entity behavior analytics (UEBA) or SIEM tool. These tools
perform analytics and can alert on anomalous behavior that could indicate compromise of a
privileged account. New analytics capabilities for detecting and alerting on unusual behavior
are becoming widely available. Some PAM tools even include basic UEBA capabilities that
can be leveraged for monitoring, auditing and alerting. File integrity monitoring tools can
track changes to configuration files. Some PAM vendors include this functionality as part of
their PEDM offerings. Database monitoring tools can track access and changes to sensitive
data and, in some cases, block access or trigger automated responses.

Operationalize privileged tasks: Many organizations invest the time and effort to capture the
security value of a PAM tool. However, they often leave real business value — such as
supporting new DevOps or robotic process automation initiatives or delegating privileged
access for third parties — on the table by failing to mature their PAM capabilities. Automation
includes increasing reliability and security by removing the “human” element. This increases
 efficiency by enabling privileged tasks to be run by more junior administrators with less
experience or by software agents, such as RPA, and it reduces the burden of reviewing
privileged activity by decreasing activity. Some of these translate to real business value in
terms of increased efficiency and helping the business reach strategic objectives.
Acronym Key and Glossary Terms
PASM Privileged account and session management

PEDM Privilege elevation and delegation

RPAM Remote privileged access management

JITP Just-in-time privilege

CIEM Cloud infrastructure entitlement management

ZSP Zero standing privilege

IGA Identity governance and administration

PAM Privileged access management

Evidence
Gartner’s observations and recommendations are based on data from:

Ongoing discussions with end user organizations in public and private sectors across all
industries

Vendor briefings, interviews and demos of products from vendors with full or partial PAM
capabilities

1
Cybersecurity Framework, National Institute of Standards and Technology (NIST).

Document Revision History

Guidance for Privileged Access Management - 17 September 2019

Architecting Privileged Access Management for Cyber Defense - 12 March 2018

Recommended by the Author

Evaluation Criteria for Privileged Access Management
Securing Privileged Access to the Cloud Using PAM
Securing Remote Privileged Access for External Users
RPA and Managing Software Robot Identities

Identity and Access Intelligence Innovation With Generative AI

Guidance for Identity Governance and Administration

Recommended For You

Identity and Access Management for Technical Professionals Primer for 2023
Securing Remote Privileged Access for External Users
Solution Path for Modernizing Access Management
How to Authenticate Frontline Workers
Is Light IGA Right for Your IAM Needs?

Supporting Initiatives
Identity and Access Management for Technical Professionals

Follow

© 2023 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc.
and its affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior
written permission. It consists of the opinions of Gartner's research organization, which should not be
construed as statements of fact. While the information contained in this publication has been obtained from
sources believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy
of such information. Although Gartner research may address legal and financial issues, Gartner does not
provide legal or investment advice and its research should not be construed or used as such. Your access and
use of this publication are governed by Gartner’s Usage Policy. Gartner prides itself on its reputation for
independence and objectivity. Its research is produced independently by its research organization without input
or influence from any third party. For further information, see "Guiding Principles on Independence and
Objectivity." Gartner research may not be used as input into or for the training or development of generative
artificial intelligence, machine learning, algorithms, software, or related technologies.

POLICIES PRIVACY POLICY TERMS OF USE OMBUDS

© 2023 Gartner, Inc. and/or its affiliates. All rights reserved.