Checks We Perform

Recommendation 1.1 of the CIS AWS Foundations Benchmark states that because the root account has unrestricted access to all resources in the AWS account, use of this account should be avoided. The root account is the most privileged AWS account. Minimizing the use of this account and adopting the principle of least privilege for access management will reduce the risk of accidental changes and unintended disclosure of highly privileged credentials.

For more information, visit the AWS documentation on AWS root accounts.

Recommendation 1.2 of the CIS AWS Foundations Benchmark states that because MFA adds an extra layer of protection on top of a user name and password, MFA needs to be enabled for all IAM users with a console password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. Enabling MFA provides increased security for console access as it requires the authenticating principal to possess a device that emits a time-sensitive key and have knowledge of a credential.

For more information, visit the AWS documentation on using MFA.

Recommendation 1.3 of the CIS AWS Foundations Benchmark states that all credentials that have been unused in 90 or greater days should be removed or deactivated. Disabling or removing unnecessary credentials will reduce the window of opportunity for credentials associated with a compromised or abandoned account to be used.

For more information, visit the AWS documentation for finding unused credentials.

The CIS AWS Foundations Benchmark explains that password policies need to enforce password complexity requirements in order to increase account resiliency against brute force login attempts. Industry best practice is to ensure that IAM password policies require at least one lowercase letter, one uppercase letter, one number, one symbol, and a minimum length of 10 characters.

For more information, visit the AWS documentation for a setting password policy for IAM users.

Industry best practices is to ensure that IAM password policies prevent password reuse for the last 24 passwords. The CIS AWS Foundations Benchmark explains that password policies need to prevent password reuse in order to increase account resiliency against brute force login attempts.

For more information, visit the AWS documentation for a setting password policy for IAM users.

Recommendation 1.16 of the CIS AWS Foundations Benchmark states that by default, IAM users, groups, and roles have no access to AWS resources. IAM policies are how privileges are granted to users, groups, or roles. To that end, IAM policies should only be attached to groups or roles – not users. Assigning privileges at the group or role level reduces the complexity of access management as the number of users grow. Reducing access management complexity may in-turn reduce opportunity for a principal to inadvertently receive or retain excessive privileges.

For more information, visit the AWS documentation for managing IAM policies.

Recommendation 1.19 of the CIS AWS Foundations Benchmark states that by ensuring IAM instance roles are used for AWS resource access, you reduce the risks associated with sharing and rotating credentials that can be used outside of AWS itself. If credentials are compromised, they can be used from outside of the AWS account they give access to. In contrast, in order to leverage role permissions an attacker would need to gain and maintain access to a specific instance to use the privileges associated with it. Additionally, if credentials are encoded into compiled applications or other hard to change mechanisms, then they are even more unlikely to be properly rotated due to service disruption risks. As time goes on, credentials that cannot be rotated are more likely to be known by an increasing number of individuals who no longer work for the organization owning the credentials.

For more information, visit the AWS documentation for using IAM roles.

Following the industry standard of least privilege, recommendation 1.22 of the CIS AWS Foundations Benchmark states that IAM policies that allow full administrative privileges should not be created. The CIS recommends to first determine what users need to do, and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges. It's more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later. Specifically, IAM policies that have a statement with "Effect": "Allow" with "Action": "*" over "Resource": "*" should be removed.

For more information, visit the AWS documentation for managing IAM policies.

S3 bucket policies and user policies are what determine the permissions and access to S3. S3 bucket policies are attached at the bucket level and apply to all objects within that bucket. Our recommendation is to ensure that S3 bucket policies do no grant access to all buckets.

For more information, visit the AWS documentation on S3 bucket policy examples.

To securely create a multi-account AWS environment, we recommend housing AWS accounts within an organization. The AWS Organizations feature provides centralized account management and governance. It allows you to group multiple accounts into an organizational units (OUs) and, in turn, apply policies to OUs instead of directly to accounts. This type of consolidation becomes extremely valuable as you scale your AWS resources and architecture.

For more information, visit the AWS documentation for AWS Organizations best practices.

Using IAM policies with MFA conditions, you can ensure that MFA is required for users who are able to make API calls. This will add an additional layer of protection and accountability before a user is allowed to perform sensitive API operations.

For more information, visit the AWS documentation on configuring MFA-protected API access.

