Compliance, Mapped to Your Cloud

Assess your AWS, Azure, and Google Cloud environments against the industry frameworks and regulations your auditors expect.

56
Frameworks Supported
18
Standards Families
3
Cloud Providers
5 min
To First Results
ASecureCloud compliance report preview
AWS logo

CIS AWS Foundations Benchmark

43 controls
44 checks mapped

The Center for Internet Security (CIS) Benchmarks are consensus-based, prescriptive configuration baselines for hardening cloud environments against the most common attack vectors.

Controls assessed

1.1 – Avoid the use of the "root" account1

\[CIS.1.1\] The "root" account has unrestricted access to all resources in the AWS account. It is highly recommended that the use of this account be avoided.

1.2 – Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password1

\[CIS.1.2\] Multi-Factor Authentication (MFA) adds an extra layer of protection on top of a user name and password. It is recommended that MFA be enabled for all accounts that have a console password.

1.3 – Ensure credentials unused for 90 days or greater are disabled1

\[CIS.1.3\] AWS IAM users can access AWS resources using different types of credentials, such as passwords or access keys. It is recommended that all credentials that have been unused in 90 or greater days be removed or deactivated.

1.4 – Ensure access keys are rotated every 90 days or less1

\[CIS.1.4\] Access keys consist of an access key ID and secret access key, which are used to sign programmatic requests that you make to AWS. It is recommended that all access keys be regularly rotated

1.5 – Ensure IAM password policy requires at least one uppercase letter1

\[CIS.1.5\] Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are comprised of different character sets. It is recommended that the password policy require at least one uppercase letter.

1.6 – Ensure IAM password policy requires at least one lowercase letter1

\[CIS.1.6\] Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are comprised of different character sets. It is recommended that the password policy require at least one lowercase letter.

1.7 – Ensure IAM password policy requires at least one symbol1

\[CIS.1.7\] Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are comprised of different character sets. It is recommended that the password policy require at least one symbol.

1.8 – Ensure IAM password policy requires at least one number1

\[CIS.1.8\] Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are comprised of different character sets. It is recommended that the password policy require at least one number.

1.9 – Ensure IAM password policy requires a minimum length of 14 or greater1

\[CIS.1.9\] Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are at least a given length. It is recommended that the password policy require a minimum password length 14.

1.10 – Ensure IAM password policy prevents password reuse1

\[CIS.1.10\] IAM password policies can prevent the reuse of a given password by the same user. It is recommended that the password policy prevent the reuse of passwords.

1.11 – Ensure IAM password policy expires passwords within 90 days or less1

\[CIS.1.11\] IAM password policies can require passwords to be rotated or expired after a given number of days. It is recommended that the password policy expire passwords after 90 days or less.

1.12 – Ensure no root account access key exists1

\[CIS.1.12\] The root account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the root account be removed.

1.13 – Ensure MFA is enabled for the "root" account1

\[CIS.1.13\] The root account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and 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.

1.14 – Ensure hardware MFA is enabled for the "root" account1

\[CIS.1.14\] The root account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and 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. For Level 2, it is recommended that the root account be protected with a hardware MFA

1.16 – Ensure IAM policies are attached only to groups or roles1

\[CIS.1.16\] By default, IAM users, groups, and roles have no access to AWS resources. IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended that IAM policies be applied directly to groups and roles but not users.

1.20 - Ensure a support role has been created to manage incidents with AWS Support1

\[CIS.1.20\] AWS provides a support center that can be used for incident notification and response, as well as technical support and customer services. Create an IAM Role to allow authorized users to manage incidents with AWS Support.

1.22 – Ensure IAM policies that allow full "*:*" administrative privileges are not created2

\[CIS.1.22\] IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege—that is, granting only the permissions required to perform a task. 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.

2.1 – Ensure CloudTrail is enabled in all Regions1

\[CIS.2.1\] AWS CloudTrail is a web service that 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.

2.2. – Ensure CloudTrail log file validation is enabled1

\[CIS.2.2\] 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. It is recommended that file validation be enabled on all CloudTrails.

2.3 – Ensure the S3 bucket CloudTrail logs to is not publicly accessible1

\[CIS.2.3\] Details: 2.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible

2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch Logs1

\[CIS.2.4\] AWS CloudTrail is a web service that records AWS API calls made in a given AWS account. CloudTrail uses Amazon S3 for log file storage and delivery, so log files are stored durably. In addition to capturing CloudTrail logs within a specified S3 bucket for long term analysis, realtime analysis can be performed by configuring CloudTrail to send logs to CloudWatch Logs. It is recommended that CloudTrail logs be sent to CloudWatch Logs.

