Here at Lightspin, we love knocking those cloud security misconceptions out of the park! In our previous editions of this series, we spoke about how relying on CVEs is not enough to keep you secure on the cloud, and how CWPP is not a good fit for modern cloud environments. Today, we're going to talk about the principle of least privilege, and why running after this on-premises concept on the cloud will add a huge amount of work, for little reward or risk reduction.
The principle of least privilege (PoLP) is a security concept where you give users exactly the permissions that they need to do their job, and no further. It was invented for on-premises security environments, and on-premises at least, it can be extremely effective at reducing risk.
More recently, with the rise in cloud-native deployments and data centers, many security professionals have attempted to lift and shift the concept of least privilege to the cloud. Here’s why I believe that when it comes to securing the cloud, least privilege is dead.
One or Two Permissions is Enough
To take full account ownership on the cloud, you really only need to have a couple of permissions, in an environment where there are often tens of thousands. For example, in AWS there are more than 10,000 different IAM actions, distributed across the various services in the cloud. These permissions are segmented between read, write, or management actions. To create a data breach, all an attacker needs is to gain access to an IAM role or user credentials that has S3:GetObject only with a wildcard in the resource. In short, any S3 bucket that doesn’t have explicit restrictions to the account is open for business to an attacker.
This is exactly what happened to CapitalOne. Just two IAM actions, ‘List S3 buckets’ and ‘Get objects’ (sync command) allowed the attackers access to cause an $80M data breach. With this attack path available from just two permissions, least privilege just isn’t possible.
Image source: ShiftLeft
The same is true when you think about threats due to Privilege Escalation in the cloud. While least privilege claims to protect against lateral movement and privilege escalation, on the cloud you can achieve this with just a couple of permissions. Think about AWS for example. As RhinoSecurity points out in this great blog, an attacker could use ec2:RunInstances and iam:PassRole as just two permissions that allow for full account ownership.
Built-in Managed Policies and Roles
On both AWS and Azure, there are managed policies and roles that are set out by the CSP that can’t be manually changed. In my experience, many users and developers are unaware of the risks of these policies and roles. Two examples are the AWSLambda_FullAccess and AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy. Although these are used by-design to achieve rapid agile development cycles out of the box, making DevOps lives easier, both of these also allow for privilege escalation when exploited.
One good example is the AWSElasticBeanstalkService managed policy that AWS announced for deprecation, and is no longer available for attachment to users, groups or roles, since April 15th, 2021. AWS recommends using the new managed policy, AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy. On this policy, some actions have had certain resources and conditions defined, but privilege escalation is still possible by exploit, a huge security gap. Here’s a gist I created for more information and a proof of concept.
The Endless Work of Creating Least Privilege Rules
The CIEM domain is built around tackling these issues and supporting businesses in achieving least privilege in the cloud. However, in reality, this causes a huge headache for DevOps teams and cloud security owners when attempting to maintain lean policies under strict resource requirements. In some cases, CIEM tools will claim to offer least privilege creation at the build stage, baked-into CI/CD pipelines, but in fact, this ROI is impossible, and the attempt causes an endless amount of maintenance.
Most developers in cloud-native companies are unaware of the risks of managed policies or wildcard policies in the cloud, and that’s fine! It’s not part of their role to gain such in-depth knowledge of cloud risks. In fact, attempting to get up to speed with changing risks of a dynamic environment would slow down the very DevOps pace that they are aiming to achieve by leveraging the cloud. Consider the time that would be spent every time we modify the policies used by our users or applications, for example when we add a new database or new IAM actions. Trying to achieve least privilege permissions here would be beyond tedious. This process involves continuously checking each identity and specific permissions, asking yourself – is it really using these permissions? If I remove one, will it break production or cause problems for the user? It’s not maintainable.
Moving Past Least Privilege in a Cloud Security Environment
Cloud-native companies have just two options. They can take the direction of policies shared between many applications, using default AWS or Azure permissions, which is not least privilege, or they can attempt to create policies for each application and user. This option generates so much maintenance and overhead for security and operations teams, that it negates the benefits of the cloud in the first place.
Lightspin's Solution: An Alternative to Least Privilege
At Lightspin, our approach is to offer Guardrails to solve this use case. By creating your own managed policy that blocks specific attack paths, there’s no need to fight with least privilege. Your teams can work unimpeded without any impact to the pace of DevOps, and instead of getting fine-grained about specific one-to-one connections between the account, or permissions into the resource (all of which need to be maintained), you just set and forget Guardrails that block the potential attack.
Ready to discuss your unique cloud environment? Schedule a call.