Applying Privileged Access Management to Cloud Environments

Privilege in IT is like oil: The machine cannot run without it, but too much and there will be a mess. The industry has struggled with privilege over the years and, with the proliferation of hybrid multi-cloud computing environments, it must improve privileged access management (PAM). The key requirements to improve PAM are:

• Better PAM integration with identity governance and administration (IGA)
• Support for just-in-time (JIT) access
• Integration with DevOps pipelines and service accounts

Over-Privileging and Breach

Many organizations run at high risk from overprivileged IT administrators and power users. Breach reports find privilege misuse to be one of the most common insider threat vectors.

Delving deeper reveals a failure to manage privileged access behind many successful externally generated cyberattacks. Sure, most incidents may have started with a spear-phished user account, but to get to the crown jewels, hackers must usually penetrate additional layers of defense. These lateral moves tend to require exploiting privileged user or service accounts.

Traditional PAM Solutions

Regulatory compliance demands controls such as least privilege and separation of duty. Thus, PAM products have been around since the early 2000s to help organizations with the use cases and controls detailed in figure 1.

A Known Problem

Although PAM systems may have impressive features on paper, they are notoriously hard to deploy.¹ The core issue is that developers and IT administrators tend to resist PAM when it interferes with their way of working. As Phillip Lieberman, former chief executive officer of Lieberman Software, said years ago, “No one deploys my [PAM] product because they want to. They deploy it because someone tells them they have to.”²

PAM should be managed as a program, not a project. As PAM requirements expand with threats and regulations, practitioners must take the time to explain why and gain more buy-in up front. Automation, support, training and testing—anything that makes PAM easier for users to implement—should be enhanced.

THE CORE ISSUE IS THAT DEVELOPERS AND IT ADMINISTRATORS TEND TO RESIST PAM WHEN IT INTERFERES WITH THEIR WAY OF WORKING.

Cloud Complications

With the rise of cloud services such as Amazon Web Services (AWS), Microsoft Azure and many Software as a Service (SaaS) applications, identity and access management (IAM) is also changing. Enterprise deployments once centered around Active Directory are fragmenting. Machine and service identities become more prevalent than users in DevOps-powered Infrastructure as a Service (IaaS) environments.

PAM, too, is morphing. Like any would-be multicloud management capability, cloud PAM must support cloud-native application program interfaces (APIs), DevOps, container and serverless computing models on top of the traditional Windows or *NIX servers still found in the fabric. IAM and PAM must also operate at higher scale amidst the disruption of rapid change.

The stakes are high. A succession of breaches such as the recent plundering of Capital One’s AWS S3 storage buckets³ highlight the need for seamless but automated management of the multicloud infrastructure.

PAM Cloud Gaps

With immature IAM and PAM multicloud management capabilities, customers have multiple cloud gaps (figure 2).

JIT PAM Cannot Come Too Soon

Services such as the AWS AssumeRole,⁴ which enables a user to obtain a temporary set of security access tokens and credentials from Amazon’s Security Token Service (STS), showcase a new access model. Also supported by Microsoft, JIT access significantly reduces the IT attack surface because privileges are not “always-on.” JIT access epitomizes the principle of least privilege.

Should PAM Converge With IGA?

Something must manage JIT access to give the command for the user to assume a role at run time. Administrators or developers cannot be expected to cooperate with manual workflow approval processes every time they want to log in to a server or run a new command.

However, it is the IGA component of IAM (not PAM) that has the deep knowledge of roles, entitlements and identities needed to grant or deny access via an automated, risk-based decision. PAM integration with IGA tends to be shallow. IGA and PAM vendors will need to integrate more tightly or else each implement more of each other’s feature sets for the cloud.

Integrate With DevOps Pipelines to Manage Privileged Service Accounts

If IGA can make the access request process almost seamless, providing JIT PAM for user accounts in the SaaS, Platform as a Service (PaaS) and IaaS environments will be a huge risk reducer. Without always-on roles and long-lived tokens, cloud breaches such as Capital One’s are less likely to occur.

More must be done for the IaaS environment. To start, IGA/PAM must support bringing DevOps under a risk-based identity governance model. DevOps user accounts for the most sensitive applications should only get elevated privileges after matching relevant risk criteria, and access should be limited to specific functions.

Next, IGA/PAM must implement a holistic approach to managing both user and service account access. Service account authentication should be controlled through API keys or externalized secrets management. Service account privileges could also be controlled through roles known to the IGA system. Such controls require cloud PAM solutions to integrate with DevOps pipeline orchestrators such as Ansible, Chef and Jenkins.

Finally, IGA/PAM must be capable of deploying an “anti-fragile” architecture model. To scale with the cloud, IGA/PAM ultimately need to run in the cloud. (Most are on-premises today.) Components such as current-day jump hosts and agents should be containerized, microservices-based and DevOps-enabled (at least in large-scale, self-contained system environments).

Conclusion

JIT access, IGA/PAM convergence and anti-fragile architectures offer the industry hope of extending PAM to the cloud and of overcoming PAM’s traditional adoption barriers. Many practical challenges remain to be overcome, and there is a risk of project overreach for early adopters. But delaying exploration of cloud IGA/PAM could perpetuate and even increase systemic vulnerabilities of the current fragmented, overprivileged IAM environments. Practitioners should begin by looking for easy wins and/or risk reduction to the most critical systems to build converged cloud IGA/PAM capability in the coming year.

Endnotes

¹ Blum, D.; “Privileged Account Management (PAM) Is Necessary, But Deploying It Stinks,” Security Architects Partners, 6 May 2015, http://security-architect.com/privileged-account-management-pam-is-very-important-but-deploying-it-stinks/
² Said in a conversation with the author
³ Blum, D.; “Did Capital One Respond Well to an ‘Erratic’ Data Breach?” Security Architects Partners, 10 September 2019, http://security-architect.com/did-capital-one-respond-well-to-an-erratic-data-breach/
⁴ Amazon Web Services (AWS), “AssumeRole,” http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html