Cloud 101CircleEventsBlog
Join us for Cybersecurity Awareness Month! Strengthen your cyber resilience with essential security tips and resources for everyone.

PAM and Cloud Security: The Case for Zero Standing Privileges

Published 08/22/2024

PAM and Cloud Security: The Case for Zero Standing Privileges

Originally published by CyberArk.

Written by Charles Chu.

The cloud has introduced entirely new environments, roles and circumstances that require us to reimagine the definition of privileged access management (PAM) and how to apply those principles to secure identities. PAM was built on the notion that identities must be secured, not just managed, to protect an organization’s most valuable assets. The well-recognized values of PAM remain highly desirable – least privilege, role-based access control and auditability of high-risk sessions. The challenge is applying all those principles to these new environments, roles and circumstances.


New Cloud Environments, New Security Requirements

It’s relatively straightforward to delineate security responsibility in on-premises environments, as clear lines can be drawn at each infrastructure layer. There’s a physical data center, physical network cables, separate network protocols that flow through the wires, physical racks that contain compute or storage – and so on – all the way up the IT stack.

Those lines of separation and segregation of duty disappear completely in cloud environments, whether you operate in a hybrid environment (lifting and shifting workloads to the cloud) or take a cloud-native approach (building applications using a microservices architecture).


Perhaps the most mundane example of cloud usage occurs when an AWS user provisions a simple storage service (S3) bucket to store electronic files. In the on-premises world, this is the equivalent of someone breaking into a data center, pushing a rack on a trolley to the data center, placing the rack on the data center floor, plugging hard drives into that rack and connecting ethernet cables. Clearly, this would never be allowed in a traditional on-premises setting and demonstrates why we can’t think of access to a cloud service provider (CSP) as ‘just another console’ in cloud environments.

Our analysis of the three major CSPs shows that a user can access approximately 1,400 native services (e.g., AWS S3, Microsoft Azure Kubernetes Service or Google Cloud BigQuery), which collectively have 40,000 different access controls … and that number grows every day.

It’s clear we can’t apply a traditional notion of a small number of admin roles with static privileges to this dynamic environment.



Admin Overload and Evolving Roles

Traditional applications have straightforward, clear-cut boundaries between admins and users. With these applications, regular users couldn’t typically access sensitive systems and data. For instance, an employee using Outlook could send and receive emails but never perform tasks like changing POP or SMTP settings or adding or deleting users. Anyone with cloud access may be provisioned with entitlements to tap into 1,400 native services, ranging from fundamental capabilities like compute or storage to sophisticated capabilities such as artificial intelligence (AI) and machine learning (ML) engines. Perhaps surprising to some, there are also an array of SaaS services among these 1,400 native services, such as workflow engines, video processing and instant messaging. Clearly, anyone with the right to buy and use any of the above should be considered an admin.

It’s especially important to note that an entire new population of ‘admins’ have appeared: software developers. With few exceptions, all modern software development tools and processes are done in the cloud and the resultant software is deployed in the cloud. All software developers are now considered cloud ‘admins’ and must also be secured. Yet, identity security has been sacrificed to accelerate velocity.

Seventy-seven percent of security professionals say developers have too many privileges — making these human identities highly attractive targets for attackers and driving up cybersecurity debt. These expansive user permissions were set to account for all possible circumstances the user may face because prior systems were inflexible and static. Developers need to innovate; they cannot wait for their shared accounts to be created and secured for every service or workload they need to access, particularly those that are short-lived. This inflexible approach deviates from cloud provider best practices and creates unacceptable delays to engineering timelines.


Cloud Architectures and New Circumstances

The rise of microservices has generated fantastic scale, efficiency and cost savings. However, it has also created an intertwined web of dependencies and complexity for any true cloud native application. A sophisticated view is of the interactions between the 700 Netflix microservices in 2014. Today, Netflix has well over 1,000.

The new circumstance created by cloud microservice architecture is that an outage impacts all customers. Simple isolation is gone. It’s not a single monolithic ERP application or simple email application where only a segment of users are impacted. A microservice application architecture means all users are impacted. When any system has an inevitable instability or an outage the on-call engineers must be allowed to roam all over the production environment to troubleshoot, diagnose and fix the issue.

While dramatic, this is clearly one of many circumstances that didn’t exist in a classic IT setting.