CIS AWS Foundations Benchmark v1.2.0

For CIS AWS Foundations Benchmark v1.2.0, Security Hub supports the following controls. Note the severity, underlying AWS Config rule, schedule type, and remediation steps for each control.

Note

We recommend upgrading to CIS AWS Foundations Benchmark v1.4.0 to stay current on security best practices, but you may have both v1.4.0 and v1.2.0 enabled at the same time. For more information, see Disabling or enabling a security standard. If you want to upgrade to v1.4.0, it's best to enable v1.4.0 first before disabling v1.2.0. If you use the Security Hub integration with AWS Organizations to centrally manage multiple accounts and wish to batch enable v1.4.0 across all accounts (and disable v1.2.0 if you wish), you can use a Security Hub multi-account script.

1.1 – Avoid the use of the root user

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

The root user has unrestricted access to all services and resources in an AWS account. We highly recommend that you avoid using the root user for daily tasks. Minimizing the use of the root user and adopting the principle of least privilege for access management reduce the risk of accidental changes and unintended disclosure of highly privileged credentials.

As a best practice, use your root user credentials only when required to perform account and service management tasks. Apply IAM policies directly to groups and roles but not users. For a tutorial on how to set up an administrator for daily use, see Creating your first IAM admin user and group in the IAM User Guide

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.3 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

When Security Hub performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling ListSubscriptionsByTopic. Otherwise Security Hub generates WARNING findings for the control.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.
Under Define pattern, do the following:
1. Copy the following pattern and then paste it into the Filter Pattern field.
```
{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
```
2. Choose Next.
Under Assign Metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric Namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric Name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then, choose Create metric filter.
In the navigation pane, choose Log groups, and then choose the filter you created under Metric filters.
Select the check box for the filter. Choose Create alarm.
Under Specify metric and conditions, do the following:
1. Under Conditions, for Threshold, choose Static.
2. For Define the alarm condition, choose Greater/Equal.
3. For Define the threshold value, enter 1.
4. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm, such as CIS-1.1-RootAccountUsage. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Medium

AWS Config rule: mfa-enabled-for-iam-console-access

Schedule type: Periodic

