The cloud has redefined the perimeter. And, as a result of the growing adoption of cloud environments, the ways in which security teams protect critical infrastructure and data have fundamentally changed.
Consider that privileges define what a user or administrator can do or access within a system or application. In a traditional on-premises environment with a defined perimeter, an attacker using a compromised account will often exploit bugs or misconfigurations to give that account more privileges than it is entitled to. From there, the attacker can potentially gain access to sensitive data or deliver a malicious payload.
But in the cloud-centric world, identities are the new perimeter—and they are proliferating, increasing the scale of identity risks. The nature of the cloud exacerbates a lot of the risks we have seen in on-premises environments—including, in particular, privilege escalations and lateral movement.
At Sonrai Security, we recently discovered that approximately 10% of enterprise-cloud identities have full administrative permissions—enough to completely compromise an organization’s cloud environment. We also measured more than 35,000 unique permissions available across AWS, Microsoft Azure, and Google Cloud, with 20 or more being created daily. We estimate that in AWS alone, there are 10,000 unique permissions, 1,800 ways to create resources, and 1,300 ways to delete them. This means that within your environment right now, there are a multiplicity of ways for a bad actor to delete infrastructure, deploy a cryptominer, access your sensitive data, or exfiltrate business-critical information.
The challenge is that traditional network segmentation, firewalling, and even first-generation cloud-security-posture management (CSPM) tools are not sufficient to find and eliminate the identity- and data-security risks in the cloud. Using the MITRE ATT&CK framework as a guide, let’s look at how privilege escalation and lateral movement act in the cloud—and how to properly address them.
Privilege Escalation
With identities the new perimeter, you need to look beyond users to non-person identities (NPIs)—the pieces of compute, serverless functions, roles, service principals, etc., that exist in your environment.
When privilege escalation occurs in the cloud, an identity can be used to delete files, view private information, or worse. This typically takes one of two forms:
- Vertical privilege escalation, where a lower-privilege identity accesses functions or content reserved for higher-privilege identities; or
- Lateral privilege escalation, where an identity accesses functions or content reserved for other identities.
The challenge with privilege escalation is that it often happens right under your nose. For example, let’s say your security team locks down a workload at least privilege but misses an NPI with a permission allowing it to manipulate another role. Even though the workload is at least privilege, it can still execute malicious acts by manipulating another identity.
Breaking things down further, the cloud enables five specific types of privilege escalation:
- Direct self-escalation: This is when an identity (for example, a global admin) can modify its own rights and has all the permissions it needs to move throughout your environment.
- Indirect escalation: This is when one identity can modify another identity’s credentials to impersonate it.
- Unintended inheritance: The result of cloud complexity, unintended inheritance gives a web of rules, policies, trust relationships, and permissions access at an unintended level.
- Confused deputy: This is an identity with a low level of permission that gets access to resources or service with a higher level of permission—and then uses that permission to perform actions on its own behalf.
- Resource-permissions escalations: In this scenario, an identity has the permission to change the configuration settings on a resource to allow the identity to perform unintended actions on that resource too (such as the ability to delete it all).
Lateral Movement
Lateral movement refers to the general movement of an attacker through your environment in search of and toward a target. Lateral movement may take the form of privilege escalation—or of an attacker simply moving from one identity to the next, looking for the right one to execute their desired plan.
It should go without saying that the ability to detect lateral movement is a critical security requirement—which may be why “visibility” is such a buzzword in security. Lateral movement in the cloud is achieved using identities (including NPIs) as steppingstones. This exemplifies why identities are the new perimeter in the cloud. They represent the key to accessing your data. More identities means more permissions—and, ultimately, more paths to your data.
On top of the more than 35,000 unique permissions already available across the three biggest cloud service providers (CSPs), we estimate that an average of 20 new permissions are added each day. Most organizations are completely unaware of these paths. But it only takes one over-privileged identity to compromise your cloud and enable an adversary to get to your data.
Consider the following rather straightforward example of what lateral movement in AWS looks like:
- A DevOps user in a dev account can assume a role in the same account. This is intended for building their application.
- That role can assume other roles in the dev account due to a misconfiguration. One such role is codePipelineDeploy. This role has a trust policy in the production account for the application.
- As intended, the codePipelineDeploy role can access the data stores in the production account, a lateral move into an account with data-store access.
When we look at the effective end-to-end permissions of the DevOps user, the user is not confined to their dev account to build and deploy their application; they are also able to use identity misconfigurations to access sensitive data in production. This excessive access in the public cloud is ubiquitous. For a bad actor, it is like winning the lottery because it allows lateral movement from a low-security area to a very-high-security area. Bad actors use lateral movement to find an identity that gives them access to what they are really looking for.
Watching your networks, in and of itself, is not sufficient to protect you in the cloud. The real concern involves limiting what moves attackers can make once they’ve infiltrated your network. This means ensuring that identity security is at the core of your cloud-security strategy. Accordingly, at a minimum, you should consider investing in automation that will help achieve the following strategic objectives:
- Continuously inventory all your cloud identities (especially the non-person ones)
- Model the end-to-end effective permissions of each identity
- Discover every asset and application they have access to
- Continuously monitor identity and data-access behavior
ID the IDs
The MITRE ATT&CK framework serves as an excellent road map to show how adversaries can access your data using identity. Misconfigured identities play a significant role in granting an attacker a pathway to your sensitive data across multiple stages of the attack framework.
Enterprises need to model all identities (person and non-person) to determine their effective permissions and look for identities that have highly sensitive permissions. But this is only a start. It is also necessary to determine whether these identities need those specific permissions to complete their job. Naturally, you’ll need to understand which permissions and what level of access each identity actually does need in your organization; this will all depend on the job role/function of each given individual or NPI.
After that, it is critical to monitor remaining identities and permissions to ensure that they are being used only as expected.
After all, poorly configured identities and entitlements in the cloud can be enormously damaging to an organization’s security posture. Enterprises must lock down this new perimeter and apply preventative controls. This will help them to mitigate risk before it becomes an incident—as well as respond quickly when an incident does occur.