AWS does allow you to make your EBS snapshots public, but we recommend restricting access to EBS snapshots by making them private, unless you have a specific business need that requires this. These point-in-time snapshots are crucial to your data backup and recovery processes; you don’t want to risk public access or permissions misconfigurations here.

For more information, visit the AWS documentation on EBS snapshots.   

Recommendation 1.11 of the CIS AWS Foundations Benchmark states that IAM password policies can require passwords to be rotated or expired after given a specified number of days. It’s recommended that password policy expire passwords after 90 days or fewer. Decreasing the password lifetime increases account resiliency against brute force login attempts. Additionally, requiring regular password changes helps scenarios like stolen passwords, redundant use of passwords across accounts, and compromised end users.

Recommendation 1.12 of the CIS AWS Foundations Benchmark recommends that all access keys associated with the root account be removed. The root account is the most privileged user in the AWS account, and Access Keys provide programmatic access to a given account. That said, if the account is compromised, by removing the access keys associated with the root account, it limits vectors by which the attackers can act on. Additionally, by removing the root access keys, it encourages the creation and use of role based accounts that are least privileged.

Recommendation 1.13 of the CIS AWS Foundations Benchmark states that the root account is the most privileged user in an AWS Account. MFA adds an additional layer of security on top of a username and password. When a user signs into an AWS website/account, if MFA is enabled, they will be prompted for their username and password following an authentication code from their AWS MFA device.

Note: When virtual MFA is used for root accounts, make sure NOT to use a personal device, but rather a dedicated mobile device (tablet/phone) that is securely independent from any other devices.

 

Recommendation 1.14 of the CIS AWS Foundations Benchmark states that the root account is the most privileged user in an AWS Account. MFA adds an additional layer of security on top of a username and password. When a user signs into an AWS website/account, if MFA is enabled, they will be prompted for their username and password following an authentication code from their AWS MFA device. For Level 2, it is recommended that the root account be protected with a hardware MFA. 

Following cryptographic best practice, we recommend rotating CMKs annually. Enabling automatic key rotation through AWS KMS is the easiest way to ensure this standard is followed. Using the automatic key rotation feature, AWS KMS will automatically generate new cryptographic material for a CMK every year, plus it will save the old cryptographic material. If you prefer, manual key rotation is also available.

For more information, visit the AWS documentation on rotating customer master keys.

To enhance the security of S3 buckets, you must ensure encryption is properly enabled. Amazon gives you the ability to set default encryption settings using SSE-S3 or SSE-KMS to automatically encrypt all objects that are stored within an S3 bucket.

For more information, visit the AWS documentation on enabling Amazon S3 default bucket encryption.

To enhance the security of your EC2 instances, you must ensure that encryption is enabled for EBS volumes. AWS provides the Amazon EBS encryption feature, which uses KSM to encrypt EBS volumes. Amazon EBS encryption is supported by all volume types.

For more information, visit the AWS documentation on EBS encryption.

To enhance the security of Amazon RDS and data at rest or in underlying storage, you must ensure that encryption is enabled for DB instances. Amazon RDS can encrypt DB instances using the industry standard AES-256 encryption algorithm to encrypt data on the server that hosts DB instances.

For more information, visit the AWS documentation on encrypting Amazon RDS resources.

To enhance the security of your Application Load Balancers (ALBs) and Network Load Balancers (NLBs), you must ensure that all load balancers that accept HTTPS traffic require, at a minimum, TLS 1.2. Older versions of TLS or legacy SSL protocols are known to have fatal security flaws and do not provide protection for data in transit.

For more information, visit the AWS documentation on creating HTTPS listeners for ALBs.

To support your backup and recovery processes, we recommend enabling versioning in S3. S3 versioning provides a way to keep your objects accurate, up to date, and protected. You can enable bucket versioning on both new buckets and buckets that already exist, and this keeps multiple versions of an object within a bucket.

For more information, visit the AWS documentation on enabling versioning on S3 buckets.

A foundation to S3 security is to ensure S3 buckets are not publicly available. Using the Block Public Access feature, you can manage access to buckets, accounts, and access points. By default, new buckets, access points, and objects do not allow public access.

For more information, visit the AWS documentation on configuring Block Public Access settings for S3 buckets.

To enhance the security of AWS RDS and DB instances, they should not be publicly accessible. Restricting unauthorized access will minimize the risk of compromise to your DB instances. 

For more information, visit the AWS documentation on public accessibility to RDS instances.