Multi-factor authentication (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're prompted for their user name and password as well as for an authentication code from their AWS MFA device.

CIS recommends that you enable MFA for all accounts that have a console password. MFA provides increased security for console access. It requires the authenticating principal to possess a device that emits a time-sensitive key and to have knowledge of a credential.

Important

The AWS Config rule used for this check may take up to 4 hours to accurately report results for MFA. Any findings that are generated within the first 4 hours after you enable the CIS security checks might not be accurate. It may also take up to 4 hours after you remediate this issue for the check to pass.

Note

AWS Config should be enabled in all Regions in which you use Security Hub. However, you can enable recording of global resources in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

Remediation

To add MFA for IAM users, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.

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

Severity: Medium

AWS Config rule: iam-user-unused-credentials-check

Schedule type: Periodic

IAM users can access AWS resources using different types of credentials, such as passwords or access keys.

CIS recommends that you remove or deactivate all credentials that have been unused for 90 days or more. Disabling or removing unnecessary credentials reduces the window of opportunity for credentials associated with a compromised or abandoned account to be used.

The AWS Config rule for this control uses the GetCredentialReport and GenerateCredentialReport API operations, which are only updated every four hours. Changes to IAM users can take up to four hours to be visible to this control.

Note

Remediation

To get some of the information that you need to monitor accounts for dated credentials, use the IAM console. For example, when you view users in your account, there is a column for Access key age, Password age, and Last activity. If the value in any of these columns is greater than 90 days, make the credentials for those users inactive.

You can also use credential reports to monitor user accounts and identify those with no activity for 90 or more days. You can download credential reports in .csv format from the IAM console. For more information about credential reports, see Getting credential reports for your AWS account.

After you identify the inactive accounts or unused credentials, use the following steps to disable them.

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Users.
Choose the name of the user with credentials over 90 days old.
Choose Security credentials and then choose Make inactive for all sign-in credentials and access keys that haven't been used in 90 days or more.

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

Severity: Medium

AWS Config rule: access-keys-rotated

Schedule type: Periodic

Access keys consist of an access key ID and secret access key, which are used to sign programmatic requests that you make to AWS. AWS users need their own access keys to make programmatic calls to AWS from the AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, the AWS SDKs, or direct HTTP calls using the APIs for individual AWS services.

When you rotate access keys regularly, you reduce the chance that an access key is used that is associated with a compromised or terminated account. Rotate access keys to ensure that data can't be accessed with an old key that might have been lost, cracked, or stolen.

Note

This control is not supported in the Africa (Cape Town) or Europe (Milan) Regions.

Remediation

To ensure that access keys aren't more than 90 days old

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Users.
For each user that shows an Access key age that is greater than 90 days, choose the User name to open the settings for that user.
Choose Security credentials.
To create a new key for the user:
1. Choose Create access key.
2. To save the key content, either download the secret access key, or choose Show and then copy it from the page.
3. Store the key in a secure location to provide to the user.
4. Choose Close.
Update all applications that were using the previous key to use the new key.
For the previous key, choose Make inactive to make the access key inactive. Now the user can't make requests using that key.
Confirm that all applications work as expected with the new key.
After confirming that all applications work with the new key, delete the previous key. After you delete the access key, you can't recover it.

To delete the previous key, choose the X at the end of the row and then choose Delete.

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

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets.

CIS recommends that the password policy require at least one uppercase letter. Setting a password complexity policy increases account resiliency against brute force login attempts.

Remediation

To modify the password policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Account settings.
Select Requires at least one uppercase letter and then choose Apply password policy.

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

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets. CIS recommends that the password policy require at least one lowercase letter. Setting a password complexity policy increases account resiliency against brute force login attempts.

Remediation

To modify the password policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Account settings.
Select Requires at least one lowercase letter and then choose Apply password policy.

1.7 – Ensure IAM password policy requires at least one symbol

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets.

CIS recommends that the password policy require at least one symbol. Setting a password complexity policy increases account resiliency against brute force login attempts.

Remediation

To modify the password policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Account settings.
Select Require at least one non-alphanumeric character and then choose Apply password policy.

1.8 – Ensure IAM password policy requires at least one number

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets.

CIS recommends that the password policy require at least one number. Setting a password complexity policy increases account resiliency against brute force login attempts.

Remediation

To modify the password policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Account settings.
Select Requires at least one number and then choose Apply password policy.

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

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords are at least a given length.

CIS recommends that the password policy require a minimum password length of 14 characters. Setting a password complexity policy increases account resiliency against brute force login attempts.

Remediation

To modify the password policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Account settings.
In the Minimum password length field, enter 14, then choose Apply password policy.

1.10 – Ensure IAM password policy prevents password reuse

Severity: Low

AWS Config rule: iam-password-policy

Schedule type: Periodic

This control checks whether the number of passwords to remember is set to 24. The control fails if the value is not 24.

IAM password policies can prevent the reuse of a given password by the same user.

CIS recommends that the password policy prevent the reuse of passwords. Preventing password reuse increases account resiliency against brute force login attempts.

Remediation

To modify the password policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Account settings.
Select Prevent password reuse and then enter 24 for Number of passwords to remember.
Choose Apply password policy.

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

Severity: Low

AWS Config rule: iam-password-policy

Schedule type: Periodic

IAM password policies can require passwords to be rotated or expired after a given number of days.

CIS recommends that the password policy expire passwords after 90 days or less. Reducing the password lifetime increases account resiliency against brute force login attempts. Requiring regular password changes also helps in the following scenarios:

Passwords can be stolen or compromised without your knowledge. This can happen via a system compromise, software vulnerability, or internal threat.
Certain corporate and government web filters or proxy servers can intercept and record traffic even if it's encrypted.
Many people use the same password for many systems such as work, email, and personal.
Compromised end-user workstations might have a keystroke logger.

Remediation

To modify the password policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Account settings.
Select Enable password expiration and then enter 90 for Password expiration period (in days).
Choose Apply password policy.

1.12 – Ensure no root user access key exists

Severity: Critical

AWS Config rule: iam-root-access-key-check

Schedule type: Periodic

The root user has complete access to all services and resources in an AWS account. Access keys provide programmatic access to a given account.

CIS recommends that all access keys be associated with the root user be removed. Removing access keys associated with the root user limits vectors that the account can be compromised by. Removing the root user access keys also encourages the creation and use of role-based accounts that are least privileged.

Note

This control is not supported in the Asia Pacific (Osaka) Region.

Remediation

To delete the root user access key, see Deleting access keys for the root user in the IAM User Guide.

1.13 – Ensure MFA is enabled for the root user

Severity: Critical

AWS Config rule: root-account-mfa-enabled

Schedule type: Periodic

The root user has complete access to all the services and resources 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're prompted for their user name and password and for an authentication code from their AWS MFA device.

When you use virtual MFA for the root user, CIS recommends that the device used is not a personal device. Instead, use a dedicated mobile device (tablet or phone) that you manage to keep charged and secured independent of any individual personal devices. This lessens the risks of losing access to the MFA due to device loss, device trade-in, or if the individual owning the device is no longer employed at the company.

Note

This control is not supported in the following Regions.

China (Beijing)
China (Ningxia)
AWS GovCloud (US-East)
AWS GovCloud (US-West)

Remediation

To add MFA to the root user, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.

1.14 – Ensure hardware MFA is enabled for the root user

Severity: Critical

AWS Config rule: root-account-hardware-mfa-enabled

Schedule type: Periodic

The root user has complete access to all services and resources 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're prompted for their user name and password and for an authentication code from their registered MFA device.

For Level 2, CIS recommends that you protect root user credentials with a hardware MFA. A hardware MFA has a smaller attack surface than a virtual MFA. For example, a hardware MFA doesn't suffer the attack surface introduced by the mobile smartphone that a virtual MFA resides on.

That said, using hardware MFA for many accounts might create a logistical device management issue. If this occurs, consider implementing this Level 2 recommendation selectively to the highest security accounts. You can then apply the Level 1 recommendation to the remaining accounts.

Both time-based one-time password (TOTP) and Universal 2nd Factor (U2F) tokens are viable as hardware MFA options.

Note

This control is not supported in the following Regions.

China (Beijing)
China (Ningxia)
AWS GovCloud (US-East)
AWS GovCloud (US-West)

Remediation

To add a hardware MFA device for the root user, see Enable a hardware MFA device for the AWS account root user (console) in the IAM User Guide.

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

Severity: Low

AWS Config rule: iam-user-no-policies-check

Schedule type: Change triggered

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.

CIS recommends that you apply IAM policies directly to groups and roles but 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 might in turn reduce opportunity for a principal to inadvertently receive or retain excessive privileges.

Note

IAM users created by Amazon Simple Email Service are automatically created using inline policies. Security Hub automatically exempts these users from this control.

Remediation

To resolve this issue, create an IAM group, and attach the policy to the group. Then, add the users to the group. The policy is applied to each user in the group. To remove a policy attached directly to a user, see Adding and removing IAM identity permissions in the IAM User Guide.

1.20 – Ensure a support role has been created to manage incidents with AWS Support

Severity: Low

AWS Config rule: iam-policy-in-use

Schedule type: Periodic

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. By implementing least privilege for access control, an IAM role will require an appropriate IAM policy to allow support center access in order to manage incidents with AWS Support.

Note

This control is not supported in the following Regions.

Africa (Cape Town)
Asia Pacific (Osaka)
Europe (Milan)

Remediation

To remediate this issue, create a role to allow authorized users to manage AWS Support incidents.

To create the role to use for AWS Support access

Open the IAM console at https://console.aws.amazon.com/iam/.
In the IAM navigation pane, choose Roles, then choose Create role.
For Role type, choose the Another AWS account.
For Account ID, enter the AWS account ID of the AWS account to which you want to grant access to your resources.

If the users or groups that will assume this role are in the same account, then enter the local account number.

Note
The administrator of the specified account can grant permission to assume this role to any IAM user in that account. To do this, the administrator attaches a policy to the user or a group that grants permission for the sts:AssumeRole action. In that policy, the resource must be the role ARN.
Choose Next: Permissions.
Search for the managed policy AWSSupportAccess.
Select the check box for the AWSSupportAccess managed policy.
Choose Next: Tags.
(Optional) To add metadata to the role, attach tags as key–value pairs.

For more information about using tags in IAM, see Tagging IAM users and roles in the IAM User Guide.
Choose Next: Review.
For Role name, enter a name for your role.

Role names must be unique within your AWS account. They are not case sensitive.
(Optional) For Role description, enter a description for the new role.
Review the role, then choose Create role.

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

Severity: High

AWS Config rule: iam-policy-no-statements-with-admin-access

Schedule type: Change triggered

This control checks whether the default version of IAM policies (also known as customer managed policies) has administrator access by including a statement with "Effect": "Allow" with "Action": "*" over "Resource": "*". The control fails if you have IAM policies with such a statement.

The control only checks the customer managed policies that you create. It does not check inline and AWS managed policies.

IAM policies define a set of privileges granted to users, groups, or roles. It's 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 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. Providing full administrative privileges instead of restricting to the minimum set of permissions that the user is required to do exposes the resources to potentially unwanted actions.

You should remove IAM policies that have a statement with "Effect": "Allow" with "Action": "*" over "Resource": "*".

Note

Remediation

To modify your IAM policies so that they do not allow full "*" administrative privileges, see Editing IAM policies in the IAM User Guide.

2.1 – Ensure CloudTrail is enabled in all Regions

Severity: High

AWS Config rule: multi-region-cloudtrail-enabled

Schedule type: Periodic

This control checks that there is at least one multi-Region CloudTrail trail. It also checks that the ExcludeManagementEventSources parameter is empty for at least one of those trails.

CloudTrail is a 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. CloudTrail provides a history of AWS API calls for an account, including API calls made via the AWS Management Console, AWS SDKs, command-line tools, and higher-level AWS services (such as AWS CloudFormation).

The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing. Additionally:

Ensuring that a multi-Region trail exists allows unexpected activity occurring in otherwise unused Regions to be detected.
Ensuring that a multi-Region trail exists aids Global Service Logging. Global Service Logging is enabled for a trail by default to capture recording of events generated on AWS global services.
For a multi-Region trail, ensuring that management events configured for all type of Read/Writes ensures recording of management operations that are performed on all resources in an AWS account.

By default, CloudTrail trails that are created using the AWS Management Console are multi-Region trails.

Remediation

To create a new trail in CloudTrail

Sign in to the AWS Management Console and open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.
If you haven't used CloudTrail before, choose Get Started Now.
Choose Trails and then choose Create trail.
Enter a name for the trail.
Under Storage location, do one of the following:
- To create a new S3 bucket for CloudTrail logs, choose Create new S3 bucket and then enter a name for the bucket.
- Choose Use existing S3 bucket and then select the bucket to use.
Choose Additional settings and, for Log file validation, choose Enabled to pass 2.2 – Ensure CloudTrail log file validation is enabled .
To pass 2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch Logs, you must enable CloudWatch Logs.
1. Under CloudWatch Logs, select the Enabled check box.
2. For Log group, do one of the following:
  - To use an existing log group, choose Existing and then enter the name of the log group to use.
  - To create a new log group, choose New and then enter a name for the log group to create.
3. For IAM role, do one of the following:
  - To use an existing role, choose Existing and then choose the role from the drop-down list.
  - To create a new role, choose New and then enter a name for the role to create. The new role is assigned a policy that grants the necessary permissions.
    
    To view the permissions granted to the role, expand the Policy document.
Choose Create.

To update an existing trail in CloudTrail

Sign in to the AWS Management Console and open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.
Choose Trails.
Choose the name of the trail in the Name column.
Update the trail configuration as needed.

To update the configuration in a particular section, do the following:
1. Choose Edit for that section.
2. Make the required updates to the configuration.
3. Choose Save changes.

2.2 – Ensure CloudTrail log file validation is enabled

Severity: Medium

AWS Config rule: cloud-trail-log-file-validation-enabled

Schedule type: Periodic

CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to Amazon S3. You can use these digest files to determine whether a log file was changed, deleted, or unchanged after CloudTrail delivered the log.

CIS recommends that you enable file validation on all trails. Enabling log file validation provides additional integrity checking of CloudTrail logs.

Remediation

To enable CloudTrail log file validation

Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.
Choose Trails.
Choose the name of a trail to edit in the Name column.
Under General details, choose Edit.
Under Additional settings, for Log file validation, select Enabled.
Choose Save.

2.3 – Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible

Severity: Critical

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic and change triggered

CloudTrail logs a record of every API call made in your account. These log files are stored in an S3 bucket. CIS recommends that the S3 bucket policy, or access control list (ACL), applied to the S3 bucket that CloudTrail logs to prevents public access to the CloudTrail logs. Allowing public access to CloudTrail log content might aid an adversary in identifying weaknesses in the affected account's use or configuration.

To run this check, Security Hub first uses custom logic to look for the S3 bucket where your CloudTrail logs are stored. It then uses the AWS Config managed rules to check that bucket is publicly accessible.

If you aggregate your logs into a single centralized S3 bucket, then Security Hub only runs the check against the account and Region where the centralized S3 bucket is located. For other accounts and Regions, the control status is No data.

If the bucket is publicly accessible, the check generates a failed finding.

Remediation

To remove public access for an Amazon S3 bucket

Open the Amazon S3 console at https://console.aws.amazon.com/s3/.
Choose the name of the bucket where your CloudTrail are stored.
Choose Permissions and then choose Public access settings.
Choose Edit, select all four options, and then choose Save.
If prompted, enter confirm and then choose Confirm.

2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch Logs

Severity: Low

AWS Config rule: cloud-trail-cloud-watch-logs-enabled

Schedule type: Periodic

CloudTrail is a web service that records AWS API calls made in a given account. 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 uses Amazon S3 for log file storage and delivery, so log files are stored durably. In addition to capturing CloudTrail logs in a specified Amazon S3 bucket for long-term analysis, you can perform real-time analysis by configuring CloudTrail to send logs to CloudWatch Logs.

For a trail that is enabled in all Regions in an account, CloudTrail sends log files from all those Regions to a CloudWatch Logs log group.

CIS recommends that you send CloudTrail logs to CloudWatch Logs.

Note

The intent of this recommendation is to ensure that account activity is captured, monitored, and appropriately alarmed on. CloudWatch Logs is a native way to accomplish this using AWS services but doesn't preclude the use of an alternate solution.

Sending CloudTrail logs to CloudWatch Logs facilitates real-time and historic activity logging based on user, API, resource, and IP address. It provides the opportunity to establish alarms and notifications for anomalous or sensitivity account activity.

Remediation

To ensure that CloudTrail trails are integrated with CloudWatch Logs

Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.
Choose Trails.
Choose a trail that there is no value for in the CloudWatch Logs Log group column.
Scroll down to the CloudWatch Logs section and then choose Edit.
Select the Enabled check box.
For Log group, do one of the following:
- To use an existing log group, choose Existing and then enter the name of the log group to use.
- To create a new log group, choose New and then enter a name for the log group to create.
For IAM role, do one of the following:
- To use an existing role, choose Existing and then choose the role from the drop-down list.
- To create a new role, choose New and then enter a name for the role to create. The new role is assigned a policy that grants the necessary permissions.
  
  To view the permissions granted to the role, expand the Policy document.
Choose Save changes.

For more information, see Configuring CloudWatch Logs monitoring with the console in the AWS CloudTrail User Guide.

2.5 – Ensure AWS Config is enabled

Severity: Medium

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

AWS Config is a web service that performs configuration management of supported AWS resources in 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.

CIS recommends that you enable AWS Config in all Regions. The AWS configuration item history that AWS Config captures enables security analysis, resource change tracking, and compliance auditing.

Note

CIS 2.5 requires that AWS Config is enabled in all Regions in which you use Security Hub.

Because Security Hub is a regional service, the check performed for this control checks only the current Region for the account. It does not check all Regions.

You also must record global resources so that security checks against global resources can be checked in each Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

You may also consider disabling these IAM controls (CIS 1.2, CIS 1.3, CIS 1.4, CIS 1.16, CIS 1.22) in Regions in which global resource recording is not enabled. Since IAM is a global service, IAM resources will only be recorded in the Region in which global resource recording is enabled.

To run this check, Security Hub performs custom logic to perform the audit steps prescribed for it in the CIS AWS Foundations Benchmark v1.2. Security Hub also requires that global resources are recorded in each Region, because Security Hub is a regional service and performs its security checks on a Region-by-Region basis.

Remediation

To configure AWS Config settings

Open the AWS Config console at https://console.aws.amazon.com/config/.
Select the Region to configure AWS Config in.
If you haven't used AWS Config before, see Getting Started in the AWS Config Developer Guide.
Navigate to the Settings page from the menu, and do the following:
- Choose Edit.
- Under Resource types to record, select Record all resources supported in this region and Include global resources (e.g., AWS IAM resources).
- Under Data retention period, choose the default retention period for AWS Config data, or specify a custom retention period.
- Under AWS Config role, either choose Create AWS Config service-linked role or choose Choose a role from your account and then select the role to use.
- Under Amazon S3 bucket, specify the bucket to use or create a bucket and optionally include a prefix.
- Under Amazon SNS topic, select an Amazon SNS topic from your account or create one. For more information about Amazon SNS, see the Amazon Simple Notification Service Getting Started Guide.
Choose Save.

For more information about using AWS Config from the AWS Command Line Interface, see Turning on AWS Config in the AWS Config Developer Guide.

You can also use an AWS CloudFormation template to automate this process. For more information, see the AWS CloudFormation StackSets sample template in the AWS CloudFormation User Guide.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

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.

CIS recommends that you enable bucket access logging on the CloudTrail S3 bucket.

By enabling S3 bucket logging on target S3 buckets, you can capture all events that might affect objects in a target bucket. Configuring logs to be placed in a separate bucket enables access to log information, which can be useful in security and incident response workflows.

To run this check, Security Hub first uses custom logic to look for the bucket where your CloudTrail logs are stored and then uses the AWS Config managed rule to check if logging is enabled.

If the bucket is publicly accessible, the check generates a failed finding.

Remediation

To enable S3 bucket access logging

Open the Amazon S3 console at https://console.aws.amazon.com/s3/.
Choose the bucket used for CloudTrail.
Choose Properties.
Choose Server access logging, then choose Enable logging.
Select a bucket from the Target bucket list, and optionally enter a prefix.
Choose Save.

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

Severity: Medium

AWS Config rule: cloud-trail-encryption-enabled

Schedule type: Periodic

CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (AWS 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.

You can configure CloudTrail logs to leverage server-side encryption (SSE) and KMS keys to further protect CloudTrail logs.

CIS recommends that you configure CloudTrail to use SSE-KMS.

Configuring CloudTrail to use SSE-KMS provides additional confidentiality controls on log data because a given user must have S3 read permission on the corresponding log bucket and must be granted decrypt permission by the KMS key policy.

Note

If you are using AWS Control Tower, you can encrypt your CloudTrail logs with an AWS KMS key. For more information, see Optionally configure AWS KMS keys in the AWS Control Tower User Guide

Remediation

To enable encryption for CloudTrail logs

Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.
Choose Trails.
Choose the trail to update.
Under Storage location, choose the pencil icon to edit the settings.
For Encrypt log files with SSE-KMS, choose Yes.
For Create a new KMS key, do one of the following:
- To create a key, choose Yes and then enter an alias for the key in the KMS key field. The key is created in the same Region as the bucket.
- To use an existing key, choose No and then select the key from the KMS key list.
Note
The KMS key and S3 bucket must be in the same Region.
Choose Save.

You might need to modify the policy for CloudTrail to successfully interact with your KMS key. For more information, see Encrypting CloudTrail log files with AWS KMS–Managed Keys (SSE-KMS) in the AWS CloudTrail User Guide.

2.8 – Ensure rotation for customer-created KMS keys is enabled

Severity: Medium

AWS Config rule: cmk-backing-key-rotation-enabled

Schedule type: Periodic

AWS KMS enables customers to rotate the backing key, which is key material stored in AWS KMS and is tied to the key ID of the KMS key. It's the backing key that is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all previous backing keys so that decryption of encrypted data can take place transparently.

CIS recommends that you enable KMS key rotation. Rotating encryption keys helps reduce the potential impact of a compromised key because data encrypted with a new key can't be accessed with a previous key that might have been exposed.

Remediation

To enable KMS key rotation

Open the AWS KMS console at https://console.aws.amazon.com/kms.
To change the AWS Region, use the Region selector in the upper-right corner of the page.
Choose Customer managed keys.
Choose the alias of the key to update in the Alias column.
Choose Key rotation.
Select Automatically rotate this KMS key every year and then choose Save.

2.9 – Ensure VPC flow logging is enabled in all VPCs

Severity: Medium

AWS Config rule: vpc-flow-logs-enabled

Schedule type: Periodic

VPC flow logs is a feature of Amazon Virtual Private Cloud (Amazon VPC) that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you have created a flow log, you can view and retrieve its data in CloudWatch Logs.

CIS recommends that you enable flow logging for packet rejects for VPCs. Flow logs provide visibility into network traffic that traverses the VPC and can detect anomalous traffic or insight during security workflows.

Remediation

To enable VPC flow logging

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
Choose Your VPCs.
Select a VPC to update.
Choose the Flow Logs tab in the bottom section of the page.
Choose Create flow log.
For Filter, choose Reject.
For Destination log group, select the log group to use.
For IAM role, select the IAM role to use.
Choose Create.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm unauthorized API calls. Monitoring unauthorized API calls helps reveal application errors and might reduce time to detect malicious activity.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.1 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.
Under Define pattern, do the following:
1. Copy the following pattern and then paste it into the Filter Pattern field.
```
{($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")}
```
2. Choose Next.
Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, for Statistic, choose Average. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.1-UnauthorizedAPICalls. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

3.2 – Ensure a log metric filter and alarm exist for AWS Management Console sign-in without MFA

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm console logins that aren't protected by MFA. Monitoring for single-factor console logins increases visibility into accounts that aren't protected by MFA.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.2 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{ ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") && ($.userIdentity.type = "IAMUser") && ($.responseElements.ConsoleLogin = "Success") }

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.2-ConsoleSigninWithoutMFA. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

3.3 – Ensure a log metric filter and alarm exist for usage of 'root' account

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for root user login attempts. Monitoring for root user logins provides visibility into the use of a fully privileged account and an opportunity to reduce the use of it.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.
Under Define pattern, do the following:
1. Copy the following pattern and then paste it into the Filter Pattern field.
```
{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
```
2. Choose Next.
Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, RootAccountUsage. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes made to IAM policies. Monitoring these changes helps ensure that authentication and authorization controls remain intact.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.4 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

Note that the alarm checks for specific API operations by name. One of these operations is DeletePolicy. The alarm does not check that the call was issued from IAM. Because of this, the alarm also is triggered when Auto Scaling calls DeletePolicy.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventName=DeleteGroupPolicy) || ($.eventName=DeleteRolePolicy) || ($.eventName=DeleteUserPolicy) || ($.eventName=PutGroupPolicy) || ($.eventName=PutRolePolicy) || ($.eventName=PutUserPolicy) || ($.eventName=CreatePolicy) || ($.eventName=DeletePolicy) || ($.eventName=CreatePolicyVersion) || ($.eventName=DeletePolicyVersion) || ($.eventName=AttachRolePolicy) || ($.eventName=DetachRolePolicy) || ($.eventName=AttachUserPolicy) || ($.eventName=DetachUserPolicy) || ($.eventName=AttachGroupPolicy) || ($.eventName=DetachGroupPolicy)}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, for Statistic, choose Average. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.4-IAMPolicyChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes to CloudTrail configuration settings. Monitoring these changes helps ensure sustained visibility to activities in the account.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.5 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventName=CreateTrail) || ($.eventName=UpdateTrail) || ($.eventName=DeleteTrail) || ($.eventName=StartLogging) || ($.eventName=StopLogging)}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.5-CloudTrailChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

