CloudCheckr provides a comprehensive unified FinOps, SecOps, and DevOps platform for 1000s of AWS users. We service single accounts with a few EC2 instances spending under $1000 per month to large environments with 100s of accounts and 10,000+ EC2 instances spending over $3 million per month. However, even with all of the size diversity, we still see some commonality in security issues.
As you review the list, here are 3 key ideas to keep top of mind:
1. All of these issues fall into the user’s portion of AWS’ shared security model
2. We believe that the most effective defense philosophy is defense in depth. Consequently, we recommend that users secure all layers and create multiple barriers to ensure that a single weak point does not compromise the entire system.
3. All of these issues can either be tracked manually by a user or tracked and alerted automatically by CloudCheckr.
So, here are the 8 common AWS security issues:
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 choses region. Once an object is stored, S3 maintains durability by quickly detecting and repairing any lost redundancy.
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, or Everyone (anonymous access). The permissions that these grantees can be given are: List, Upload/Delete, View Permissions, and 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. Specifically, any bucket with permissions granted to ‘Everyone’ should be immediately reviewed.
2. 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.
It is important to have CloudTrail enabled within your AWS account so you always know who, and from where, your AWS account is being accessed.
3. Failure to Enable Logging on All S3 buckets: 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 choses region. Once an object is stored, S3 maintains durability by quickly detecting and repairing any lost redundancy.
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. Having logging enabled on all buckets is important as it provides insight into the nature of the requests made against the buckets.
4. Broad IP Range Access for DB Security Groups: 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) it’s assigned to. 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 allowed for the Security Groups.
5. 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 they belong to.
Any users that have their own unique permissions should have those permissions revoked, and be added to a group
6. VPC security groups allow inbound traffic from any IP address: AWS security groups act like a firewall, controlling the traffic allowed into a group of instances. Each instance can be assigned one or more security groups, and each group has rules that govern the allowed inbound traffic. All other inbound traffic is discarded.
To protect instances, only specific IP ranges should be specified for a security group and only needed ports should be exposed. Leaving a security group open to all ports and all IP addresses is highly discouraged because it creates a large attack surface for an attacker.
7. Network ACLs 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. You can set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC.
Rules within a 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 you will typically see a NACL rule #100 – Set character limit for Project Names that allows all inbound ports and IP Address. Best practice is to restrict traffic to only necessary ports and IP addresses.
If you find a NACL open to all ports and IP addresses, remove the rule and create more restrictive rules to allow only the appropriate inbound traffic.
8. Unintentionally Public AMIs: AMIs contains all the information necessary to launch an Amazon 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.
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.
Again: All of these issues can either be tracked manually by a user or tracked and alerted automatically by CloudCheckr. Do it yourself or take a free trial with CloudCheckr and see how we can help.