CIS AWS Foundations Benchmark controls

For the CIS AWS Foundations standard, Security Hub supports the following controls. For each control, the information includes the required AWS Config rule and the remediation steps.

1.1 – Avoid the use of the "root" account

Severity: Critical

AWS Config rule: None

The root account has unrestricted access to all resources in the AWS account. We highly recommend that you avoid using this account. The root account is the most privileged account. Minimizing the use of this account and adopting the principle of least privilege for access management reduces the risk of accidental changes and unintended disclosure of highly privileged credentials.

As a best practice, use your root 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.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. These are the same steps to remediate findings for 3.3 – Ensure a log metric filter and alarm exist for usage of "root" account .

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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.
Copy the following pattern and then paste it into the Filter Pattern field.
```
{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
```
Choose Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-1.1-RootAccountUsage.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
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

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.

Security Hub recommends enabling MFA for all accounts that have a console password. Enabling MFA provides increased security for console access because it requires the authenticating principal to possess a device that emits a time-sensitive key and 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 enabling the CIS security checks may not be accurate. It may also take up to 4 hours after remediating this issue for the check to pass.

Remediation

To configure MFA for a user

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Users.
Choose the User name of the user to configure MFA for.
Choose Security credentials and then choose Manage next to Assigned MFA device.
Follow the Manage MFA Device wizard to assign the type of device appropriate for your environment.

To learn how to delegate MFA setup to users, see How to Delegate Management of Multi-Factor Authentication to AWS IAM Users on the AWS Security Blog.

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

Severity: Medium

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

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

Security Hub recommends that you remove or deactivate all credentials that have been unused in 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.

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 managed rule: access-keys-rotated

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.

Security Hub recommends that you regularly rotate all access keys. Rotating access keys reduces the chance for an access key that is associated with a compromised or terminated account to be used. 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 Africa (Cape Town) or Europe (Milan).

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

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

Security Hub 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

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets. Security Hub 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

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

Security Hub 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

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

Security Hub 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

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

Security Hub 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

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.

Security Hub 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

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

Security Hub 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 account access key exists

Severity: Critical

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

The root account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given account.

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

Note

This control is not supported in Africa (Cape Town).

Remediation

To deactivate or delete access keys

Log in to your account using the root credentials.
Choose the account name near the top-right corner of the page and then choose My Security Credentials.
In the pop-up warning, choose Continue to Security Credentials.
Choose Access keys (access key ID and secret access key).
For any existing keys, do one of the following:
- Choose Make Inactive to prevent the key from being used to authenticate the account.
- Choose Delete and then choose Yes to permanently delete the key. You can't recover deleted keys.

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

Severity: Critical

AWS Config rule: root-account-mfa-enabled

The root account is the most privileged user in an 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 root accounts, Security Hub 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 enable MFA for the root account

Log in to your account using the root credentials.
Choose the account name near the top-right corner of the page and then choose My Security Credentials.
In the pop-up warning, choose Continue to Security Credentials.
Choose Multi-factor authentication (MFA).
Choose Activate MFA.
Choose the type of device to use for MFA and then choose Continue.
Complete the steps to configure the device type appropriate to your selection.

Choose a hardware-based authentication mechanism for best results in passing the check 1.14 – Ensure hardware MFA is enabled for the "root" account .

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

Severity: Critical

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

For Level 2, Security Hub recommends that you protect the root account 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.

Using hardware MFA for many, 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.

Note

This control is not supported in the following Regions.

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

Remediation

To enable hardware-based MFA for the root account

Log in to your account using the root credentials.
Choose the account name near the top-right corner of the page and then choose My Security Credentials.
In the pop-up warning, choose Continue to Security Credentials.
Choose Multi-factor authentication (MFA).
Choose Activate MFA.
Choose a hardware-based (not virtual) device to use for MFA and then choose Continue.
Complete the steps to configure the device type appropriate to your selection.

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

Severity: Low

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

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.

Security Hub 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.

Remediation

To resolve this issue, create an IAM group, assign the policy to the group, and then add the users to the group. The policy is applied to each user in the group.

To create an IAM group

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Groups and then choose Create New Group.
Enter a name for the group to create and then choose Next Step.
Select each policy to assign to the group and then choose Next Step.

The policies that you choose should include any policies currently attached directly to a user account. The next step to resolve a failed check is to add users to a group and then assign the policies to that group. Each user in the group gets assigned the policies assigned to the group.
Confirm the details on the Review page and then choose Create Group.

For more information about creating groups, see Creating IAM groups in the IAM User Guide.

To add users to an IAM group

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Groups.
Choose Group Actions and then choose Add Users to Group.
Select the users to add to the group and then choose Add Users.

For more information about adding users to groups, see Adding and removing users in an IAM group.

To remove a policy attached directly to a user

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Users.
For the user to detach a policy from, choose the name in the User name column.
For each policy listed under Attached directly, choose the X on the right side of the page to remove the policy from the user and then choose Remove.
Confirm that the user can still use AWS services as expected.

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

Severity: Low

AWS Config rule: iam-policy-in-use

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 Africa (Cape Town) or 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: Critical

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

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": "*".

Remediation

To modify an IAM policy

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Policies.
Select the radio button next to the policy to remove.
From the Policy actions drop-down menu, choose Detach.
On the Detach policy page, select the radio button next to each user to detach the policy from and then choose Detach policy.

Confirm that the user that you detached the policy from can still access AWS services and resources as expected.

2.1 – Ensure CloudTrail is enabled in all Regions

Severity: Critical

AWS Config rule: multi-region-cloudtrail-enabled

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 ensures that unexpected activity occurring in otherwise unused Regions is detected
Ensuring that a multi-Region trail exists ensures that 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

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.
For Apply trail to all regions, choose Yes.
Under Storage location, do one of the following:
- To create a new S3 bucket for CloudTrail logs, choose Yes next to Create a new S3 bucket and then enter a name for the bucket.
- Choose No next to Create a new S3 bucket and then select the bucket to use.
Choose Additional settings and, for Enable log file validation, choose Yes to pass 2.2. – Ensure CloudTrail log file validation is enabled .
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.
Choose the pencil icon for the Trail settings.
For Apply trail to all regions, choose Yes and then choose Save.
Choose the pencil icon for the Management events.
Select All for Read/Write events, then choose Save.
Choose the pencil icon for the Storage location.
Choose Yes for Enable log file validation to pass check 2.2, then choose Save.

2.2. – Ensure CloudTrail log file validation is enabled

Severity: Low

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

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

Security Hub 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.
Choose the pencil icon for the Storage location.
For Enable log file validation, choose Yes and then choose Save.

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

Severity: Critical

AWS Config rules: s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited

CloudTrail logs a record of every API call made in your account. These log files are stored in an S3 bucket. Security Hub recommends that the 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

For example, if you are using Security Hub in the US East (N. Virginia) Region, and you are storing AWS CloudTrail logs in a bucket in the US West (N. California) Region, Security Hub cannot find the bucket in the US West (N. California) Region. When this happens, the check returns a warning that the resource cannot be located.

Similarly, if you are aggregating logs from multiple accounts into a single bucket, the CIS check returns a warning finding for all accounts except the account that owns the bucket. Failed findings are returned when the bucket is located in the account and region where the check is being performed and that bucket is publicly accessible.

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

If Security Hub cannot discover the bucket because it is in a different account or region, a warning finding is generated.

If the bucket is discovered and 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

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.

Security Hub recommends that you send CloudTrail logs to CloudWatch Logs.

Note

The intent of this recommendation is to ensure that account activity is being 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 Configure.
In the New or existing log group field, do one of the following:
- To use the default log group, keep the name as is.
- To use an existing log group, enter the name of the log group to use.
- To create a new log group, enter a name for the log group to create.
Choose Continue.
Do one of the following:
- To use the default IAM role, go to the next step.
- To specify the role to use, choose View Details.
  1. For IAM role, do one of the following:
    - Choose the CloudTrail_CloudWatchLogs_role and then select the policy to use in the Policy Name drop-down list.
    - Choose Create a new IAM Role and then enter a name for the role to create.
      
      A role is created and assigned a policy that grants the necessary permissions.
Choose Allow.

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

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.

Security Hub 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.

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, choose Get started.
On the Settings page, do the following:
- Under Resource types to record, select Record all resources supported in this region and Include global resources (e.g., AWS IAM resources).
- 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.
- 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.
Choose Next.
On the AWS Config rules page, choose Skip.
Choose Confirm.

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: s3-bucket-logging-enabled

Amazon 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.

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Similarly, if you are aggregating logs from multiple accounts into a single bucket, the CIS check returns a warning finding for all accounts except the account that owns the bucket.

Failed findings are returned when the bucket is located in the account and region where the check is being performed and that bucket is publicly accessible.

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 cannot be discovered because it is in a different account or region, a warning finding is generated. If the bucket is discovered and 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 CMKs

Severity: Medium