3.6 – Ensure a log metric filter and alarm exist for AWS Management Console authentication failures

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for failed console authentication attempts. Monitoring failed console logins might decrease lead time to detect an attempt to brute-force a credential, which might provide an indicator, such as source IP, that you can use in other event correlations.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.6 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.
Under Define pattern, do the following:
1. Copy the following pattern and then paste it into the Filter Pattern field.
```
{($.eventName=ConsoleLogin) && ($.errorMessage="Failed authentication")}
```
2. Choose Next.
Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.6-ConsoleAuthenticationFailure. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for customer managed keys that have changed state to disabled or scheduled deletion. Data encrypted with disabled or deleted keys is no longer accessible.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.7 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters. The control also fails if ExcludeManagementEventSources contains kms.amazonaws.com.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.
Under Define pattern, do the following:
1. Copy the following pattern and then paste it into the Filter Pattern field.
```
{($.eventSource=kms.amazonaws.com) && (($.eventName=DisableKey) || ($.eventName=ScheduleKeyDeletion))}
```
2. Choose Next.
Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.7-DisableOrDeleteCMK. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes to S3 bucket policies. Monitoring these changes might reduce time to detect and correct permissive policies on sensitive S3 buckets.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.8 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventSource=s3.amazonaws.com) && (($.eventName=PutBucketAcl) || ($.eventName=PutBucketPolicy) || ($.eventName=PutBucketCors) || ($.eventName=PutBucketLifecycle) || ($.eventName=PutBucketReplication) || ($.eventName=DeleteBucketPolicy) || ($.eventName=DeleteBucketCors) || ($.eventName=DeleteBucketLifecycle) || ($.eventName=DeleteBucketReplication))}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, for Statistic, choose Average. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.8-S3BucketPolicyChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes to AWS Config configuration settings. Monitoring these changes helps ensure sustained visibility of configuration items in the account.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.9 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventSource=config.amazonaws.com) && (($.eventName=StopConfigurationRecorder) || ($.eventName=DeleteDeliveryChannel) || ($.eventName=PutDeliveryChannel) || ($.eventName=PutConfigurationRecorder))}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.9-AWSConfigChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls 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 in a VPC.

