The Ultimate AWS Security Cheat Sheet Bundle

Protect your AWS workloads from threats with our curated bundle of security best practices. Gain insights into S3 security, security group management, and more to ensure the confidentiality, integrity, and availability of your data.

AWS Security Risks

This article examines common AWS security challenges, including identity and access control gaps, data exposure risks, and monitoring blind spots.

Wiz Experts Team
8 minutes read

Amazon Web Services (AWS) empowers businesses to make the most of the cloud. However, preventable security misconfigurations and oversights can leave organizations vulnerable to ever-evolving threats.

This article examines common AWS security challenges, including identity and access control gaps, data exposure risks, and monitoring blind spots. We'll explore these potential pitfalls and provide actionable recommendations to address each challenge. By implementing these recommendations, you can fortify your security posture at every stage of your cloud journey.

Inadequate access and identity controls

As organizations scale their AWS cloud infrastructure, the identity access management (IAM) infrastructure supporting it often grows exponentially, making IAM an area where serious security issues and vulnerabilities can lurk. Without proper controls, IAM sprawl and excessive permissions can quickly become unmanageable, leading to unauthorized access, data breaches, and other security incidents. Let’s take a closer look at the top IAM challenges that AWS users face:

Exposure of static AWS access keys

One of the most common AWS security issues is the possibility of static credentials being exposed. This issue is particularly prevalent in development environments, where hard-coded credentials are often used for convenience or quick testing. However, when these credentials are committed to source code repositories, they become vulnerable to exposure and can be exploited by malicious actors.

To lower the risk of exposed credentials:

  • Avoid hard-coding access keys whenever possible. Instead, use more secure alternatives such as IAM roles for EC2 instances or AWS Lambda functions. 

  • Use OpenID Connect (OIDC) for third-party providers like GitHub. This allows for secure authentication without the need to manage separate access keys.

Overly permissive IAM roles

Overly permissive IAM roles are another prevalent AWS security concern, granting unintended access to resources and posing risks similar to those associated with exposed static keys. Over-permissioned IAM roles provide a larger attack surface, increasing the blast radius if attackers manage to compromise a user account or application.

To address this issue:

  • Enforce the principle of least privilege from the start. Grant only the permissions necessary for each IAM entity to perform its intended tasks, even if it requires more frequent IAM policy updates during development.

  • Regularly review and audit IAM policies to identify and remove any excessive permissions. Make this a part of your ongoing security maintenance process.

  • Implement IAM Access Analyzer, which analyzes access patterns and provides recommendations for reducing permissions.

  • Use AWS IAM policy simulator to test IAM policies and ensure they grant only the intended permissions before applying them to production environments.

  • Implement IAM constraints using service control policies (SCPs) to set guardrails and restrict actions across multiple accounts, preventing the use of overly broad permissions.

Data exposure

Data is one of the most valuable assets for any organization with cloud infrastructure, and protecting it should be a top priority. However, the shift from traditional on-premises environments to cloud services presents new data security challenges. The public-facing, "always available" nature of cloud resources, coupled with a fuzzy network boundary, means that organizations must adopt a different mindset when it comes to data protection. Below, we’ll look at common data exposure issues and their solutions. 

Unencrypted data in S3, EBS, and RDS

Storing data in AWS services such as S3 buckets, EBS volumes, and RDS instances without proper encryption is a significant security risk. Unencrypted data can be easily accessed by unauthorized parties if these services are compromised, leading to data breaches and compliance violations. To mitigate this risk, it's essential to implement encryption at rest and in transit.

For data at rest, AWS provides server-side encryption (SSE) options for S3, EBS, and RDS. When enabled, AWS automatically encrypts your data before it is written to disk and decrypts it when accessed by authorized parties. 

For S3, AWS offers three types of SSE:

  • Server-side encryption with Amazon S3-managed keys (SSE-S3)

  • Server-side encryption with customer-managed keys (CMKs) stored in AWS Key Management Service (SSE-KMS)

  • Server-side encryption with customer-provided keys (SSE-C)

For RDS, AWS offers several encryption options that cover various stages of the data life cycle:

  • RDS encryption at rest with AWS-managed keys (default)

  • RDS encryption at rest with customer-managed keys (CMKs)

  • RDS encryption in transit with SSL/TLS

  • RDS Transparent Data Encryption (TDE) for Oracle and SQL Server

Because RDS encryption can only be enabled when an instance is created, it’s best practice to enforce policy automation that ensures only encrypted instances can be created.

For EBS:

  • EBS encryption with AWS-managed keys (default)

  • EBS encryption with customer-managed keys (CMKs)

EBS also requires that encryption is enabled at the creation of a new volume or snapshot, so default encryption should be enabled for each applicable region.

Public S3 buckets

Another common data exposure risk is the presence of public S3 buckets. These buckets allow unrestricted access to anyone, potentially exposing sensitive data. Some of the most high-profile data breaches have been a result of public, unsecured S3 storage. Here are some configuration settings that can help you avoid this risk vector:

  • Use S3 Block Public Access settings on all buckets. This feature provides centralized controls to limit public access to your buckets and objects.

  • Set resource-based policies to explicitly deny public access. These policies provide an additional layer of protection by specifying who can access your buckets and objects.

  • Authenticate bucket access using IAM roles only. This ensures that only authorized entities with the appropriate IAM permissions can access specific S3 buckets.

Monitoring and visibility gaps

Effective monitoring and visibility are essential for maintaining a secure AWS environment. Without proper monitoring, organizations may miss critical security events, security misconfigurations, or unauthorized activities. Read on for the top three monitoring and visibility gaps along with actionable solutions.

Inadequate logging configuration

