IAM Leaders’ Guide to Privileged Access Management
9 May 2024- ID G00809178- 22 min read
By Abhyuday Data, Felix Gaehtgens, and 1 more
Privileged, administrative or excessively empowered accounts remain one of the primary targets of attackers and are often responsible for significant breaches. Security and risk management leaders responsible for identity and access management should use PAM tools to safeguard privileged accounts.
Analysis
Unrestricted, widespread or poorly monitored use of access privileges across an organization’s IT infrastructure not only violates the basic security principle of least privilege, but also severely limits the ability to establish individual accountability for privileged actions undertaken.
Traditional identity and access management (IAM) technologies such as identity governance and administration (IGA) and access management (AM) offer control of standard users’ access. However, they do not offer sufficient privileged access management (PAM) capabilities to manage shared use of privileged accounts, controlled elevation of administrator privileges, service accounts and cloud infrastructure permissions.
Security and risk management leaders responsible for IAM should focus on special considerations, processes and tools to manage expedient operational privileged access. This will help streamline the mitigation of security, operational and business risks created by the inherent power of administrative privileges.
Organizations also need a comprehensive understanding of all types of privileged accounts across the enterprise because the existence of any unaccounted privileged access, for even a short time, carries significant risk.
At a broad level, all privileged accounts are classified into two categories: people, and software and machines (see Figure 1).
Figure 1: A Taxonomy of Privileged Accounts
Privileged accounts used by people for interactive administrative access to assets (infrastructure, devices, applications, control panels, etc.) include:
- Personal privileged accounts
- Shared privileged accounts such as:
- Built-in administrator accounts, such as the local administrator and the root user
- Other shared administrator accounts set up by the organization
Privileged accounts used by software and machines include:
- Workloads such as:
- Containers
- Virtual machines (VMs)
- Application accounts used by applications, scripts or batch jobs to access other services and databases, among some others
- Service accounts used by an application or a service to interact with the operating system and other services
- Robotic process automation (RPA)
- Scripts
- Infrastructure as a service (IaaS) or platform as a service (PaaS) accounts, which are used in web-based configuration panels and consoles for IaaS, PaaS, SaaS and other cloud assets
- Devices: privileged accounts on (hardware) devices, as well as accounts used by these devices to interact with other systems, applications or services, such as:
- Mobile devices
- Desktop devices
- Cyber-physical systems (CPS)
The collection of research and market trends that we summarize in the following section can help organizations focused on PAM to mitigate security risks and increase agility in their security posture.
Research Highlights
Some recommended content may not be available as part of your current Gartner subscription.
PAM Tool Landscape and Usage
Gartner defines PAM as tools that administer or configure systems and applications to provide an elevated level of technical access through the management and protection of accounts, credentials and commands. PAM tools, available as software, SaaS or hardware appliances, manage privileged access for both people (system administrators and others) and machines (systems or applications).
There are five categories of PAM tools that Gartner has identified (see Figure 2).
Figure 2: Categories of PAM Tools
The five categories of PAM tools are for:
- 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 privileged credentials’ injection into sessions, and full session recording. Passwords and other credentials for privileged accounts are actively managed, such as being changed at definable intervals or after specific events. Optionally, PASM solutions can also provide application-to-application password management (AAPM) and/or zero-install remote privileged access features for IT staff and third parties that do not require a VPN.
- 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), application allow/deny/isolate controls, and/or privilege elevation which allows particular commands to be run with a higher level of privileges. PEDM tools must execute on the actual operating system (kernel or process level). Command control through protocol filtering is explicitly excluded from this definition, because the point of control is less reliable. Optionally, PEDM tools can also provide file integrity monitoring features.
- Remote privileged access management (RPAM). RPAM tools enable access for remote privileged users through session brokering, credential injection/vaulting and strong authentication capabilities, which mitigate many of the risks of unmanaged devices employed by those users. These tools also provide controls for establishing, monitoring and recording remote privileged sessions to specific targets and eliminate the need for VPN and provide more secure access to critical systems. The tools also enable alignment with zero-trust architectures, because there is no implicit trust in corporate networks or endpoint devices. Most stand-alone RPAM tools offer multifactor authentication (MFA) features to provide effective protection against account takeover (ATO) threats.
- Secrets management. Credentials (such as passwords, OAuth tokens and Secure Shell [SSH] keys) and secrets 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 DevSecOps pipelines. Secrets management is often used in dynamic and agile environments such as IaaS, PaaS and container management platforms.
- Cloud infrastructure entitlement management (CIEM). An adjacent cloud security area, CIEM offerings provide administration time controls for the governance of entitlements in hybrid and multicloud IaaS. This helps mitigate identity risks associated with permissions to virtual infrastructure (IaaS). CIEM solutions typically use analytics, machine learning (ML) and other methods to detect anomalies in account entitlements, like accumulation of privileges, and dormant and unnecessary entitlements. CIEM provides remediation and enforcement of least privilege approaches in cloud infrastructures.
On the surface, it seems that IGA and AM tools can also be used to manage access for privileged users, but this is not true. Managing privileged access requires distinct capabilities that IGA and AM tools do not have (see Note 1).
For more details, see:
PAM products are now mainstream, but organizations struggle with adoption beyond the basic controls, which some vendors address better than others. Support for account discovery and machine identity management, pricing and licensing terms also continue to be uneven. HashiCorp enters the PAM space.
Privileged accounts are a prime vector for the exploitation of breaches. Effective privileged access management is more important than ever, and cyberinsurance companies are demanding the use of PAM tools. Security and risk management leaders should use this research to compare their effectiveness.
Managing cloud permissions is challenging due to the number of assets and diverse authorization systems, worsened by the explosion of machine identities. Security and risk management leaders must combine traditional IAM and cloud security approaches with CIEM for efficient identity-first security.
Managing Privileged Accounts for Software and Machines
Workload accounts are one example of privileged accounts used by software as opposed to humans (see Figure 1). These include accounts for application and services, which are often not adequately protected and improperly managed. These accounts pose significant security and operational risks because they are secured with credentials that are available to applications or services.
Managing privileged accounts for software and machines is tricky, because:
- Many applications or services are installed using accounts that may be quickly forgotten and thus not managed properly, risking discovery and abuse by an unauthorized party.
- Modern DevOps and cloud approaches create accounts in an agile manner. This means that these types of accounts are rapidly created at any instant by other teams and business units. Most organizations struggle to enforce centralized registration processes for new workload accounts. Thus, discovery is critical in ensuring that these accounts are being found and tracked properly, and that ownership is assigned.
- Accounts for software and machines use credentials in the form of passwords or keys. Established security practices require these to be changed or rotated periodically. Yet changing service account credentials is not trivial: In many cases, credentials need to be changed in multiple locations, and services sometimes need to be restarted. This can cause outages when not done properly, that is, when there are dependencies between services being restarted or when password changes are not properly synchronized.
- Changing account credentials in highly available or clustered services often requires special handling and respect for maintenance windows.
- Authentication between services often requires credentials to be stored, which creates significant security risks. If credentials are not encrypted, they can be stolen and abused. Even when they are encrypted, the decryption key needs to be kept safe.
PAM tools (specifically PASM and secrets management solutions) can manage and secure access to the privileged accounts for software and machines. PASM tools can often scan systems and identify password storage areas and configuration files that store credentials to discover the relevant software accounts. For legacy software that does not have a secure storage mechanism for credentials, AAPM tools, a subcategory of PASM tools, can be used. AAPM tools allow software to gain access to application credentials in a secure manner through proprietary SDKs and command line interfaces (CLIs).
PASM tools also help manage service account credentials (passwords and keys) by changing them periodically and reliably updating every location where they are needed. PASM tools have specific features to automate these types of changes, such as:
- Running custom scripts or commands after a password change to propagate the change.
- Restarting services after password changes.
- Keeping track of dependencies between services to avoid outages when password or key changes are made or services are restarted.
- Using dynamic account pools that allow rotation between multiple equivalent service accounts and allow one inactive account to have its password or key changed and then be “swapped in.”
A specialized category of PAM tools for managing machine and software accounts is also now available, known as secrets management tools. While there is some overlap with traditional PASM tools, pure secrets management tools specialize in the management and brokering of credentials for workloads to exchange secrets and to manage authorizations and related functions. They can also manage runtime encryption keys between different applications and services, and secure continuous integration/continuous deployment (CI/CD) technology used in DevOps processes. Secrets for software and machines are programmatically managed, stored, and retrieved through APIs and SDKs.
Secrets management tools are available as stand-alone tools, or are built into existing cloud service providers or PASM solutions. They provide capabilities to generate, vault, rotate and provide credentials to workloads (for example, via APIs) in a secure manner. These can include credential injection techniques, application fingerprinting, native integrations with DevOps and CI/CD components such as container management systems, integration with trust frameworks (like RPA platforms), encryption, and trust brokering.
The management of software and machine account credentials requires a disciplined approach. Figure 3 gives an overview of secrets management tools. They are often used in dynamic environments such as DevOps pipelines, IaaS, PaaS and container management platforms.
Figure 3: Typical Interaction Between Applications and Secrets Managers
Fore more details, see:
Machine-to-machine communication is ubiquitous. There are now more identities and more internet traffic generated for machines than for humans. Security and risk management leaders need to manage trust between machines to prevent security breaches. Secrets management tools are one possible solution.
The management of machine identities, keys, secrets and certificates require an expanded identity fabric. Security and risk management technical professionals must establish a team that makes use-case-based tooling decisions that meet the needs for discovery, automation and governance, and those of developers.
PAM for Cyber-Physical Systems (CPS)
PAM for CPS is unique. Managing privileged access to CPS possesses several challenges as many of these CPS are built on components that have not been patched for a long time, have numerous known security vulnerabilities and are sometimes even using obsolete or unsupported components (such as very old versions of Linux or Windows).
While a natural reaction would be to consider protecting these networks with an air gap (i.e., removing them from business networks or internet connectivity), this is not practical. With the increased adoption of Industrial Internet of Things (IIoT) and shift to remote work, IT and operational technology (OT) systems are increasingly connected to each other, and thus the risk of intrusion of bad actors has amplified. 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.
For OT, industrial control system (ICS) and supervisory control and data acquisition (SCADA) types of CPS scenarios, most access happens between the human machine interface (HMI), and devices that feed data to and accept data from the HMI. In terms of service and application account management, OT devices, sensors, gauges, valves and others cannot often be supported through secrets management, or agent-based AAPM. The HMI is often used to control policy, device configuration, traffic flows and operations.
In an OT environment, the HMI is generally the linchpin in terms of security. 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 provide remote access to the HMI for user access, password management and other purposes. There are a few PAM vendors that have built connectors for specific OT and ICS components, such as BeyondTrust and WALLIX.
For organizations which need to manage privileged access to CPS:
- Prevent direct third-party access to CPS environments.
- From a PAM perspective, use PASM tools’ PSM functionality to broker third-party access to HMIs.
- If you plan to use PAM tools in a CPS context, ensure that no regulatory requirement prohibits it. (For example, high-risk environments in high-risk sectors such as the nuclear energy sector would require specific standards to be met.)
- Ensure that you are aware of and respect the Purdue model if it is in use for network topology at least for OT, ICS and SCADA environments. Don’t use the same RPAM instance to manage both IT and OT systems.
- Favor RPAM tools or dedicated CPS secure remote access tools for remote access to CPS.
For more details, see:
RPAM tools improve administrative efficiency and reduce the security risks of poorly managed remote privileged access. Security and risk management leaders responsible for IAM should deploy these tools to reduce attack exposure and provide secure remote privileged access.
Organizations increasingly need to provide secure remote access to production or mission-critical CPS to manufacturers, employees, and contractors. This research provides security and risk management leaders with insights into new secure remote access solutions specific to CPS environments.
Managing Privileged Access in and for the Cloud
Managing privileged access from, for and in the cloud presents several unique challenges. In terms of assets that require privileged access, there are:
- Web-based configuration panels and consoles for IaaS, PaaS, SaaS and other cloud assets
- APIs for configuration
- Access to virtual machines or containers
Organizations must take a use-case-based approach to evaluate their PAM needs and implement the right controls to secure their cloud resources (see Figure 4).
Figure 4: PAM for Cloud Scenarios
Organizations should assess the above-mentioned cloud scenarios in order to effectively manage and secure privileged access to cloud infrastructures. It should be noted that PASM tools alone do not cover all these requirements fully. Organizations with a single cloud strategy should prioritize the use of its cloud service providers’ (CSPs’) native features, whereas organizations with multicloud strategy would benefit from using third-party tools like secrets management and CIEM tools, in addition to PASM tools and the native features of CSPs.
With regards to PASM tools, check for capabilities such as allowing the management of privileged access to web-based administration consoles. When using APIs for configuration (such as for infrastructure as a code), investigate capabilities to broker secrets, credentials or to issue short-lived security tokens for this purpose.
For more details, see:
The adoption of public cloud is making privileged access management more complex. This research helps security and risk management technical professionals secure cloud systems and applications using PAM capabilities, such as session management and privileged access governance.
Delivery Mechanisms for PAM
Virtually, all vendors offer PAM as SaaS. From a tool delivery perspective, PAM software can be installed on physical servers or virtual machines in IaaS environments. Some PAM vendors provide preconfigured virtual images for common IaaS environments such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).
Keep in mind, however, that PAM solutions need some local footprint close to managed resources. For example, if you have a significant on-premises footprint you would want to have some components of the PAM solution (for example, session management and account rotation) running in that data center, synchronized with the SaaS service.
When choosing a delivery model for PAM, ask yourself the following questions:
- Is there a significant on-premises footprint with mission-critical systems? If so, consider deploying PAM tools within your data center, either as hardware appliances or software.
- Is there a significant footprint on one particular IaaS? If so, you may install a separate PAM environment in that IaaS, to manage those cloud assets, or centralize your PAM solution in that IaaS.
- Is your IaaS footprint following a multicloud strategy (i.e., the use of multiple IaaS offerings from different providers)? If so, you may prefer SaaS-based PAM tools.
Alternatively, consider a hybrid strategy with PAM tools running on-premises or in the cloud, with replication for redundancy between the different on-premises and IaaS-based data centers.
For more details, see:
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.
Just-in-Time PAM Model
Proper management of privileged access requires following the principle of least privilege. This principle states, broadly speaking, that someone or something should have exactly the minimum rights required to carry out a specific task. However, many organizations start from a point where certain users have access to highly privileged accounts and in many cases, personal privileged accounts. This provides them with privileged access on a long-term basis, whenever they want and with little limitation.
An effective way to embrace the principle of least privilege is to use a just-in-time (JIT) approach for PAM. JIT is a necessary step forward in terms of overall PAM maturity and provides the basis for zero standing privileges (ZSPs).
For more details, see:
Privileged access carries significant risk. Even with privileged access management tools in place, the residual risk of users with standing privileges remains high. Security and risk management leaders focused on IAM must implement just-in-time strategies to pursue zero standing privileges.
Attaining PAM Maturity
PAM implementations can be complex and costly, from both a time and people perspective. Organizations focused on PAM should not consider PAM implementations as a one-time “install and forget” initiative; rather, they should consider it as a long-term project. Not having a long-term roadmap or not having the right tool can jeopardize the success of a PAM initiative.
A mature PAM practice will build on the foundation of your information security program. Organizations should use five interlocking strategies of PAM (see Note 2) to move the organization past the analysis paralysis at the beginning, through the fear of change in the middle and on toward the cornucopia of value through the completion of a mature PAM practice.
Planning PAM capabilities around these strategies enables organizations to move beyond the base functions of PAM, password vaulting, session recording and others, and into the next-generation functions of zero standing privileged access. These activities also allow organizations to capture reliability gains by removing the human element, and using privileged task execution to automate repeatable, predictable privileged tasks.
Organizations focused on PAM should utilize the following guiding principles of defining the basic, next-up and further-out steps to attain maturity of their PAM program (see Figure 5).
Figure 5: An Example of a PAM Capability Deployment Roadmap
At first, you should take the following actions to achieve the basic, minimum level of maturity:
- Discover and inventory privileged accounts
- Vault privileged accounts
- Implement multifactor authentication (MFA) for all privileged pathways
- Establish a privileged operations model. This has two main components:
- Preferring establishing sessions and injecting credentials transparently, and deemphasizing and deprecating credentials, whenever possible, to disclose them to administrators.
- Providing privileged access either using shared accounts securely with a PAM tool, or personal privileged accounts with just-in-time elevation.
- Provide session management, recording and remote access capabilities.
Alternatively, some organizations start directly with PEDM/least privilege as an alternative pathway.
After the basic capabilities have been achieved, organizations will have more options that they can choose to focus on next in terms of privileged access. They should acquire the basic capabilities before striving to achieve others listed in Figure 5.
Once you’ve achieved the basics, you have some options, such as:
- Extending coverage to include more systems like SaaS business apps and CPS. Other types of privileged users such as remote third-party users and database administrators (DBAs) will inevitably require political skills to come up with a common approach, rather than one that splits the responsibilities across different types of targets.
- Improving process maturity through measures such as continuous discovery of assets (rather than ad hoc), integration with IT service management, and implementing formal processes for auditing specific administrative sessions (most likely those of high risk or of high sensitivity).
- Promoting business transformation by securing DevOps through PAM integration, and adopting a just-in-time operational model that can help the overall organization become more efficient.
After achieving the basics, you will have a more flexible pathway to higher levels of PAM maturity, and you don’t need to acquire the capabilities listed on the maturity curve as shown in Figure 5 one by one.
For more details, see:
Managing privileged access risk is virtually impossible without specialized PAM tools. However, security and risk management leaders responsible for IAM must build a mature PAM practice that focuses on people and processes before making technology-purchasing decisions.
5 Interlocking Strategies for a Successful PAM Implementation
PAM tools provide significant cybersecurity value, but implementation presents many challenges and potential pitfalls. Security and risk management leaders responsible for IAM should plan for success by focusing on culture, discovery, least privilege, visibility and operational efficiency.
PAM tools provide significant cybersecurity value, but implementation presents many challenges and potential pitfalls. Security and risk management leaders responsible for IAM should plan for success by focusing on culture, discovery, least privilege, visibility and operational efficiency.
Acronym Key and Glossary Terms
| AAPM | application-to-application password management |
| AM | access management |
| API | application programming interface |
| ATO | account takeover |
| AWS | Amazon Web Services |
| CI/CD | continuous integration/continuous deployment |
| CIEM | cloud infrastructure entitlement management |
| CLI | command line interface |
| CPS | cyber-physical systems |
| CSP | cloud service provider |
| DBA | database administrator |
| GCP | Google Cloud Platform |
| HMI | human machine interface |
| IaaS | infrastructure as a service |
| IAM | identity and access management |
| ICS | industrial control system |
| IGA | identity governance and administration |
| IIoT | Industrial Internet of Things |
| JIT | just in time |
| MFA | multifactor authentication |
| ML | machine learning |
| OT | operational technology |
| PaaS | platform as a service |
| PAM | privileged access management |
| PASM | privileged account and session management |
| PEDM | privilege elevation and delegation management |
| PSM | privileged session management |
| RPA | robotic process automation |
| RPAM | remote privileged access management |
| SaaS | software as a service |
| SCADA | supervisory control and data acquisition |
| SDK | software development kit |
| SSH | Secure Shell |
| VM | virtual machine |
| VPN | virtual private network |
| ZSP | zero standing privilege |
Note 1: Why Are IGA or AM Tools Not Enough to Manage Privileged Access?
Why are IGA tools unfit for PAM use cases? IGA tools focus on admin-time control, whereas PAM requires runtime control of privileged access. Using IGA’s self-service and approval workflow capabilities for requesting and approving privileged access would lead to privileged access granted on a longer-term basis (which should be an exception rather than the norm). IGA tools are not designed to allow access on a per-session, just-in-time (JIT) basis, which is a recommended practice for PAM. In addition, IGA tools do not have the discovery capabilities for privileged accounts, nor the capabilities to rotate and update software and machine account credentials and neither do they offer session monitoring/recording controls. These gaps make IGA tools unfit for PAM use cases. However, IGA tools can work hand in hand with PAM tools by providing life cycle management for users along with governance functionality, such as access certification, segregation of duties (SOD) analysis, and tracking long-term privilege assignments (which, by their nature, should be the exception rather than the norm). See IAM Leaders’ Guide to Identity Governance and Administration for more details on IGA tools.
Why are AM tools unfit for PAM use cases? AM tools implement single sign-on (SSO) to business applications for standard users. They could be used to control privileged access to web-based control panels, and some AM tools can even broker RDP or SSH sessions. However, they do not tend to have discovery features and do not manage privileged accounts and their credentials (especially legacy or on-premises assets) holistically as PAM tools do. AM tools also don’t tend to support typical privileged access patterns (just-in-time for varied privileged use cases, purpose-driven versus long-standing access), nor are they built to support the admin time structure needed to support these patterns. See IAM Leaders’ Guide to Access Management for more details on AM tools.
Note 2: Five Interlocking Strategies of PAM
The five interlocking strategies of PAM that security and risk management leaders can leverage are:
- Changing the culture.
- Implementing comprehensive discovery.
- Enforcing the principle of least privilege.
- Creating and capturing visibility for all PAM activities.
- Increasing operational efficiency with PAM.