Recommendation 2.7 of the CIS AWS Foundations Benchmark is to ensure CloudTrail logs are encrypted at rest using KMS CMKs . The CIS explains that CloudTrail records AWS API calls for your account and delivers log files to you. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use
SSE-KMS. 

To strengthen your security posture, we recommend configuring EC2 instances as managed instances under AWS Systems Manager. AWS Config can use the ec2-instance-managed-by-systems-manager rule to check whether the EC2 instances in your account are managed by Systems Manager.

For more information, visit the AWS documentation on AWS Systems Manager managed instances.

AWS explains that you can improve the security posture of your managed instances by configuring AWS Systems Manager to use an interface VPC endpoint. An interface VPC endpoint enables you to connect to services powered by AWS PrivateLink, a technology that enables you to privately access Amazon EC2 and Systems Manager APIs by using private IP addresses. This means that your managed instances don't have access to the Internet.

For more information, visit the AWS documentation on creating VCP endpoints.

Patch management is an integral component of vulnerability management. To ensure your EC2 instances are compliant with patching standards, you must use AWS Systems Manager to apply patch baselines to instances. To associate a specific patch baseline with your instances, you will add EC2 instances to a patch group, then adding a patch group to a patch baseline.

For more information, visit the AWS documentation on creating a patch grou

It is best practice not to use insecure ports and protocols such as FTP, Telnet, and SNMP. Using insecure ports and protocols makes it possible for your traffic to be sent unencrypted over the Internet. To ensure protection, you can utilize the inbound rules for security groups. Security groups act as a firewall in your AWS environment and their inbound rules will show you areas of vulnerability in terms of insecure ports and protocols.

For more information, visit the AWS documentation on security group rules.

To build a strong perimeter, you must ensure that EC2 instances are not directly connected to the Internet. You can deploy EC2 instances in two ways: on an internal network or assigning them a public IP address. For security purposes, you want to ensure that when possible, your EC2 instances live on an internal network and you do not allow direct Internet access to them.

For more information, visit the AWS documentation on networking in Amazon EC2.

Recommendation 4.2 of the CIS AWS Foundations Benchmark is to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to port 3389. The CIS explains how security groups provide stateful filtering of ingress/egress network traffic to AWS resources. By removing unfettered connectivity to remote console services, such as RDP, this reduces a server's exposure to risk.

For more information, visit the AWS documentation on security group rules for different use cases.

Just because you create a NAT gateway does not mean that EC2 instances have the ability to run outbound traffic through the Internet. You need to define a route that allows EC2 instances on a private subnet to talk to NAT gateways and then go out to the Internet. This is where route tables comes into play. AWS defines a route table as a set of rules (called routes) that are used to determine where network traffic from your subnet or gateway is directed. When you save your route, you’ve created a route for instances in that Availability Zone to be able to route outbound traffic to the Internet.

For more information, visit the AWS documentation on NAT gateways. 

Recommendation 4.1 of the CIS AWS Foundations Benchmark is to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to port 22. The CIS explains how security groups provide stateful filtering of ingress/egress network traffic to AWS resources. By removing unfettered connectivity to remote console services, such as SSH, this reduces a server's exposure to risk.

For more information, visit the AWS documentation on security group rules for different use cases.

It is a security best practice to ensure that the Amazon Relational Database Service (Amazon RDS) instances are not publicly accessible. This could lead to potential data loss as you are giving direct access to your database when it is exposed to the internet.

To enhance your security perimeter, you must ensure that you do not have multiple hosts with external access to administrative ports, like port 22, and that you implement the principle of least privilege around administrative ports. You can use Session Manager feature in AWS Systems Manager or bastion hosts to ensure that no more than 1 host per account is allowed external access to port 22.

For business continuity and disaster recovery purposes, it’s extremely important to have the maintenance and backup settings in your Amazon RDS correctly configured. If configured properly, your RDS can easily manage your backups, patching, failure detection, and more.

For more information, visit the AWS documentation on working with RDS backups.

If your security groups allow unrestricted traffic (0.0.0.0/0 or ::/0) to all ports, this invalidates everything the security groups are working to accomplish as a virtual firewall. You must ensure that your security groups do not allow unrestricted traffic to all ports. 

For more information, visit the AWS documentation on security group inbound and outbound rules. 

Recommendation 4.3 of the CIS AWS Foundations Benchmark is to ensure that the default security group of every VPC restricts all traffic. This CIS explains that a VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to this default security group. Configuring all VPC default security groups to restrict all traffic will encourage least privilege security group development and mindful placement of AWS resources into security groups which will in-turn reduce the exposure of those resources.

