Do You Know Who's Lurking in Your Cloud Environment?

Most organizations don't have full visibility into what users can do in their cloud environment. They don't know who can assume other identities to escalate privileges or which permissions they'd be able to achieve – a lack of insight that could put the business at risk. 

Colin Estep, senior security researcher at Netskope, started researching potential security holes in Google Cloud Platform (GCP) about a year ago. In that time, he has sought to learn how more organizations can evaluate their full identity and access management (IAM) exposure to be able to answer the question: Do you know what all your users can do in your cloud environment? 

"Overall, for any cloud platform that's what's been intriguing to me: asking this really basic question that nobody really has the answer to," says Estep. "The answer to that is largely, 'No, I don't know what every single user can do. I don't know what their full capabilities are.'"

The general issue of IAM in the cloud stems from the dynamic nature of cloud environments, he continues. Fast-moving resources are constantly changing – people are working on different projects and spinning things up, and new services are emerging. The rapidly evolving nature of the cloud makes it difficult for organizations to stay informed on what these new services are, how they work, and what the implications are for permissions to various resources in the cloud.

"It's just this monumental thing to get a handle on," Estep explains. "Identity, in particular, is really one of the critical areas because … if you don't have your identity solution figured out, then you could expose sensitive data, you could have resources be abused or deleted – all kinds of things could happen in your environment."

Estep, who had previously worked with Amazon Web Services (AWS), began working with GCP due to Netskope's heightened customer demand. He found Google's platform interesting and different in the way it structures and grants permissions to employees.

"I feel like Google had a lot more of a layout in mind … where they have a hierarchy within the environment and you can assign permissions in this hierarchy," he explains. GCP also does not have "deny" policies. While it tries to keep permissions policies simpler, Estep says things can get complex when admins have to put different layers together to figure out what's going on.

This is partly why he decided to focus his research on Google Cloud, which is also the topic for his upcoming Black Hat Europe talk, "Permission Mining in GCP."

What's the worst that could happen if an attacker gains too much access? "The sky's the limit," Estep says. As part of his research, he developed a proof-of-concept tool (PoC) for businesses to learn permissions granted to employees throughout their environments. When the tool was used in production environments, the findings were worse than what he expected to find.

For example, it discovered instances where the environment owners had no idea how many users were actually "shadow admins," meaning they could escalate privileges until they had full capabilities over the environment at an organizational level. GCP has a notion of an "organization," which is the topmost piece of the environment, Estep explains. Employees who have admin level of the organization inherit admin capabilities throughout all levels.

"They could go in and change logging, they could go in and create resources, they could delete things, access all the data, add users for themselves," he says. "They could probably do everything except delete the entire environment."

By learning who has which permissions, a business can address the risk before a data breach or another security incident happens.

Services Drive Complexity, Worsen Visibility
Google is keeping its eye on this issue, notes Estep, who says the company has done a good job on authentication versus authorization. However, there is a broad issue across cloud providers of too many services creating complexity. Instead of simplifying a process for customers, many will instead create more services to address the complexity in some way.

As an example, he describes additional controls that state permissions can only be used under certain circumstances or in a specific part of the organization. However, because these controls may fall under a different service, it's outside the normal permissions. This introduces a problem for admins who query permissions for users to see what they're capable of accessing.

"It's still not the full picture because now I have these outside controls that have some effect on it," Estep explains, noting again this issue is not unique to GCP. "And that introduces more complexity. In my mind it's more of a headache now because, as a customer, you have to take that into account, and maybe you don't know that it exists."

A Solution Comes Into Focus
GCP has many hierarchies and permissions. In order to understand their full effect, admins have to look at all the layers together – tough to do in the console, Estep notes. His solution aims to provide a simple way for businesses to map out permissions granted to members, GCP environment structure, and service accounts.

"This project was originally a PoC where I wanted to see if I could answer the question of, 'Do you know what all your users can do?'" he says. The first version, which will be released at BHEU, looks at users and their permissions to see which service accounts can be impersonated.

The solution uses a graph to map out the entities and relationships so admins can see which permissions are attached to GCP users. Once it obtains the relevant data via API calls, the graph maps out the information admins need in a way that's digestible. While he initially didn't want to use a graph, he says it was the best way to consider the many different layers together.

Estep's approach to solving the visibility problem is still young and doesn't yet consider other services, though it's a capability he'd like to integrate in the future. 

"Let's just get the permissions aggregated together in one spot first," he says. "Then we can start adding to that."