CIS recommends that you create a metric filter and alarm for changes to security groups. Monitoring these changes helps ensure that resources and services aren't unintentionally exposed.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.10 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventName=AuthorizeSecurityGroupIngress) || ($.eventName=AuthorizeSecurityGroupEgress) || ($.eventName=RevokeSecurityGroupIngress) || ($.eventName=RevokeSecurityGroupEgress) || ($.eventName=CreateSecurityGroup) || ($.eventName=DeleteSecurityGroup)}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.10-SecurityGroupChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls 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 in a VPC.

CIS recommends that you create a metric filter and alarm for changes to NACLs. Monitoring these changes helps ensure that AWS resources and services aren't unintentionally exposed.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.11 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventName=CreateNetworkAcl) || ($.eventName=CreateNetworkAclEntry) || ($.eventName=DeleteNetworkAcl) || ($.eventName=DeleteNetworkAclEntry) || ($.eventName=ReplaceNetworkAclEntry) || ($.eventName=ReplaceNetworkAclAssociation)}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.11-NetworkACLChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Network gateways are required to send and receive traffic to a destination outside a VPC.

CIS recommends that you create a metric filter and alarm for changes to network gateways. Monitoring these changes helps ensure that all ingress and egress traffic traverses the VPC border via a controlled path.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.12 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventName=CreateCustomerGateway) || ($.eventName=DeleteCustomerGateway) || ($.eventName=AttachInternetGateway) || ($.eventName=CreateInternetGateway) || ($.eventName=DeleteInternetGateway) || ($.eventName=DetachInternetGateway)}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, leave the default values. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.12-NetworkGatewayChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Routing tables route network traffic between subnets and to network gateways.