For more information, visit the AWS documentation on default security groups.

Best practice for AWS WAF rules is to maintain logging in order to gain details about the traffic that is analyzed by your web ACLs. AWS explains that the information contained in the logs includes the time that AWS WAF received the request from your AWS resource, detailed information about the request, and the action for the rule that each request matched. You send logs from your web ACL to an Amazon Kinesis Data Firehose with a configured storage destination. After you enable logging, AWS WAF delivers logs to your storage destination through the HTTPS endpoint of Kinesis Data Firehose.

For more information, visit the AWS documentation on logging web ACL traffic information.

Internet-facing ALBs need to have WAF ACLs attached. WAF, as part of your security posture, will sit in front of your ALBs and provide a web ACL to block malicious traffic on the load balancer side. To implement this best practice, you must understand which load balancers are attached to the WAF through we ACLs.

For more information, visit the AWS documentation on associating web ACLs with an AWS resources.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Oracle ports 1521 and 2483. These are common ports that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to MySQL port 3306. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to PostgreSQL port 5432. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Redis port 6379. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to MongoDB ports 27017 and 27018. These are common ports that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Cassandra ports 7199, 8888, and 9160. These are common ports that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Memcached port 11211. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Microsoft SQL Server port 1433. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

By using AWS WAF in combination with web ACLs, you can control control how a variety of services (including API Gateways) respond to web requests, as well as inspect web requests to see if they match your criteria. The Amazon API Gateway service is used to create, publish, maintain, monitoring, and secure REST, HTTP, and WebSocket APIs.

For more information, visit the AWS documentation on Amazon API Gateway.

Recommendation 2.1 of the CIS AWS Foundations Benchmark is to ensure CloudTrail is enabled in all regions. The CIS explains that CloudTrail records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services. The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing.

For more information, visit the AWS documentation on best practices in CloudTrail.

Recommendation 2.2 of the CIS AWS Foundations Benchmark states that enabling log file validation will provide additional integrity checking of CloudTrail logs. CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to S3. These digest files can be used to determine whether a log file was changed, deleted, or unchanged after CloudTrail delivered the log.

For more information, visit the AWS documentation on validating CloudTrail log file integrity.

Recommendation 2.3 of the CIS AWS Foundations Benchmark states that, by using bucket policies or ACLs, S3 buckets used to store CloudTrail logs should prevent public access. Allowing public access to CloudTrail log content may aid an adversary in identifying weaknesses in the affected account's use or configuration.

For more information, visit the AWS documentation on S3 bucket policies for CloudTrail.

Recommendation 2.4 of the CIS AWS Foundations Benchmark states that CloudTrail logs need to be integrated with CloudWatch logs. Sending CloudTrail logs to CloudWatch Logs will facilitate real-time and historic activity logging based on user, API, resource, and IP address, and provides opportunity to establish alarms and notifications for anomalous or sensitivity account activity.

For more information, visit the AWS documentation on monitoring CloudTrail log files with CloudWatch logs.

Recommendation 2.5 of the CIS AWS Foundations Benchmark is to ensure AWS Config is enabled in all regions. The CIS explains that AWS Config performs configuration management of supported AWS resources within your account and delivers log files to you. The recorded information includes the configuration item, relationships between configuration items, and any configuration changes between resources. The AWS configuration item history captured by AWS Config enables security analysis, resource change tracking, and compliance auditing.

For more information, visit the AWS documentation on best practices for AWS Config.

Recommendation 2.6 of the CIS AWS Foundations Benchmark is to ensure CloudTrail S3 bucket logging is enabled, which generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed. By enabling S3 bucket logging on target S3 buckets, it is possible to capture all events which may affect objects within a target bucket. Configuring logs to be placed in a separate bucket allows access to log information which can be useful in security and incident response workflows.

For more information, visit the AWS documentation on enabling S3 server access logging.

Recommendation 2.9 of the CIS AWS Foundations Benchmark states that in order to capture information about the IP traffic going to and from network interfaces in your VPC, you must enable VPC flow logging in all VPCs. VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or insight during security workflows.

For more information, visit the AWS documentation on VPC flow logs.

