The Challenges of Securing Data Access in the Cloud, Part 1 (of 4)

Through a series of four posts, I will explain why I think securing data access in the cloud is so challenging, and why many organizations get it wrong. Let’s start by analyzing the risks associated with the compromising of identities and access permissions, as this has always been a main concern for anyone operating in the cloud. The problem has become even more acute over time as organizations continue to adopt cloud resources as part of their infrastructure without the ability to properly assign and manage entitlements. As a result, users and applications tend to accumulate permissions that far exceed technical and business requirements, thus creating a large permissions gap.

The potential impact of lax authorization can be devastating. Attackers can use compromised credentials with excessive permissions for something like stealing time and CPU to mine Bitcoin. Even worse, excessive privilege can also enable a threat actor to steal sensitive data or delete parts of the infrastructure.

We all learn best through examples, so let’s take a look at an especially interesting one: the Capital One breach of 2019. Before we continue, I want to say that I highly respect Capital One’s technology team. These guys pioneered cloud computing in the banking industry, and what happened to them often happens to trailblazers who test out new technologies. We have gathered here to learn, not criticize.

The problem stemmed, in part, from a vulnerable open-source Web Application Firewall (WAF) that Capital One used as part of its operations hosted in the cloud with Amazon Web Services (AWS), its Cloud Security Provider (CSP). This vulnerability allowed the attacker to obtain credentials to access any resource in the account to which that WAF had access.

In AWS, exactly what access is associated with a set of credentials depends on the permissions assigned to the entity. In Capital One’s case, the vulnerable WAF was assigned excessive permissions, i.e. it was allowed to list all files in any bucket of data, and to read the contents of each of those files. These excessive permissions allowed the attacker to obtain access to a sensitive S3 bucket.

To mitigate risks associated with excessive permissions in the cloud, you should be looking to adopt the principle of least privilege. In an ideal world, every user or application would be limited to the exact permissions required. In practice, however, the effort required to determine the precise permissions necessary for each application in a complex production environment is prohibitively expensive and doesn’t scale.

In the next posts in this series, I will examine the AWS Identity and Access Management (IAM) service - a powerful tool that allows you to securely configure access to AWS cloud resources. With more than 2,500 permissions (and counting), IAM gives users fine-grained control over which actions can be performed on a given resource in AWS. I’ll begin with AWS IAM because as of today, AWS is the most popular platform, and it offers one of the most granular, and therefore complex IAM systems out there. I will also take a look at additional cloud providers, namely Azure and GCP, and highlight the differences between the Big 3. My hope is that you will gain some practical tools and information as you progress through the series.

The first step to achieving least privilege, and removing excessive permissions, is to understand which permissions a given user or application has to begin with. But even such a simple task might not be as straightforward as you think.

Stay tuned for the next post in this series, where I’ll dig into IAM policies...