Sharing is caring, and in the cloud, no one cares more for your workloads than you.

There’s no denying that cloud computing has revolutionized the IT industry and just about any industry leveraging IT to support business operations. Aside from the common benefits of cloud computing such as reduced CapEx, elasticity and scalability, cloud also allows organizations to innovate and shed cumbersome on-premise technical debt. Organizations are increasingly adopting cloud, and COVID-19 and the rapid expansion of the remote workforce have only exacerbated this reality. With the proliferation of cloud computing, traditional perimeter-based security models are no longer sufficient and organizations are attempting to scramble to a Zero Trust-based model, where data and identity represent new perimeters. 

That said, many customers rush to the cloud without understanding one of the most fundamental aspects of cloud computing: the Shared Responsibility Model. The Shared Responsibility Model helps delineate what the cloud consumer is responsible for and what the cloud service provider (think Amazon Web Services, Microsoft Azure or Google Cloud Platform) are responsible for. While this model can change depending on which service model the customer is consuming (IaaS, PaaS, and SaaS), the customer ultimately still bears some responsibility. 

Below is a depiction of the Shared Responsibility Model from the leading CSP, Amazon Web Services (AWS), which is largely the same across other major CSPs. While AWS does take responsibility for its hardware and global infrastructure, the customer still bears various responsibilities, including Identity & Access Management (IAM), and ultimately the safekeeping of their data. It is commonly said that the CSP is responsible for the cloud, while the customer is responsible for what is IN the cloud. This means the CSP is responsible for the underlying infrastructure (hardware, power, etc.), but the customer is responsible for what they place in the cloud, such as data. Many customers rush into cloud without understanding this reality. When things go awry, they often look to the CSP for answers as to why risks, including those associated with IAM, weren’t mitigated. It also leads many to claim that the cloud is insecure and shouldn’t be used for sensitive data, despite the fact that the majority of cloud breaches involve customer misconfigurations and breached credentials, which were the responsibility of the customer to begin with.

AWS Shared Responsibility Model 

So what’s the big deal?

So why is this such a significant point when discussing cloud data breaches? Based on the 2020 Verizon Data Breach Investigation Report, “77% of cloud breaches involved breached credentials. This is not so much an indictment of cloud security as it is an illustration of the trend of cybercriminals finding the quickest and easiest route to their victims.” This is further bolstered by the SANS 2020 Enterprise Cloud Incident Response Survey which found that 30%+ of all cloud incidents involved unauthorized access by an external party and misconfigured IAM roles. Misconfiguration is a problem that runs rampant in cloud environments and can lead to risks such as excessive access to sensitive data and unauthorized access by external parties. A survey conducted by Ermetic found that across 300 CISOs, among their primary concerns with cloud include security misconfiguration and IAM permission errors. 

As demonstrated above, breached cloud credentials are a widespread problem. CSPs have come under increased scrutiny to do more to address this issue and to try and help cloud consumers avoid these risks, and to be fair, they have tried. AWS, for example, has implemented secure-by-default configurations for things such as S3 bucket policies and IAM roles and trust policies. Additionally, they’ve implemented warnings to try and make it evident to administrators of customer environments that they’re introducing risk by their configuration changes, yet the issue is still pervasive. 

While cloud environments offer tremendous opportunities to organizations to innovate, scale and be dynamic, they also introduce complexity, ambiguity and the need for a new security paradigm. Let’s take a look at an example of just how widespread a misconfiguration issue can be and the impact it can have on an organization. 

Real-World Example – Palo Alto Cloud Threat Report 2H 2020

For our example, we’re going to take a look at the recently published Palo Alto Cloud Threat Report and something their Unit 42 researchers discovered when working with a large enterprise customer. This customer, in particular, had thousands of workloads operating in AWS, with hundreds of S3 storage buckets and 1,000 IAM roles across four AWS accounts. 

While the researchers identified a number of vulnerabilities/deficiencies, one deals with a misconfigured IAM trust policy. AWS utilizes trust policies to determine who you trust to assume a role within your cloud environment. This trust policy is attached to a role in IAM and you can define the principals (e.g. identities/entities) you trust, which can include users, other roles and even other AWS accounts outside of your organization. While trust policies are often used for roles and identities within your organization, they are often used to allow external access with business partners and external service providers as well. 

However, herein lies the problem and risk for misconfiguration: When dealing with trust policies for AWS accounts, you generally will define the AWS account ID(s) associated with the account you want to trust. Failing to do so properly can open the door to malicious actors seeking to obtain unauthorized access to your cloud environment. 

That is precisely what happened in the activity Unit 42 conducted. While working with their initial large enterprise client, Unit 42 identified a misconfigured IAM trust policy, which allowed ANY user who is not in the account to assume the role and obtain an access token. Rather than defining specific AWS account ID(s), this customer had prescribed the always dangerous “*” identifier, which essentially means ANYONE can assume the role and its associated permissions. The researchers did just that, granting themselves access to the customer’s environment and the associated permissions of the role. From there, they were able to enumerate roles, procure temporary access, see all the instances in the environment, access S3 buckets which contained sensitive data, utilize KMS to decrypt ciphertext, and obtain plaintext credentials and sensitive data. What’s worth noting in this case is while it is common to hear about insecure S3 buckets, this particular insecure configuration exposes not just S3 buckets but various other customer resources and potentially their entire infrastructure.

Example of * Trusted Entities