Recommendation 1.1 of the CIS AWS Foundations Benchmark states that because the root account has unrestricted access to all resources in the AWS account, use of this account should be avoided. The root account is the most privileged AWS account. Minimizing the use of this account and adopting the principle of least privilege for access management will reduce the risk of accidental changes and unintended disclosure of highly privileged credentials.

For more information, visit the AWS documentation on AWS root accounts.

Recommendation 1.2 of the CIS AWS Foundations Benchmark states that because MFA adds an extra layer of protection on top of a user name and password, MFA needs to be enabled for all IAM users with a console password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. Enabling MFA provides increased security for console access as it requires the authenticating principal to possess a device that emits a time-sensitive key and have knowledge of a credential.

For more information, visit the AWS documentation on using MFA.

Recommendation 1.3 of the CIS AWS Foundations Benchmark states that all credentials that have been unused in 90 or greater days should be removed or deactivated. Disabling or removing unnecessary credentials will reduce the window of opportunity for credentials associated with a compromised or abandoned account to be used.

For more information, visit the AWS documentation for finding unused credentials.

The CIS AWS Foundations Benchmark explains that password policies need to enforce password complexity requirements in order to increase account resiliency against brute force login attempts. Industry best practice is to ensure that IAM password policies require at least one lowercase letter, one uppercase letter, one number, one symbol, and a minimum length of 10 characters.

For more information, visit the AWS documentation for a setting password policy for IAM users.

Industry best practices is to ensure that IAM password policies prevent password reuse for the last 24 passwords. The CIS AWS Foundations Benchmark explains that password policies need to prevent password reuse in order to increase account resiliency against brute force login attempts.

For more information, visit the AWS documentation for a setting password policy for IAM users.

Recommendation 1.16 of the CIS AWS Foundations Benchmark states that by default, IAM users, groups, and roles have no access to AWS resources. IAM policies are how privileges are granted to users, groups, or roles. To that end, IAM policies should only be attached to groups or roles – not users. Assigning privileges at the group or role level reduces the complexity of access management as the number of users grow. Reducing access management complexity may in-turn reduce opportunity for a principal to inadvertently receive or retain excessive privileges.

For more information, visit the AWS documentation for managing IAM policies.

Recommendation 1.19 of the CIS AWS Foundations Benchmark states that by ensuring IAM instance roles are used for AWS resource access, you reduce the risks associated with sharing and rotating credentials that can be used outside of AWS itself. If credentials are compromised, they can be used from outside of the AWS account they give access to. In contrast, in order to leverage role permissions an attacker would need to gain and maintain access to a specific instance to use the privileges associated with it. Additionally, if credentials are encoded into compiled applications or other hard to change mechanisms, then they are even more unlikely to be properly rotated due to service disruption risks. As time goes on, credentials that cannot be rotated are more likely to be known by an increasing number of individuals who no longer work for the organization owning the credentials.

For more information, visit the AWS documentation for using IAM roles.

Following the industry standard of least privilege, recommendation 1.22 of the CIS AWS Foundations Benchmark states that IAM policies that allow full administrative privileges should not be created. The CIS recommends to first determine what users need to do, and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges. It's more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later. Specifically, IAM policies that have a statement with "Effect": "Allow" with "Action": "*" over "Resource": "*" should be removed.

For more information, visit the AWS documentation for managing IAM policies.

S3 bucket policies and user policies are what determine the permissions and access to S3. S3 bucket policies are attached at the bucket level and apply to all objects within that bucket. Our recommendation is to ensure that S3 bucket policies do no grant access to all buckets.

For more information, visit the AWS documentation on S3 bucket policy examples.

To securely create a multi-account AWS environment, we recommend housing AWS accounts within an organization. The AWS Organizations feature provides centralized account management and governance. It allows you to group multiple accounts into an organizational units (OUs) and, in turn, apply policies to OUs instead of directly to accounts. This type of consolidation becomes extremely valuable as you scale your AWS resources and architecture.

For more information, visit the AWS documentation for AWS Organizations best practices.

AWS does allow you to make your EBS snapshots public, but we recommend restricting access to EBS snapshots by making them private, unless you have a specific business need that requires this. These point-in-time snapshots are crucial to your data backup and recovery processes; you don’t want to risk public access or permissions misconfigurations here.

For more information, visit the AWS documentation on EBS snapshots.   