CIS recommends that you create a metric filter and alarm for changes to route tables. Monitoring these changes helps ensure that all VPC traffic flows through an expected path.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.13 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventName=CreateRoute) || ($.eventName=CreateRouteTable) || ($.eventName=ReplaceRoute) || ($.eventName=ReplaceRouteTableAssociation) || ($.eventName=DeleteRouteTable) || ($.eventName=DeleteRoute) || ($.eventName=DisassociateRouteTable)}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, for Statistic, choose Average. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.13-RouteTableChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: Low

AWS Config rule: None (custom Security Hub rule)

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. You can have more than one VPC in an account, and you can create a peer connection between two VPCs, enabling network traffic to route between VPCs.

CIS recommends that you create a metric filter and alarm for changes to VPCs. Monitoring these changes helps ensure that authentication and authorization controls remain intact.

To run this check, Security Hub uses custom logic to perform the exact audit steps prescribed for control 3.14 in the CIS AWS Foundations Benchmark v1.2. This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

Note

The check results in FAILED findings in the following cases:

No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.

The check results in a control status of NO_DATA in the following cases:

The multi-Region trail is based in a different Region. Security Hub can only generate findings in the Region where the trail is based.
The multi-Region trail belongs to a different account. Security Hub can only generate findings for the account that owns the trail.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

