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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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.
{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
-
Choose Next.
-
-
Under Assign Metric, do the following:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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
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.
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
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.
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:
-
Choose Create access key.
-
To save the key content, either download the secret access key, or choose Show and then copy it from the page.
-
Store the key in a secure location to provide to the user.
-
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.
This control is not supported in Africa (Cape Town).
Remediation
To 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).
-
To permanently delete the key, choose Delete and then choose Yes. You cannot recover deleted keys.
-
If there is more than one root user access key, then repeat steps 4 and 5 for each key.
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.
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
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.
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.
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.
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 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
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.
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.
-
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.
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
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.
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 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 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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.
{($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")}
-
Choose Next.
-
-
Under Assign metric, do the following:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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")}
-
Choose Next.
-
-
Under Assign metric, do the following:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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.
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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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.
{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
-
Choose Next.
-
-
Under Assign metric, do the following:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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) && ($.errorMessage="Failed authentication")}
-
Choose Next.
-
-
Under Assign metric, do the following:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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=kms.amazonaws.com) && (($.eventName=DisableKey) || ($.eventName=ScheduleKeyDeletion))}
-
Choose Next.
-
-
Under Assign metric, do the following:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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: 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
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.
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/
. -
In the navigation pane, choose Log groups.
-
Select the check box for the log group that you made a note of in the previous procedure.
-
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:
-
In Filter name, enter a name for your metric filter.
-
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.
-
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.
-
For Metric value, enter
1
. -
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 Alarms.
-
Choose Create Alarm.
-
Under Specify metric and conditions, do the following:
-
Choose Select metric.
-
On the Select metric panel, on the All metrics tab, choose the LogMetrics namespace. You can use the search bar to search for it.
-
Choose Metrics with no dimensions.
-
Select the check box for the metric that you created. Then choose Select metric.
-
Under Metric, leave the default values.
-
Under Conditions, for Threshold, choose Static.
-
For Define the alarm condition, choose Greater/Equal.
-
For Define the threshold value, enter
1
. -
Choose Next.
-
-
Under Configure actions, do the following:
-
Under Alarm state trigger, choose In alarm.
-
Under Select an SNS topic, choose Select an existing SNS topic.
-
For Send a notification to, enter the name of the SNS topic that you created in the previous procedure.
-
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
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.
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.
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.
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.