Recommendation 1.11 of the CIS AWS Foundations Benchmark states that IAM password policies can require passwords to be rotated or expired after given a specified number of days. It’s recommended that password policy expire passwords after 90 days or fewer. Decreasing the password lifetime increases account resiliency against brute force login attempts. Additionally, requiring regular password changes helps scenarios like stolen passwords, redundant use of passwords across accounts, and compromised end users.

Recommendation 1.12 of the CIS AWS Foundations Benchmark recommends that all access keys associated with the root account be removed. The root account is the most privileged user in the AWS account, and Access Keys provide programmatic access to a given account. That said, if the account is compromised, by removing the access keys associated with the root account, it limits vectors by which the attackers can act on. Additionally, by removing the root access keys, it encourages the creation and use of role based accounts that are least privileged.

Recommendation 1.13 of the CIS AWS Foundations Benchmark states that the root account is the most privileged user in an AWS Account. MFA adds an additional layer of security on top of a username and password. When a user signs into an AWS website/account, if MFA is enabled, they will be prompted for their username and password following an authentication code from their AWS MFA device.

Note: When virtual MFA is used for root accounts, make sure NOT to use a personal device, but rather a dedicated mobile device (tablet/phone) that is securely independent from any other devices.

 

Recommendation 1.14 of the CIS AWS Foundations Benchmark states that the root account is the most privileged user in an AWS Account. MFA adds an additional layer of security on top of a username and password. When a user signs into an AWS website/account, if MFA is enabled, they will be prompted for their username and password following an authentication code from their AWS MFA device. For Level 2, it is recommended that the root account be protected with a hardware MFA. 

Using IAM policies with MFA conditions, you can ensure that MFA is required for users who are able to make API calls. This will add an additional layer of protection and accountability before a user is allowed to perform sensitive API operations.

For more information, visit the AWS documentation on configuring MFA-protected API access.

Following cryptographic best practice, we recommend rotating CMKs annually. Enabling automatic key rotation through AWS KMS is the easiest way to ensure this standard is followed. Using the automatic key rotation feature, AWS KMS will automatically generate new cryptographic material for a CMK every year, plus it will save the old cryptographic material. If you prefer, manual key rotation is also available.

For more information, visit the AWS documentation on rotating customer master keys.

To enhance the security of S3 buckets, you must ensure encryption is properly enabled. Amazon gives you the ability to set default encryption settings using SSE-S3 or SSE-KMS to automatically encrypt all objects that are stored within an S3 bucket.

For more information, visit the AWS documentation on enabling Amazon S3 default bucket encryption.

To enhance the security of your EC2 instances, you must ensure that encryption is enabled for EBS volumes. AWS provides the Amazon EBS encryption feature, which uses KSM to encrypt EBS volumes. Amazon EBS encryption is supported by all volume types.

For more information, visit the AWS documentation on EBS encryption.

To enhance the security of Amazon RDS and data at rest or in underlying storage, you must ensure that encryption is enabled for DB instances. Amazon RDS can encrypt DB instances using the industry standard AES-256 encryption algorithm to encrypt data on the server that hosts DB instances.

For more information, visit the AWS documentation on encrypting Amazon RDS resources.

To enhance the security of your Application Load Balancers (ALBs) and Network Load Balancers (NLBs), you must ensure that all load balancers that accept HTTPS traffic require, at a minimum, TLS 1.2. Older versions of TLS or legacy SSL protocols are known to have fatal security flaws and do not provide protection for data in transit.

For more information, visit the AWS documentation on creating HTTPS listeners for ALBs.

To support your backup and recovery processes, we recommend enabling versioning in S3. S3 versioning provides a way to keep your objects accurate, up to date, and protected. You can enable bucket versioning on both new buckets and buckets that already exist, and this keeps multiple versions of an object within a bucket.

For more information, visit the AWS documentation on enabling versioning on S3 buckets.

A foundation to S3 security is to ensure S3 buckets are not publicly available. Using the Block Public Access feature, you can manage access to buckets, accounts, and access points. By default, new buckets, access points, and objects do not allow public access.

For more information, visit the AWS documentation on configuring Block Public Access settings for S3 buckets.

To enhance the security of AWS RDS and DB instances, they should not be publicly accessible. Restricting unauthorized access will minimize the risk of compromise to your DB instances. 

For more information, visit the AWS documentation on public accessibility to RDS instances.

Recommendation 2.7 of the CIS AWS Foundations Benchmark is to ensure CloudTrail logs are encrypted at rest using KMS CMKs . The CIS explains that CloudTrail records AWS API calls for your account and delivers log files to you. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use
SSE-KMS. 

