AWS Guidance Report

1. Underutilized EC2 instance (Priority: Moderate)

Baseline:

Checks the resource utilization of Amazon Elastic Compute Cloud (EC2) instances and labels them as underutilized if the CPU usage is less than 2% for the past 48hrs.

Recommendation:

For Amazon EC2, you are billed based on the instance type and the number of consumed hours. You can lower your costs by identifying and stopping low utilized instances. In addition, we also show the Current Instance Type and recommend the desired instance type (Suggested Instance Type) that you can downgrade to for better cost cutting.

Required Permissions:

"ec2:DescribeInstances", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", and "cloudwatch:ListMetrics"

2. EC2 Security Groups – Unrestricted access on specific ports (Priority: High)

Baseline:

Checks the security group of monitored EC2 instances for rules that allow unrestricted access on the following ports: 20, 21, 22, 1433, 1434, 3306, 3389, 4333, 5432, or 5500.

Description:

Unrestricted access can lead to DDoS attacks or malicious traffic reaching your application.

Recommendation:

Expose TCP ports 80 and 443 to the internet, and minimize the opportunities for an attacker.

Required Permissions:

"ec2:DescribeInstances" and "ec2:DescribeSecurityGroups"

3. EC2 instance termination protection (Priority: High)

Baseline:

Checks the configuration of EC2 instances to see whether termination protection is enabled.

Description:

Termination protection safeguards your instance from accidental deletion and also ensures AutoScaling policy doesn't terminate a specific EC2 instance while scaling in.

Recommendation:

EC2 instance termination protection is disabled by default. Enable to protect against unexpected instance termination.

Required Permissions:

"ec2:DescribeInstances" and "ec2:DescribeInstanceAttribute

4. Amazon EC2-VPC instance - Security group with too many rules assigned  (Priority: Moderate)

Baseline:

Checks for Amazon EC2-VPC instances that have security groups with more than 50 rules (inbound and outbound).

Description:

When you launch an instance in a VPC, you can specify up to five security groups that get associated with the instance. For each security group, you can add rules that control inbound and outbound traffic. Instance performance can be affected if the security group has a large number of rules.

Recommendation:

Reduce the number of rules configured in the associated VPC security group.

Permissions Required:

"ec2:DescribeInstances" and "ec2:DescribeSecurityGroups"

5. Untagged EC2 instances (Priority: Info)

Baseline:

Checks Elastic Compute Cloud (EC2) instances for user-defined tags (Key-value pair).

Description:

AWS allows users to assign metadata in the form of tags (key-value pair) to better track and manage instances, images, and AutoScaling groups. Organizations come up with relevant tag groupings and practical tagging strategies to efficiently manage their EC2 resource farm.

Recommendation:

Create a tagging strategy adhering to AWS best practices.

Required Permissions:

"ec2:DescribeInstances"

6. Amazon EC2 - high instance utilization (Priority: High)

Baseline:

Checks the performance counters for Amazon EC2 and identifies instances that appear to be highly utilized.

Description:

A EC2 instance is deemed as overutilized if it meets the following criteria:

• The average daily CPU usage for the EC2 instance is more than 90% for the last 7 days.
• The average daily memory utilization for the EC2 instance is more than 90% for the last 7 days (Only applicable if you've deployed our agent on the EC2 instance).

Recommendation:

Consider changing the instance size or add the instance to an Autoscaling group.

7. IAM Roles for Amazon EC2 (Priority: High)

Baseline:

Checks the configuration of your monitored EC2 instances and identifies resources with no IAM role.

Description:

In a microservices architecture, the application running on EC2 instances needs to access resources running on other AWS services (e.g., S3 bucket, Lambda, or DynamoDB). To provide access to resources, you can either create and distribute AWS credentials to the instances (and take up the overhead of rotating or updating them in the future) or use IAM roles to delegate permissions to resources to make API requests.

Recommendation:

Create an IAM role for your EC2 instances to delegate permissions to resources to make API requests.

Required Permissions:

"ec2:DescribeInstances"

8. EC2 instances not attached to a AutoScaling group (Priority: Info)

Baseline:

Checks for Elastic Compute Cloud (EC2) instances not associated with any AutoScaling Groups.

Description:

AutoScaling helps you to scale up and scale down your compute resources based on demand. By creating groups of EC2 instances called as AutoScaling groups, you can specify the desired capacity or assign policies, to ensure an optimum number of EC2 instances are available to handle incoming application requests.

Recommendation:

Organize your EC2 instances as AutoScaling groups.

Required Permissions:

"ec2:DescribeInstances" "autoscaling:DescribeAutoScalingGroups"

9. EC2 instances not launched within a VPC (Priority: Moderate)

Baseline:

Checks for Elastic Compute Cloud (EC2) instances launched in the EC2 Classic platform.

Description:

The Amazon EC2 network is categorized into two platforms - EC2 Classic and EC2 VPC. When you launch an instance within the Classic platform, your instance gets launched in a network that is shared by other AWS tenants. Whereas when you launch instances in a VPC, your resources are logically isolated from the other networks.

Recommendation:

Migrate your instances to a VPC.

Required Permissions:

"ec2:DescribeInstances"

10. EC2 system status check failed (Priority: High)

Baseline:

System reachability check failure.

Description:

System status checks are automated checks that are performed by Amazon EC2. This check monitors the operational reliability of the AWS physical infrastructure hosting your EC2 instance.

Recommendation:

Set up automated actions to restart the instance. If the instance is regularly failing system checks, try replacing the instance or change to a current generation instance type.

Required Permissions:

"ec2:DescribeInstances" and "ec2:DescribeInstanceStatus"

11. EC2 instance status check failure (Priority: High)

Baseline:

Instance reachability check failure.

Description:

Instance status checks are automated checks that are performed by Amazon EC2 itself. This check determines the health of the instance by sending an address resoulution protocol (ARP) request.

Recommendation:

Check OS and network configurations, retrieve system logs to troubleshoot or set up automated actions to restart instance.

Required Permissions:

"ec2:DescribeInstances" and "ec2:DescribeInstanceStatus"

12. Scheduled maintenance for EC2 instance (Priority: Moderate)

Baseline:

Checks Elastic Compute Cloud (EC2) instances for scheduled maintenance events.

Description:

From time to time, AWS would schedule a system maintenance event for your instance to perform routine maintenance tasks on the underlying physical host.

Recommendation:

Associate the monitored EC2 instance to Site24x7's smart maintenance window to suppress alerts and continue monitoring during downtime.

Required Permissions:

"ec2:DescribeInstances" and "ec2:DescribeInstanceStatus"

13. Unused Amazon EC2 security groups (Priority: Low)

Resource-level description:

Unused Amazon EC2 security groups can accrue additional charges.

Baseline:

Checks if any unused Amazon EC2 security groups are present.

Description:

Every unused (detached) Amazon EC2 security group must be removed from the AWS account to avoid accruing additional charges for those security groups.

Recommendation:

Delete security groups that aren't attached to any instance. This ensures that underutilized security groups aren't accidentally attached to an EC2 instance, inadvertently opening up the environment to attacks.

14. EC2 instances not using the Instance Metadata Service (Priority: Low)

Resource-level description:

Amazon EC2 instances not using IMDSv2 can impact network security.

Baseline:

Checks if any Amazon EC2 instances are not using v2 of the Instance Metadata Service (IMDSv2).

Description:

The EC2 IMDS is used for querying instance metadata values. The IMDS is attached locally to every instance and runs on special "link local" IP addresses. By default, both IMDSv1 and IMDSv2 are available to the instance. When you restrict the IMDS to v2 only (IMDSv2), you can enhance the security further, so it's important to use IMDSv2 for EC2 instances.

Recommendation:

Add an additional layer of defense to combat network vulnerabilities by using IMSDv2 for every EC2 instance.

15. Stopped EC2 instances should be removed after a specified time period

Resource-level description:

When EC2 instances are stopped and are not removed after the specified time period, they will accrue additional charges.

Baseline:

Checks if the EC2 instances that have been stopped are present for more than the allowed number of days.

Description:

When EC2 instances are stopped, you can still be charged for storage; however, when you terminate them, the charges will also be terminated. Plus, if an EC2 instance has not run for a specified time, it can pose a high risk since the instance may not be actively maintained.

Recommendation:

Ensure there are no stopped EC2 instances after the specified time period.

16. Amazon EC2 - Multiple ENIs attached (Priority: Low)

Baseline:

Checks whether the Amazon EC2 instance has multiple Elastic Network Interfaces (ENIs) attached.

Description:

Multiple ENIs can cause dual-homed instances, meaning instances that have multiple subnets. This can add to network security complexity and introduce unintended network paths and access.

Recommendation:

Consider detaching unwanted ENIs from EC2 instance.

Required permission:

• "ec2:DescribeInstances"

1. EBS volumes without snapshot (Priority: High)

Baseline:

Checks Amazon Elastic Block Store (EBS) volume configuration for associated snapshot ID.

Description:

EBS provides persistent block level storage support for your EC2 instances. Snapshots are a point in time, incremental backups of the data stored in your EBS volume. For redundancy, these Snapshots get stored in S3 buckets across multiple Availability Zones. In the event of a failure, these snapshots help you to create new volumes or move volumes across Availability Zones or Regions.

Recommendation:

Create weekly snapshots for your EBS volumes.

Required Permission:

"ec2:DescribeVolumes" and "ec2:DescribeSnapshots"

2. EBS volumes without a recent snapshot (Priority: Moderate)

Baseline:

No recent EBS snapshots taken in the last 30days.

Description:

Snapshots record the point in time state of your EBS volume. In the event of a failure replicas of the original volume can be created using these snapshots.

Recommendation:

Depending on how frequently you are making changes to your EBS volume, you can set up an automated scheduler to take regular snapshots to improve EBS data protection and recoverability.

Required Permission:

"ec2:DescribeVolumes" and "ec2:DescribeSnapshots"

3. EBS volumes attached to stopped EC2 instances (Priority: Moderate)

Baseline:

Checks instance state of an EBS attached EC2 instance.

Description:

EBS volumes continue to persist, regardless of any transitions that an instance undergoes during its life cycle. For EBS volumes you are billed based on the amount of storage you provision and for the IOPS (Only for Provisioned IOPS SSD (io1) Volumes) until the storage is released.

Recommendation:

Create a snapshot of the EBS volume and release the storage.

Required Permission:

"ec2:DescribeInstances" and "ec2:DescribeVolumes"

4. Unattached EBS volumes (Priority: Moderate)

Baseline:

Checks Amazon Elastic Block Store (EBS) volume configuration for associated instance ID.

Description:

Elastic block store volumes can persist independently even after instance termination or even after you explicitly unmount and detach the volume from the instance. As you may know, unattached volumes are still charged based on the storage provisioned and for IOPS.

Recommendation:

Associate the configured EBS volume, with an active instance or release the storage volume.

Required Permissions:

"ec2:DescribeVolumes"

5. Amazon EBS - Encryption (Priority: High)

Baseline:

Checks the configuration for Amazon Elastic Block Store (EBS) volumes and alerts you if any volumes are unencrypted.

Description:

When you enable encryption for an EBS volume and attach it to an EC2 instance, you encrypt all the data inside the volume. Also, all data that moves between your volume and instance gets encrypted.

Recommendation:

Encrypt an existing unencrypted volume if it is storing sensitive data.

6. Amazon EBS - Encryption using AWS managed CMK (Priority: High)

Baseline:

Checks the configuration for Amazon Elastic Block Store (EBS) volumes and identifies volumes where encryption is enabled using AWS-managed CMK.

Description:

Amazon EBS encryption uses the AWS key management service CMKs for encryption. There are three types of CMKs: Customer managed CMK, AWS managed CMK, and AWS owned CMK. Creating your own CMK (Customer managed CMK) gives you more flexibility, including establishing and maintaining key policies, IAM policies, grants and more.

Recommendation:

Create a customer managed CMK to encrypt your volumes.

1. Unused Elastic Load Balancers (Priority: High)

Baseline:

Checks the configuration of monitored classic load balancers to find ELB nodes with no registered back-end instances.

Description:

A configured Load Balancer continues to accrue charges, till you delete it. If a load balancer has no registered back-end instances, then it is not being used efficiently.

Recommendation:

Either add/register instances to the load balancer or consider terminating it.

Required Permission:

"elasticloadbalancing:DescribeLoadBalancers" and "elasticloadbalancing:DescribeInstanceHealth"

2. Idle Elastic Load Balancer (Priority: High)

Baseline:

Checks the usage stats of monitored classic load balancers deems them as idle if the number of requests received/routed or the number of TCP connections established with the target instance is less than 100 in the past 48hrs.

Description:

Amazon Web Services bills you for each partial or full hour your load balancer runs. If your load balancer is routing less then 100 requests, then it is not adequately being used.

Recommendation:

Consider terminating and running your application without a load balancer.

Required Permission

"elasticloadbalancing:DescribeLoadBalancers", cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", and "cloudwatch:ListMetrics"

3. Load balancers with fewer than "n" healthy instances (Priority: Moderate)

Baseline:

Checks the metric "healthy host count" for load balancers and warns when the count drops below the threshold.

Description:

The load balancer performs health checks on all registered instances to find whether the instance is healthy or not. However, sometimes the default health check configuration can be overly restrictive and can deem heath instances as unhealthy.

Recommendation:

Create your own health check configuration and configure optimum interval—healthy/unhealthy threshold, and timeout.

Required Permissions:

"elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeInstanceHealth"

4. ELB not utilizing multiple Availability Zones (Priority: High)

Baseline:

Checks for load balancers operating in a single Availability Zone.

Description:

If you are launching EC2 instances in a single Availability Zone, then any failure occurring in that data center could render all of your instances unavailable. By deploying multiple EC2 instances to different Availability Zones in the same Region, you remove a single point of failure.

Recommendation:

For increased resilience and fault tolerance, please ensure the EC2 instances registered to your load balancer is attached to different Availability Zones.

Required Permissions:

"elasticloadbalancing:DescribeLoadBalancers"

5. Elastic Load Balancer - Cross zone load balancing (Priority: High)

Baseline:

Checks for Elastic load balancers where Cross-Zone load balancing is disabled.

Description:

By default Cross-Zone load balancing is not enabled for your classic type Elastic Load Balancer. Generally, a load balancer equally distributes incoming traffic across configured Availability Zones. However, there could be a mismatch in the load if you are not running an equivalent number of EC2 instances in each zone. This could easily happen as instances could get manually deregistered or detached due to health check failures or removed for maintenance. If cross-zone load balancing is enabled, then Elastic Load Balancer equally distributes application traffic to all registered instances.

Recommendation:

Enable cross-zone balancing for your classic type Elastic Load Balancer

Required Permissions:

"elasticloadbalancing:DescribeLoadBalancers"

6. Elastic Load Balancer - Access Logs (Priority: Moderate)

Baseline:

Checks the configuration of your load balancers to see if Access Logs is enabled for your ELB.

Description:

Access logs capture and stores in-depth information for each request received by the Load Balancer. Information like IP address, latencies, request path, back-end server response gets stored in an Amazon S3 bucket that you specify. AWS account holders can use this to analyze traffic patterns and troubleshoot advanced ELB issues.

Recommendation:

This is an optional feature that is disabled by default. Enable Access logs for your Elastic Load Balancer.

Required Permissions:

"elasticloadbalancing:DescribeLoadBalancers"

7. Elastic Load Balancer - Connection draining (Priority: High)

Baseline:

Checks configuration of monitored Elastic Load Balancers to identify ELB nodes where Connection Draining is disabled.

Description:

When an EC2 instance gets terminated or deregistered from an AutoScaling group due to a health check failure, the ELB stops routing new requests to that instance and abruptly closes the active connection. If Connection Draining is enabled, the ELB will keep the connection open for active sessions to complete.

Recommendation:

Enable Connection Draining for your load balancer.

Required Permissions:

"elasticloadbalancing:DescribeLoadBalancers"

8. Elastic Load Balancer - Listener security (Priority: High)

Baseline:

Checks the configuration of Elastic load balancers (Classic and Application type) and warns you when there are no listeners that use the secure protocol (HTTPS or SSL).

Description:

A listener is a process that checks for connection requests. When your Elastic Load Balancer has no configured HTTPS listeners, unauthorized parties can read the data sent across the network between the client and your load balancer.

Recommendation:

Enable SSL/TLS support for the HTTP listener by deploying an SSL certificate on your load balancer.

9. Health checks for Auto Scaling groups associated with a load balancer (Priority: Moderate)

Baseline:

Checks if Auto Scaling groups (ASGs) associated with a load balancer have a health check configuration for the load balancer.

Description:

The default health checks for an Auto Scaling group are EC2 status checks only, and the ASG does not consider an instance unhealthy if it fails the health checks provided by a load balancer. You can determine an instance's health from the load balancer by configuring the ASG to use load balancer health checks.

Recommendation:

Add a load balancer health check to an ASG so instance health is determined by both the EC2 status checks and the load balancer health checks.

1. Access keys for IAM users (Priority: Moderate)

Baseline:

Checks the created time of access keys and identifies IAM users with keys older than 90 days (You can customize the baseline using our advanced configurations.)

Description:

Access keys consist of an access key ID and a secret access key, and they are used to sign requests to AWS API endpoints programmatically.

Recommendation:

As a security best practice, you can shorten the period an access key is active for by rotating access keys on a regular schedule.

Required Permissions:

"iam:ListUsers" and "iam:ListAccessKeys"

2. IAM Groups - Inline policies (Priority: Info)

Baseline:

Checks for IAM groups with inline policies.

Description:

IAM policies are JSON policy documents that you can assign to an entity – IAM user, role or group. A key advantage of using managed policies is that they are maintained and updated by AWS as new services, and APIs get introduced.

Recommendation:

Use AWS managed policies to grant permission to IAM groups.

Permissions Required:

"iam:ListGroupPolicies"

3. IAM users with full admin privileges (Priority: High)

Baseline:

Checks each IAM user in your account and identifies users where the managed policy AdministratorAccess is assigned.

Description:

The AdministratorAccess policy grants permissions for all four access levels: List, Read, Write, and Permissions management. Unrestricted admin access can easily lead to orphaned resources, security issues, and unexpected spikes in your AWS bill.

Recommendation:

When assigning permissions to IAM users, follow the practice of granting the least privilege–that is, grant only the permissions required to perform the task.

Required Permissions:

"iam:ListEntitiesForPolicy"

4. IAM roles with full admin privileges (Priority: High)

Baseline:

Checks each IAM role in your account and identifies roles where the managed policy AdministratorAccess is assigned.

Description:

The AdministratorAccess policy enables the users assuming the role to perform all actions, including read resource content; create, delete, or modify resources; and modify resource permissions.

Recommendation:

Assign this policy only to the account administrator. Regularly audit the IAM policies assigned to other roles to keep your resources secure.

Required Permissions:

"iam:ListAttachedRolePolicies"

5. Unnecessary Access Keys (Priority: High)

Baseline:

Checks for IAM users with two active Access Keys.

Description:

IAM users use Access Keys to make secure REST or HTTP requests to AWS service APIs.

Recommendation:

As a best practice try to keep only one key active.

Required Permissions:

"iam:ListUsers" and "iam:ListAccessKeys"

6. Unused IAM users (Priority: Moderate)

Baseline:

Checks the age of the console password for IAM users with no programmatic access and warns when they remain unused.

Description:

Console passwords are used by IAM users to sign into the AWS management console. By deleting the unused IAM user or disabling the password, you can add an extra layer of security to your AWS account.

Recommendation:

Delete the unused IAM user.

Required Permissions:

"iam:ListUsers" and "iam:GetLoginProfile"

7. Inactive IAM users (Priority: Moderate)

Baseline:

Checks the age of the console password for IAM users with no programmatic access, and warns when they have not been used in the last 90days.

Description:

Console passwords are used by IAM users to sign into the AWS management console. By deleting the unused IAM user or disabling the password, you can add an extra layer of security to your AWS account.

Recommendation:

Delete the inactive IAM user or disable the sign-in credentials.

Required Permissions:

"iam:ListUsers" and "iam:GetLoginProfile"

8. MFA - AWS root account (Priority: High)

Baseline:

Checks whether multi-factor authentication (MFA) is enabled for the root account.

Description:

The AWS root account holder has complete access to all AWS services and resources in the account. With two-step verification or MFA, you can add an extra layer of security to your sensitive AWS resources by requiring a user’s password as well as a time-synchronized one-time password.

Recommendation:

Use security-token-based MFA to protect your AWS account.

9. IAM Groups (Priority: High)

Baseline:

Checks whether an IAM group is created for the AWS account or not.

Description:

As you may already know you can provide your team members the ability to sign in to the AWS console or make programmatic requests to AWS services by creating IAM users. Instead of attaching policies directly to a user or manually editing user's permissions, you can create an IAM group (collection of IAM users) for easier management.

Recommendation:

Create multiple IAM groups with different permission scopes.

Required Permissions:

iam:ListGroups"

10. IAM password policy (Priority: High)

Baseline:

Checks whether a password policy is set for your AWS account.

Description:

You can create a password policy to enforce complexity requirements (password length and character type) and rotation periods for your IAM user passwords.

Recommendation:

Set a password policy to enforce strong password creation.

Required Permissions:

"iam:GetAccountPasswordPolicy"

11. IAM user - Support Access (Priority: Moderate)

Baseline:

Checks the list of attached IAM policies for each IAM role for a policy named "AWSSupportAccess."

Description:

The managed policy "AWSSupportAccess" grants an IAM user access to file and manage cases in the AWS Support Center.

Recommendation:

Make sure that there is at least one IAM user in your AWS account with permission to create and manage support cases.

Required Permissions:

"iam:ListEntitiesForPolicy"

12. AWS root account user - Access keys (Priority: High)

Baseline:

Checks the AWS account root user for active access keys.

Description:

Access keys are used to make secure REST API or HTTP query requests to AWS service APIs. Anyone with AWS root account user access keys can gain unrestricted access to all the resources, including billing data using these keys.

Recommendation:

Delete access keys for the root user or make it inactive.

13. Ensure the IAM password policy requires at least one uppercase letter, lowercase letter, symbol, and number (Priority: Moderate)

Baseline:

Checks if the IAM password policy requires at least one uppercase letter, lowercase letter, symbol, and number.

Description:

If an administrator doesn't set a custom password policy, IAM user passwords must meet the default AWS password policy by containing at least one uppercase letter, lowercase letter, symbol, and number.

Recommendation:

Maintain the security of your AWS accounts by implementing a strong AWS IAM password and changing it frequently. 

14. Ensure IAM policies are attached only to groups or roles (Priority: Low)

Baseline:

Determine if IAM policies are attached only to groups or roles.

Description:

Manage user-based access to your AWS resources efficiently by defining permissions at the IAM group level instead of the IAM user level. Since you don't need to define policies for each user or switch existing users between groups when they receive different roles, you can avoid duplicate information and save time and effort.

Recommendation:

Ensure that the existing IAM policies are attached only to groups or roles to efficiently assign permissions to all users within your AWS account.

15. Ensure the IAM password policy requires at least one uppercase letter, lowercase letter, symbol, and number (Priority: Moderate)

Resource-level description:

The IAM password policy must require at least one uppercase letter, lowercase letter, symbol, and a number or the security could be compromised.

Baseline:

Checks if the IAM password policy requires at least one uppercase letter, lowercase letter, symbol, and number.

Description:

If an administrator doesn't set a custom password policy, IAM user passwords must meet the default AWS password policy by containing at least one uppercase letter, lowercase letter, symbol, and number.

Recommendation:

Maintain the security of your AWS accounts by implementing a strong AWS IAM password and changing it frequently.

16. Ensure IAM policies are attached only to groups or roles (Priority: Low)

Resource-level description:

IAM policies must be attached only to groups or roles to efficiently assign permissions to all the users within your AWS account.

Baseline:

Determine if IAM policies are attached only to groups or roles.

Description:

Manage user-based access to your AWS resources efficiently by defining permissions at the IAM group level instead of the IAM user level. Since you don't need to define policies for each user or switch existing users between groups when they receive different roles, you can avoid duplicate information and save time and effort.

Recommendation:

Ensure that the existing IAM policies are attached only to groups or roles to efficiently assign permissions to all users within your AWS account.

1. Public S3 Buckets (Priority: Moderate)

Baseline:

Checks the bucket policies and user policies (not access control lists) of monitored S3 buckets to identify publicly accessible buckets.

Description:

Publicly accessible means anyone can read the bucket, listing the objects in it, and upload or remove objects. As you may already know, for S3 you're charged based on the request type, quantity of requests, and volume of data retrieved. Frequent list API requests from unintended public users can quickly lead to high charges.

Recommendation:

Determine if the bucket in question truly requires public access. If it doesn’t, restrict access and make the resource private.

Required Permissions:

"s3:ListBucket" and "s3:GetBucketPolicyStatus"

2. Amazon S3 - Default encryption (Priority: Moderate)

Baseline:

Checks and identifies Amazon S3 buckets where default S3 encryption is disabled.

Description:

Server-side encryption or encryption at rest ensures Amazon S3 encrypts your data at the object level.

Recommendation:

Use server-side encryption with Amazon S3-Managed Keys (SSE-S3) or AWS KMS-Managed Keys (SSE-KMS)

Required Permissions:

s3:GetEncryptionConfiguration" and "s3:ListBucket"

3. Amazon S3 - Access logging (Priority: Moderate)

Baseline:

Checks and identifies, Amazon S3 buckets where server access logging is disabled.

Description:

By default Amazon S3 doesn't collect server access logs. By enabling logging, you can store details about a single access request – requester, bucket name, request time, response status and more on a target bucket of your choice. There is no extra charge for enabling server access logging. However usual charges for storage are applied.

Recommendation:

Enable server access logging for your S3 buckets to help with your security and access audits.

Required Permissions:

s3:GetBucketLogging" and "s3:ListBucket"

4. Amazon S3 - MFA Delete (Priority: Moderate)

Baseline:

Checks the configuration of Amazon S3 buckets and identifies buckets where MFA delete is disabled.

Description:

MFA delete enabled buckets required additional authentication for version state changes and permanent delete operations.

Recommendation:

Add a layer of security to your S3 bucket by enabling MFA Delete.

Required Permission

"s3:ListBucket" and "s3:GetBucketVersioning"

5. Amazon S3 - S3 bucket policies should only allow requests that use Secure Socket Layer (SSL) (Priority: Moderate)

Baseline:

Determines if your S3 bucket policies are only allowing requests with SSL or not.

Description:

S3 buckets must be configured to strictly require SSL connections. If not, the connection between users, applications, and these buckets will be vulnerable to eavesdropping and man-in-the-middle (MITM) attacks.

Recommendation:

While dealing with sensitive data, enforce SSL-only access by denying all HTTP requests without SSL to your buckets.

6. Amazon S3 - S3 bucket should have cross-region replication enabled (Priority: Moderate)

Baseline:

Checks if S3 buckets have cross-region replication enabled or not.

Description:

With cross-region replication enabled, you can automatically replicate data or copy objects across S3 buckets in different AWS regions. Whether for a disaster recovery plan or performance optimization, data replication will improve the availability and reliability of your application.

Recommendation:

Enable cross-region replication for all S3 buckets.

7. Ensure the S3 bucket CloudTrail logs are not publicly accessible (Priority: High)

Baseline:

Determines if your S3 bucket CloudTrail logs are publicly accessible or not.

Description:

Amazon S3 buckets and objects are private by default; only the individual who created the bucket can access it and the objects it contains. CloudTrail logs may include detailed events of API activity in your account. If the permissions you provide for your CloudTrail logs to be stored in an S3 bucket are not secure, you may be providing malicious users access to your AWS account log data, which can increase the risk of unauthorized access.

Recommendation:

Ensure that the S3 bucket associated with CloudTrail logging is not publicly accessible, and safeguard your AWS account log data.

8. Ensure that Amazon S3 permissions granted to other AWS accounts in bucket policies are restricted (Priority: High)

Baseline:

Checks if the Amazon S3 permissions granted to other AWS accounts in bucket policies are restricted or not.

Description:

Implement least privilege access for other AWS accounts while using a shared Amazon S3 bucket. The denied actions for a principal in another account are as follows:

• s3:DeleteBucketPolicy
• s3:PutBucketAcl
• s3:PutBucketPolicy
• s3:PutEncryptionConfiguration
• s3:PutObjectAcl

Recommendation:

Principals from other AWS accounts should not perform denied actions on resources in S3 while using a shared Amazon S3 bucket to reduce the impact of errors or malicious attacks.

9. Amazon S3 - Lifecycle policy (Priority: Low)

Baseline:

Checks if the lifecycle policy is configured for the monitored S3 buckets.

Description:

S3 bucket lifecycle policy can be used to manage your objects so that they are stored cost effectively throughout their lifecycle. Lifecycle policy can be configured to transfer objects from one storage class to another or delete objects after some period of object creation. S3 storage costs can be saved based on the lifecycle policy.

Recommendation:

Consider configuring S3 bucket lifecycle policy.

Required Permissions:

• "s3:GetBucketLifecycleConfiguration"
• "s3:ListBucket"

1. RDS Security Groups - Unrestricted inbound access (Priority: Moderate)

Baseline:

Checks RDS-VPC security groups for inbound rules that has a source IP address with the CIDR notation 0.0.0.0/0.

Description:

VPC security group controls traffic access to a DB instance. You can add rules in a security group that allows access from specific IP range, port or EC2 security group.

Recommendation:

Restrict access to a specific IP address to prevent malicious activity.

Permissions Required

"rds:DescribeDBInstances" and "rds:DescribeDBSecurityGroups"

2. Public RDS instances (Priority: High)

Baseline:

Checks the accessibility options and identifies DB instances that are publicly accessible.

Description:

An internet-facing DB instance with a publicly resolvable DNS name can increase the risk of a cyberattack and accrue unexpected data transfer charges.

Recommendation:

Disable the publicly accessible flag.

Required Permissions:

"rds:DescribeDBInstances"

3. Automated backups for RDS (Priority: High)

Baseline:

Checks the configuration and identifies RDS DB instances where automated backups are disabled.

Description:

Amazon takes storage volume backups of your entire DB instance at regular intervals and retains the backups for a specific number of days to help with point-in-time recovery.

Recommendation:

Enable automated backups for RDS instances for smooth data restoration.

Required Permissions:

"rds:DescribeDBInstances"

4. Amazon RDS - Encryption (Priority: High)

Baseline:

Checks and identifies Amazon RDS DB instances where encryption is not enabled.

Description:

Encrypt data at rest for RDS, including underlying storage, automated backups, read replicas and snapshots to provide an additional layer of protection.

Recommendation:

Enable encryption for an RDS DB instance during creation or encrypt a copy of a DB snapshot and then restore a DB instance from the encrypted snapshot.

Required Permissions:

"rds:DescribeDBInstances"

5. RDS Multi-Availability Zone(AZ) (Priority: Moderate)

Baseline:

Checks for DB instances deployed in a single Availability Zone(AZ).

Description:

In a Multi-AZ deployment, Amazon automatically provisions a standby in a different AZ and synchronously replicates data. When a failure or planned maintenance occurs, Amazon RDS automatically performs a failover to the standby without any manual intervention.

Recommendation:

Provision a Multi-AZ DB instance or modify an existing DB instance to be Multi-AZ deployment.

Required Permissions:

"rds:DescribeDBInstances"

6. Amazon RDS - High utilization (Priority: High)

Baseline:

Checks the CloudWatch performance counters for Amazon RDS and identifies DB instances that appear to be highly utilized.

Description:

An RDS instance is deemed to be overutilized if it meets the following criteria:

• The average daily CPU usage is more than 90% for at least 4 days in the last 7 days.
• The amount of disk space consumed is more than 85% for at least 4 days in the last 7 days.

Recommendation:

Vertically scale up your master database or use read replicas to meet the demands of your application.

7. Amazon RDS - idle DB instance (Priority: High)

Baseline:

Checks the CloudWatch performance counters for Amazon RDS instances and identifies DB instances that appear to be underutilized.

Description:

An RDS instance is deemed to be idle if it meets the following criteria:

• The average daily CPU usage is less than 20% for at least 4 days in the last 7 days.
• The average number of daily database connections is less than 100 for at least 4 days in the last 7days.

Recommendation:

For Amazon RDS you pay for compute capacity by the hour your DB instance runs. If your DB instance is receiving fewer connections or is consuming meager amounts of CPU you can consider taking a snapshot and deleting the instance to reduce costs. In addition, we also show the Current Instance Type and recommend the desired instance type (Suggested Instance Type) that you can downgrade to for better cost cutting.

8. Amazon RDS - RDS snapshots should prohibit public access (Priority: High)

Baseline:

Checks if AWS RDS snapshots are publicly accessible or not.

Description:

RDS cluster snapshots take backups of an entire database cluster instead of backing up just the single database. To avoid potential leak or misuse of sensitive data, keep your snapshots private so that other AWS users cannot access, copy, or create a new volume out of it.

Recommendation:

Ensure that your AWS RDS database snapshots are not available publicly (i.e. shared with all AWS accounts and users) to avoid exposing your data.

9. Amazon RDS - RDS clusters should have deletion protection enabled (Priority: Moderate)

Baseline:

Check if Amazon RDS clusters have enabled deletion protection or not.

Description:

When Amazon RDS clusters have deletion protection enabled, clusters are not deleted accidently, preventing any data loss. You can enable this setting for all RDS database engines including the Amazon Aurora databases.

Recommendation:

Enable the RDS cluster deletion protection setting for all database engines.

10. Amazon RDS - Event subscription for OS updates (Priority: Moderate)

Baseline:

Checks if the RDS event subscriptions for instance source type has Security Patching event category included.

Description:

RDS DB instances occasionally require operating system updates to improve database performance and overall security posture. Using event subscriptions, you can set up email or text alerts to get notified as soon as an update becomes available. You can use these alerts to plan for updates that may be required to help you meet your compliance obligations.

Recommendation:

Consider subscribing to the security patching event category for instance source type.

Required Permissions:

• "rds:DescribeDBInstances"
• "rds:DescribeEventSubscriptions"

1. SNS - Publish message to Topic (everyone) (Priority: Moderate)

Baseline:

Checks the topic access policy of your Amazon SNS topics for topics that allow everyone to publish.

Description:

Allowing any AWS user or resource to publish message could lead to an unexpected increase in SNS publish charges.

Recommendation:

Allow only the topic owner and specific users to publish messages.

Required Permissions:

sns:GetTopicAttributes" and "sns:ListTopics"

2. SNS - Subscribe to Topic (everyone) (Priority: Moderate)

Baseline:

Checks topic access policy of Amazon SNS topics for topics that allow anonymous subscription.

Description:

Allowing everyone to subscribe can end up breaking message confidentiality. For example, any unauthorized entity can now subscribe to the topic and received the messages that get published.

Recommendation:

Limit subscription to the topic owner or particular endpoints to maintain topic security.

Required Permissions:

sns:GetTopicAttributes" and "sns:ListTopics"

3. Amazon SNS - HTTP endpoint as subscriber (Priority: Moderate)

Baseline:

Checks for SNS topics with HTTP endpoint as subscribers.

Description:

Amazon Simple Notification Service (SNS) is an asynchronous message delivery service the works on the publisher-subscriber paradigm. When you subscribe an HTTP/HTTPS endpoint to a topic and publish a message, SNS sends a POST request delivering the contents of the message to the said endpoint. However, messages sent over HTTP can be vulnerable to eavesdropping.

Recommendation:

When you subscribe a URL choose HTTPS over HTTP.

4. Amazon SNS - Delivery status logging (Priority: Moderate)

Baseline:

Checks if monitored SNS topics have delivery status logging enabled for notification messages sent to the SNS topic.

Description:

Logging is an important part of maintaining the reliability, availability, and performance of services. Logging notification message delivery status helps provide operational insights such as:

• Knowing whether a message was delivered to the Amazon SNS endpoint.
• Identifying the response sent from the Amazon SNS endpoint to Amazon SNS.
• Determining the message dwell time (the time between the publish timestamp and the hand off to an Amazon SNS endpoint).

Recommendation:

Consider enabling delivery status logging for the SNS topic.

Required Permission:

"sns:GetTopicAttributes"

1. DynamoDB - Auto Scaling (Priority: High)

Baseline:

Checks for Amazon DynamoDB tables where table throughput is manually managed.

Description:

When you create a table in Amazon DynamoDB you specify capacity requirements for read and write activity. Estimating adequate capacity or manually adjusting provisioned capacity based on demand can become an operational burden in the long run when you're dealing with cyclical or unpredictable DB workloads.

Recommendation:

Dynamically adjust table throughput capacity in response to traffic patterns automatically with DynamoDB Auto Scaling.

2. DynamoDB - On-demand backup and restore (Priority: High)

Baseline:

Checks for Amazon DynamoDB tables with no backups in the last 30 days.

Description:

Data archival is a critical aspect of long-term data retention and regulatory compliance requirements. Amazon DyanomDB lets you create full backups for you tables in seconds and helps you restore data anytime with zero impact on application performance or availability.

Recommendation:

Execute the backup and restore operations for your DynamoDB tables using the AWS management console or DynamoDB APIs.

3. DynamoDB - Server-side encryption (Priority: High)

Baseline:

Checks for Amazon DynamoDB tables where encryption at reset is disabled.

Description:

Enable encryption at rest for your data (tables, local secondary indexes, and global secondary indexes) using an AES-256 and service-default AWS Key Mangement Service (KMS) key to protect sensitive information and achieve compliance requirements.

Recommendation:

You can't enable encryption at rest on an existing table. Create a new encrypted table using the AWS management console or APIs.

4. DynamoDB - Unused tables (Priority: Moderate)

Baseline:

Checks the Amazon DynamoDB tables running at the time and alerts you if the total item count is zero.

Description:

As you may already know, for DynamoDB you either pay for the manually provisioned throughput or for the resources Amazon provisions to maintain your target read and write capacity. So any configured table continues to accrue charges. If a table has no data, then it is not efficiently being used.

Recommendation:

Consider deleting the unused table.

5. Amazon DynamoDB - Point-in-time recovery (Priority: Moderate)

Baseline:

Checks whether Amazon DynamoDB tables have point-in-time recovery (PITR) enabled.

Description:

Backups help you to recover more quickly from a security incident. They also strengthen the resilience of your systems. DynamoDB PITR automates backups for DynamoDB tables. It reduces the time to recover from accidental delete or write operations. DynamoDB tables that have PITR enabled can be restored to any point in time in the last 35 days.

Recommendation:

Consider enabling PITR for DynamoDB tables.

Required permission:

• "dynamodb:DescribeContinuousBackups"

1. SQS - Server-Side Encryption (SSE) (Priority: Moderate)

Baseline:

checks the configuration of SQS queues and warns you when server-side encryption is disabled.

Description:

Server-Side Encryption (SSE) encrypts the message body to help you reliably exchange sensitive data between distributed application components or microservices.

Recommendation:

Enable server-side encryption for your existing queue or enable the option during queue creation.

2. SQS - SSE using AWS managed CMKs (Priority: Moderate)

Baseline:

Checks for SQS queues where default AWS managed CMK is used to enable server-side encryption.

Description:

When you enable server-side encryption you choose a key provided by AWS Key Management Service (KMS) to encrypt messages stored in your standard and FIFO queues. You can either use the default AWS-managed Customer Master key (CMK) or create and manage your own keys for better flexibility, access control, rotation, and deletion.

Recommendation:

Create your own Customer Master Keys (CMKs). (Note: customer managed CMKs incur a monthly fee.)

3. SQS queue access policy - wildcard usage. (Priority: High)

Baseline:

Checks for the wildcard (*) usage in the principal element for SQS queue Access Policy.

Description:

The principal element in a policy specifies which AWS account or service or user has access to the queue. The wildcard (*) value in the principal element means that your queue is open to all AWS accounts. Overtly open access for your SQS queue could lead to unauthorized message delivery.

Recommendation:

Allow Amazon SQS access based on an AWS account ID.

4. SQS - No dead letter queue (Priority: Moderate)

Baseline:

Checks and identifies standard or FIFO queues with no designated dead letter queue.

Description:

A dead letter queue is an undelivered message queue to which messages get sent when a consumer does not successfully process them. Users can use this holding queue to isolate and troubleshoot problematic messages and determine why they failed.

Recommendation:

Dead letter queues can't be configured for existing queues. Configure a new SQS source queue and create a second queue as a dead letter queue.

5. SQS - Stalled queue (Priority: Moderate)

Baseline:

Checks the SQS CloudWatch metric: Approximate number of messages visible and alerts you when the number exceeds 100 for 3 consecutive polls.

Description:

Amazon SQS offers a fully managed hosted queue service to help integrate distributed application components. The metric "Approximate number of messages visible" provides insight about active queue size and backlog. If the metric keeps on increasing it could indicate a stuck or slow queue.

Recommendation:

Check the resource usage of your consumers (EC2 instances, Lambda functions, ECS instances) to identify and troubleshoot the problem.

1. Amazon SES - Verify identities (Priority: Info)

Baseline:

Checks for Amazon SES identities both email address and domain with the pending verification status.

Description:

In Amazon SES, an identity is an email address or domain that you can use to send email. Before you begin, you must verify each identity that you're going to use as From, Source, Sender or Return-Path address. If you're using the Amazon SES sandbox, you need to verify the recipient addresses as well.

Recommendation:

Resolve issues with the verification process immediately.

2. Amazon SES - DKIM signature (Priority: Info)

Baseline:

Checks for SES identities (domain and email addresses) that are not configured to use DKIM signatures.

Description:

Domain Keys Identified Mail (DKIM) is an email authentication protocol that allows senders to sign a particular representation of an email message cryptographically. The receiving mail server uses this signature to check whether any third party modified the message in transit.

Recommendation:

Automatically add a DKIM signature to every email you send using Easy DKIM in Amazon SES or manually add your own DKIM signature.

1. Amazon Kinesis Streams - SSE using AWS managed CMKs (Priority: High)

Baseline:

Checks for Amazon Kinesis Data Streams where server-side encryption (SSE) is enabled by AWS managed CMKs.

Description:

CMKs (Customer Master Keys) are the primary resource used to encrypt and decrypt data. There are three types: customer managed CMKs, AWS managed CMKs, and AWS owned CMKs. You can either encrypt data in your Amazon Kinesis Streams using AWS managed CMKs or create your own customer managed CMKs for more control and flexibility.

Recommendation:

Use customer managed CMKs to encrypt data at rest within the Kinesis Data Stream service.

2. Amazon Kinesis Streams - Server Side Encryption (SSE) (Priority: High)

Baseline:

Checks for Amazon Kinesis Data Streams where Server-side-encryption (SSE) is disabled.

Description:

Encryption at rest plays a crucial part in data management and helps your application meet strict compliance and regulatory requirements. By enabling server-side encryption you data gets automatically encrypted as it enters and decrypted as it leaves the stream service.

Recommendation:

Enable Server-side-encryption for you live stream using the Amazon Key Management (KMS) keys.

1. AWS WAF - Unassigned web ACLs (Priority: High)

Baseline:

Checks the configuration for Web Application Firewall (WAF) and identifies unassigned Web ACLs.

Description:

For AWS WAF you're metered based on the number of Web Access Control list and the number of rules that you add per web ACL regardless of whether they are associated with a resource—CloudFront distribution/Application Load Balancer or not.

Recommendation:

Consider deleting unused web ACLs (Note: You have to remove rules and disassociate all CloudFront distributions and Application Load Balancers from the ACL before deletion).

2. Amazon WAF Classic - Rule conditions (Priority: Moderate)

Baseline:

Checks if Amazon WAF Classic rules for Global and Regional types has at least one condition.

Description:

A WAF Global or Regional rule can contain multiple conditions. Condition can be of different types like Geo match, IP address matching, etc. The rule's conditions allow for traffic inspection and take a defined action (allow, block, or count). If none of the conditions are present, the traffic passes without inspection. A WAF rule with no conditions, but with a name or tag suggesting allow, block, or count, could lead to the wrong assumption that one of those actions is occurring.

Recommendation:

Consider configuring rules to have at least one condition.

Required Permission:

• "waf:GetRule"

3. Amazon WAF Classic - Rule group rules (Priority: Moderate)

Baseline:

Checks if Amazon WAF Classic WebACLs for Global and Regional types has at least one rule.

Description:

A WAF Global or Regional rule group can contain multiple rules. The rule has a set of conditions of different types and it allows for traffic inspection and take a defined action (allow, block, or count). If none of the rules are present, the traffic passes without inspection. A WAF rule group with no rules, but with a name or tag suggesting allow, block, or count, could lead to the wrong assumption that one of those actions is occurring.

Recommendation:

Consider configuring rule groups to have at least one rule.

Required Permission:

• "waf:ListActivatedRulesInRuleGroup"

4. Amazon WAF Classic - WebACL rules / rule groups (Priority: Moderate)

Baseline:

Checks if Amazon WAF Classic WebACLs for Global and Regional types has at least one rule or rule group.

Description:

A WAF Global or Regional web ACL can contain a collection of rules and rule groups that inspect and control web requests. If a web ACL is empty, the web traffic can pass without being detected or acted upon by WAF depending on the default action.

Recommendation:

Consider configuring WebACLs to have at least one rule or rule group.

Required Permission:

• "waf:GetWebACL"

1. Amazon Redshift - Underutilized Clusters (Priority: High)

Baseline:

Checks the performance counters for Amazon Redshift and identifies clusters that appear to be underutilized.

Description:

Checks the performance counters of running Amazon Redshift clusters and flags them as idle if they meet the following criteria.

• The average number of database connection is less than 10 for the last 7 days.
• The cluster-wide CPU utilization is less than 5% for the last 7 days.
• The average number of read and write operations across the cluster is less than "x" for the last 7 days.

Note: You can change the default alert criteria using Advanced configurations.

Recommendation:

For Amazon Redshift you pay an hourly rate based on the type and number of nodes in your cluster. If your cluster is receiving minimal connections or is consuming meager amounts of CPU you can consider downsizing or termination.(Note: Take a final snapshot before you shutdown the cluster)

2. Amazon Redshift clusters - High disk usage (Priority: High)

Baseline:

Checks the performance counters for Amazon Redshift and identifies data warehouse clusters with high disk usage.

Description:

Checks the metric: percentage disk space used (across the cluster) and alerts if you if the value is more than 90% on at least 4 of the last 7 days.

Recommendation:

Respond immediately and increase the number of nodes within your data warehouse cluster via the AWS console or the ModifyCluster API and make sure you have enough storage for new data

3. Amazon Redshift publicly accessible. (Priority: High)

Baseline:

Checks the network configuration for Amazon Redshift and identifies data warehouse clusters that are publicly accessible.

Description:

A publicly accessible cluster (public IP) can be accessed by any machine from the internet thus increasing the opportunity of security risks.

Recommendation:

Limit connection to your cluster from only within the VPC.

4. Amazon Redshift - Database audit logging (Priority: Moderate)

Baseline:

Checks the configuration for Amazon Redshift for data warehouse clusters and alerts you if database audit logging is disabled

Description:

When audit logging is enabled, detailed information about authentication attempts, connections, disconnections, user activity, changes to DB user definitions and more are captured and uploaded to a S3 bucket.

Recommendation:

Enable audit logging for security and troubleshooting purposes.

5. Amazon Redshift - Connect using SSL (Priority: Moderate)

Baseline:

Checks the parameter groups for Amazon Redshift and identifies clusters where the require_ssl parameter is set to false.

Description:

By default cluster databases accepts client connections whether it uses SSL or not. However, establishing an unencrypted communication between your client and data warehouse clusters can lead to security vulnerabilities.

Recommendation:

Create a custom parameter group, set the parameter name require_ssl as true, and associate it to the cluster

6. Amazon Redshift - Clusters automatic snapshot (Priority: Moderate)

Baseline:

Checks if the automatic snapshot is enabled for Amazon Redshift clusters.

Description:

Backups help you to recover more quickly from a security incident. They strengthen the resilience of your systems. Amazon Redshift takes periodic snapshots by default.

Recommendation:

Consider updating the snapshot retention period for the cluster to be at least 7 days.

Required Permission:

• "redshift:DescribeClusters"

7. Amazon Redshift - Clusters enhanced VPC routing (Priority: Moderate)

Baseline:

Checks if Amazon Redshift clusters uses enhanced VPC routing.

Description:

Enhanced VPC routing forces all COPY and UNLOAD traffic between the cluster and data repositories to go through your VPC. You can then use VPC features such as security groups and network access control lists to secure network traffic. You can also use VPC Flow Logs to monitor network traffic.

Recommendation:

Consider enabling enhanced VPC routing for Redshift clusters.

Required Permission:

• "redshift:DescribeClusters"

1. Lambda function - Publicly accessible (Priority: High)

Baseline:

Checks the configuration of AWS Lambda and alerts you if any functions are publicly accessible.

Description:

As you may already know, for Lambda you are charged based on the number of requests and AWS counts a request each time a function starts executing in response to an event notification or invoke call. Allowing unauthorized executions can lead to unexpected charges on you AWS bill.

Recommendation:

User Lambda function policies to manage invocation permissions.

2. AWS Lambda - X-Ray tracing disabled (Priority: Moderate)

Baseline:

Checks configuration for Lambda functions and alerts when tracing is disabled.

Description:

CloudWatch automatically provides performance counters for all executions of your Lambda function. However, these metrics might not be enough to provide you an end-to-end view of each invocation requests—from event source all the way to down stream calls.

Recommendation:

Enable active tracing for your Lambda functions.

3. VPC configuration for AWS Lambda functions (Priority: Moderate)

Baseline:

Determines if your Lambda functions have VPC configuration enabled for accessing the AWS resource privately.

Description:

By default, Lambda runs your functions in a secure VPC with access to AWS services and the internet. However, you can also configure your Lambda function to access resources with a custom VPC. A custom VPC defines a private network of resources, such as databases, cache instances, or internal services that allows you to connect to your Lambda function from within a VPC without internet access. This method is used to block unauthorized outbound traffic to the internet. Several AWS services offer VPC endpoints. You can use VPC endpoints to connect to AWS services from within a VPC without internet access.

Recommendation:

Add the VPC configuration to Lambda functions to access the AWS resources privately without internet access.

4. Lambda functions should use the latest runtime (Priority: Moderate)

Baseline:

Checks if the runtime used for Lambda functions is deprecated or not.

Description:

The AWS Lambda runtime (execution) environment is a container built based on the configuration settings chosen while creating your Lambda function. Lambda deprecates a runtime when support for a component of the runtime is disabled in security updates. With the latest runtime, you can benefit from new features and enhancements, and better security, performance, and reliability.

Recommendation:

Utilize the latest runtime to leverage the best security improvements, reducing the risk of bugs and vulnerabilities in your Lambda function.

5. Lambda functions should use the latest runtime (Priority: Moderate)

Resource-level description:

Upgrade the Lambda functions to the latest runtime and don't use out-of-date runtime environments, which may cause unavailability of security updates.

Baseline:

Checks if the runtime used for Lambda functions is deprecated or not.

Description:

The AWS Lambda runtime (execution) environment is a container built based on the configuration settings chosen while creating your Lambda function. Lambda deprecates a runtime when support for a component of the runtime is disabled in security updates. With the latest runtime, you can benefit from new features and enhancements, and better security, performance, and reliability.

Recommendation:

Utilize the latest runtime to leverage the best security improvements, reducing the risk of bugs and vulnerabilities in your Lambda function.

1. Amazon ElastiCache - Underutilized nodes (Priority: High)

Baseline:

Checks the host-level metrics for Amazon ElastiCache and identifies nodes that appear to be underutilized.

Description:

A cache node is considered to be underutilized if it matches the following criteria:

• The percentage of daily CPU usage is less than 10% for at least 4 of the last 7 days.
• The percentage of daily Engine CPU usage (Only for Redis Engine) is less than 10% on at least 4 of the last 7 days.

Recommendation:

Remove nodes from your cluster or change to a smaller node type.

2. Amazon ElastiCache for Redis - Multi-AZ (Priority: Moderate)

Baseline:

Checks the configuration for ElastiCache Redis and identifies clusters where Multi-AZ is not enabled.

Description:

During planned maintenance or in the unlikely event of node/Availability Zone failure you have to recreate and provision a new primary node manually. Instead you can enable Multi-AZ and allow ElastiCache to automatically promote a read replica as a primary and complete failover within seconds.

Recommendation:

Enable Multi-AZ with Automatic Failover using the ElastiCache management console or APIs.

3. Underutilized ElastiCache Memcached instances (Priority: High)

Resource-level description:

ElastiCache Memcached instances deemed as underutilized are listed.

Baseline:

Checks the resource utilization of Amazon ElastiCache for Memcached cache environment in the cloud and labels them as underutilized if the CPU usage is less than 2% for the past 48 hours.

Recommendation:

For Amazon ElastiCache, you are billed based on the instance type and the number of consumed hours. You can lower your costs by identifying and stopping the instances that are utilized less.

4. ElastiCache Memcached - High instance utilization (Priority: High)

Baseline:

Checks the performance counters for Amazon ElastiCache for Memcached and identifies instances that appear to be highly utilized.

Description:

A ElastiCache for Memcached instance is deemed as overutilized if the average daily CPU usage for the ElastiCache for Memcached instance is more than 90% for the last seven days.

Recommendation:

Consider changing the instance size.

5. Underutilized ElastiCache Redis instances (Priority: High)

Resource-level description:

ElastiCache Redis instances deemed as underutilized are listed.

Baseline:

Checks the resource utilization of Amazon ElastiCache for Redis cache environment in the cloud and labels them as underutilized if the CPU usage is less than 2% for the past 48 hours.

Recommendation:

For Amazon ElastiCache you are billed based on the instance type and the number of consumed hours. You can lower your costs by identifying and stopping the instances that are utilized less.

6. ElastiCache Redis - High instance utilization (Priority: High)

Baseline:

Checks the performance counters for Amazon ElastiCache for Redis and identifies instances that appear to be highly utilized.

Description:

A ElastiCache for Redis instance is deemed as overutilized if the average daily CPU usage for the ElastiCache for Redis instance is more than 90% for the last seven days.

Recommendation:

Consider changing the instance size.

1. Amazon CloudFront – WAF Integration (Priority: Moderate)

Baseline:

Checks if Amazon CloudFront web distributions are integrated with the Web Application Firewall (AWS WAF).

Description:

AWS Cloudfront—WAF integration enables you to block any malicious requests made to your Cloudfront Content Delivery Network based on the criteria defined in the WAF Web Access Control List (ACL) associated with the CDN distribution. It helps protect against application-layer attacks that can compromise the security of your web applications or place unnecessary load on them.

Recommendation:

Create the required WAF Access Control List and associate it with the appropriate web distribution to integrate CloudFront with AWS WAF.

Required Permission:

"cloudfront:ListDistributions"

2. Amazon CloudFront – Access Logging (Priority: Moderate)

Baseline:

Checks if Amazon Cloudfront distributions have Access Logging feature enabled.

Description:

The Cloudfront access logs contain detailed information (requested object name, date and time of the access, client IP, access point, error code, etc) about each request made for your web content, information that can be extremely useful during security audits or as input data for various analytics/reporting tools.

Recommendation:

Enable access logging for your Cloudfront CDN distributions.

Required Permission:

"cloudfront:ListDistributions" and "cloudfront:GetDistribution"

3. Amazon CloudFront – Enforce Encryption (Priority: Moderate)

Baseline:

Checks whether the communication between your Amazon CloudFront CDN distribution and its end users is encrypted using HTTPS.

Description:

Establishing communication with HTTPS (SSL encryption) for your CloudFront CDN distribution can guarantee that the encrypted traffic between the edge (cache) servers and the application viewers cannot be decrypted by malicious users in case they are able to intercept packets sent across the CDN distribution network.

Recommendation:

Configure CloudFront distribution viewer protocol policy to enforce HTTPS for data in transit encryption.

Required Permission:

"cloudfront:ListDistributions"

4. Amazon CloudFront – Field-Level Encryption (Priority: Moderate)

Baseline:

Checks whether field-level encryption is enabled for your Amazon CloudFront web distributions.

Description:

CloudFront field-level encryption lets you add an additional layer of security, along with SSL encryption (HTTPS), helping you protect specific sensitive data throughout system processing so that only certain applications within your environment can see this data.

Recommendation:

Enable field-level encryption for your Amazon CloudFront web distributions.

Required Permission:

"cloudfront:ListDistributions"

5. Amazon CloudFront – Insecure SSL Protocols (Priority: Moderate)

Baseline:

Ensures that AWS CloudFront distributions origin(s) do not use insecure SSL protocols.

Description:

Using insecure and deprecated SSL protocols for your Cloudfront distributions could make the connection between the Cloudfront CDN and the origin server vulnerable to exploits such as POODLE (Padding Oracle on Downgraded Legacy Encryption). You're strongly recommended to use TLSv1.0 or later (ideally use only TLSv1.2 if you origins support it) and avoid using the SSLv3 protocol.

Recommendation:

Remove the deprecated SSLv3 protocol from your Cloudfront distributions origin.

Required Permission:

"cloudfront:ListDistributions"

6. Amazon CloudFront – Unencrypted Traffic (Priority: Moderate)

Baseline:

Checks whether the communication between your AWS CloudFront distributions and their custom origins is encrypted using HTTPS.

Description:

Using HTTPS for your AWS Cloudfront distributions can offer you the guarantee that the encrypted traffic between the edge servers and the custom origin cannot be unsealed by malicious users in case they are able to capture packets sent across Cloudfront Content Distribution Network (CDN). It helps you secure the delivery of your web content and fulfill compliance requirements for data in transit encryption.

Recommendation:

Enable HTTPS for encrypting the traffic between your CloudFront distributions edge locations and their origins.

Required Permission:

"cloudfront:ListDistributions"

7. Amazon CloudFront - Default root object (Priority: High)

Baseline:

Checks if monitored CloudFront distributions have a default root object configured.

Description:

The default root object can be returned to the user when the user requests the root URL for your CloudFront distribution instead of an object in your distribution. Configuring the default root object prevents unintentional exposure of distribution content or errors.

Recommendation:

Consider configuring the default root object for your distribution.

Required permission:

"cloudfront:GetDistributionConfig"

8. Amazon CloudFront - Origin Access Identity (Priority: High)

Baseline:

Checks if CloudFront distribution origins of type S3 origin have Origin Access Identity (OAI) enabled.

Description:

If OAI is not used, then CloudFront distribution origins that are of type S3 need to have public access for the bucket enabled. If OAI is used, then public access to the S3 bucket is not required. Any request to the S3 bucket can only go through CloudFront, which has access to the bucket through OAI.

Recommendation:

Enable OAI for the distribution.

Required permission:

"cloudfront:GetDistributionConfig"

9. Amazon CloudFront - Origin failover (Priority: Moderate)

Baseline:

Checks if monitored CloudFront distributions have origin failover configured.

Description:

CloudFront distributions with origin failover configured provide high availability. Distributions can be configured to have primary and secondary origin, whereby if the primary satisfies the configured failover criteria, then the secondary can be used to serve content.

Recommendation:

Configure failover for distributions by satisfying all the conditions below:

• CloudFront distribution should have at least two origins.
• CloudFront distribution should have an origin group with primary and secondary origins configured.
• The CloudFront distribution origin group should have failover criteria configured.

Required permission:

"cloudfront:GetDistributionConfig"

10. Amazon CloudFront - SNI (Priority: Moderate)

Baseline:

Checks if monitored CloudFront distributions with aliases (alternate domain names or CNAMES) serve HTTPS requests using Server Name Indication (SNI).

Description:

CloudFront distributions with aliases can serve HTTPS requests using either SNI or a dedicated IP for that purpose. Using SNI is recommended and is supported by most browsers. Dedicated IPs are used if the user has a browser that doesn't support SNI. Dedicated IPs incur additional costs, whereas using SNI doesn't.

Recommendation:

Configure distributions to serve HTTPS requests only for clients that support SNI.

Required Permission:

"cloudfront:GetDistributionConfig"

1. API Gateway - Enable SSL Client Certificate (Priority: Moderate)

Baseline:

Checks if your Amazon API Gateway APIs are using SSL certificates to verify that HTTP requests made to your backend system are from API Gateway service.

Description:

To ensure that the HTTP requests made to your backend services are originating from your Amazon API Gateway APIs, it is strongly recommended to use client-side SSL certificates to verify the requester's authenticity.

Recommendation:

Generate an SSL certificate and associate it with your Amazon API Gateway API.

Required Permission:

"apigateway:RestApis" and "apigateway:GetStages"

2. API Gateway - CloudWatch Logs for APIs (Priority: Moderate)

Baseline:

Checks if AWS CloudWatch logging is enabled for APIs created with Amazon API Gateway.

Description:

Amazon CloudWatch logging facilitates recording information about the API execution at the stage level. This information can be extremely useful for troubleshooting any issues that you have with your APIs.

Recommendation:

Enable AWS CloudWatch Logs for your Amazon API Gateway APIs.

Required Permission:

"apigateway:RestApis" and "apigateway:GetStages"

3. API Gateway - Content Encoding (Priority: Moderate)

Baseline:

Checks if Content Encoding feature is enabled for your Amazon API Gateway APIs.

Description:

Amazon API Gateway allows your client to call your API with compressed payloads using one of the supported compression types. Once Content Encoding is enabled, the API Gateway service allows compression of response bodies based on client's Accept-Encoding header. Enabling compression for your API payload will help you improve your API performance and reduce bandwidth utilization.

Recommendation:

Enable Amazon API Gateway API payload compression using Content Encoding feature.

Required Permission:

"apigateway:RestApis"

4. API Gateway - CloudWatch Metrics for APIs (Priority: Moderate)

Baseline:

Checks whether detailed CloudWatch metrics are enabled for all APIs created with AWS API Gateway.

Description:

AWS CloudWatch metrics for API stages allow you to fetch more granular metric data which can help you to act fast and take immediate actions based on information delivered by these metrics through alarms.

Recommendation:

Enable detailed CloudWatch metrics for your Amazon API Gateway APIs stages.

Required Permission:

"apigateway:RestApis" and "apigateway:GetStages"

5. Amazon API Gateway - X-Ray tracing (Priority: Moderate)

Baseline:

Checks if monitored API Gateway resources have X-Ray tracing enabled.

Description:

AWS X-Ray can be used to trace and analyze user requests as they travel through your Amazon API Gateway REST APIs to the underlying services. X-Ray gives you an end-to-end view of an entire request, so that you can analyze latencies in your APIs and their backend services. X-Ray tracing enables a more rapid response to performance changes in the underlying infrastructure.

Recommendation:

Consider enabling X-Ray tracing for API Gateway.

Required Permissions:

• "apigateway:RestApis"
• "apigateway:GetStages"

6. API Gateway - WAF Integration (Priority: Moderate)

Baseline:

Checks whether AWS Web Application Firewall (WAF) is integrated with Amazon API Gateway APIs.

Description:

Associate API Gateway API stages with AWS WAF Web Access Control Lists to monitor and filter the HTTP and HTTPS requests that are forwarded to your API to add protection against common web exploits such as SQL injection attacks, cross-site scripting (XSS) attacks, and cross-site request forgery (CSRF) attacks. These attacks can affect API availability and performance, compromise API data security, or consume excessive resources.

Recommendation:

Enable Amazon API Gateway - Amazon WAF integration by associating API stages with web ACLs.

Required Permissions:

• "apigateway:RestApis"
• "apigateway:GetStages"

7. Amazon API Gateway - Encrypt cache data (Priority: Moderate)

Baseline:

Checks if monitored API Gateway resources with API cache has cache encryption enabled.

Description:

Encrypting data at rest reduces the risk of data stored on the disk being accessed by a user not authenticated by AWS. It adds another set of access controls to limit an unauthorized user's ability to access the data. For example, API permissions are required to decrypt the data before it can be read. API Gateway REST API caches should be encrypted at rest for an added layer of security.

Recommendation:

Consider enabling cache encryption for API Gateway REST API cache.

Required Permissions:

• "apigateway:RestApis"
• "apigateway:GetStages"

8. Amazon API Gateway - Route authorization (Priority: Moderate)

Baseline:

Checks whether Amazon API Gateway routes have an authorization type configured.

Description:

API Gateway supports multiple mechanisms for controlling and managing access to your APIs. By specifying an authorization type, you can restrict access to your APIs to only authorized users or processes.

Recommendation:

Consider configuring authorization type of API Gateway routes.

 

1. AWS EFS - Managed KMS Keys (Priority: High)

Baseline:

Checks if your Amazon EFS file systems are encrypted using KMS Customer Master Keys (CMKs) instead of AWS managed-keys (default keys used by the EFS service when there are no customer keys defined).

Description:

Upon defining and using your own KMS CMK customer-managed keys to protect the EFS file systems data and metadata, you gain full control over who can use these keys to access the data (including the system metadata). The AWS KMS service allows you to create, rotate, disable and audit CMK encryption keys for your file systems and helps you have more granular control over your data-at-rest encryption/decryption process.

Recommendation:

Encrypt an existing AWS EFS file system with your own AWS KMS CMK customer-managed key.

Required Permission:

"elasticfilesystem:DescribeFileSystems"

2. AWS EFS - Encryption (Priority: High)

Baseline:

Checks whether your Amazon EFS file systems are encrypted to protect your data at rest.

Description:

Encryption keys are managed by AWS KMS service, eliminating the need to build and maintain a secure key management infrastructure. Your data is transparently encrypted while being written and transparently decrypted while being read from your file system, therefore the encryption process does not require any additional action from you or your application. It's strongly recommended to encrypt your EFS file systems in order to protect your data and metadata from unauthorized access, and thereby enforce compliance requirements for data-at-rest encryption within your organization.

Recommendation:

Enable Encryption for your AWS EFS file system.

Required Permission:

"elasticfilesystem:DescribeFileSystems"

3. Amazon EFS - File system backup (Priority: Low)

Baseline:

Checks if automatic backup is enabled for monitored Elastic File System (EFS) volumes.

Description:

Including the EFS file systems in the backup plans prevents deletion and loss of data.

Recommendation:

Consider enabling automatic backup for EFS file system.

Required Permissions:

• "elasticfilesystem:DescribeFileSystems"
• "elasticfilesystem:DescribeBackupPolicy"

5. Amazon EFS - User identity (Priority: Moderate)

1. Amazon EMR - Logging enabled to S3

Baseline:

Checks whether Amazon EMR cluster log files are enabled to upload in S3 bucket.

Description:

By enabling logging for EMR , it will help us to maintain the historical data of EMR Cluster. By default, all log files are automatically deleted from the cluster. These files are helpful in the analysis and debug any issues related to EMR cluster.

Recommendation:

Enable the setting, for log files to be stored in S3.

2. Amazon EMR - Via VPC

Baseline:

Checks if Amazon EMR clusters are provisioned using the EC2-VPC platform instead of EC2-Classic platform.

Description:

Amazon provides two options to launch cluster : EC2-Classic or EC2-VPC. In EC2-Classic, your instances run in a single, flat network. EC2-VPC enables you to run in an isolated area ,within AWS, where you can configure a virtual network, controlling the aspects such as private IP address ranges, subnets, routing tables, and network gateways.

Recommendation:

Always launch your EMR clusters with EC2-VPC for better security and availability.

3. Amazon EMR - Encryption

Baseline:

Checks in-transit and at-rest Encryption is enabled for Amazon EMR Cluster.

Description:

Amazon EMR allow us to encrypt data at rest, data in transit, or both. Enabling encryption will prevent unauthorized users from reading sensitive data available on your EMR clusters.

Recommendation:

Enable Encryption for data stored in EMR Cluster.

4. Ensure Amazon EMR cluster master nodes do not use public IP addresses (Priority: High)

Baseline:

Checks if Amazon EMR cluster master nodes use public IP addresses or not.

Description:

Amazon EMR provisions and manages a Hadoop cluster for customers to process large data sets using a MapReduce pattern. By default, the control logic that manages and communicates with other clusters is over a public IP address. If you are processing sensitive data in your cluster, you may want an additional access control to launch that cluster.

Recommendation:

Ensure that master nodes on Amazon EMR clusters don't use any public IP addresses.

5. Ensure Amazon EMR cluster master nodes do not use public IP addresses (Priority: High)

Resource-level description:

Amazon EMR cluster master nodes using public IP addresses can disrupt the security of your network.

Baseline:

Checks if Amazon EMR cluster master nodes use public IP addresses or not.

Description:

Amazon EMR provisions and manages a Hadoop cluster for customers to process large data sets using a MapReduce pattern. By default, the control logic that manages and communicates with other clusters is over a public IP address. If you are processing sensitive data in your cluster, you may want an additional access control to launch that cluster.

Recommendation:

Ensure that master nodes on Amazon EMR clusters don't use any public IP addresses.

1. Amazon Route 53 - Auto Renew

Baseline:

Checks whether Auto Renew feature is enabled for your registered domain in order to renew automatically.

Description:

Enabling Auto Renew feature will help to renew our domain before late-renewal period and prevent from the domain available to other register. Even if we restore the domain after its expiry, the cost of restoring domain is higher than renewing.

Recommendation:

It is safe to enable the Auto Renew option to prevent our domain getting expired.

2. Amazon Route 53 - Domain Expired

Baseline:

Checks and identifies if any registered domain has expired currently.

Description:

When your domain gets expires, it is not shown in console. If you don't renew a domain before renewal period, then it will get expired and some registries for top-level domains (TLDs) allow you to restore the domain, before it becomes available for other registries to register. The price for restoring domain is always higher than renew and new registration, so before restore see the price of restoring the expired domain.

Recommendation:

Restoring the domain will help you have full access for your expired domain. It is safe to restore a domain before it becomes available for other registries to register.

3. Amazon Route 53 - Enable Tranfer Lock

Baseline:

Check whether Transfer lock is enabled, to prevent the domain hijacking.

Description:

Enabling Transfer Lock for your domain registries for all generic top-level domains(TLDs) registered with AWS Route 53 will prevent someone from transferring the domain to another registrar without your permission. This feature enables the registrar to force all transfer requests to be rejected automatically.

Recommendation:

Your domain names must have the Transfer Lock feature enabled.

4. Amazon Route 53 - Empty DNS

Baseline:

Route 53 hosted zone checks for the availability of Route 53 DNS service.

Description:

Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. It effectively connects user requests to infrastructure running in AWS – such as Amazon EC2 instances, Elastic Load Balancer, or Amazon S3. It is cost effective, secured with IAM and flexible with any AWS service.

Recommendation:

Configure AWS Route 53 to DNS service for your domain.

5. Amazon Route 53 - Dangling DNS Records

Baseline:

Checks and identifies the Dangling DNS records in Route 53 cluster in order to maintain the security.

Description:

Check whether Dangling DNS entry , pointing to domain or subdomain, are deleted, in order to maintain security and prevent malicious access. If you leave a domain pointing at an IP address that you do not control, then there is a risk that someone may come along and “claim” traffic destined for your domain.

Recommendation:

Remove all Dangling DNS entry in your domain.

6. Amazon Route 53 - Public Hosted Zone with Private DNS

Baseline:

Checks the publicly available hosted zone with private DNS records in order to prevent information expose outside of AWS.

Description:

Checks AWS Route 53 Public Hosted Zones that contain DNS records for private IPs/resources. For publishing website you need public hosted zone and private hosted zone only responds to queries coming from within the associated VPC. You can use Amazon Route 53 to configure split-view DNS, also known as split-horizon DNS. If you want to maintain internal and external versions of the same website or application, you can configure public and private hosted zones to return different internal and external IP addresses for the same domain name.

Recommendation:

Make sure that you don't have any private DNS records in your Route 53 Public Hosted Zones.

7. Amazon Route 53 - ROOT Alias Point to ELB

Baseline:

Checks ROOT domain alias that point to ELB in order to maintain the traffic.

Description:

Ensure that the root domain alias record points to the Elastic Load Balancer (ELB). Amazon DNS record type that allows you to create an A record for the root domain and point it to an Elastic Load Balancer (ELB). An alias record provides a Route 53–specific extension to DNS functionality. Instead of an IP address or a domain name, an alias record must contain a pointer to your Elastic Load Balancer.

Recommendation:

Create Route 53 alias in your hosted zone that contains a root domain alias record that points to your ELB.

8. Amazon Route 53 - DNS alias for ROOT Domain

Baseline:

Checks DNS alias record available for ROOT Domain in AWS Route 53.

Description:

By creating Alias records for Amazon Route 53, it lets you route traffic to selected AWS resources, such as CloudFront distributions and Amazon S3. Unlike a CNAME record, you can create an alias record at the top node of a DNS namespace. For example, if you register the DNS name example.com, the zone apex is example.com. You can't create a CNAME record for example.com, but you can create an alias record like example.com that routes traffic to www.example.com.

Recommendation:

Ensure that DNS alias record set for the root domain within your AWS Route 53 hosted zone.

9. Amazon Route 53 - Enable Privacy Protection

Baseline:

Checks whether the Privacy Protection is enabled, to protect sensitive information.

Description:

Enabling Privacy Protection will protect your contact information from WHOIS ("Who is") queries and reduces the amount of spam that you receive. While registering domain privacy protection is enabled by default. You can choose to disable privacy protection for some or all contacts for a domain. If you do, anyone can see the contact information, that you provided while registering or transferring the domain, including name, address, phone number, and email address by sending a WHOIS query.

Recommendation:

Enable privacy protection for a domain that you registered using Route 53.

1. Amazon Storage Gateway Volumes - Managed KMS Keys

Baseline:

Checks if your Amazon Storage Gateway Volumes are encrypted using KMS Customer Master Keys (CMKs) instead of Amazon Web Services (AWS) managed-keys.

Description:

Defining and using your own KMS CMK customer-managed keys to protect the Amazon Storage Gateway, you gain full control over who can use these keys to access the volumes (cached or stored volumes). The AWS KMS service allows you to create, rotate, disable, and audit CMK encryption keys for your file systems, and helps you have more granular control over your data-at-rest encryption/decryption process.

Recommendation:

Encrypt Amazon Storage Gateway Volumes with your own AWS KMS CMK.

2. Amazon Storage Gateway File Shares - Managed KMS Keys

Baseline:

Checks if your Amazon Storage Gateway File Shares are encrypted using KMS CMKs instead of AWS managed-keys.

Description:

Upon defining and using your own KMS CMKs to protect the Amazon Storage Gateway File Shares backed in Amazon S3, you gain full control over who can use these keys to access the volumes (cached or stored volumes). The AWS KMS service allows you to create, rotate, disable, and audit CMK encryption keys for your file systems, and helps you have more granular control over your data-at-rest encryption/decryption process.

Recommendation:

Encrypt Amazon Storage Gateway File Shares with your own AWS KMS CMK.

3. Amazon Storage Gateway Tapes - Managed KMS Keys

Baseline:

Checks if your Amazon Storage Gateway Tapes are encrypted using KMS CMKs instead of AWS managed-keys.

Description:

Upon defining and using your own KMS CMKs to protect the data available in Amazon Storage Gateway Tapes, you gain full control over who can use these keys to access the volumes (cached or stored volumes). The AWS KMS service allows you to create, rotate, disable, and audit CMK encryption keys for your file systems, and helps you have more granular control over your data-at-rest encryption/decryption process.

Recommendation:

Encrypt Amazon Storage Gateway Tapes with your own AWS KMS CMK.

1. Amazon MQ - Public Access

Baseline:

Check if AWS MQ brokers are not publicly accessible to exposing sensitive data and minimize security risks.

Description:

Publicly available Amazon MQ brokers can be accessed directly outside of a Amazon Virtual Private Cloud (Amazon VPC). Publicly accessible means anyone can access your MQ brokers through their public endpoints, and this can increase the opportunity for malicious activity, such as cross-site scripting (XSS), and clickjacking attacks.

Recommendation:

Disable public accessibility in Amazon MQ by recreating them within a VPC.

2. Amazon MQ - Network of Brokers

Baseline:

Check if your production AWS MQ brokers are running within a mesh network of single-instance, or active/standby brokers.

Description:

A network of brokers enables cloud applications to continue to operate during the failure of a broker, interruption of an availability zone (AZ), or in the event of a disaster that can lead to loss of connectivity with an entire AWS region. Deploying a network of brokers also distributes the load for higher message throughput, and an increased number of application connections to achieve high availability and scalability.

Recommendation:

Recreate Amazon MQ brokers with a mesh network of single-instance, or active/standby brokers.

3. Amazon MQ - Log Exports

Baseline:

Check and identify that the log exports feature is enabled to publish your broker log events to AWS CloudWatch Logs.

Description:

When the Log Exports feature is enabled, Amazon MQ publishes general and audit logs to AWS CloudWatch Logs, allowing you to maintain continuous visibility into your broker's activity, and meet compliance requirements when it comes to auditing.

Recommendation:

Enable the Log Exports feature for your existing Amazon MQ brokers.

4. Amazon MQ - Deployment Mode

Baseline:

Check if AWS MQ brokers are using the active/standby deployment mode for high availability.

Description:

By enabling Deployment Mode, as opposed to the single-broker mode (enabled by default), you can achieve high availability for your Amazon MQ brokers as the service provides automatic failover capability. The MQ active/standby deployment mode includes two broker instances configured by creating a single broker instance in one AZ, and another standby broker instance in a different AZ.

Recommendation:

To enable active/standby deployment mode for your existing Amazon MQ brokers, you need to recreate them with the high availability configuration.

5. Amazon MQ - Auto Minor Version Upgrade

Baseline:

Check if Amazon MQ brokers have the Auto Minor Version Upgrade feature enabled to receive automatically minor engine upgrades.

Description:

With the Auto Minor Version Upgrade feature enabled, the version upgrades will occur automatically during the maintenance window. This way, your AWS MQ brokers can obtain the new software features, bug fixes, and security patches.

Recommendation:

To enable the Auto Minor Version Upgrade feature for your existing Amazon MQ brokers, you need to recreate the brokers with the necessary configuration.

6. Underutilized MQ instances (Priority: High)

Resource-level description:

Amazon MQ instances deemed as underutilized will be listed.

Baseline:

Checks the resource utilization of Amazon MQ message broker services and labels them as underutilized if the CPU usage is less than 2% for the past 48 hours.

Recommendation:

For Amazon MQ, you are billed based on the instance type and the number of consumed hours. You can lower your costs by identifying and stopping the instances that are utilized less.

7. Amazon MQ - High instance utilization (Priority: High)

Baseline:

Checks the performance counters for Amazon MQ and identifies instances that appear to be highly utilized.

Description:

An MQ broker is deemed as overutilized if the average daily CPU usage for the MQ broker is more than 90% for the last seven days.

Recommendation:

Consider changing the instance size.

1. AWS Certificate Manager - Certificates Wildcard Usage

Baseline:

Check if AWS Certificate Manager (ACM) single domain name certificates are used instead of wildcard certificates within your AWS account.

Description:

Use single domain name certificates instead of wildcard certificates to reduce the risks of hacking domain/subdomain. By using a wildcard certificate, when the private key of a certificate is hacked, there is a chance the domain and subdomains will become affected.

Recommendation:

Use a single domain name certificate for each first-level subdomain in ACM to enhance security.

2. AWS Certificate Manager - Certificates Validity

Baseline:

Check if all the requests made during SSL/TLS certificate issue or renewal process are validated when managed by ACM.

Description:

When your ACM certificates are not validated on time (within 72 hours after the request is made), these become invalid, and you will have to request new SSL/TLS certificates, which could cause interruption to your applications or services.

Recommendation:

Determine if any ACM certificate requests are not currently validated within your AWS account.

3. AWS Certificate Manager - Certificates Renewal

Baseline:

Before the validity periods end, check if any SSL/TLS certificates managed by ACM need to be renewed.

Description:

When ACM certificates are not renewed before their expiration date, they become invalid, and the AWS resource that implements these certificates (the CloudFront distribution) will no longer be secure. The ACM service does not automatically renew certificates that are not in use (i.e. no longer associated with other AWS resources). The renewal process must be performed manually before these certificates become invalid.

Recommendation:

Renew SSL/TLS certificates that are about to expire using the ACM service.

4. AWS Certificate Manager - Certificates Expired

Baseline:

Check if all expired SSL/TLS certificates managed by ACM are removed.

Description:

Removing expired ACM certificates eliminates the risk that an invalid SSL/TLS certificate will be deployed accidentally to another resource, such as Elastic Load Balancing (ELB).

Recommendation:

Delete any expired SSL/TLS certificates managed by ACM.

1. AWS EKS - Publicly Accessible

Baseline:

Check if the Amazon Elastic Kubernetes Service (EKS) cluster's Kubernetes API server endpoint is not publicly accessible from the internet to avoid exposing private data.

Description:

Amazon EKS creates an endpoint for the managed Kubernetes API server that communicates with the newly created cluster. By default, this API server endpoint, managed by AWS EKS, can be accessed directly, outside of a VPC. Therefore, every machine on the internet can reach the EKS cluster through its public endpoint, and this can increase the opportunity for malicious activities and attacks.

Recommendation:

To disable public accessibility, you need to reconfigure the visibility of your EKS cluster API server endpoints.

2. AWS EKS - Security Groups

Baseline:

Check if security groups associated with your EKS clusters are configured to allow inbound traffic only on TCP port 443 (HTTPS).

Description:

Do not use every type of port inside your Amazon EKS security groups. Allow inbound traffic only on HTTPS to protect your clusters against malicious activities, such as brute-force attacks.

Recommendation:

To allow access only on TCP port 443, you need to reconfigure the security groups associated with your Amazon EKS clusters.

3. AWS EKS - Cluster Logging

Baseline:

Check if Amazon EKS clusters have logs enabled so you can publish logs to AWS CloudWatch Logs.

Description:

By enabling the EKS Control Plane Logging feature, EKS sends audit and diagnostic logs directly to AWS CloudWatch Logs. These logs can help you to secure and efficiently run your EKS clusters. You can select the log type (API, audit, controller manager, scheduler or authenticate logs) that you need. Logging data is sent to the AWS CloudWatch log group created for the specified Amazon EKS cluster.

Recommendation:

Enable your AWS EKS clusters to publish API, audit, controller manager, scheduler or authenticate logs to Amazon CloudWatch.

1. Amazon WorkSpaces - Unused Instances

Baseline:

Check for unused AWS WorkSpaces instances to reduce your AWS cost.

Description:

A WorkSpaces instance running within your AWS account will add charges even if you are not using it. It is highly recommended that you remove any unused WorkSpaces instances.

Recommendation:

Terminate any unused Amazon WorkSpaces instances available in your AWS Account.

2. Amazon WorkSpaces - Storage Encryption

Baseline:

To meet security and compliance requirements, check whether WorkSpaces storage volumes are encrypted.

Description:

WorkSpaces Storage Encryption allows you to encrypt data to prevent unauthorized users from reading sensitive data. To fulfill security and privacy compliance requirements, encrypt your WorkSpaces storage volumes.

Recommendation:

To encrypt existing AWS WorkSpaces data, you must recreate the necessary WorkSpaces instances with the volumes encryption feature enabled.s

3. Amazon WorkSpaces - Healthy Instances

Baseline:

Checks whether all WorkSpaces instances are healthy and running properly in order to maintain the working state.

Description:

A WorkSpaces instance that doesn't respond to the service health checks is considered unhealthy. The WorkSpaces service periodically sends status requests to the WorkSpaces instances, and it is determined to be unhealthy when a response to a HealthCheck request is not received.

Recommendation:

Unhealthy WorkSpaces indicators can often be cleared by rebooting.

1. Amazon Neptune - IAM Database Authentication

Baseline:

Checks whether the Identity and Access Management (IAM) Database Authentication feature is enabled for your Amazon Neptune database clusters to manage database access.

Description:

IAM Database Authentication for Neptune database clusters removes the need to log in to AWS IAM with user credentials. It provides various benefits. This includes in-transit encryption, the network traffic to and from database clusters that is encrypted using SSL, and centralized management while signing in.

Recommendation:

Enable IAM Database Authentication for your Neptune clusters to manage user credentials through IAM.

2. Amazon Neptune - Auto Minor Version Upgrade

Baseline:

Check whether Neptune database instances have the Auto Minor Version Upgrade feature enabled in order to automatically receive minor engine upgrades.

Description:

The Neptune databases upgrades regularly to introduce new software features, bug fixes, security patches, and performance improvements. The automatic upgrades are applied to Neptune instances during the system maintenance window.

Recommendation:

Enable Auto Minor Version Upgrade feature to update the Neptune database instances.

3. Amazon Neptune - Multi-AZ

Baseline:

Ensures that your Neptune graph database clusters are deployed in at least two AZs.

Description:

If you have Neptune graph database clusters in multiple AZs and these share one Neptune graph database cluster, in the event of AZ failure, the Neptune graph database clusters become unavailable, and the resources within other AZs lose internet access. Create fault tolerance by deploying Neptune graph database clusters in at least two AZs.

Recommendation:

Remove a single point of failure and increase the availability of your application by deploying Neptune graph database clusters in at least two AZs.

4. Amazon Neptune - Encryption

Baseline:

Checks whether your Amazon Neptune database instances are encrypted to protect your data at rest.

Description:

Encryption keys are managed by AWS KMS service, eliminating the need to build and maintain a secure key management infrastructure. Your data is transparently encrypted while being written, and transparently decrypted while being read from your database. The encryption process does not require any additional action from you or your application. It's strongly recommended that you encrypt your Neptune database instances to protect your data and metadata from unauthorized access, and thereby enforce compliance requirements for data-at-rest encryption within your organization.

Recommendation:

Enable encryption for your AWS Neptune database instances.

5. Amazon Neptune - Managed KMS Keys

Baseline:

Checks if your Amazon Neptune database instances are encrypted using KMS CMKs instead of AWS managed-keys (the default encryption keys used by the service when there are no customer keys defined).

Description:

Upon defining and using your own KMS CMK to protect the Neptune database instances, you gain full control over who can use these keys to access the data, including the system metadata. The AWS KMS service allows you to create, rotate, disable, and audit CMK encryption keys for your file systems, and helps you have more granular control over your data-at-rest encryption/decryption process.

Recommendation:

Secure an existing AWS Neptune database instance by recreating it with the required encryption configuration.

6. Amazon Neptune - Backup Retention Period

Baseline:

Checks whether Amazon Neptune graph database clusters have set a minimum backup retention period to retain automated snapshots.

Description:

The minimum retention period set for Amazon Neptune clusters will result in backups continuously and incremental so you can quickly restore to any point within the backup retention period. Backups for a longer time will allow you to handle the data restoration process in the event of a failure.

Recommendation:

Update the Neptune cluster configuration to set up a sufficient backup retention period.

7. Underutilized Neptune instances (Priority: High)

Resource-level description:

Neptune instances deemed as underutilized are listed.

Baseline:

Checks the resource utilization of Amazon Neptune fully managed graph database services and labels them as underutilized if the CPU usage is less than 2% for the past 48 hours.

Recommendation:

For Amazon Neptune you are billed based on the instance type and the number of consumed hours. You can lower your costs by identifying and stopping low utilized instances.

8. Neptune - high instance utilization (Priority: High)

Baseline:

Checks the performance counters for Amazon MQ and identifies instances that appear to be highly utilized.

Description:

A Neptune instance is deemed as overutilized if the average daily CPU usage for the Neptune instance is more than 90% for the last seven days.

Recommendation:

Consider changing the instance size.

1. Amazon DMS - AWS DMS replication instances should not be public when on the same network (Priority: High)

Baseline:

Checks if AWS DMS replication instances are exposed to the public when the source and target databases are in the same network.

Description:

The AWS DMS replication instances can either have a public or private IP address that the instance leverages to connect to the source and target databases. Do not expose the DMS instances to the public when both the source and target databases are on the same network and connected to the instance's virtual private cloud (VPC) through a virtual private network (VPN).

Recommendation:

The instances must be privately accessible when the source and target databases are within your AWS VPC. Restrict exposing your DMS replication instances to the public by creating security groups.

1. Amazon OpenSearch Service domains should be in a VPC (Priority: Moderate)

Baseline:

Checks if the OpenSearch service domains are present within a VPC network or not.

Description:

ES domains in AWS are deployed with either public access or VPC access. When an ES cluster is deployed to a VPC, only users with access to that VPC can reach the cluster. By blocking public requests, you can lower your attack surface by stopping potential threats before they hit your resources.

Recommendation:

Launch an Amazon ES cluster within an AWS VPC to facilitate secure communication between the ES cluster and other AWS services without the need for internet gateways, a network address translation (NAT) device, or a VPN connection.

2. OpenSearch domains should have encryption at rest enabled (Priority: High)

Baseline:

Determines if OpenSearch domains have encryption at rest enabled or not.

Description:

Encryption of data at rest helps prevent unauthorized access so no malicious activities can be performed on the sensitive data within your OpenSearch domains (clusters) and their storage systems. OpenSearch at rest encryption leverages the AWS KMS service to store and manage the encryption keys.

Recommendation:

Ensure that OpenSearch domains are encrypted at rest to protect them from malicious access and to meet any compliance requirements in your organization.

3. OpenSearch domains should have encryption at rest enabled (Priority: High)

Resource-level description:

OpenSearch domains must be encrypted at rest to safeguard the resource from security attacks.

Baseline:

Determines if OpenSearch domains have encryption at rest enabled or not.

Description:

Encryption of data at rest helps prevent unauthorized access so no malicious activities can be performed on the sensitive data within your ES domains (clusters) and their storage systems. ES at rest encryption leverages the AWS KMS service to store and manage the encryption keys.

Recommendation:

Ensure that ES domains are encrypted at rest to protect them from malicious access and to meet any compliance requirements in your organization.

1. GuardDuty should be enabled (Priority: Moderate)

Baseline:

Checks if Amazon GuardDuty is enabled or not.

Description:

AWS GuardDuty is a managed threat detection service that continuously monitors your VPC flow logs, AWS CloudTrail event logs, and DNS logs for malicious or unauthorized behavior. When GuardDuty is enabled, it can help identify and generate findings on unauthorized or unusual activities and provides remediation.

Recommendation:

Enable GuardDuty in every region where your AWS resources are available to fortify your infrastructure against security threats.

1. CloudTrail log file validation should be enabled (Priority: Moderate)

Baseline:

Checks if the CloudTrail log file validation is enabled or not.

Description:

Validate the integrity of your CloudTrail log files and determine if the files were changed after being delivered to the specified S3 bucket. Ideally, the log files should remain unchanged. 

Recommendation:

Enable the file integrity validation feature to check the log files and analyze if any were modified or deleted after the CloudTrail agent delivered them to the S3 bucket.

2. Ensure CloudTrail global services is enabled (Priority: High)

Baseline:

Ensure CloudTrail global services is enabled.

Description:

Improve the visibility of the API activity in your AWS accounts by enabling CloudTrail global services. This toughens the security and simplifies management of AWS accounts by also capturing activities that are not region specific, like IAM events. You can also manage trail configurations for all regions from one location and record API calls in unused regions to detect any unusual activity.

Note: Enabling global services in more than one trail generates duplicate entries. To prevent this, enable it in only a single trail and disable it in other trails.

Recommendation:

Enable CloudTrail global services to better manage AWS accounts and fortify the security of your cloud infrastructure.

3. Ensure CloudTrail Logs are encrypted at rest using AWS KMS keys (Priority: Moderate)

Baseline:

Determines if CloudTrail Logs are encrypted at rest using AWS Key Management Service (KMS) keys.

Description:

CloudTrail logs can be configured to leverage server-side encryption provided by AWS KMS keys to further protect the logs. This enhances the security of your CloudTrail bucket and facilitates better control over who can read the log files in your organization.

Recommendation:

Add an additional layer of security by encrypting CloudTrail logs at rest using AWS KMS keys.

4. Ensure both a log metric filter and an alarm exist (Priority: Moderate)

Baseline:

Determines if a CloudWatch metric filter and an alarm are present for detecting changes to CloudTrail configurations. 

Description:

A metric filter is used to create numeric values from log data coming from CloudTrail to CloudWatch. You can set an alarm based on the incoming logs, and also visualize the stats for the filter in CloudWatch. Each time a configuration change is made at the CloudTrail service level, a CloudWatch alarm, created in your AWS account, is triggered. Use CloudWatch alarms to detect AWS CloudTrail configuration changes to maintain the integrity of the service configuration.

Recommendation:

Ensure that both a log metric filter and an alarm are enabled.

5. CloudTrail should be enabled and configured with at least one multi-region trail (Priority: High)

Baseline:

Checks if CloudTrail is enabled and configured with at least one multi-region trail. 

Description:

When you create a multi-region CloudTrail, AWS actually sets up trails in every region (and every account, in the case of an organization trail). They are separate trails that send data to a shared S3 bucket. So, by creating a multi-region trail, the data is collected centrally.

Recommendation:

Turn on CloudTrail and configure at least one multi-region trail.

6. CloudTrail log file validation should be enabled (Priority: Moderate)

Resource-level description:

CloudTrail log file validation must be enabled, failing which the availability of resources is disrupted.

Baseline:

Checks if the CloudTrail log file validation is enabled or not.

Description:

Validate the integrity of your CloudTrail log files and determine if the files were changed after being delivered to the specified S3 bucket. Ideally, the log files should remain unchanged.

Recommendation:

Enable the file integrity validation feature to check the log files and analyze if any were modified or deleted after the CloudTrail agent delivered them to the S3 bucket.

7. Ensure CloudTrail global services is enabled (Priority: High)

Resource-level description:

Enabling CloudTrail global services captures regional and global events to facilitate better visibility over the API activity of your AWS account.

Baseline:

Ensure CloudTrail global services is enabled.

Description:

Improve the visibility of the API activity in your AWS accounts by enabling CloudTrail global services. This toughens the security and simplifies management of AWS accounts by also capturing activities that are not region specific, like IAM events. You can also manage trail configurations for all regions from one location and record API calls in unused regions to detect any unusual activity.

Recommendation:

Enable CloudTrail global services to better manage AWS accounts and fortify the security of your cloud infrastructure.

8. Ensure the S3 bucket CloudTrail logs are not publicly accessible (Priority: High)

Resource-level description:

Public S3 bucket CloudTrail logs can disrupt the security of your resources.

Baseline:

Determines if your S3 bucket CloudTrail logs are publicly accessible or not.

Description:

Amazon S3 buckets and objects are private by default; only the individual who created the bucket can access it and the objects it contains. CloudTrail logs may include detailed events of API activity in your account. If the permissions you provide for your CloudTrail logs to be stored in an S3 bucket are not secure, you may be providing malicious users access to your AWS account log data, which can increase the risk of unauthorized access.

Recommendation:

Ensure that the S3 bucket associated with CloudTrail logging is not publicly accessible, and safeguard your AWS account log data.

9. Ensure CloudTrail Logs are encrypted at rest using AWS KMS keys (Priority: Moderate)

Resource-level description:

CloudTrail logs that aren't encrypted at rest using AWS KMS keys are open to security vulnerabilities.

Baseline:

Determines if CloudTrail Logs are encrypted at rest using AWS Key Management Service (KMS) keys.

Description:

CloudTrail logs can be configured to leverage server-side encryption provided by AWS KMS keys to further protect the logs. This enhances the security of your CloudTrail bucket and facilitates better control over who can read the log files in your organization.

Recommendation:

Add an additional layer of security by encrypting CloudTrail logs at rest using AWS KMS keys.

10. CloudTrail should be enabled and configured with at least one multi-region trail (Priority: High)

Resource-level description:

CloudTrail trails that aren't configured with at least one multi-region trail can disrupt the availability of resources.

Baseline:

Checks if CloudTrail is enabled and configured with at least one multi-region trail.

Description:

When you create a multi-region CloudTrail, AWS actually sets up trails in every region (and every account, in the case of an organization trail). They are separate trails that send data to a shared S3 bucket. So, by creating a multi-region trail, the data is collected centrally.

Recommendation:

Turn on CloudTrail and configure at least one multi-region trail.

11. Ensure both a log metric filter and an alarm exist (Priority: Moderate)

Resource-level description:

A log metric filter and an alarm must be enabled to ensure high availability of resources.

Baseline:

Determines if a CloudWatch metric filter and an alarm are present for detecting changes to CloudTrail configurations.

Description:

A metric filter is used to create numeric values from log data coming from CloudTrail to CloudWatch. You can set an alarm based on the incoming logs, and also visualize the stats for the filter in CloudWatch. Each time a configuration change is made at the CloudTrail service level, a CloudWatch alarm, created in your AWS account, is triggered. Use CloudWatch alarms to detect AWS CloudTrail configuration changes to maintain the integrity of the service configuration.

Recommendation:

Ensure that both a log metric filter and an alarm are enabled.

1. Ensure rotation for KMS keys is enabled (Priority: Moderate)

Baseline:

Determines if KMS keys can be rotated or not.

Description:

Rotating KMS keys helps reduce the potential impact of a compromised key since the data encrypted using the new key can't be accessed using the previous, exposed key.  

Recommendation:

Ensure rotation of customer-created KMS keys and reduce the chance of a compromised key.

2. Ensure rotation for KMS keys is enabled (Priority: Moderate)

Resource-level description:

Rotation of customer-created KMS keys must be enabled to protect the key from being exposed.

Baseline:

Determines if KMS keys can be rotated or not.

Description:

Rotating KMS keys helps reduce the potential impact of a compromised key since the data encrypted using the new key can't be accessed using the previous, exposed key.

Recommendation:

Ensure rotation of customer-created KMS keys and reduce the chance of a compromised key.

1. Underutilized DocumentDB instances (Priority: High)

Resource-level description:

DocumentDB instances deemed as underutilized will be listed.

Baseline:

Checks the resource utilization of Amazon DocumentDB's fully managed database services and labels them as underutilized if the CPU usage is less than 2% for the past 48 hours.

Recommendation:

For Amazon DocumentDB, you are billed based on the instance type and the number of consumed hours. You can lower your costs by identifying and stopping low utilized instances.

2. Amazon DocumentDB - High instance utilization (Priority: High)

Baseline:

Checks the performance counters for Amazon DocumentDB and identifies instances that appear to be highly utilized.

Description:

A DocumentDB instance is deemed as overutilized if the average daily CPU usage for the DocumentDB instance is more than 90% for the last seven days.

Recommendation:

Consider changing the instance size.

1. Amazon ECS Task definitions - Network modes and user definition (Priority: High)

Baseline:

Checks if the latest ACTIVE revision of ECS monitored task definitions that have host networking mode also have elevated privileges and the user specified as non-root user in the container definition.

Description:

If a task definition has elevated privileges, it is because the user has specifically opted in to that configuration. This control checks for unexpected privilege escalation when a task definition has host networking enabled, but the customer has not opted in to elevated privileges.

Recommendation:

Consider updating the task definition without having escalated privilege.

Required Permissions:

• "ecs:DescribeClusters"
• "ecs:ListTasks"
• "ecs:DescribeTaskDefinition"

2. Amazon ECS service - Auto assign public IP (Priority: High)

Baseline:

Checks if monitored ECS cluster services have a public IP assigned automatically.

Description:

If you launch your Amazon ECS instances with a public IP address, then your Amazon ECS instances are reachable from the internet. Amazon ECS services should not be publicly accessible, as this may allow unintended access to your container application servers.

Recommendation:

Create a new cluster service with public IP disabled since auto-assign public IP cannot be disabled after creation of cluster service.

Required Permission:

• "ecs:DescribeServices"

3. Amazon ECS task definition - Host process namespace (Priority: High)

Baseline:

Checks if latest ACTIVE revision of ECS monitored task definition shares host's process namespace.

Description:

A process ID (PID) namespace provides separation between processes. It prevents system processes from being visible, and allows PIDs to be reused. If the host’s PID namespace is shared with containers, it would allow containers to see all of the processes on the host system. This reduces the benefit of process-level isolation between the host and the containers. These circumstances could lead to unauthorized access to processes on the host itself, including the ability to manipulate and terminate them.

Recommendation:

Consider updating the task definition with PID mode as a task.

Required Permissions:

• "ecs:DescribeClusters"
• "ecs:ListTasks"
• "ecs:DescribeTaskDefinition"

4. Amazon ECS Container definition - Elevated privilege (Priority: High)

Baseline:

Checks if ECS Container definitions inside the latest ACTIVE revision of ECS monitored task definitions has privileged parameter enabled.

Description:

Container definitions with privileged parameter enabled is given elevated privileges on the host container instance (similar to root user). It is not recommended to run a container as privileged.

Recommendation:

Consider updating task definition with container definition without the elevated privilege.

Required Permissions:

• "ecs:DescribeClusters"
• "ecs:ListTasks"
• "ecs:DescribeTaskDefinition"

5. Amazon ECS Container definition - Root file system read-only access (Priority: Moderate)

Baseline:

Checks if ECS Container definitions inside the latest ACTIVE revision of ECS monitored task definitions have read-only access to the mounted root file systems enabled.

Description:

Enabling this option reduces security attack vectors since the ECS container instance's filesystem cannot be tampered with or written to, unless it has explicit read-write permissions on its filesystem folder and directories. This control also adheres to the principle of least privilege.

Recommendation:

Consider updating task definition with container definition with the read-only root file system option enabled.

Required Permissions:

• "ecs:DescribeClusters"
• "ecs:ListTasks"
• "ecs:DescribeTaskDefinition"

6. Amazon ECS Container definition - Secrets as environmental variable (Priority: High)

Baseline:

Checks if secrets are present as environmental variables in ECS Container definitions defined inside the latest ACTIVE ECS monitored task definitions.

Description:

Environment variables are great for configuring and changing the behavior of your applications. There's a downside: a "docker inspect" command can be used to retrieve environmental variables configured for the container. As a result, sensitive information of any kind should never be passed to the container using the environment variables.

Recommendation:

AWS Systems Manager Parameter Store can help you improve the security posture of your organization. It is recommended to use the Parameter Store to store secrets and credentials instead of directly passing them into your container instances or hard coding them into your code.

Required Permissions:

• "ecs:DescribeClusters"
• "ecs:ListTasks"
• "ecs:DescribeTaskDefinition"

7. Amazon ECS cluster - Container insights (Priority: Moderate)

Baseline:

Checks if monitored clusters have container insights enabled.

Description:

Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon ECS clusters. Use AWS CloudWatch container insights to collect, aggregate, and summarize metrics and logs from your containerized applications and micro services. CloudWatch automatically collects metrics for many resources, such as CPU, memory, disk, and network. Container insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly.

Recommendation:

Container insights cannot be enabled after a cluster is created. Consider creating a new cluster with container insights enabled.

Required Permission:

• "ecs:DescribeClusters"

1. Amazon EC2-VPC security group - too many rules (Priority: Moderate)

Baseline:

Checks and identifies Amazon EC2-VPC security groups that have more than 50 inbound and outbound rules.

Description:

When you launch an instance in a VPC, you can specify up to five security groups that get associated with the instance. For each security group, you can add rules that control inbound and outbound traffic. Instance performance can be affected if the security group has a large number of rules.

Recommendation:

Delete unnecessary or overlapping rule in an EC2-VPC security group.

Permissions Required:

• "ec2:DescribeInstances"
• "ec2:DescribeSecurityGroups"

 2. Unused Virtual Private Gateways (Priority: Low)

Baseline:

Checks configuration for Amazon Virtual Private Gateways (VGWs) and identifies unused VGWs that are not associated with the VPC side of the VPN connection.

Description:

Every unused (detached) AWS Virtual Private Gateway should be removed from AWS account to facilitate better management and to prevent from reaching service limit.

Recommendation:

Identify and remove any unused Virtual Private Gateways provisioned within your AWS account to avoid reaching service limit (by default, you are limited to 5 VGWs - attached or detached - per AWS region).

Required Permission:

"ec2:DescribeVpcs"

3. Amazon VPN Tunnels - UP (Priority: High)

Baseline:

Ensures that the state of your AWS Virtual Private Network (VPN) tunnels is UP to ensure network traffic flow over your Virtual Private Network.

Description:

Continuous monitoring for your VPN tunnels will help you take immediate actions in the event of a failure, in order to maximize uptime and ensure network traffic flow over your Amazon VPN connections at all times.

Recommendation:

If your AWS VPN connection tunnels are currently offline, ensure that your firewall configuration is allowing the VPN connection tunneling in the firewall policy.

Required Permission:

• "ec2:DescribeVpnConnections"

4. Amazon VPC - Peering Connection Configuration (Priority: Moderate)

Baseline:

Ensures that the Amazon VPC peering connection configuration is compliant with the desired routing policy.

Description:

Proper configuration of the VPC peering connection routing tables restrict traffic only between the desired resources, hence, leading to an effective way of minimizing the impact of security breaches as AWS resources outside of these routes become inaccessible to the peered VPC.

Recommendation:

Determine if the routing tables associated with your peered VPCs implement the right routing policy.

Required Permission:

• "ec2:DescribeVpcPeeringConnections" 
• "ec2:DescribeRouteTables"

5. Amazon VPC - Flow Logs (Priority: Moderate)

Baseline:

Ensures whether Virtual Private Cloud (VPC) Flow Logs feature is enabled in all applicable AWS regions or not.

Description:

Once enabled, VPC Flow Logs will start collecting network traffic data to and from VPC, thus helping you detect and troubleshoot security issues and make sure network access rules are not overly permissible. You also get notified when abnormal activities are triggered within your VPC network such as rejected connection requests or unusual levels of data transfer.

Recommendation:

Enable Flow Logs for your AWS VPC.

Required Permissions:

• "ec2:DescribeVpcs" 
• "ec2:DescribeFlowLogs"

6. Default VPC (Priority: Moderate)

Baseline:

Ensures that your AWS application is not deployed with the default Virtual Private Cloud so as to follow security best practices.

Description:

A default VPC is suitable for getting started quickly, and for launching public instances such as a blog or simple website, however, when you deploy complex applications and use multi-tier architectures you may need to create a non-default VPC that suits your specific requirements.

Recommendation:

Create a own (non- default) VPC that suits your specific requirements and migrate your custom AWS applications to it.

Required Permissions:

• "ec2:DescribeVpcs" 
• "ec2:DescribeInstances"

7. Ineffective Network ACL DENY Rules (Priority: High)

Baseline:

Ensures that Amazon Network ACL DENY rules are effective within the VPC configuration.

Description:

AWS Network ACL is an additional layer of defense for your Virtual Private Cloud, basically a network firewall where you can set rules that allow or deny access to a specific port or IP range. An AWS NACL contains a numbered list of rules that are evaluated in order, starting with the lowest numbered rule (e.g. 100), to determine whether the traffic is allowed in or out of the associated VPC subnet(s). The order of the DENY rules within your Network ACLs is crucial as these are evaluated in order and any ineffective or deficient DENY rule can be applied regardless of any higher-numbered rule that may contradict it.

Recommendation:

Reconfigure any ineffective or mis configured AWS NACL DENY rules in order to block the traffic to the necessary port at the subnet level.

Required Permission:

• "ec2:DescribeNetworkAcls"

8. Network ACL - Unrestricted Inbound Traffic (Priority: Moderate)

Baseline:

Ensures no Amazon Network ACL allows inbound/ingress traffic from all ports.

Description:

Regulating the subnets inbound/ingress traffic by opening just the ports required by your applications will add an additional layer of security to your VPC and protect against malicious activity such as such as Denial of Service (DoS) attacks or Distributed Denial of Service (DDoS) attacks. Manage your AWS NACL inbound rules to implement the principle of least privilege and reduce the possibility of unauthorized access at the subnet level.

Recommendation:

Update your AWS NACL inbound rules configuration in order to allow traffic from specific source port or source port range only.

Required Permission:

• "ec2:DescribeNetworkAcls"

9. Network ACL - Unrestricted Outbound Traffic (Priority: Moderate)

Baseline:

Ensures no Amazon Network ACL allows outbound/egress traffic to all ports.

Description:

Controlling the outbound traffic of one or more subnets by opening just the ports required by your applications will add an additional layer of security to your VPC (a second layer of defense after security groups). Manage your AWS NACL outbound rules to implement the principle of least privilege and reduce the possibility of unauthorized access at the subnet level.

Recommendation:

Update your AWS NACL inbound rules configuration in order to allow traffic from specific source port or source port range only.

Required Permission:

• "ec2:DescribeNetworkAcls"

10. Private Subnets - Create Route Table (Priority: Moderate)

Baseline:

Checks whether a custom route table is created and associated with your private subnets in order to control the subnets routing.

Description:

To control the routing for your private subnets you need to create custom route tables. Once these VPC resources are created, all the subnets which should be private within web, app and data tiers can be explicitly associated with the new route tables. A route table contains a set of routes that are used to determine where the network traffic is directed. The custom route table associated with private subnets should contain only the default route (0.0.0.0/0) pointing to an AWS NAT Gateway. A private subnet can be associated only with one route table at a time, however, you can associate multiple private subnets with the same route table.

Recommendation:

Create custom route table and associate it with your private subnets.

Required Permission:

• "ec2:DescribeRouteTables"

11. Amazon VPC - Exposed Endpoints (Priority: Moderate)

Baseline:

Ensures Amazon VPC endpoints are not exposed to everyone.

Description:

When the Principal element value is set to "*" within the access policy, the VPC endpoint allows full access to any IAM user or service within the VPC using credentials from any AWS accounts. Allowing access in this manner is considered bad practice and can lead to security issues. Updating the access policy allows to stop any unsigned requests made to the supported services and resources.

Recommendation:

Restrict access to your Amazon VPC endpoints by updating access policy.

Required Permission:

• "ec2:DescribeVpcEndpoints"

12. Use VPC Endpoints (Priority: Moderate)

Baseline:

Check whether the Amazon Virtual Private Cloud (VPC) endpoints are used to securely connect your VPC to other AWS services.

Description:

VPC endpoints enable you to privately access specific AWS services from your own Amazon Virtual Private Cloud, without using public IP addresses and without requiring the traffic data to travel across the Internet.

Recommendation:

Enable VPC endpoint to connect with particular AWS services that are outside your VPC network through a private link.

Required Permission:

• "ec2:DescribeVpcEndpoints"

13. Ensure the default security group of every VPC restricts traffic (Priority: Low)

Baseline:

Determines if the default security group of every VPC instance restricts traffic.

Description:

The AWS default security group does not restrict all inbound and outbound traffic. By default, VPC comes with a security group whose initial configuration denies all inbound traffic from the internet and allows all outbound traffic. Configure all VPC default security groups to restrict all traffic so the instance doesn't accidentally send outbound traffic.

Recommendation:

Ensure that AWS EC2 default security groups restrict all inbound traffic, and force users to create custom security groups instead of using default ones.

14. Amazon VPC - Subnet auto-assign public IP (Priority: Moderate)

Baseline:

Checks whether Amazon VPC Subnets have auto-assign public IPv4 address enabled.

Description:

A public IPv4 address is an IP address that is reachable from the internet. Instances that are launched into subnets with auto-assign public IPv4 address enabled will have a public IP address assigned to their primary network interface.

Recommendation:

Evaluate if VPC subnet needs to have an auto-assigned public IPv4 address enabled, then disable it if it's not needed.

Required permission:

• "ec2:DescribeSubnets"

15. Amazon VPC - Network ACL unused (Priority: Low)

Baseline:

Checks whether there are any network access control lists (ACLs) that aren't associated with a subnet.

Description:

Network ACLs are useful at regulating inbound and outbound traffic at the subnet level. Unused resources in AWS add clutter and unnecessary security risks. By cleaning up unused or redundant network ACLs, you can ensure that your AWS account is well-maintained.

Recommendation:

Consider deleting unused network ACLs.

Required permission:

• "ec2:DescribeNetworkAcls"

1. Allocate Elastic IPs for NAT Gateways (Priority: Moderate)

Baseline:

Ensures that an Elastic IP is allocated for each NAT gateway that you want to deploy within your AWS account.

Description:

Allocating Elastic IP for NAT Gateways, use a NAT device to enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating connections with the instances. You can mask the failure of an EC2 instance by rapidly remapping the address to another instance launched in your VPC.

Recommendation:

Allocate an AWS Elastic IP for each NAT gateway that you want to deploy within your VPC.

Required Permissions:

• "ec2:DescribeVpcs"
• "ec2:DescribeNatGateways"

2. Amazon VPC - Managed NAT Gateway (Priority: Moderate)

Baseline:

Ensures AWS VPC Managed NAT (Network Address Translation) Gateway service is enabled for high availability (HA).

Description:

AWS provides two types of NAT devices: a managed NAT gateway and a NAT instance. Using the AWS VPC Managed NAT Gateway service that has built-in redundancy for high availability enables EC2 instances sitting in a private subnet to connect to the internet or with other AWS components.

Recommendation:

Enable the Managed NAT Gateway service for your AWS VPC network(s).

Required Permissions:

• "ec2:DescribeVpcs"
• "ec2:DescribeNatGateways"

3. NAT Gateways - Multi-AZ (Priority: Moderate)

Baseline:

Ensures that your NAT gateways are deployed in at least two Availability Zones (AZs).

Description:

If you have EC2 instances in multiple Availability Zones and these share one NAT gateway, in the event of AZ failure the NAT gateway becomes unavailable and the resources within other Availability Zones lose internet access. Create fault tolerance by deploying NAT gateways in at least two AZs.

Recommendation:

Remove a single point of failure and increase the availability of your application by deploying NAT gateways in atleast two Availability Zones (AZs).

Required Permissions:

• "ec2:DescribeVpcs"
• "ec2:DescribeSubnets"

1. Auto Scaling Groups (EC2) - Multi-AZ (Priority: Moderate)

Baseline:

Checks for Auto Scaling groups launching instances in a single Availability Zone (AZ)

Description:

As you may already know the AWS systems housing your EC2 instances are hosted in high availability data centers. Auto Scaling lets you take advantage of this geographical isolation by allowing you to distribute Auto Scaling groups across multiple Availability Zones.

Recommendation:

Remove a single point of failure and increase the availability of your application.

Required Permissions:

• "autoscaling:DescribeAutoScalingGroups"

2. Launch configurations – Security group does not exist (Priority: High)

Baseline:

Identifies launch configurations with invalid or deleted security groups.

Description:

The launch configuration determines aspects of the EC2 instance (AMI, instance type, storage, tags, etc.) that Auto Scaling creates for you. The instance will fail to launch if the name of the security group mentioned in the launch configuration does not exist.

Recommendation:

Create a new launch configuration and update it for the Auto Scaling group.

Required Permissions:

"autoscaling:DescribeLaunchConfigurations"

3. Health checks for Auto Scaling groups associated with a load balancer (Priority: Moderate)

Resource-level description:

ASGs associated with a load balancer must use load balancer health checks to ensure the availability of resources.

Baseline:

Checks if Auto Scaling groups (ASGs) associated with a load balancer have a health check configuration for the load balancer.

Description:

The default health checks for an Auto Scaling group are EC2 status checks only, and the ASG does not consider an instance unhealthy if it fails the health checks provided by a load balancer. You can determine an instance's health from the load balancer by configuring the ASG to use load balancer health checks.

Recommendation:

Add a load balancer health check to an ASG so instance health is determined by both the EC2 status checks and the load balancer health checks.

4. Amazon EC2 Instance Auto Scaling - Launch templates metadata response hop limit (Priority: High)

Baseline:

Checks whether Amazon EC2 Instance Auto Scaling group launch template configuration has a metadata response hop limit greater than one.

Description:

The Instance Metadata Service (IMDS) provides metadata information about an Amazon EC2 instance and is useful for application configuration. Restricting the HTTP PUT response for the metadata service to only the EC2 instance protects the IMDS from unauthorized use.
The Time To Live (TTL) field in the IP packet is reduced by one on every hop. This reduction can be used to ensure that the packet does not travel outside EC2. If metadata response hop limit is greater than one, the token can leave the EC2 instance.

Recommendation:

Consider modifying metadata response hop limit of the launch template to one.

Required permissions:

• "ec2:DescribeLaunchTemplates"
• "ec2:describeLaunchTemplateVersions"

5. Amazon EC2 Instance Auto Scaling - Launch templates auto-assign public IP (Priority: Moderate)

Baseline:

Checks whether the launch templates associated with Amazon EC2 Auto Scaling group are configured to assign public IP to network interfaces upon launch.

Description:

Amazon EC2 instances in an Auto Scaling group launch configuration should not have an associated public IP address, except for in limited edge cases. Amazon EC2 instances should only be accessible from behind a load balancer, instead of being directly exposed to the internet.

Recommendation:

Consider disabling the Auto-assign public IP address option of Auto Scaling launch templates.

Required permissions:

• "ec2:DescribeLaunchTemplates"
• "ec2:describeLaunchTemplateVersions"

6. Amazon EC2 Instance Auto Scaling Groups (EC2) - Use launch template (Priority: Moderate)

Baseline:

Check whether Amazon EC2 Auto Scaling group is created from an EC2 Launch template.

Description:

An EC2 Auto Scaling group can be created from either an EC2 launch template or a launch configuration. However, using a launch template to create an Auto Scaling group ensures that you have access to the latest features and improvements.

Recommendation:

Consider migrating from launch configurations to launch templates for EC2 Auto Scaling groups.

Required permission:

• "autoscaling:DescribeAutoScalingGroups"

1. Unmapped Elastic IP address (Priority: Moderate)

Baseline:

Checks whether the allocated Elastic IP address is associated with an active EC2 instance or network interface.

Description:

Elastic IP is a static, public IPv4 address. When you associate an Elastic IP to an EC2 instance, or network interface, the already existing public IP address of the instance gets released back into the available address pool. With an Elastic IP address, you can hide the failure of an instance or resource, by disassociating the IP address from the resource and remapping to a different one in the same account.

Recommendation:

For efficient utilization, Amazon Web service limits the number of Elastic IPs to 5 per Region for all accounts. Also, a small hourly fee gets levied on unused addresses. So either associate the Elastic IP with an active instance/interface or release it back to the pool.

Required Permission:

• "ec2:DescribeInstances"

2. Unused EC2 Elastic IP Address (Priority: Low)

Baseline:

Checks if any unused EC2 Elastic IP addresses are present.

Description:

Elastic IPs (EIPs) allow users to mask instance failure or software failure by rapidly remapping the address to another instance in the same account. AWS enforces an hourly charge if an EIP address within your account isn't associated with a running EC2 instance or an Elastic Network Interface (ENI).

Recommendation:

Remove any unused EC2 EIP addresses in your AWS account and release them to avoid excessive charges to your monthly AWS bill.

1. AWS Secrets Manager - Automatic rotation (Priority: Moderate)

Baseline:

Checks whether AWS Secrets Manager secrets have automatic rotation enabled.

Description:

The AWS Secrets Manager helps you improve the security posture of your organization. You can use secret rotation to replace long-term secrets with short-term ones. Rotating your secrets reduces the amount of time an unauthorized person can use a compromised secret.

Recommendation:

Consider enabling automatic rotation of Secrets Manager secrets.

Required permission:

• "secretsmanager:ListSecrets"

2. AWS Secrets Manager - Max days since rotation (Priority: Moderate)

Baseline:

Checks whether AWS Secrets Manager secrets have been rotated once, every 90 days.

Description:

Rotating secrets can help you reduce the risk of unauthorized use of your secrets in your AWS account. Examples include database credentials, passwords, third-party API keys, and even arbitrary text. If you do not change your secrets for a long period of time then the secrets are more likely to be compromised.

Recommendation:

Setup Rotation Configuration of the secrets so that they are rotated at least once every 90 days.

Required permission:

• "secretsmanager:ListSecrets"

3. AWS Secrets Manager - Unsuccessful rotation (Priority: Moderate)

Baseline:

Checks whether AWS Secrets Manager secrets are rotated successfully based on configured rotation schedule.

Description:

The AWS Secrets Manager rotates secrets. In addition to configuring secrets to rotate automatically, you should also ensure that those secrets rotate successfully based on the rotation schedule. If the automatic rotation fails, then the AWS Secrets Manager might have encountered errors with the configuration.

Recommendation:

Consider troubleshooting the unsuccessful rotation of secrets.

Required permission:

• "secretsmanager:ListSecrets"

4. AWS Secrets Manager - Unused secrets (Priority: Moderate)

Baseline:

Checks whether AWS Secrets Manager secrets have been accessed within the last 90 days.

Description:

Deleting unused secrets is as important as rotating secrets. Deleting unused secrets helps revoke secret access from users who no longer need it. It also helps to reduce the cost of using AWS Secrets Manager. Therefore, it is essential to delete unused secrets routinely.

Recommendation:

Consider deleting unused secrets from AWS Secrets Manager.

Required permission:

• "secretsmanager:ListSecrets"

5. AWS Secrets Manager - Customer managed encryption (Priority: Low)

Baseline:

Checks whether AWS Secrets Manager secrets are encrypted using customer-managed keys (AWS Key Management Service).

Description:

A secret can be encrypted either with AWS-managed Key Management Service (KMS) keys (default option) or Customer Master Keys (CMK). All secrets that have default encryption will be encrypted with the same AWS managed key and policy for the key cannot be edited since it is created by the service. Use CMKs in order to have granular control over key permissions and have each secret encrypted using different KMS keys.

Recommendation:

Consider using AWS KMS CMKs for encrypting secrets instead of using AWS-managed KMS for encryption.

Required permission:

• "secretsmanager:ListSecrets"