To create an Amazon SNS topic

Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
Create an Amazon SNS topic that receives all CIS alarms.

Create at least one subscriber to the topic. For more information, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in 2.1 – Ensure CloudTrail is enabled in all Regions.

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Log groups.
Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.
From Actions, choose Create Metric Filter.

Under Define pattern, do the following:

Copy the following pattern and then paste it into the Filter Pattern field.


{($.eventName=CreateVpc) || ($.eventName=DeleteVpc) || ($.eventName=ModifyVpcAttribute) || ($.eventName=AcceptVpcPeeringConnection) || ($.eventName=CreateVpcPeeringConnection) || ($.eventName=DeleteVpcPeeringConnection) || ($.eventName=RejectVpcPeeringConnection) || ($.eventName=AttachClassicLinkVpc) || ($.eventName=DetachClassicLinkVpc) || ($.eventName=DisableVpcClassicLink) || ($.eventName=EnableVpcClassicLink)}

Choose Next.

Under Assign metric, do the following:
1. In Filter name, enter a name for your metric filter.
2. For Metric namespace, enter LogMetrics.
  
  If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.
3. For Metric name, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.
4. For Metric value, enter 1.
5. Choose Next.
Under Review and create, verify the information that you provided for the new metric filter. Then choose Create metric filter.
Choose the Metric filters tab, then choose the metric filter that you just created.

To choose the metric filter, select the check box at the upper right.
Choose Create Alarm.
Under Specify metric and conditions, do the following:
1. Under Metric, for Statistic, choose Average. For more information about the available statistics, see Statistics in the Amazon CloudWatch User Guide.
2. Under Conditions, for Threshold, choose Static.
3. For Define the alarm condition, choose Greater/Equal.
4. For Define the threshold value, enter 1.
5. Choose Next.
Under Configure actions, do the following:
1. Under Alarm state trigger, choose In alarm.
2. Under Select an SNS topic, choose Select an existing SNS topic.
3. For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
4. Choose Next.
Under Add name and description, enter a Name and Description for the alarm. For example, CIS-3.14-VPCChanges. Then choose Next.
Under Preview and create, review the alarm configuration. Then choose Create alarm.

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

Severity: High

AWS Config rule: restricted-ssh

Schedule type: Change triggered

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources.

CIS recommends that no security group allow unrestricted ingress access to port 22. Removing unfettered connectivity to remote console services, such as SSH, reduces a server's exposure to risk.

Note

This control is not supported in the following Regions.

Africa (Cape Town)
Asia Pacific (Osaka)
Europe (Milan)

Remediation

Perform the following steps for each security group associated with a VPC.

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the left pane, choose Security groups.
Select a security group.
In the bottom section of the page, choose the Inbound Rules tab.
Choose Edit rules.
Identify the rule that allows access through port 22 and then choose the X to remove it.
Choose Save rules.

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

