Mapping Top Security Risks to Core AWS Services

The world has largely transitioned to be cloud-first, and in this evolution, AWS has emerged as the market leader when selecting cloud infrastructure. AWS is no longer just infrastructure, in its growing marketplace and ecosystem of tools and add-ons are a vast array of core services that drive business operations and innovation. 

However, like all engineering domains, without proper security measures, these services can expose sensitive data, invite unauthorized access, and lead to costly breaches. In this post, we’ll explore some of the current security concerns & risks, and map them to the most popular and core AWS services. 

We’ll share some of the most common ways popular AWS services can expose users, and effective ways to remediate these potential risks. 

Why AWS security is critical

Let’s take a quick look at some of the most popular AWS services, and some of the high profile attacks and breaches they’ve encountered historically. 

AWS IAM is crucial for managing access controls, and as Werner Vogels said in a recent Re:Invent keynote, it is the only service used by every single AWS customer. Misconfigurations, like overly permissive roles, have led to breaches like the Capital One hack in 2019, where poor access management was exploited.

Other core AWS services include RDS, which simplifies database management, and is widely adopted in enterprise environments, S3 AWS’s leading storage service, and EC2 that powers a large portion of cloud workloads globally. Kubernetes clusters, including EKS, can be vulnerable to container escape attacks, where an attacker breaks out of a container and gains access to the host. 

CVE-2019-11246 is a Kubernetes vulnerability allowed users with specific privileges to escalate permissions, potentially impacting any applications deployed on EKS with default or misconfigured security policies. Elasticsearch, and by extension OpenSearch, has also seen its share of vulnerabilities allowing RCE attacks. CVE-2015-5377 and CVE-2014-3120 were early examples of RCE vulnerabilities where attackers could execute arbitrary commands, affecting improperly secured instances. 

Each of these has seen their fair share of breaches over the years like the RDS Accenture leak in 2021, the Verizon S3 breach in 2017, and the EC2 and Kuberentes (EKS) Tesla breach in 2018.  This tells us that even the largest industry giants are not immune to such risk and breaches. That said, there’s no need to panic, as there is also an incredible open source community security built around AWS working towards combating these risks, that provide a wide range of protection for AWS core services that every developer should know about.

Key AWS Core Services and Common Risks

Now that we’ve covered some of the risks, let’s briefly map some of the top security risks to AWS core services and see how these open-source tools address them. We’re going to specifically look at the following core services for the purpose of this risk mapping.

• IAM (Identity and Access Management)

• S3 (Simple Storage Service)

• EC2 (Elastic Compute Cloud)

• RDS (Relational Database Service)

• EKS (Elastic Kubernetes Service)

• Serverless / Lambda Functions

• OpenSearch (Formerly ElasticSearch)

This approach not only helps with prioritizing security efforts but also ensures that each service is configured to follow best practices, reducing the attack surface and enhancing overall cloud security. This is because each AWS service has its own potential vulnerabilities, whether it’s misconfigurations, overly permissive access, or unencrypted data. 

IAM (Identity and Access Management)

Common risks in IAM include overly permissive roles, unused credentials, and lack of multi-factor authentication (MFA) for users. To mitigate these risks, organizations should adopt the principle of least privilege, review and revoke unnecessary permissions regularly, enforce MFA for all users, and routinely monitor access logs to detect unusual activity.

S3 (Simple Storage Service)

S3 misconfigurations, such as public access permissions, missing encryption, and lack of versioning, can expose sensitive data. Best practices for mitigating these risks include restricting bucket permissions to only authorized users, enabling encryption at rest and in transit, and enabling versioning to prevent data loss from accidental deletions or overwrites. Regular audits of bucket policies are also recommended to ensure security standards are upheld.

EC2 (Elastic Compute Cloud)

Security risks for EC2 instances include exposed instances, unpatched software, and open security group configurations that allow unrestricted access. To minimize these vulnerabilities, organizations should restrict access to only necessary IP ranges, apply security patches promptly, and use network segmentation to isolate sensitive workloads. Additionally, continuous monitoring for abnormal traffic patterns and maintaining an incident response plan can help in promptly addressing potential threats.

