Mapping cloud permissions at scale
Most organizations’ cloud estates are growing in size and complexity at an extraordinary, and often underestimated, rate. It's not uncommon for a medium or large enterprise to use AWS, Azure, Google Cloud, and maybe some Alibaba or Huawei. There might be more niche players like IBM or Oracle Cloud lying around too - and that’s just platforms. On top of all of that, there are likely to be plenty of SaaS products like Microsoft 365 and Salesforce.
Each one of these platforms and SaaS suites adds complexity, and because cloud organizations and providers continually add features and services to their offerings, that complexity continues to rise. Manually mapping and understanding cloud permissions—that is, who can do what in your cloud estate—is unfeasible.
If roles, users or groups are set up incorrectly, and if who has which permissions is unclear, attackers can capitalize on misconfigurations with ease, pivot between services, and escalate their privileges to steal data, take services offline, or execute malware.
Verizon's 2022 Data Breach Investigations Report states that over 70% of breaches involved stolen credentials in the cloud. A huge proportion of the breaches Verizon analyzed are either the direct result of misconfigured permissions or where misconfigured permissions have made a potentially minor breach significantly worse.
Identity and access management has long been recognized as one of the major problems in the cyber security space, but the rise in the use of cloud has made the problem demonstrably worse.
The current solutions
Most organizations combine three tactics to minimize this problem: making everything as least privileged as possible, setting up approval workflows, and using periodic human audits.
Theoretically, every individual user should only have the permissions they need to do their job and no more; no one should be able to access any area or resource that they do not need. This is generally considered to be an impossible goal to reach for most organizations that have crossed a relatively low level of size or complexity.
A more common approach is to create and assign pre-made permission sets designed for different use cases. For example, there might be a set of permissions for all developers in the organization, another set for administrators, and other sets for other role-types as required.
Approval workflows can help to reduce the potential for damage when people are assigned the wrong permission set. Someone will request additional permissions through a workplace management solution that request will be reviewed and approved or denied, either by an automated process or an administrator.
This tactic slows down people’s workflows, but it is seen as a necessary evil in many organizations, especially within heavily regulated environments.
This work is often backed up by periodic human audits; someone will look at what permissions have been set up and try to identify cases where someone has been given too many permissions, or where the wrong systems and entities in the cloud have been given the wrong permissions to other systems and entities.
These audits are inevitably time limited, and again do not scale well, especially as cloud estates keep on increasing in size and complexity. This is compounded by the industry-wide shortage of skilled cloud security professionals.
Nick Jones, a Principal Security Consultant at WithSecure, built a tool called IAM-Hunter to help solve this problem within AWS estates. IAM in this context stands for Identity and Access Management.
IAM-Hunter ingests all the different IAM permissions models from different accounts, as well as the service control policies that are applied to those accounts, then looks for cases where different roles and users in the accounts have permissions that are consistent with privilege escalation or dangerous data exfiltration techniques.
But IAM-Hunter cannot automatically find the real issues; it is essentially data sifting tool that prioritizes certain indicators so that human reviewers can do their audits faster. Almost every cloud security tool and cloud security posture management vendor will do a base level of scanning, looking for basic mistakes and common major flaws. These tools are significantly better than nothing, but compliance-based configuration scanning used by many CSPMs will miss more complex issues.
Thinking in graphs
It is important that we think in terms of relationships between different entities and systems and how they interact, rather than looking purely at lists of assets, users, and permissions.
Tools like Bloodhound can map out which users are in which groups and what permissions they have so that you can see how they interrelate in a more intuitive way. However, these tools do have some drawbacks, including that they are all single cloud while most organizations operate in a multi-cloud environment. This means that we have limited visibility by default because these tools do not work together.
Common tools also struggle to model accurately because of the extreme complexity involved in cloud IAM. At least six different policies and influences are factored into every AWS permission request, which will decide whether a user can perform a particular interaction in the cloud. This gets even more complicated when you factor in role assumption, which is an AWS feature that allows you to essentially become a different set of permissions via an API call. The tremendous complexity is simply overwhelming for many tools, which can often result in a high number of false negatives and positives, and inaccurate modelling.
SMT solvers are a mathematical concept for analyzing whether a given formula is satisfiable, that is, is it true for a given set of variables and constraints? These tools allow us to build a data model with conditions and permissions built in, then ask, for example, whether a particular user can do a certain action against a given resource.
Mohit Gupta, a Senior Security Consultant at WithSecure, built IAMspy: an SMT Solver-based decision engine which takes in a variety of policy types and then produces a data model. We can ask it whether something will be approved or denied for a given entity and permission set, as shown in Figure 1.
Figure 1 – The IAMspy model
IAMSpy works offline, so it will be quite useful in cases where live analysis against the AWS APIs is not wanted (such as red team engagements or to avoid AWS API rate limiting).
In the future
The team plans to build a graph-based modelling solution that utilizes IAMspy. This would use IAMSpy to solve combinations of permissions across an entire enterprise, then load those results into a graph-based model. This should allow efficient querying at any scale as graph databases are fast and optimized for that use-case, and the majority of data processing will already have been pre-computed. We aim to do differential analysis based on live updates by subscribing to data feeds and constantly updating the model based on what is happening in a cloud estate in real time.
In the long term, we aim to make this tool operational throughout multi-cloud estates. We will feed the datasets of all the different cloud providers into the analysis engine to produce a multi-cloud map. This will allow us to explore and audit access, but also to define unacceptable situations and prioritize and inform detection and response because we will have a better understanding of how important a breach of any particular user really is.
This article was based on a briefing talk given by Nick Jones, which you can watch here: