More Identities, More Problems, Part 2

4 mins to read

This is part 2 from a previous blog, “More Cloud Identities, More Problems’, available here.

In the first part of this blog, I addressed the reality that identities are proliferating in the cloud to a scale unmanageable for most organizations. We established what was causing this proliferation (machine identities, the scope of the cloud, microservices, least privilege policies, and more) and what challenges were arising as a result of it. In part-two we’ll explore what the answer to this proliferation is.

Organizations are facing two broad challenges in relation to identity proliferation:

  • The tangential explosion of permissions and access to manage for all these identities and the risk unmanaged access poses.
  • Who owns the responsibility of identity and permission management and what tools or solutions should be implemented.

What is so Dangerous About Permission Proliferation?

With an immense number of identities in your environment, comes the tens to hundreds of permissions attached to these identities. The State of Enterprise Cloud Security Report by Sonrai and Osterman Research found enterprises with $100M+ in cloud spending to host over 7,750 identities in their environment. With even just 10 permissions granted to each identity (that’s an extremely conservative estimation) you’re looking at about 77,500 permissions to oversee.

Now, many of those permissions are necessary for identities, whether human or machine, to complete their job function. However, the reality is, the majority are not. In fact, about 95% of accounts use less than 3% of the entitlements they are granted. This leaves about 97% of the permissions in the average cloud as an unnecessary attack surface waiting to be exploited.

This is because most of the privilege identities can grasp is a result of blindspots in your environment. Blindspots are toxic combinations, inherited rights, trust relationships, privilege escalation capabilities, managed policies and more, that lend identities to acquire privileges they were never intended to have. 

Read ‘You’ve Got Identity Blindspots’ blog.

This is modern cloud enterprises greatest risk: unknown toxic permissions. These permissions (and the identities that possess them) are the stepping stones attackers leverage to move laterally through your environment until they find the key to accessing their end goal – your high-value assets and applications.

effective permissions example

Excessive vs Effective Permissions

Security often comes in generations – meaning, there are waves of solutions that address a certain set of contemporary challenges that, overtime, become antiquated as technology (and problems) advance.

Addressing excessive permissions was part of the ‘first generation’ of Cloud Infrastructure Entitlements Management (CIEM) Excessive permissions are any permissions that pass the threshold of what is deemed to be ‘necessary’ for an identity to perform its job function. This threshold could be determined by examining 30, 60, or 90 day audits where if identities do not use specific permissions, they are deemed unnecessary and therefore detached. Excessive permissions are associated with upholding Least Privilege – a policy enforcing identities only be granted the most conservative scope of privilege necessary.

The issue with only considering excessive permissions in your privilege and access management strategy, is you are only considering the past. It is like driving and only looking through the rearview mirror – possible to do, but perhaps not the most secure measure. Excessive permissions does not account for a lot of the privilege in the cloud including things like AWS permission boundaries, like Service Control Policies (SCPs) and S3 bucket Access Control Lists (ACLs), nor phenomenons like Nested Groups in Azure Active Directory or GCP. 

It is through these means that identities inherit unintended permissions. Ones they (or an attacker) can use in the future. Excessive permissions cannot account for these types of permissions. Consider an identity with a ‘read’ permission they haven’t used in 90 days. You detach the permission, but they’re actually a part of a group, that’s part of another group, that’s part of another group, that holds this same ‘read’ permission. While the identity no longer directly holds the permission, they inherit it through this nested grouping – and you would never know…unless you were able to see the identities ‘Effective Permissions.’

Effective Permissions

Effective permissions are the true scope of every and any action an identity can take in your cloud. This accounts for any permission directly attached to the identity, and all the ones inherited through covert means like organization inheritance, nested groups, trust relationships, or managed policies. It is the answer to all your blindspots. Consider the image below – this is the permission-chain lending a serverless function (a machine identity) to acquire access to a data container in a different environment, nine degrees of separation away from it and through several roles, policies, and permissions.

Picking a tool with effective permissions technology innately built into it will give you the super power of understanding what is happening in your cloud in a way that excessive permissions alone, could never conceptualize.

Who Manages Permissions? What Tool Do I Use?

As we discussed in part-one, there is some confusion around who actually should be overseeing and managing identity permissions and access. There are silos between the teams creating identities – often developers, the teams managing human identities – IAM teams, and the team remediating concerns – security teams. There is no single source of truth all teams can work from.

Sonrai commissioned a Forrester study alongside AWS that found enterprises have on average 6 different security tools (and 96% of them still faced a security incident in the previous year.) This leaves one clear takeaway: more tools does not mean more security. Instead, it is about finding the right tool to aggregate all the different alerts and findings into one organized space offering a critical feature: context.

Consider on-prem teams (and even some cloud orgs) using SIEMs and SOARs for incident management. What brought context to those findings were the humans behind the tools trying to make sense of all the alerts and determine what was the biggest priority. 

Today, the right CIEM solution – one with context, automatic prioritization, and the ability to see effective permissions is the answer to all of the challenges outlined above. The context that informs prioritization comes from the effective permissions technology. If you know what every identity can possibly access, and you know what your most sensitive assets are, you know where to focus your attention first. The context is where the security happens. The right CIEM should have a central and integrated workflow that loops in all responsible teams to address that responsibility question.

I think Sonrai’s CIEM is the best of its class because of its mastering of Effective Permissions and excellent operationalized workflow for remediation. If you’re interested in seeing it in action. Ask for a demo and I’ll be there to answer any questions.