Applications and services running in AWS should be configured to stream logs to CloudWatch for centralized monitoring and analysis. However, implementing this configuration is often overlooked, leading to gaps in visibility. To ensure comprehensive logging:

  • Configure EC2 instances to have CloudWatch agents installed and properly set up to stream logs.

  • Enable logging policies at the application or service level for compute resources like Lambda functions or EKS clusters.

  • Consider using CloudWatch as an aggregation target and streaming logs to a third-party tool for advanced search, query, and analytics capabilities to better understand application behavior and identify anomalies.

Disabling CloudTrail

CloudTrail is a critical service that provides visibility into API usage and user activity within your AWS environment. Disabling CloudTrail limits your ability to detect and investigate potential security threats. To maximize visibility:

  • Enable CloudTrail across all regions and accounts in your AWS environment.

  • Configure CloudTrail to log all management-plane and data events, providing a comprehensive audit trail of activities.

Lack of continuous configuration monitoring

Continuous monitoring helps keep existing configurations compliant. To help maintain configuration consistency:

  • Implement a process to scan infrastructure as code (IaC) templates for misconfigurations before deployment with tools like OPA.

  • Use AWS Config to continuously monitor your resource configurations and detect any changes or deviations from your desired state.

  • Create AWS Config rules to automatically evaluate resource compliance against your organization's security policies and best practices.

Underutilizing native security tools

In addition to its portfolio of infrastructure tools and services, there are several first-party security solutions available that can help improve your AWS security posture. However, many organizations underutilize these tools, missing out on the benefits of their native integrations. To take full advantage of these tools:

  • Enable AWS CloudTrail across all AWS accounts to log and monitor API activity. CloudTrail provides a detailed record of all API calls made within an AWS environment, including what identity made the request, the source IP address, and the time of the request.

  • Use Amazon Macie to discover and protect sensitive data stored in Amazon S3. Macie uses machine learning to identify sensitive data and classify its severity. It can also detect potential data access issues and provide recommendations for securing data.

  • Implement Amazon GuardDuty to continuously monitor for malicious activity and unauthorized behavior. GuardDuty can identify potential threats, such as unusual API calls, unauthorized deployments, and compromised instances.

  • Centrally aggregate findings from these services using AWS Security Hub, which provides a dashboard for security alerts and compliance status. Security Hub collects and prioritizes findings from various AWS security services as well as from third-party tools.

Incomplete configuration of security tools

Even when organizations do use AWS native security tools, they often fail to configure them correctly. This can lead to gaps in security visibility and protection. To ensure that your security tools are properly configured:

  • Turn on Amazon Macie data discovery for all your S3 buckets to identify and protect sensitive data. By default, Macie analyzes only a subset of your S3 buckets. To achieve full coverage, you should enable Macie for all buckets and configure it to scan for sensitive data regularly.

  • Enable Amazon GuardDuty anomaly detection features to identify unusual API usage patterns and potential security threats. As previously mentioned, GuardDuty offers several anomaly detection types, such as unusual API calls, unauthorized deployments, and compromised instances. Ensure that all relevant anomaly detection types are enabled and properly configured.

  • To ensure AWS Config effectively monitors your resource configurations, it's crucial to be thorough when setting it up. Start by defining rules that align with your desired resource configurations. Once properly configured, Config will continuously evaluate your resources against these rules, identifying misconfigurations that could lead to security vulnerabilities. However, without a complete setup, Config may fail to detect critical issues, leaving your resources exposed to potential threats.

Not leveraging specialized security tools

While the broad suite of AWS security tools covers many aspects of cloud security, specialized tools can fill gaps in specific areas and provide advanced capabilities for threat detection, investigation, and response. For example:

  • Amazon Detective is a security analysis and visualization tool that helps users investigate potential security issues and performs root cause analysis (RCA). Detective automatically collects and analyzes log data from various AWS services, building a linked set of data that makes security investigations much easier.

  • Amazon Inspector is an automated vulnerability management service that continuously scans AWS workloads for potential security risks, utilizing a comprehensive knowledge base of best practices and known vulnerability definitions. This service provides constant monitoring of an AWS environment to identify potential problems and vulnerabilities.

  • AWS Firewall Manager is a centralized platform for configuring and maintaining firewall rules across multiple AWS accounts and applications. This service simplifies the process of enforcing security policies at scale, ensuring that firewall rules are applied uniformly throughout your AWS environment. 

Conclusion

AWS cloud security can be a daunting task for many organizations. With insecure defaults and the rapid scaling of complexity that comes with using just a few services, it's easy for attack vectors to be exposed.

Fortunately, many of these issues can be addressed with straightforward configuration changes and the implementation of basic policy automation. By following the best practices outlined in this article, you can significantly enhance your AWS security posture. Regular audits, adherence to the principle of least privilege, and the use of encryption and access controls can go a long way in mitigating common security risks.

However, relying solely on AWS native security tools may not be enough to fully secure your environment. It’s a good idea to augment these tools with third-party solutions that provide additional features and capabilities. Our cloud native application protection platform (CNAPP) solution is the industry-leading cloud security platform, providing users with an agentless approach that not only identifies security risks but highlights potentially unknown, combined issues that may represent much more critical issues.

An example of a toxic combination of public exposure, authentication and high privileges found by Wiz

To learn more about how Wiz can help secure your AWS environment, request a demo today and take the first step towards a more secure cloud journey.

Agentless full stack coverage of your AWS Workloads in minutes

Learn why CISOs at the fastest growing companies choose Wiz to help secure their AWS environments.

Get a demo 

Continue reading

Secure Coding Explained

Secure coding is the practice of developing software that is resistant to security vulnerabilities by applying security best practices, techniques, and tools early in development.

Secure SDLC

Secure SDLC (SSDLC) is a framework for enhancing software security by integrating security designs, tools, and processes across the entire development lifecycle.