7 mins to read
2022 CIEM has emerged on the market as the best solution to tackle identity and access management in the cloud. Cloud Infrastructure Entitlement Management (CIEM) solutions help organizations gain visibility into their public cloud environments where identities come and go and their permissions evolve constantly. But, just because you know you need a CIEM solution, doesn’t mean the specific use cases are crystal clear. Sometimes having real-world examples is what makes a concept tangible. Oftentimes in our conversations with customers or prospects, people aren’t even aware of the possible risks regarding identity, and therefore the solutions available to manage them.
In this blog, we’ll explore several examples that build off of each other, to point out when exactly a CIEM solution could save the day. These real-world examples are inspired directly from what customers are experiencing today and are running totally blind to, until shown.
Non-Person Identity
The story:
You have an AWS Lambda function generating Tableau reports in a sandbox environment.
A few years ago, back when your organization was much smaller, this Lambda inherited permissions through a role that had an inline policy attached to it. At the time, your permission pathways were more direct and your environment more simple. While this was harmless at first, these inline policies can, when multiplied, create a technical debt that will come back to haunt you. Here’s why:
This AWS Lambda role inherits a trust relationship to a TableauTester role through a policy. Through the attached inline policy and managed policy, your AWS Lambda role can utilize that trust relationship to assume another role all while still in the sandbox environment. The AWS Lambda role now can access the TableauTester role. This Tableau Tester role is where things go wrong because often this happens in sandbox environments. An overpermissioned role with access to another role in a sandbox environment is now promoted into a production environment. This mistake we often see through the “AssumeRole” because your team may need to create temporary credentials within your account or for cross-account access.
The TableauTester role needs to be able to deploy infrastructure, so the managed policy in this environment allows it to have access. However, this managed policy actually inadvertently opened up some other opportunities for this TableauTester role. The managed policy has some trust relationships to both a builder role and a role deploy function in a production environment. So now your sandbox Lambda function has access to a production environment, and can suddenly build and deploy roles through a variety of trust relationships. This means it can create its own roles and create its own infrastructure in production. This can be used to deface your website, to affect an application, deploy ransomware, or anything a criminal wants. In sum: this Lambda function in a Sandbox account can ultimately take action in a Production account, through a variety of misconfigurations and trust relationships.
The answer:
Your organization cannot fix what it cannot see, and without a CIEM solution that can actually see this, uncovering the complex web of access paths and identity chains existing in most modern cloud environments is nearly impossible. In this example, deepening your understanding through a CIEM capability that can map out the effective permissions of this Lambda function across AWS accounts could be critical to the security of your production environment. This allows your team to hone in on that Tableau Tester role as the turning point for where permissions get out of hand. To the human eye, one cannot easily see how this non-person identity is able to perform the most sensitive actions in your environment, but the right CIEM solutions can.
Azure Excessive Permissions
The story:
Your organization is also an Azure customer and you use Azure Active Directory. You have an Azure AD user, ‘Azure Admin’ that is a legacy account for an early hire in the company. It has been years and your organization has no grasp on the full scope of its permissions as inventorying has proved to be too overwhelming manually. On the surface, there appears to be no problem, but let’s dive in a little deeper to what’s going on behind the scenes.
It turns out, this identity has a number of roles assigned to it including ‘Global Admin’, ‘User Access Admin’, and even an ‘Owner’ role in Azure Active Directory. This ‘Owner’ role gives the identity star permissions, which means it can essentially do whatever it wants in your Azure environment. This identity is the owner of everything in this subscription and this type of power becomes problematic when you consider that this identity can, for example, get into your blobs in the Production environment or Azure SQL, and maybe access your company’s most sensitive data. This identity is the perfect target for exploitation as it offers a direct path for bad-actors to get what they want – leeway in your environment and crown-jewel data.
The answer:
With the help of CIEM solutions, your organization would be alerted any time identities hold excessive permissions. Additionally, mature CIEM solutions provide clear and actionable remediation tips within that alert ticket. In this case, a case of excessive permissions, the clear answer is to detach permissions that have proven to be unnecessary to an identity’s job function, i.e. the ‘Owner’ role. Perhaps stripping the privilege is not the answer, and this identity needs access to the ‘Owner’ role, a CIEM solution may suggest an alternative option of customizing the role to detail what actions exactly are necessary within the role, as opposed to offering a full scope of everything. Lastly, taking things even further, a CIEM solution has the ability to include a policy that detects high-level credentials vs. just sensitive ones. This allows your team to prioritize the most concerning issues first. Once again, a CIEM is the only way to visualize the effective permissions of an identity so that you can reveal the covert dangers manual efforts may have missed.
Nested Groups in Active Directory
The story:
In your Azure tenant, you have another identity, an IT Manager, named Jen Archer. Jen Archer has full read permissions through the ‘Reader’ role in a Management Group. Through this role, this identity can read all data inside of your Azure subscriptions: sandbox, development, staging and even production or any other operations subscriptions. Jen hasn’t used this permission in 30 days. Just this alone is our simple excessive permissions use case. But let’s continue the story granted your business finds a use case for Jen Archer to have read permissions.
Jen is supposed to only have reader permissions inside your environment, but covertly has ‘Write’ permissions in Production. How? This brings us to our next CIEM use case, the nested groups. Jen Archer is assigned to the ‘AllEmployees’ group; within that she was assigned to the ‘IT’ group. Sometime in the past, this IT group was assigned to the ‘Security Team’ group. The ‘Security Team’ group has access to a policy, ‘Security Admin’, which holds the write permission. While it is legitimate for the Security Team to have the permission associated with it, it results in Jen Archer, an IT Manager, having access to the ‘Security Admin’ role. With this access, she can make changes to permissions across the subscription. This should be ringing alarm bells.
The answer:
It is fair to conceptualize nested groups like Russian dolls, one living within the next. An organization would struggle to understand what complexities exist within their environment that allow your average IT employee to have admin access to an entire subscription. This is where CIEM solutions shine. Sometimes permissions are not directly attached to an identity, and there are more covert or undetectable ways acces threads through a number of roles, policies or in this case, groups.
Multi Cloud
The story:
Now at the same company as Jen Archer, there is an employee, Kevin Keller, who is a DevOps user in a Dev environment. Kevin is in a similar situation as Jen’s so the excessive permissions through nested group use case applies here as well, but there’s even more to this story. Kevin Keller actually has no direct attached permissions. But, the reality is Kevin can actually access your AWS environment and assume several roles. Shockingly, these roles include the Tableau Tester role, which we know from previous examples has a lot of issues. But how is this possible if Kevin is an identity in your Azure AD environment?
Because Kevin is a developer, he needs access to the Tableau Tester role in the AWS sandbox environment from example 1. While this permission is legitimate, it opens far more doors than intended. This Tableau Tester role has the effective permissions that allow him to assume the ‘DeployInfrastructure’ Role (all still within a sandbox.)
However, this ‘DeployInfrastructure’ role has to have Active Directory access because when it deploys infrastructure in AWS, it needs to give the Security Team access, because this company is using Active Directory for SSO. The team needs access to the resources in both AWS and Azure.
In Jen and Kevin’s organization, the Security Team has the ability to impact all of their Azure tenant for a legitimate business need. However, through toxic combinations, the result is Kevin Keller, an IT employee working in Development, has the ability to directly impact all of Azure AD. If Kevin’s credentials were ever impacted, that criminal now has the keys to the entire Identity kingdom to do as they wish.
The answer:
This example is an important one as many organizations are multi cloud. This only adds to the complexity of your environment, making it that much easier for inappropriate or dangerous permissions to fall through the cracks. As we learned in the first use case with the AWS Lambda function, the ‘Tableau Tester’ carries a lot of power and offers Kevin privileges he should not hold.
Conclusion
The ever-growing web of identities and their permissions allows for infinite potential pathways to danger in the cloud. The complexity is overwhelming, but the connections between identity and data are so critical, they demand our full attention. The time has come to rely on third-party tools that can help reveal these risky pathways to sensitive data, excessive permissions or over-permissioned identities.
Sonrai Dig has graphing technologies & an effective permissions engine that can visually map out every role, trust relationship, identity and policy so that you can see the effective permissions of every identity in your organization.
Find the pathways or identity chains in your environment that allow your average IT employee to jump a few hoops and acquire admin level privileges.
To learn more about what CIEM solutions can offer your organization, explore our use case page.
