Unlock the power of modern technology to transform your business.
Choose the service that is right for your organization:
Choose the training that is right for your role:
Learn about the Oteemo Way.
Meet the members of Oteemo!
Cloud, Cyber Security, Cloud Security, Cloud Native
by Chris Hughes | Dec 30, 2020
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 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.
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.
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.
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.
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?
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Save my name, email, and website in this browser for the next time I comment.
Submit Comment
11 Cloud Native Transformation Lessons You Need To Know
An Overview of Google Anthos
Kubernetes Security 101 | Learn Best Practices With Oteemo