9 Common AWS Security Mistakes — and How to Fix Them

The vast ecosystem of features and functions within Amazon Web Services (AWS) is without a doubt one of the public cloud platform’s best features. However, with its complexity, it’s easy for administrators to overlook or make a mistake with an important security setting. This can lead to potentially devastating security issues.
Even though a single misconfiguration may not sound like much, it can lead to disastrous consequences. Gartner predicts that by 2025, 99% of cloud security failures will have resulted from simple customer error. If information is compromised, this could mean service interruptions, business losses, costly data breaches, and potential fines and penalties for non-compliance with data privacy laws.
No matter the size and type of organization, information security personnel need to know how to prevent and mitigate security vulnerabilities within their public cloud environment. Most commonly, these issues fall into three distinct categories:

• Insufficient permissions or encryption
• Failure to log access data
• Broad range IP address access

All of these configurations fall into the user’s portion of cloud’s shared responsibility model. The list below contains nine of the most common AWS security issues that result from misconfiguration — and how to fix them.

Insufficient permissions or encryption

1. Overly permissive S3 bucket permissions

Simple Storage Service (S3) allows AWS users to store and retrieve data in a reliable and inexpensive way. Users select a region to store their data, create a bucket within that region, and then upload objects to the bucket. The S3 infrastructure stores objects on multiple devices across multiple facilities within the chosen region. Once an object is stored, S3 maintains durability by quickly detecting and repairing any lost redundancy.
S3 buckets are private, by default, but an administrator can choose to make a bucket public as sometimes that is desirable. However, if a user uploads private content to that public bucket, that can be problematic. 
AWS users also have the ability to control who has access to the S3 buckets and objects and which permissions they are granted. Using the AWS console, the following grantees can be given access to a bucket:

• Authenticated users (anyone with an AWS account)
• Log delivery
• Everyone (anonymous access)

The permissions that these grantees can be given are:

• List
• Upload/Delete
• View Permissions
• Edit Permissions

Users can also generate custom bucket policies that provide greater flexibility than the AWS console.
Depending on the bucket and the objects it contains, granting any of these permissions may or may not be cause for concern. However, any bucket with permissions granted to “Everyone” should be immediately reviewed. If left open to anyone, that anonymous access could lead to stolen or compromised data. In 2018, for instance, Symantec found that poor configuration led to more than 70 million records stolen or leaked from S3 buckets alone.

2. IAM users granted direct permissions

Identity and Access Management (IAM) enables AWS users to control access to their account by creating and managing AWS users and permissions. In addition to creating users, IAM allows for the creation of groups. Permissions can be granted to a group, and any user that belongs to that group is given those particular permissions.
This streamlines permissions management, as each user does not have their own unique set of permissions, and administrators can quickly tell which users are allowed which permissions by the group to which they belong. Any users that have their own unique permissions should have those permissions revoked and be added to a group instead.

3. Unintentionally public AMIs

Amazon Machine Images (AMIs) contain all the information necessary to launch an Amazon Elastic Compute Cloud (EC2) instance. They act as a template that contains the software configuration (operating system, application server, and applications) that will be used with the launched instance. AWS users can create their own AMIs, utilize public AMIs, or purchase custom AMIs.
When a user creates an AMI, they are given the option to make the AMI public, share it with specific AWS accounts, or make it private. Public AMIs can be launched by all AWS accounts and are shared in the AMI catalog. However, because AMIs often contain proprietary or sensitive data, it is recommended that they always be set to private. Any AMIs that are publicly accessible should be carefully reviewed.

4. Lack of encryption

Almost all traffic should be encrypted but this is especially true for financial and healthcare data. The performance hit of encrypting and decrypting data is negligible and it ensures trust among web users when submitting forms. This is referred to as Encryption in Transit.
Additionally, data in storage arrays should be protected from prying eyes. This is referred to as Encryption at Rest. Enterprises need to ensure that there are no weak links in the chain when it comes to securing sensitive data.

Failure to log access data

5. Disabled, not enabled, or improperly configured CloudTrail

Amazon CloudTrail provides AWS users with a complete history of all of the API calls made against their account. This includes calls made from the AWS Management Console, SDKs, command line tools, and other AWS services. CloudTrail creates log files of this data and deposits the log files into a designated S3 bucket. Included in log files is the source IP address of the calls and the date and time of the calls.
Administrators should have CloudTrail enabled within the AWS account so that they always know who and from where the AWS account is being accessed.

6. Failure to enable logging on all S3 buckets

Logging must be manually enabled on any S3 bucket, as it is disabled by default. When enabled, an access log record will be created for all requests made against a bucket containing the request type, resource with which the request worked, and the date and time the request was processed.
As with CloudTrail, having logging enabled on all S3 buckets is important as it provides insight into the nature of the requests made against the buckets. This also allows administrators to determine whether a resource is receiving heavy traffic, which means that it may have been left public by accident.

Broad range IP address access

7. Insufficient IP address ranges in virtual private cloud

A Virtual Private Cloud (VPC) functions like a VPN, enabling users to launch AWS resources in an isolated virtual network. Administrators can control who has access to the virtual private cloud by selecting IP address ranges, creating subnets, and configuring route tables and network gateways, depending on the level of security they need. 
Because this is a customizable solution, cloud admins need to define the permissions in their virtual private cloud environment. Only specific IP ranges should be specified for the VPC and only needed ports should be exposed. Leaving the VPC open to all ports and all IP addresses is highly discouraged because it creates a large attack surface for a malicious user.

8. Broad IP range access for database security groups

Database (DB) security groups act as a firewall that controls the traffic allowed into a group of instances. An EC2 instance can have multiple security groups assigned to it, and the rules for security groups can be modified at any time.
Each security group has rules that dictate the allowed inbound traffic to the instance(s) to which it’s assigned. All other traffic is discarded. These rules enable a specific source to access the instances using a certain protocol (TCP, UDP, or ICMP) and destination ports. This source can be an individual IP address or a range of addresses. To protect instances, only specific IP ranges should be designated for the DB security groups.

9. Network access control lists allow all inbound traffic

A network access control list (NACL) is an optional layer of security that acts as a firewall for controlling traffic in and out of a subnet. Administrators can set up NACLs with rules similar to their security groups in order to add an additional layer of security to a VPC.
Rules within an NACL are evaluated based on a rule number set for the rule. AWS allows or denies packets depending on the first rule to match the request. The lowest or first-numbered rule to match takes priority and is used. In a default VPC, it’s common to see NACL rule #100, which allows all inbound ports and IP addresses. One best practice is to restrict traffic to only necessary ports and IP addresses. If administrators find an NACL open to all ports and IP addresses, they should remove the rule and create more restrictive rules to allow only the appropriate inbound traffic.

Why are these AWS security issues so common?

While AWS has the capability to do so much for customers, it is also a complex platform for organizations of all sizes. Even the most highly trained cloud technicians and biggest information security teams need to be aware of the security vulnerabilities that can result from improper configurations and permissions within AWS.
Fortunately, there are tools that can help cloud administrators gain a foothold on security best practices. All of the AWS security issues described above can all be tracked, alerted, and fixed automatically within CloudCheckr CMx.
CloudCheckr CMx provides total visibility into a cloud environment, all in a single dashboard. This robust cloud management platform gives users access to more than 600 cloud best practice checks. 

Find solutions to your most pressing security issues

Schedule a 30-minute live demo to learn why the largest enterprises, service providers, resellers, and government agencies trust CloudCheckr with their public cloud security