AWS Config rule: cloud-trail-encryption-enabled

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 AWS KMS customer-created master keys (CMKs) to further protect CloudTrail logs.

Security Hub 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 CMK policy.

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 AWS 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 CMK. 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 CMKs is enabled

Severity: High

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

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 CMK. 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.

Security Hub recommends that you enable CMK 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 CMK 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 CMK 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

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

Security Hub 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: Medium

AWS Config rule: None

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

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

For example, if you enable Security Hub in the US East (N. Virginia) Region, but you create CloudWatch alarms or SNS topics in the US West (N. California) Region, Security Hub running in the US East (N. Virginia) Region can’t locate the CloudWatch alarms or SNS topics in the US West (N. California) Region.

When this happens, the check returns a warning that the resource can’t be located. A Failed finding is generated only when a resource is successfully located but is not compliant with CIS requirements for the control.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.
Copy the following pattern and then paste it into the Filter Pattern field.
```
{($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")}
```
Choose Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.1-UnauthorizedAPICalls.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.
Copy the following pattern and then paste it into the Filter Pattern field.
```
{($.eventName="ConsoleLogin") && ($.additionalEventData.MFAUsed !="Yes")}
```
Choose Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.2-ConsoleSigninWithoutMFA.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

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

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs, then choose Log groups.
Choose the log group where CloudTrail is logging.
On the log group details page, choose Metric filters.
Choose Create metric filter.
Copy the following pattern and then paste it into Filter pattern.
```
{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
```
Choose Next.
Enter the name of the new filter. For example, RootAccountUsage.
Confirm that the value for Metric namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
In Metric name, enter the name of the metric.
In Metric value, enter 1, and then choose Next.
Choose Create metric filter.
Next, set up the notification. Select the select the metric filter you just created, then choose Create alarm.
Enter the threshold for the alarm (for example, 1), then choose Next.
Under Select an SNS topic, for Send notification to, choose an email list, then choose Next.
Enter a Name and Description for the alarm, such as RootAccountUsageAlarm, then choose Next.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.4-IAMPolicyChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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


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

Choose Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.5-CloudTrailChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.
Copy the following pattern and then paste it into the Filter Pattern field.
```
{($.eventName=ConsoleLogin) && ($.errorMessage="Failed authentication")}
```
Choose Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.6-ConsoleAuthenticationFailure.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

Security Hub recommends that you create a metric filter and alarm for customer-created CMKs 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.
Copy the following pattern and then paste it into the Filter Pattern field.
```
{($.eventSource=kms.amazonaws.com) && (($.eventName=DisableKey) || ($.eventName=ScheduleKeyDeletion))}
```
Choose Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.7-DisableOrDeleteCMK.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.8-S3BucketPolicyChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.9-AWSConfigChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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.

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.10-SecurityGroupChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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.

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.11-NetworkACLChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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.

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.12-NetworkGatewayChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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.

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

The steps to remediate this issue include setting up an Amazon SNS topic, 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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.13-RouteTableChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
Choose Create Alarm.

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

Severity: Medium

AWS Config rule: None

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.

Security Hub 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.

Important

Security Hub supports CIS AWS Foundations checks only on resources in the same Region and owned by the same account as the one in which Security Hub is enabled.

Remediation

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

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.
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 associated log group name.

To create a metric filter and alarm

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
Choose Logs.
Find the log group that you made a note of in the previous procedure and then choose the value in the Metric Filters column.
Choose Add Metric Filter.

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 Assign Metric.
(Optional) Update the filter name to a name of your choice.
Confirm that the value for Metric Namespace is LogMetrics.

This ensures that all CIS Benchmark metrics are grouped together.
Enter a name in the Metric Name field and then choose Create Filter.

The filter is created, and its details appear.
Choose Create Alarm.
Under Alarm details, enter a Name and Description for the alarm, such as CIS-3.14-VPCChanges.
Under Actions, for Send notification to, choose Enter list and then enter the name of the topic that you created in the previous procedure.
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

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

Security Hub 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 Africa (Cape Town) or 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

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

Security Hub 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 Africa (Cape Town) or 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: Medium

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

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.

Security Hub 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 required by systems to work properly because it can log all packet acceptances and rejections occurring 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, which 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 AWS Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Required AWS Config resources

Controls that you might want to disable

CIS AWS Foundations Benchmark controls

1.1 – Avoid the use of the "root" account

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 account access key exists

Remediation

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

Remediation

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

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 CloudTrail logs to 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 CMKs

Remediation

2.8 – Ensure rotation for customer-created CMKs 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 created CMKs

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