RDS (Relational Database Service)

Common RDS risks include unencrypted databases, weak password policies, and instances that are publicly accessible. Mitigation strategies involve enforcing encryption for data at rest and in transit, using strong password policies, and placing databases within private subnets to restrict public access. Regularly reviewing access controls and database configurations can further strengthen security.

EKS (Elastic Kubernetes Service)

Security challenges with EKS stem from IAM role misconfigurations, network policy weaknesses, and the lack of runtime monitoring for workloads. Organizations should enforce strict IAM roles, configure network policies to isolate sensitive workloads, and implement runtime monitoring to detect and respond to anomalous activity within the cluster. Regular Kubernetes configuration reviews are essential to maintaining a secure EKS environment.

Lambda (Serverless Functions)

Risks for Lambda functions include excessive permissions, lack of code vulnerability scanning, and unrestricted network access. To address these issues, organizations should follow the principle of least privilege for IAM roles associated with Lambda functions, perform security reviews of function code for potential vulnerabilities, and restrict network access to private subnets when feasible. Regularly reviewing and updating permissions can help keep Lambda functions secure.

OpenSearch (formerly Elasticsearch)

Misconfigurations in OpenSearch can lead to unauthorized access, data leaks, and lack of encryption. To mitigate these risks, access to clusters should be restricted to trusted networks, encryption should be enforced both in transit and at rest, and access controls should be monitored and updated regularly. Establishing logging and monitoring practices helps in detecting suspicious activity early on.

AWS Service Security Recap

By understanding and addressing these common risks, organizations can proactively secure their AWS environments. Implementing strong access controls, enforcing encryption, maintaining up-to-date patches, and regularly reviewing security configurations across these services helps create a resilient cloud security posture. Adopting a continuous monitoring strategy and conducting regular audits are also key to detecting and mitigating potential vulnerabilities as they arise.

Using ASPM to secure your apps and infrastructure

When it comes to cloud security, relying on point solutions for each service or risk area often leads to fragmented visibility and inconsistent security practices. 

Managing distinct tools for identity, data storage, network configuration, and runtime security can create gaps in coverage, leaving misconfigurations and vulnerabilities unaddressed. This siloed approach can also strain resources, as teams must learn, maintain, and monitor multiple systems. 

An emerging platform that provides a comprehensive security approach is ASPM (Application Security Posture Management) that plays a crucial role in consolidating the management of end-to-end security risks within cloud environments, including AWS. 

ASPM tools automate the process of identifying misconfigurations, enforcing security policies, and monitoring the security posture of applications running on AWS services like IAM, RDS, S3, EC2, EKS or Serverless.

ASPM addresses these challenges by unifying security visibility and governance across cloud environments. With ASPM, organizations can streamline risk identification, prioritize critical vulnerabilities, and maintain consistent policies across services like IAM, EC2, and Lambda, creating a cohesive and scalable security strategy.

Integrating an ASPM will provide continuous visibility into the security of applications, making it easier to detect issues early and prioritize remediation efforts. For instance, ASPM can automatically flag overly permissive IAM roles or public S3 buckets using IaC scanning, where tools like Jit also provide auto-remediation when possible in your next pull request, or guidance and suggestions for how to fix issues when an automated fix isn’t possible. 

This proactive approach ensures that organizations can manage the dynamic and evolving security landscape of AWS environments more effectively, without adding friction to engineering processes, and also catch risks before they reach production.

Automating AWS Security

Securing your AWS environment requires a deep understanding of the risks associated with each core service. By leveraging open-source tools like Prowler, ScoutSuite, Cloud Custodian, and Trivy or an open ASPM like Jit, you can automate security scanning, enforce best practices, and maintain continuous security. 

The key to true cloud security is not just identifying risks, but also having the right tools to address them in real time, as well as continuously in the long-term.