2.5 – Ensure AWS Config is enabled1

\[CIS.2.5\] AWS Config is a web service that performs configuration management of supported AWS resources within your account and delivers log files to you. The recorded information includes the configuration item (AWS resource), relationships between configuration items (AWS resources), and any configuration changes between resources. It is recommended to enable AWS Config in all regions

2.6 – Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket1

\[CIS.2.6\] S3 Bucket Access Logging 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. It is recommended that bucket access logging be enabled on the CloudTrail S3 bucket.

2.7 – Ensure CloudTrail logs are encrypted at rest using AWS KMS CMKs1

\[CIS.2.7\] 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.

2.8 – Ensure rotation for customer-created CMKs is enabled1

\[CIS.2.8\] AWS Key Management Service (KMS) allows customers to rotate the backing key which is key material stored within the KMS which is tied to the key ID of the Customer Created customer master key (CMK). It is the backing key that is used to perform cryptographic operations such as encryption and decryption. It is recommended that CMK key rotation be enabled.

2.9 – Ensure VPC flow logging is enabled in all VPCs1

\[CIS.2.9\] VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet "Rejects" for VPCs.

3.1 – Ensure a log metric filter and alarm exist for unauthorized API calls1

\[CIS.3.1\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for unauthorized API calls.

3.2 – Ensure a log metric filter and alarm exist for AWSManagement Console sign-in without MFA1

\[CIS.3.2\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for console logins that are not protected by multi-factor authentication (MFA).

3.3 – Ensure a log metric filter and alarm exist for usage of "root" account1

\[CIS.3.3\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for root login attempts

3.4 – Ensure a log metric filter and alarm exist for IAM policy changes1

\[CIS.3.4\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established changes made to Identity and Access Management (IAM) policies.

3.5 – Ensure a log metric filter and alarm exist for CloudTrail configuration changes1

\[CIS.3.5\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for detecting changes to CloudTrail's configurations.

3.6 – Ensure a log metric filter and alarm exist for AWSManagement Console authentication failures1

\[CIS.3.6\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for failed console authentication attempts.

3.7 – Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs1

\[CIS.3.7\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for customer created CMKs which have changed state to disabled or scheduled deletion.

3.8 – Ensure a log metric filter and alarm exist for S3 bucket policy changes1

\[CIS.3.8\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for changes to S3 bucket policies.

3.9 – Ensure a log metric filter and alarm exist for AWS Config configuration changes1

\[CIS.3.9\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for detecting changes to CloudTrail's configurations.

3.10 – Ensure a log metric filter and alarm exist for security group changes1

\[CIS.3.10\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Security Groups are a stateful packet filter that controls ingress and egress traffic within a VPC. It is recommended that a metric filter and alarm be established changes to Security Groups.

3.11 – Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)1

\[CIS.3.11\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. NACLs are used as a stateless packet filter to control ingress and egress traffic for subnets within a VPC. It is recommended that a metric filter and alarm be established for changes made to NACLs.

3.12 – Ensure a log metric filter and alarm exist for changes to network gateways1

\[CIS.3.12\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Network gateways are required to send/receive traffic to a destination outside of a VPC. It is recommended that a metric filter and alarm be established for changes to network gateways.

3.13 – Ensure a log metric filter and alarm exist for route table changes1

\[CIS.3.13\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Routing tables are used to route network traffic between subnets and to network gateways. It is recommended that a metric filter and alarm be established for changes to route tables.

3.14 – Ensure a log metric filter and alarm exist for VPC changes1

\[CIS.3.14\] Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is possible to have more than 1 VPC within an account, in addition it is also possible to create a peer connection between 2 VPCs enabling network traffic to route between VPCs. It is recommended that a metric filter and alarm be established for changes made to VPCs.

4.1 – Ensure no security groups allow ingress from 0.0.0.0/0 to port 221

\[CIS.4.1\] Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to port 22.

4.2 – Ensure no security groups allow ingress from 0.0.0.0/0 to port 33891

\[CIS.4.2\] Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to port 3389.

4.3 – Ensure the default security group of every VPC restricts all traffic1

\[CIS.4.3\] 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. It is recommended that the default security group restrict all traffic.

See where you stand against any framework

Connect an account and get a full compliance breakdown with mapped findings and remediation guidance — free to start.