To strengthen your security posture, we recommend configuring EC2 instances as managed instances under AWS Systems Manager. AWS Config can use the ec2-instance-managed-by-systems-manager rule to check whether the EC2 instances in your account are managed by Systems Manager.

For more information, visit the AWS documentation on AWS Systems Manager managed instances.

AWS explains that you can improve the security posture of your managed instances by configuring AWS Systems Manager to use an interface VPC endpoint. An interface VPC endpoint enables you to connect to services powered by AWS PrivateLink, a technology that enables you to privately access Amazon EC2 and Systems Manager APIs by using private IP addresses. This means that your managed instances don't have access to the Internet.

For more information, visit the AWS documentation on creating VCP endpoints.

Patch management is an integral component of vulnerability management. To ensure your EC2 instances are compliant with patching standards, you must use AWS Systems Manager to apply patch baselines to instances. To associate a specific patch baseline with your instances, you will add EC2 instances to a patch group, then adding a patch group to a patch baseline.

For more information, visit the AWS documentation on creating a patch grou

It is best practice not to use insecure ports and protocols such as FTP, Telnet, and SNMP. Using insecure ports and protocols makes it possible for your traffic to be sent unencrypted over the Internet. To ensure protection, you can utilize the inbound rules for security groups. Security groups act as a firewall in your AWS environment and their inbound rules will show you areas of vulnerability in terms of insecure ports and protocols.

For more information, visit the AWS documentation on security group rules.

To build a strong perimeter, you must ensure that EC2 instances are not directly connected to the Internet. You can deploy EC2 instances in two ways: on an internal network or assigning them a public IP address. For security purposes, you want to ensure that when possible, your EC2 instances live on an internal network and you do not allow direct Internet access to them.

For more information, visit the AWS documentation on networking in Amazon EC2.

Recommendation 4.2 of the CIS AWS Foundations Benchmark is to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to port 3389. The CIS explains how security groups provide stateful filtering of ingress/egress network traffic to AWS resources. By removing unfettered connectivity to remote console services, such as RDP, this reduces a server's exposure to risk.

For more information, visit the AWS documentation on security group rules for different use cases.

Just because you create a NAT gateway does not mean that EC2 instances have the ability to run outbound traffic through the Internet. You need to define a route that allows EC2 instances on a private subnet to talk to NAT gateways and then go out to the Internet. This is where route tables comes into play. AWS defines a route table as a set of rules (called routes) that are used to determine where network traffic from your subnet or gateway is directed. When you save your route, you’ve created a route for instances in that Availability Zone to be able to route outbound traffic to the Internet.

For more information, visit the AWS documentation on NAT gateways. 

Recommendation 4.1 of the CIS AWS Foundations Benchmark is to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to port 22. The CIS explains how security groups provide stateful filtering of ingress/egress network traffic to AWS resources. By removing unfettered connectivity to remote console services, such as SSH, this reduces a server's exposure to risk.

For more information, visit the AWS documentation on security group rules for different use cases.

It is a security best practice to ensure that the Amazon Relational Database Service (Amazon RDS) instances are not publicly accessible. This could lead to potential data loss as you are giving direct access to your database when it is exposed to the internet.

To enhance your security perimeter, you must ensure that you do not have multiple hosts with external access to administrative ports, like port 22, and that you implement the principle of least privilege around administrative ports. You can use Session Manager feature in AWS Systems Manager or bastion hosts to ensure that no more than 1 host per account is allowed external access to port 22.

For business continuity and disaster recovery purposes, it’s extremely important to have the maintenance and backup settings in your Amazon RDS correctly configured. If configured properly, your RDS can easily manage your backups, patching, failure detection, and more.

For more information, visit the AWS documentation on working with RDS backups.

If your security groups allow unrestricted traffic (0.0.0.0/0 or ::/0) to all ports, this invalidates everything the security groups are working to accomplish as a virtual firewall. You must ensure that your security groups do not allow unrestricted traffic to all ports. 

For more information, visit the AWS documentation on security group inbound and outbound rules. 

Recommendation 4.3 of the CIS AWS Foundations Benchmark is to ensure that the default security group of every VPC restricts all traffic. This CIS explains that a VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to this default security group. Configuring all VPC default security groups to restrict all traffic will encourage least privilege security group development and mindful placement of AWS resources into security groups which will in-turn reduce the exposure of those resources.