As seen above, this misconfiguration allowed the team extensive reach into the customer’s environment and the ability to wreak havoc which included accessing sensitive data, encryption keys and the potential to delete entire infrastructures and data stores. While this sort of finding may seem obscure, it isn’t. The team conducted extensive searches of GitHub repositories and identified 68,361 role names and 32,987 potential accounts. Many of these accounts could possess the same sort of overly permissive trust policies and likely do, based on the overwhelming number of cloud data breaches involving misconfigurations and poorly managed IAM roles as mentioned in the studies above. 

Infrastructure-as-Code (IaC): It’s great until it’s not

If you’ve been working with cloud computing for any time, you’re likely familiar with Infrastructure-as-Code (IaC). But for those who aren’t, it is the modern way of deploying infrastructure in cloud environments through common formats such as YAML, JSON and others. CSPs have native offerings such as AWS CloudFormation or Azure Resource Manager (ARM) templates, but more and more organizations are taking a provider-agnostic approach that allows them to implement IaC across multiple CSP environments. The most popular agnostic IaC tool available today is Terraform. The benefits are great since it can serve as a single source of truth for your infrastructure, is repeatable, modular, eliminates human error in management consoles, and hardens the configuration and provisioning process. 

However, it can also introduce risk, when errors and misconfigurations exist within your IaC, just as they did within the example Unit 42 discovered. The Trust Policy Misconfiguration existed in their Terraform code, which was utilized across their various environments, including production, development and even government clouds. This misconfiguration was then replicated across multiple roles in multiple accounts, causing a cascading impact of risk and vulnerabilities across their entire ecosystem. To avoid these sorts of issues, you need a rigorous versioning strategy and also must implement IaC scanning to identify and remediate vulnerabilities before they’re replicated across your infrastructure.

But what about the CSP, shouldn’t they do their part?

When these sorts of findings occur, or worse, an incident and data breach occurs, there’s always a lot of cloud naysayers who claim “see, the cloud isn’t secure!” This has no context of the incident and seems to absolve the customers of their responsibilities under the Shared Responsibility Model we discussed. 

In the case of the AWS IAM trust policies discussed above, AWS has designed them to be secure-by-default. This required a manual configuration change by the customer, then of which they’re met with a notification that their configuration change is introducing insecure configurations. That said, they did it anyway, and often move forward with the configuration change anyways, either not understanding the implications, or worse, ignoring the risk entirely. 

In an environment where the CSP is providing a secure-by-default implementation and accompanying that with several warnings to cloud administrators that their changes are introducing risk to their organization, we can no longer continue to blame the CSP. 

So what can we do?

As the cloud consumer, what are some options or best practices to avoid these sorts of misconfigurations when it comes to cloud identities, roles and permissions?

• Spend more time gathering requirements: Understand, in its entirety, the migration and consumption-model for cloud. Define the business rules if they exist in the client organization, prior to any implementation efforts. If those rules don’t exist, now is a good time to create them. IAM configurations should mirror the organization’s existing model for IAM and accurately reflect those processes. A lack of this critical understanding will plague your cloud operating model at every stage in the consumption lifecycle. 
• Utilize cloud-native services that are available to assist:  In the case of the overly permissive AWS IAM trust policy above, the organization clearly wasn’t using services to help identify these issues. Services such as AWS IAM Access Analyzer can help you identify resources in your account that are shared with an external identity. This helps avoid unintended access to your resources and data. AWS IAM Access Analyzer identifies access grants to principals outside of your zone of trust and generates associated findings for these items. In addition to analyzing trust policies, IAM Access Analyzer also can provide findings associated with S3 buckets, KMS keys, Lambda Functions and SQS Queues — all of which can introduce risk to an organization.
• Utilize Open Source tools to evaluate your IAM policies: In addition to native tools such as AWS Access Analyzer, you can use Open Source tools such as Policy Sentry (reference below) to evaluate/generate IAM policies that take a least permissive approach and limit the blast radius of AWS account compromise and other IAM related vulnerabilities/risks. 
• Upskill your workforce: Many organizations are rushing to cloud and even have an entire cloud migration roadmap that focuses on technological innovation and modernization. However, often forgotten in the picture is upskilling your workforce. This can include training and education for existing resources, hiring qualified cloud professionals and bringing in trusted partners to help advise and assist as part of your cloud migration and maturity efforts. Understanding these cloud platforms and their associated service offerings, nuanced permission implementations and more is a daunting task. To do so, you need to have a competent workforce prepared to do so, either internally, or externally with trusted partners and advisers. 
• Establish a Cloud Center of Excellence: Among the AWS Well-Architected Framework and its associated five pillars is the recommendation to establish a Cloud Center of Excellence (CCoE). This team can help serve as a centralized source of cloud expertise and guidance across the organization as it relates to cloud, including cloud security. They can help establish guidance, best practices and organizational-wide policies to mitigate risk. Similar frameworks are available from other major CSPs as well.
• Mitigate Infrastructure-as-Code (IaC) Risks: While IaC is an excellent capability that allows for modularity, automation, configuration control and more, as seen above in the Unit 42 example, it can also introduce vulnerabilities when implemented poorly. It is recommended to utilize an IaC scanner to help identify insecure configurations such as overly permissive roles, network exposures, and compliance violations. You can also implement Policy-as-Code (PaC)/Compliance-as-Code (CaC) which can help ensure specific insecure configurations are not permitted in your IaC templates. One example is Terrascan (link in references), which can help identify misconfigurations or vulnerable configurations in common CSP environments such as AWS, Azure and GCP.
• Understand your Responsibilities: As mentioned in the initial section of this post, the Shared Responsibility Model is a great construct that establishes a partnership between the cloud consumer and cloud service provider. However, it is critical for organizations to be clear on what their responsibilities are in the SRM and ensure they are doing their part to protect their data and workloads. At the end of the day, no one will care for your data and organizational interests as much as you.