Severity: High

AWS Config rule: restricted-common-ports

Schedule type: Change triggered

The name of the associated AWS Config managed rule isrestricted-common-ports. However, the rule that is created uses the name restricted-rdp.

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources.

CIS recommends that no security group allow unrestricted ingress access to port 3389. Removing unfettered connectivity to remote console services, such as RDP, reduces a server's exposure to risk.

Note

This control is not supported in the following Regions.

Africa (Cape Town)
Asia Pacific (Osaka)
Europe (Milan)

Remediation

Perform the following steps for each security group associated with a VPC.

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the left pane, choose Security groups.
Select a security group.
In the bottom section of the page, choose the Inbound Rules tab.
Choose Edit rules.
Identify the rule that allows access through port 3389 and then choose the X to remove it.
Choose Save rules.

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

Severity: High

AWS Config rule: vpc-default-security-group-closed

Schedule type: Change triggered

A VPC comes with a default security group with initial settings that 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. Security groups provide stateful filtering of ingress and egress network traffic to AWS resources.

CIS recommends that the default security group restrict all traffic.

Update the default security group for the default VPC in every Region to comply. Any new VPCs automatically contain a default security group that you need to remediate to comply with this recommendation.

Note

When implementing this recommendation, you can use VPC flow logging, enabled for 2.9 – Ensure VPC flow logging is enabled in all VPCs , to determine the least-privilege port access that systems require to work properly. VPC flow logging can log all packet acceptances and rejections that occur under the current security groups.

Configuring all VPC default security groups to restrict all traffic encourages least-privilege security group development and mindful placement of AWS resources into security groups. This in turn reduces the exposure of those resources.

Remediation

To update the default security group to restrict all access

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
View the default security groups details to see the resources that are assigned to them.
Create a set of least-privilege security groups for the resources.
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the Amazon EC2 console, change the security group for the resources that use the default security groups to the least-privilege security group you created.
For each default security group, choose the Inbound tab and delete all inbound rules.
For each default security group, choose the Outbound tab and delete all outbound rules.

For more information, see Working with Security Groups in the Amazon VPC User Guide.

Warning Javascript is disabled or is unavailable in your browser.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Required AWS Config resources

CIS AWS Foundations Benchmark v1.4.0

CIS AWS Foundations Benchmark v1.2.0

1.1 – Avoid the use of the root user

Remediation

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

Remediation

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

Remediation

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

Remediation

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

Remediation

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

Remediation

1.7 – Ensure IAM password policy requires at least one symbol

Remediation

1.8 – Ensure IAM password policy requires at least one number

Remediation

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

Remediation

1.10 – Ensure IAM password policy prevents password reuse

Remediation

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

Remediation

1.12 – Ensure no root user access key exists

Remediation

1.13 – Ensure MFA is enabled for the root user

Remediation

1.14 – Ensure hardware MFA is enabled for the root user

Remediation

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

Remediation

1.20 – Ensure a support role has been created to manage incidents with AWS Support

Remediation

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

Remediation

2.1 – Ensure CloudTrail is enabled in all Regions

Remediation

2.2 – Ensure CloudTrail log file validation is enabled

Remediation

2.3 – Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible

Remediation

2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch Logs

Remediation

2.5 – Ensure AWS Config is enabled

Remediation

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

Remediation

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

Remediation

2.8 – Ensure rotation for customer-created KMS keys is enabled

Remediation

2.9 – Ensure VPC flow logging is enabled in all VPCs

Remediation

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

Remediation

3.2 – Ensure a log metric filter and alarm exist for AWS Management Console sign-in without MFA

Remediation

3.3 – Ensure a log metric filter and alarm exist for usage of 'root' account

Remediation

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

Remediation

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

Remediation

3.6 – Ensure a log metric filter and alarm exist for AWS Management Console authentication failures

Remediation

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

Remediation

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

Remediation

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

Remediation

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

Remediation

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

Remediation

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

Remediation

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

Remediation

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

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