Top 3 Identity Risks In Enterprise Clouds

Originally published by Sonrai Security.

Written by Tally Shea.

After months of reporting on what identity and privilege risks are leaving organizations vulnerable to data breach and business disruption, where exactly those risks are, and how to fix them, one thing has been made clear: There’s a gap of knowledge between what security leaders think to be true about their cloud security and its actual state of affairs.

We’ve analyzed our findings and gathered the top 3 cloud identity risks plaguing multi-cloud enterprise environments.

So, your peers are struggling with these three things, are you?

1. Unknown Inherited Admins

Admin identities carry inherent risk – they hold a lot of power by nature. There are a lot of security controls and practices to protect these privileged identities and limit their usage, but these efforts only help the ones you know about.

Yes, there are identities with admin privilege in your cloud that you never explicitly assigned. This privilege is somehow inherited through various permission-chains involving access keys, roles, groups, and other means. To illustrate how this sort of inheritance comes about, we’ve grabbed an example from a Sonrai policy violation:

AWS SAML User gains cross-environment access via a role assumption inherited through an AWS SAML group. From there they can assume an additional role, which grants them admin access in another environment.

Enterprises we talk to are confident they don’t have unknown admins. Why wouldn’t they be? They use cloud-native directories, PAM, IGA, and IAM tools that all assure them their admins are accounted for and safe. But that’s the thing – these solutions do not see inherited admins. They do not analyze cloud permissions at the level of granularity necessary to see inheritance through permission-chaining.

In one multicloud enterprise cloud we analyzed, almost 50% of total admins were inherited admins in the Diagnostic results. That means HALF of all admins were unknown to the organization and therefore unsecured.

Sample Diagnostic report detailing associated risks with privileged identities including inherited and machine admins.

Unknown human admins are not the only cause for concern. The Diagnostic research reveals swarms of rogue machine admins in enterprise environments – that is machine identities with org or tenant-level admin privilege.

In fact, machine identities comprised 71% of the identities with admin privilege in one run-of-the-mill enterprise cloud – unbeknownst to their teams, of course. Not to mention, machine identities should almost never hold admin privilege.

So, do you know if you have unknown inherited admins and rogue machine identity admins in your cloud?

2. Third Party Privilege

There are many use cases for trust relationships and policies across the different clouds, but a frequent one is allowing third parties to have access to your environment and cloud resources. However, allowing a third party to enter your cloud is creating the potential for an open door directly into your environment.

In the Diagnostics we’ve run, managing third party privilege is a recurring challenge for multi-cloud enterprises. This can be broken down further into two specific risks – overprivileged third party identities and dormant third party identities.

The danger of overprivileged third parties is quite apparent – an external entity that you have no control over has great power in your environment and the potential to exfiltrate data or disrupt your business. Many cloud breaches are the result of a compromised third party. Your security can be top notch, but if a contractor you use goes down, you can go down with them.

Read about LastPass breach caused by a third party compromise.

The danger of dormant or unused third party identities is not as obvious, but unused identities can represent a significant chunk of the risk in enterprise clouds.

In one of the Diagnostics we analyzed, 91% of the third-party identities in the environment were unused. These identities likely once served a purpose, but projects, contracts and tests ended, and these roles, trust policies and identities remained. This represents an unnecessary and increased attack surface waiting to be exploited.

Sample report from the Diagnostic analyzing risks associated with trust relationships.

If a trust policy assigned to a third party is unused for 30-60 days, this should be flagged for recertification and likely removed.

Removing unused identities in general proves to be an extremely efficient way to significantly reduce privilege and access risk. Your IAM tool may be flooding your teams with lateral movement or privilege escalation alerts, but if those risks are tied to unused identities, simply removing the identity will trickle down into reducing potential attack paths.

So, do you know if you have dormant third parties lying around unused and overprivileged in your environment?

3. Privilege Escalation

The final risk we’ve seen enterprises struggle with the most in our Cloud Identity Diagnostics is related to opportunities for direct and indirect privilege escalation. This occurs any time an identity has some combination of permissions that allows it a path to escalate its own permissions. Sometimes the identity can directly self escalate, but other times an identity can actually alter the permissions of another identity that they can then assume or manipulate to execute their intended goal.

Sample image from the Diagnostic report analyzing lateral movement risks including privilege escalation.

These scenarios are extremely dangerous as an attacker could acquire whatever privilege they desire and have their way with your cloud.

Insight into privilege escalation potential is very difficult. That is because privilege escalation potential is often the result of very complex webs of inherited or gathered permissions. To illustrate the kinds of pathways that create privilege escalation, we’ve gathered an example from a privilege escalation policy violation from our platform:

Sample image from a Sonrai privilege escalation policy violation.

This graph shows an Active Directory user, Daniel, experiencing what we call ‘nested grouping’ where they are a part of several groups that each have their own permissions assigned to them, but the combination of Daniel’s participation in all of these groups creates a toxic combination that grants them greater privilege than they should have. In this case, Daniel is able to gather enough privilege to escalate into being a Security Admin.

No cloud-native directory or traditional IAM tool could compute this end result for you. They can tell you Daniel is directly in the ‘all employees’ group and ‘devops’ group, but not that he inherits the privilege of the ‘architecture’, ‘IT’ and ‘security team’ groups – and that all those combined grant him the ability to escalate to Admin level.

So, do you know if you have low-level identities with paths allowing them the ability to escalate their privilege into dangerous power?