For more information, visit the AWS documentation on default security groups.

Best practice for AWS WAF rules is to maintain logging in order to gain details about the traffic that is analyzed by your web ACLs. AWS explains that the information contained in the logs includes the time that AWS WAF received the request from your AWS resource, detailed information about the request, and the action for the rule that each request matched. You send logs from your web ACL to an Amazon Kinesis Data Firehose with a configured storage destination. After you enable logging, AWS WAF delivers logs to your storage destination through the HTTPS endpoint of Kinesis Data Firehose.

For more information, visit the AWS documentation on logging web ACL traffic information.

Internet-facing ALBs need to have WAF ACLs attached. WAF, as part of your security posture, will sit in front of your ALBs and provide a web ACL to block malicious traffic on the load balancer side. To implement this best practice, you must understand which load balancers are attached to the WAF through we ACLs.

For more information, visit the AWS documentation on associating web ACLs with an AWS resources.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Oracle ports 1521 and 2483. These are common ports that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to MySQL port 3306. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to PostgreSQL port 5432. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Redis port 6379. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to MongoDB ports 27017 and 27018. These are common ports that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Cassandra ports 7199, 8888, and 9160. These are common ports that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Memcached port 11211. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

It is best practice to ensure that security groups do not allow ingress from 0.0.0.0/0 or ::/0 to Microsoft SQL Server port 1433. This is a common port that should not have unrestricted connectivity to your environment. By restricting access through the inbound rules for security groups, you will reduce risk exposure.

For more information, visit the AWS documentation on security group rules for different use cases.

By using AWS WAF in combination with web ACLs, you can control control how a variety of services (including API Gateways) respond to web requests, as well as inspect web requests to see if they match your criteria. The Amazon API Gateway service is used to create, publish, maintain, monitoring, and secure REST, HTTP, and WebSocket APIs.

For more information, visit the AWS documentation on Amazon API Gateway.

Recommendation 2.1 of the CIS AWS Foundations Benchmark is to ensure CloudTrail is enabled in all regions. The CIS explains that CloudTrail records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services. The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing.

For more information, visit the AWS documentation on best practices in CloudTrail.

Recommendation 2.2 of the CIS AWS Foundations Benchmark states that enabling log file validation will provide additional integrity checking of CloudTrail logs. CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to S3. These digest files can be used to determine whether a log file was changed, deleted, or unchanged after CloudTrail delivered the log.

For more information, visit the AWS documentation on validating CloudTrail log file integrity.

Recommendation 2.3 of the CIS AWS Foundations Benchmark states that, by using bucket policies or ACLs, S3 buckets used to store CloudTrail logs should prevent public access. Allowing public access to CloudTrail log content may aid an adversary in identifying weaknesses in the affected account's use or configuration.

For more information, visit the AWS documentation on S3 bucket policies for CloudTrail.

Recommendation 2.4 of the CIS AWS Foundations Benchmark states that CloudTrail logs need to be integrated with CloudWatch logs. Sending CloudTrail logs to CloudWatch Logs will facilitate real-time and historic activity logging based on user, API, resource, and IP address, and provides opportunity to establish alarms and notifications for anomalous or sensitivity account activity.

For more information, visit the AWS documentation on monitoring CloudTrail log files with CloudWatch logs.

Recommendation 2.5 of the CIS AWS Foundations Benchmark is to ensure AWS Config is enabled in all regions. The CIS explains that AWS Config performs configuration management of supported AWS resources within your account and delivers log files to you. The recorded information includes the configuration item, relationships between configuration items, and any configuration changes between resources. The AWS configuration item history captured by AWS Config enables security analysis, resource change tracking, and compliance auditing.

For more information, visit the AWS documentation on best practices for AWS Config.

Recommendation 2.6 of the CIS AWS Foundations Benchmark is to ensure CloudTrail S3 bucket logging is enabled, which generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed. By enabling S3 bucket logging on target S3 buckets, it is possible to capture all events which may affect objects within a target bucket. Configuring logs to be placed in a separate bucket allows access to log information which can be useful in security and incident response workflows.

For more information, visit the AWS documentation on enabling S3 server access logging.

Recommendation 2.9 of the CIS AWS Foundations Benchmark states that in order to capture information about the IP traffic going to and from network interfaces in your VPC, you must enable VPC flow logging in all VPCs. VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or insight during security workflows.

For more information, visit the AWS documentation on VPC flow logs.