docs.aws.amazon.com Open in urlscan Pro
54.239.23.208 Public Scan

Back to summary

Submitted URL:
https://docs.aws.amazon.com/console/securityhub/standards-cis-2.8/remediation
Effective URL:
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls.html
Submission: On November 18 via api (November 18th 2021, 5:47:24 pm UTC) from US — Scanned from DE

Form analysis
0 forms found in the DOM

Text Content

SELECT YOUR COOKIE PREFERENCES

We use cookies and similar tools to enhance your experience, provide our
services, deliver relevant advertising, and make improvements. Approved third
parties also use these tools to help us deliver advertising and provide certain
site features.

CustomizeAccept all

CUSTOMIZE COOKIE PREFERENCES

We use cookies and similar tools (collectively, "cookies") for the following
purposes.

ESSENTIAL

Essential cookies are necessary to provide our site and services and cannot be
deactivated. They are usually set in response to your actions on the site, such
as setting your privacy preferences, signing in, or filling in forms.

PERFORMANCE

Performance cookies provide anonymous statistics about how customers navigate
our site so we can improve site experience and performance. Approved third
parties may perform analytics on our behalf, but they cannot use the data for
their own purposes.

Allow performance category
Allowed

FUNCTIONAL

Functional cookies help us provide useful site features, remember your
preferences, and display relevant content. Approved third parties may set these
cookies to provide certain site features. If you do not allow these cookies,
then some or all of these services may not function properly.

Allow functional category
Allowed

ADVERTISING

Advertising cookies may be set through our site by us or our advertising
partners and help us deliver relevant marketing content. If you do not allow
these cookies, you will experience less relevant advertising.

Allow advertising category
Allowed

Blocking some types of cookies may impact your experience of our sites. You may
review and change your choices at any time by clicking Cookie preferences in the
footer of this site. We and selected third-parties use cookies or similar
technologies as specified in the AWS Cookie Notice

CancelSave preferences

English

Feedback
Preferences
AWS Security Hub
User Guide
* What is AWS Security Hub?
* Benefits of Security Hub
* How Security Hub works
* Security Hub free trial, usage, and pricing

* Terminology and concepts
* Prerequisites and recommendations
* Using Organizations
* Enabling AWS Config

* Quotas
* Supported Regions
* Setting up Security Hub
* Enabling Security Hub manually
* Service-linked role assigned to Security Hub

* Security
* Data protection
* AWS Identity and Access Management
* How AWS Security Hub works with IAM

* Using service-linked roles
* AWS managed policies
* Compliance validation
* Infrastructure security
* VPC endpoints (AWS PrivateLink)

* Managing accounts
* Effects of an administrator-member relationship
* Restrictions and recommendations
* Making the transition to Organizations
* Allowed actions for accounts
* Designating a Security Hub administrator account
* Managing organization member accounts
* Enabling new accounts automatically
* Enabling member accounts
* Disassociating member accounts

* Managing member accounts by invitation
* Adding and inviting member accounts
* Responding to an invitation
* Disassociating member accounts
* Deleting member accounts
* Disassociating from your administrator account

* Effect of account actions on Security Hub data

* Findings
* Creating and updating findings
* Using BatchImportFindings
* Using BatchUpdateFindings

* Aggregating findings
* How finding aggregation works
* Viewing the current configuration
* Enabling finding aggregation
* Updating the configuration
* Stopping finding aggregation

* Viewing a cross-Region finding summary
* Viewing finding lists and details
* Filtering and grouping findings (console)
* Viewing finding details (console)
* Retrieving finding details (Security Hub API, AWS CLI)

* Taking action on findings
* Setting the workflow status for findings
* Sending findings to a custom action

* Finding format
* ASFF syntax
* ASFF attributes
* Types taxonomy for ASFF

* Insights
* Viewing and filtering the list of insights
* Viewing insight results and findings
* Managed insights
* Managing custom insights

* Product integrations
* Managing product integrations
* Available AWS service integrations
* Available third-party partner product integrations
* Using custom product integrations

* Standards and controls
* Running security checks
* How Security Hub uses AWS Config rules to run security checks
* Schedule for running security checks
* Generating and updating control findings
* Determining the control status
* Determining the standard security score

* Viewing and managing standards
* Disabling or enabling a security standard
* Viewing details for a standard

* Viewing and managing controls
* Viewing details for a control
* Enabling new controls automatically
* Disabling and enabling individual controls
* Viewing and taking action on control findings
* Filtering and sorting findings
* Viewing finding and resource details
* Taking action on control findings

* Available standards
* CIS AWS Foundations Benchmark
* Required AWS Config resources
* CIS AWS Foundations Benchmark controls
* Controls that you might want to disable
* CIS AWS Foundations Benchmark security checks that are not supported
in Security Hub

* Payment Card Industry Data Security Standard (PCI DSS)
* Required AWS Config resources
* PCI DSS controls
* Controls that you might want to disable

* AWS Foundational Security Best Practices standard
* Required AWS Config resources
* AWS Foundational Security Best Practices controls
* Control categories
* Controls that you might want to disable

* Security Hub with CloudTrail
* Automated response and remediation
* Types of EventBridge integration
* EventBridge event formats
* Configuring a rule for automatically sent findings
* Configuring and using custom actions

* Disabling AWS Security Hub
* Document history

CIS AWS Foundations Benchmark controls - AWS Security Hub
AWSDocumentationAWS Security HubUser Guide
1.1 – Avoid the use of the "root" account1.2 – Ensure multi-factor
authentication (MFA) is enabled for all IAM users that have a console password
1.3 – Ensure credentials unused for 90 days or greater are disabled1.4 – Ensure
access keys are rotated every 90 days or less 1.5 – Ensure IAM password policy
requires at least one uppercase letter1.6 – Ensure IAM password policy requires
at least one lowercase letter1.7 – Ensure IAM password policy requires at least
one symbol1.8 – Ensure IAM password policy requires at least one number1.9 –
Ensure IAM password policy requires a minimum length of 14 or greater1.10 –
Ensure IAM password policy prevents password reuse1.11 – Ensure IAM password
policy expires passwords within 90 days or less1.12 – Ensure no root account
access key exists1.13 – Ensure MFA is enabled for the "root" account 1.14 –
Ensure hardware MFA is enabled for the "root" account 1.16 – Ensure IAM policies
are attached only to groups or roles1.20 - Ensure a support role has been
created to manage incidents with AWS Support 1.22 – Ensure IAM policies that
allow full "*:*" administrative privileges are not created 2.1 – Ensure
CloudTrail is enabled in all Regions2.2. – Ensure CloudTrail log file validation
is enabled 2.3 – Ensure the S3 bucket CloudTrail logs to is not publicly
accessible2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch
Logs2.5 – Ensure AWS Config is enabled2.6 – Ensure S3 bucket access logging is
enabled on the CloudTrail S3 bucket 2.7 – Ensure CloudTrail logs are encrypted
at rest using AWS KMS keys2.8 – Ensure rotation for customer-created KMS keys is
enabled2.9 – Ensure VPC flow logging is enabled in all VPCs 3.1 – Ensure a log
metric filter and alarm exist for unauthorized API calls 3.2 – Ensure a log
metric filter and alarm exist for AWS Management Console sign-in without MFA 3.3
– Ensure a log metric filter and alarm exist for usage of "root" account 3.4 –
Ensure a log metric filter and alarm exist for IAM policy changes 3.5 – Ensure a
log metric filter and alarm exist for CloudTrail configuration changes 3.6 –
Ensure a log metric filter and alarm exist for AWS Management Console
authentication failures 3.7 – Ensure a log metric filter and alarm exist for
disabling or scheduled deletion of customer managed keys 3.8 – Ensure a log
metric filter and alarm exist for S3 bucket policy changes3.9 – Ensure a log
metric filter and alarm exist for AWS Config configuration changes 3.10 – Ensure
a log metric filter and alarm exist for security group changes 3.11 – Ensure a
log metric filter and alarm exist for changes to Network Access Control Lists
(NACL)3.12 – Ensure a log metric filter and alarm exist for changes to network
gateways 3.13 – Ensure a log metric filter and alarm exist for route table
changes 3.14 – Ensure a log metric filter and alarm exist for VPC changes 4.1 –
Ensure no security groups allow ingress from 0.0.0.0/0 to port 22 4.2 – Ensure
no security groups allow ingress from 0.0.0.0/0 to port 3389 4.3 – Ensure the
default security group of every VPC restricts all traffic

CIS AWS FOUNDATIONS BENCHMARK CONTROLS

PDF
Kindle
RSS

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: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

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

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

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

{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}

2. Choose Next.

6. Under Assign Metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric Namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric Name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. In the navigation pane, choose Alarms.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Choose Select metric.

2. On the Select metric panel, on the All metrics tab, choose the
LogMetrics namespace. You can use the search bar to search for it.

3. Choose Metrics with no dimensions.

4. Select the check box for the metric that you created. Then choose Select
metric.

5. Under Metric, leave the default values.

6. Under Conditions, for Threshold, choose Static.

7. For Define the alarm condition, choose Greater/Equal.

8. For Define the threshold value, enter 1.

9. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm,
such as CIS-1.1-RootAccountUsage. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

1.2 – ENSURE MULTI-FACTOR AUTHENTICATION (MFA) IS ENABLED FOR ALL IAM USERS THAT
HAVE A CONSOLE PASSWORD

Severity: Medium

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

Schedule type: Periodic

Multi-factor authentication (MFA) adds an extra layer of protection on top of a
user name and password. With MFA enabled, when a user signs in to an AWS
website, they're prompted for their user name and password as well as for an
authentication code from their AWS MFA device.

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

Important

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

REMEDIATION

To configure MFA for a user

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Users.

3. Choose the User name of the user to configure MFA for.

4. Choose Security credentials and then choose Manage next to Assigned MFA
device.

5. Follow the Manage MFA Device wizard to assign the type of device appropriate
for your environment.

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

1.3 – ENSURE CREDENTIALS UNUSED FOR 90 DAYS OR GREATER ARE DISABLED

Severity: Medium

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

Schedule type: Periodic

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

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

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Users.

3. Choose the name of the user with credentials over 90 days old.

4. Choose Security credentials and then choose Make inactive for all sign-in
credentials and access keys that haven't been used in 90 days or more.

1.4 – ENSURE ACCESS KEYS ARE ROTATED EVERY 90 DAYS OR LESS

Severity: Medium

AWS Config rule: access-keys-rotated

Schedule type: Periodic

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

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

Note

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

REMEDIATION

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

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Users.

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

4. Choose Security credentials.

5. To create a new key for the user:

1. Choose Create access key.

2. To save the key content, either download the secret access key, or choose
Show and then copy it from the page.

3. Store the key in a secure location to provide to the user.

4. Choose Close.

6. Update all applications that were using the previous key to use the new key.

7. For the previous key, choose Make inactive to make the access key inactive.
Now the user can't make requests using that key.

8. Confirm that all applications work as expected with the new key.

9. After confirming that all applications work with the new key, delete the
previous key. After you delete the access key, you can't recover it.

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

1.5 – ENSURE IAM PASSWORD POLICY REQUIRES AT LEAST ONE UPPERCASE LETTER

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

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

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

REMEDIATION

To modify the password policy

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Account settings.

3. Select Requires at least one uppercase letter and then choose Apply password
policy.

1.6 – ENSURE IAM PASSWORD POLICY REQUIRES AT LEAST ONE LOWERCASE LETTER

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

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

REMEDIATION

To modify the password policy

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Account settings.

3. Select Requires at least one lowercase letter and then choose Apply password
policy.

1.7 – ENSURE IAM PASSWORD POLICY REQUIRES AT LEAST ONE SYMBOL

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

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

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

REMEDIATION

To modify the password policy

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Account settings.

3. Select Require at least one non-alphanumeric character and then choose Apply
password policy.

1.8 – ENSURE IAM PASSWORD POLICY REQUIRES AT LEAST ONE NUMBER

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

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

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

REMEDIATION

To modify the password policy

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Account settings.

3. Select Requires at least one number and then choose Apply password policy.

1.9 – ENSURE IAM PASSWORD POLICY REQUIRES A MINIMUM LENGTH OF 14 OR GREATER

Severity: Medium

AWS Config rule: iam-password-policy

Schedule type: Periodic

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

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

REMEDIATION

To modify the password policy

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Account settings.

3. In the Minimum password length field, enter 14, then choose Apply password
policy.

1.10 – ENSURE IAM PASSWORD POLICY PREVENTS PASSWORD REUSE

Severity: Low

AWS Config rule: iam-password-policy

Schedule type: Periodic

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

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

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

REMEDIATION

To modify the password policy

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Account settings.

3. Select Prevent password reuse and then enter 24 for Number of passwords to
remember.

4. Choose Apply password policy.

1.11 – ENSURE IAM PASSWORD POLICY EXPIRES PASSWORDS WITHIN 90 DAYS OR LESS

Severity: Low

AWS Config rule: iam-password-policy

Schedule type: Periodic

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

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

* Passwords can be stolen or compromised without your knowledge. This can
happen via a system compromise, software vulnerability, or internal threat.

* Certain corporate and government web filters or proxy servers can intercept
and record traffic even if it's encrypted.

* Many people use the same password for many systems such as work, email, and
personal.

* Compromised end-user workstations might have a keystroke logger.

REMEDIATION

To modify the password policy

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Account settings.

3. Select Enable password expiration and then enter 90 for Password expiration
period (in days).

4. Choose Apply password policy.

1.12 – ENSURE NO ROOT ACCOUNT ACCESS KEY EXISTS

Severity: Critical

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

Schedule type: Periodic

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

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

Note

This control is not supported in Africa (Cape Town) or Asia Pacific (Osaka).

REMEDIATION

To delete access keys

1. Log in to your account using the root credentials.

2. Choose the account name near the top-right corner of the page and then
choose My Security Credentials.

3. In the pop-up warning, choose Continue to Security Credentials.

4. Choose Access keys (access key ID and secret access key).

5. To permanently delete the key, choose Delete and then choose Yes. You cannot
recover deleted keys.

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

Schedule type: Periodic

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

Note

This control is not supported in the following Regions.

* China (Beijing)

* China (Ningxia)

* AWS GovCloud (US-East)

* AWS GovCloud (US-West).

REMEDIATION

To enable MFA for the root account

1. Log in to your account using the root credentials.

2. Choose the account name near the top-right corner of the page and then
choose My Security Credentials.

3. In the pop-up warning, choose Continue to Security Credentials.

4. Choose Multi-factor authentication (MFA).

5. Choose Activate MFA.

6. Choose the type of device to use for MFA and then choose Continue.

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

Schedule type: Periodic

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

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

Note

This control is not supported in the following Regions.

* China (Beijing)

* China (Ningxia)

* AWS GovCloud (US-East)

* AWS GovCloud (US-West).

REMEDIATION

To enable hardware-based MFA for the root account

1. Log in to your account using the root credentials.

2. Choose the account name near the top-right corner of the page and then
choose My Security Credentials.

3. In the pop-up warning, choose Continue to Security Credentials.

4. Choose Multi-factor authentication (MFA).

5. Choose Activate MFA.

6. Choose a hardware-based (not virtual) device to use for MFA and then choose
Continue.

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

Schedule type: Change triggered

By default, IAM users, groups, and roles have no access to AWS resources. IAM
policies are how privileges are granted to users, groups, or roles.

CIS recommends that you apply IAM policies directly to groups and roles but not
users. Assigning privileges at the group or role level reduces the complexity of
access management as the number of users grow. Reducing access management
complexity might in turn reduce opportunity for a principal to inadvertently
receive or retain excessive privileges.

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

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Groups and then choose Create New Group.

3. Enter a name for the group to create and then choose Next Step.

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

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

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Groups.

3. Choose Group Actions and then choose Add Users to Group.

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

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Users.

3. For the user to detach a policy from, choose the name in the User name
column.

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

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

Schedule type: Periodic

AWS provides a support center that can be used for incident notification and
response, as well as technical support and customer services.

Create an IAM role to allow authorized users to manage incidents with AWS
Support. By implementing least privilege for access control, an IAM role will
require an appropriate IAM policy to allow support center access in order to
manage incidents with AWS Support.

Note

This control is not supported in the following Regions.

* Africa (Cape Town)

* Asia Pacific (Osaka)

* Europe (Milan)

REMEDIATION

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

To create the role to use for AWS Support access

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. In the IAM navigation pane, choose Roles, then choose Create role.

3. For Role type, choose the Another AWS account.

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

5. Choose Next: Permissions.

6. Search for the managed policy AWSSupportAccess.

7. Select the check box for the AWSSupportAccess managed policy.

8. Choose Next: Tags.

9. (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.

10. Choose Next: Review.

11. For Role name, enter a name for your role.

Role names must be unique within your AWS account. They are not case
sensitive.

12. (Optional) For Role description, enter a description for the new role.

13. Review the role, then choose Create role.

1.22 – ENSURE IAM POLICIES THAT ALLOW FULL "*:*" ADMINISTRATIVE PRIVILEGES ARE
NOT CREATED

Severity: High

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

Schedule type: Change triggered

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

1. Open the IAM console at https://console.aws.amazon.com/iam/.

2. Choose Policies.

3. Select the radio button next to the policy to remove.

4. From the Policy actions drop-down menu, choose Detach.

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

Schedule type: Periodic

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

CloudTrail is a service that records AWS API calls for your account and delivers
log files to you. The recorded information includes the identity of the API
caller, the time of the API call, the source IP address of the API caller, the
request parameters, and the response elements returned by the AWS service.
CloudTrail provides a history of AWS API calls for an account, including API
calls made via the AWS Management Console, AWS SDKs, command-line tools, and
higher-level AWS services (such as AWS CloudFormation).

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

* Ensuring that a multi-Region trail exists 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

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

REMEDIATION

To create a new trail in CloudTrail

1. Sign in to the AWS Management Console and open the CloudTrail console at
https://console.aws.amazon.com/cloudtrail/.

2. If you haven't used CloudTrail before, choose Get Started Now.

3. Choose Trails and then choose Create trail.

4. Enter a name for the trail.

5. Under Storage location, do one of the following:

* To create a new S3 bucket for CloudTrail logs, choose Create new S3 bucket
and then enter a name for the bucket.

* Choose Use existing S3 bucket and then select the bucket to use.

6. Choose Additional settings and, for Log file validation, choose Enabled to
pass 2.2. – Ensure CloudTrail log file validation is enabled .

7. To pass 2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch
Logs, you must enable CloudWatch Logs.

1. Under CloudWatch Logs, select the Enabled check box.

2. For Log group, do one of the following:

* To use an existing log group, choose Existing and then enter the name
of the log group to use.

* To create a new log group, choose New and then enter a name for the
log group to create.

3. For IAM role, do one of the following:

* To use an existing role, choose Existing and then choose the role from
the drop-down list.

* To create a new role, choose New and then enter a name for the role to
create. The new role is assigned a policy that grants the necessary
permissions.

To view the permissions granted to the role, expand the Policy
document.

8. Choose Create.

To update an existing trail in CloudTrail

1. Sign in to the AWS Management Console and open the CloudTrail console at
https://console.aws.amazon.com/cloudtrail/.

2. Choose Trails.

3. Choose the name of the trail in the Name column.

4. Update the trail configuration as needed.

To update the configuration in a particular section, do the following:

1. Choose Edit for that section.

2. Make the required updates to the configuration.

3. Choose Save changes.

2.2. – ENSURE CLOUDTRAIL LOG FILE VALIDATION IS ENABLED

Severity: Medium

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

Schedule type: Periodic

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

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

REMEDIATION

To enable CloudTrail log file validation

1. Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.

2. Choose Trails.

3. Choose the name of a trail to edit in the Name column.

4. Under General details, choose Edit.

5. Under Additional settings, for Log file validation, select Enabled.

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

Schedule type: Periodic and change triggered

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

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

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

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

REMEDIATION

To remove public access for an Amazon S3 bucket

1. Open the Amazon S3 console at https://console.aws.amazon.com/s3/.

2. Choose the name of the bucket where your CloudTrail are stored.

3. Choose Permissions and then choose Public access settings.

4. Choose Edit, select all four options, and then choose Save.

5. If prompted, enter confirm and then choose Confirm.

2.4 – ENSURE CLOUDTRAIL TRAILS ARE INTEGRATED WITH AMAZON CLOUDWATCH LOGS

Severity: Low

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

Schedule type: Periodic

CloudTrail is a web service that records AWS API calls made in a given account.
The recorded information includes the identity of the API caller, the time of
the API call, the source IP address of the API caller, the request parameters,
and the response elements returned by the AWS service.

CloudTrail uses Amazon S3 for log file storage and delivery, so log files are
stored durably. In addition to capturing CloudTrail logs in a specified Amazon
S3 bucket for long-term analysis, you can perform real-time analysis by
configuring CloudTrail to send logs to CloudWatch Logs.

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

CIS recommends that you send CloudTrail logs to CloudWatch Logs.

Note

The intent of this recommendation is to ensure that account activity is 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

1. Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.

2. Choose Trails.

3. Choose a trail that there is no value for in the CloudWatch Logs Log group
column.

4. Scroll down to the CloudWatch Logs section and then choose Edit.

5. Select the Enabled check box.

6. For Log group, do one of the following:

* To use an existing log group, choose Existing and then enter the name of
the log group to use.

* To create a new log group, choose New and then enter a name for the log
group to create.

7. For IAM role, do one of the following:

* To use an existing role, choose Existing and then choose the role from the
drop-down list.

* To create a new role, choose New and then enter a name for the role to
create. The new role is assigned a policy that grants the necessary
permissions.

To view the permissions granted to the role, expand the Policy document.

8. Choose Save changes.

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

2.5 – ENSURE AWS CONFIG IS ENABLED

Severity: Medium

AWS Config rule: None

Schedule type: Periodic

AWS Config is a web service that performs configuration management of supported
AWS resources in your account and delivers log files to you. The recorded
information includes the configuration item (AWS resource), relationships
between configuration items (AWS resources), and any configuration changes
between resources.

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

Note

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

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

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

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

REMEDIATION

To configure AWS Config settings

1. Open the AWS Config console at https://console.aws.amazon.com/config/.

2. Select the Region to configure AWS Config in.

3. If you haven't used AWS Config before, choose Get started.

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

5. Choose Next.

6. On the AWS Config rules page, choose Skip.

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

Schedule type: Change triggered

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.

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

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

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

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

REMEDIATION

To enable S3 bucket access logging

1. Open the Amazon S3 console at https://console.aws.amazon.com/s3/.

2. Choose the bucket used for CloudTrail.

3. Choose Properties.

4. Choose Server access logging, then choose Enable logging.

5. Select a bucket from the Target bucket list, and optionally enter a prefix.

6. Choose Save.

2.7 – ENSURE CLOUDTRAIL LOGS ARE ENCRYPTED AT REST USING AWS KMS KEYS

Severity: Medium

AWS Config rule: cloud-trail-encryption-enabled

Schedule type: Periodic

CloudTrail is a web service that records AWS API calls for an account and makes
those logs available to users and resources in accordance with IAM policies. AWS
Key Management Service (AWS KMS) is a managed service that helps create and
control the encryption keys used to encrypt account data, and uses hardware
security modules (HSMs) to protect the security of encryption keys.

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

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

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

REMEDIATION

To enable encryption for CloudTrail logs

1. Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.

2. Choose Trails.

3. Choose the trail to update.

4. Under Storage location, choose the pencil icon to edit the settings.

5. For Encrypt log files with SSE-KMS, choose Yes.

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

7. Choose Save.

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

2.8 – ENSURE ROTATION FOR CUSTOMER-CREATED KMS KEYS IS ENABLED

Severity: Medium

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

Schedule type: Periodic

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

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

REMEDIATION

To enable KMS key rotation

1. Open the AWS KMS console at https://console.aws.amazon.com/kms.

2. To change the AWS Region, use the Region selector in the upper-right corner
of the page.

3. Choose Customer managed keys.

4. Choose the alias of the key to update in the Alias column.

5. Choose Key rotation.

6. Select Automatically rotate this KMS key every year and then choose Save.

2.9 – ENSURE VPC FLOW LOGGING IS ENABLED IN ALL VPCS

Severity: Medium

AWS Config rule: vpc-flow-logs-enabled

Schedule type: Periodic

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

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

REMEDIATION

To enable VPC flow logging

1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

2. Choose Your VPCs.

3. Select a VPC to update.

4. Choose the Flow Logs tab in the bottom section of the page.

5. Choose Create flow log.

6. For Filter, choose Reject.

7. For Destination log group, select the log group to use.

8. For IAM role, select the IAM role to use.

9. Choose Create.

3.1 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR UNAUTHORIZED API CALLS

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

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

{($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, for Statistic, choose Average. For more information about
the available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.1-UnauthorizedAPICalls. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.2 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR AWS MANAGEMENT CONSOLE
SIGN-IN WITHOUT MFA

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

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

{($.eventName="ConsoleLogin") && ($.additionalEventData.MFAUsed !="Yes")}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.2-ConsoleSigninWithoutMFA. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.3 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR USAGE OF "ROOT" ACCOUNT

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

CIS recommends that you create a metric filter and alarm for root 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.

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

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

{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, RootAccountUsage. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.4 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR IAM POLICY CHANGES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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)}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, for Statistic, choose Average. For more information about
the available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.4-IAMPolicyChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.5 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR CLOUDTRAIL CONFIGURATION
CHANGES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

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

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

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.5-CloudTrailChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.6 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR AWS MANAGEMENT CONSOLE
AUTHENTICATION FAILURES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

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

{($.eventName=ConsoleLogin) && ($.errorMessage="Failed authentication")}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.6-ConsoleAuthenticationFailure. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.7 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR DISABLING OR SCHEDULED
DELETION OF CUSTOMER MANAGED KEYS

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

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

{($.eventSource=kms.amazonaws.com) && (($.eventName=DisableKey) || ($.eventName=ScheduleKeyDeletion))}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.7-DisableOrDeleteCMK. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.8 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR S3 BUCKET POLICY CHANGES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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))}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, for Statistic, choose Average. For more information about
the available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.8-S3BucketPolicyChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.9 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR AWS CONFIG CONFIGURATION
CHANGES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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))}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.9-AWSConfigChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.10 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR SECURITY GROUP CHANGES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to
CloudWatch Logs and establishing corresponding metric filters and alarms.
Security groups are a stateful packet filter that controls ingress and egress
traffic in a VPC.

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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)}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.10-SecurityGroupChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.11 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR CHANGES TO NETWORK ACCESS
CONTROL LISTS (NACL)

Severity: Low

AWS Config rule: None

Schedule type: Periodic

You can do real-time monitoring of API calls by directing CloudTrail logs to
CloudWatch Logs and establishing corresponding metric filters and alarms. NACLs
are used as a stateless packet filter to control ingress and egress traffic for
subnets in a VPC.

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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)}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.11-NetworkACLChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.12 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR CHANGES TO NETWORK
GATEWAYS

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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)}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, leave the default values. For more information about the
available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.12-NetworkGatewayChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.13 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR ROUTE TABLE CHANGES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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)}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, for Statistic, choose Average. For more information about
the available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.13-RouteTableChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

3.14 – ENSURE A LOG METRIC FILTER AND ALARM EXIST FOR VPC CHANGES

Severity: Low

AWS Config rule: None

Schedule type: Periodic

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

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

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

Note

The check results in FAILED findings in the following cases:

* No trail is configured.

* The available trails that are in the current Region and that are owned by
current account do not meet the control requirements.

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

* The multi-Region trail is based in a different Region. Security Hub can only
generate findings in the Region where the trail is based.

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

REMEDIATION

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

To create an Amazon SNS topic

1. Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Create an Amazon SNS topic that receives all CIS alarms.

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

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

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

Finally, create the metric filter and alarm.

To create a metric filter and alarm

1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

2. In the navigation pane, choose Log groups.

3. Select the check box for the CloudWatch Logs log group that is associated
with the CloudTrail trail that you created.

4. From Actions, choose Create Metric Filter.

5. Under Define pattern, do the following:

1. 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)}

2. Choose Next.

6. Under Assign metric, do the following:

1. In Filter name, enter a name for your metric filter.

2. For Metric namespace, enter LogMetrics.

If you use the same namespace for all of your CIS log metric filters,
then all CIS Benchmark metrics are grouped together.

3. For Metric name, enter a name for the metric. Remember the name of the
metric. You will need to select the metric when you create the alarm.

4. For Metric value, enter 1.

5. Choose Next.

7. Under Review and create, verify the information that you provided for the
new metric filter. Then choose Create metric filter.

8. Choose the Metric filters tab, then choose the metric filter that you just
created.

To choose the metric filter, select the check box at the upper right.

9. Choose Create Alarm.

10. Under Specify metric and conditions, do the following:

1. Under Metric, for Statistic, choose Average. For more information about
the available statistics, see Statistics in the Amazon CloudWatch User
Guide.

2. Under Conditions, for Threshold, choose Static.

3. For Define the alarm condition, choose Greater/Equal.

4. For Define the threshold value, enter 1.

5. Choose Next.

11. Under Configure actions, do the following:

1. Under Alarm state trigger, choose In alarm.

2. Under Select an SNS topic, choose Select an existing SNS topic.

3. For Send a notification to, enter the name of the SNS topic that you
created in the previous procedure.

4. Choose Next.

12. Under Add name and description, enter a Name and Description for the alarm.
For example, CIS-3.14-VPCChanges. Then choose Next.

13. Under Preview and create, review the alarm configuration. Then choose
Create alarm.

4.1 – ENSURE NO SECURITY GROUPS ALLOW INGRESS FROM 0.0.0.0/0 TO PORT 22

Severity: High

AWS Config rule: restricted-ssh

Schedule type: Change triggered

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

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

Note

This control is not supported in the following Regions.

* Africa (Cape Town)

* Asia Pacific (Osaka)

* Europe (Milan)

REMEDIATION

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

1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

2. In the left pane, choose Security groups.

3. Select a security group.

4. In the bottom section of the page, choose the Inbound Rules tab.

5. Choose Edit rules.

6. Identify the rule that allows access through port 22 and then choose the X
to remove it.

7. Choose Save rules.

4.2 – ENSURE NO SECURITY GROUPS ALLOW INGRESS FROM 0.0.0.0/0 TO PORT 3389

Severity: High

AWS Config rule: restricted-common-ports

Schedule type: Change triggered

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

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

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

Note

This control is not supported in the following Regions.

* Africa (Cape Town)

* Asia Pacific (Osaka)

* Europe (Milan)

REMEDIATION

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

1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

2. In the left pane, choose Security groups.

3. Select a security group.

4. In the bottom section of the page, choose the Inbound Rules tab.

5. Choose Edit rules.

6. Identify the rule that allows access through port 3389 and then choose the X
to remove it.

7. Choose Save rules.

4.3 – ENSURE THE DEFAULT SECURITY GROUP OF EVERY VPC RESTRICTS ALL TRAFFIC

Severity: High

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

Schedule type: Change triggered

A VPC comes with a default security group with initial settings that deny all
inbound traffic, allow all outbound traffic, and allow all traffic between
instances assigned to the security group. If you don't specify a security group
when you launch an instance, the instance is automatically assigned to this
default security group. Security groups provide stateful filtering of ingress
and egress network traffic to AWS resources.

CIS recommends that the default security group restrict all traffic.

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

Note

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

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

REMEDIATION

To update the default security group to restrict all access

1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

2. View the default security groups details to see the resources that are
assigned to them.

3. Create a set of least-privilege security groups for the resources.

4. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

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

6. For each default security group, choose the Inbound tab and delete all
inbound rules.

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

This page is helpful.

Thanks for your vote. To provide details, send feedback.

This page is not helpful.

Javascript is disabled or is unavailable in your browser.

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

Document Conventions
Required AWS Config resources
Controls that you might want to disable
Did this page help you?
Yes No

Did this page help you? - Yes

Thanks for letting us know we're doing a good job!

If you've got a moment, please tell us what we did right so we can do more of
it.

Feedback

Did this page help you? - No

Thanks for letting us know this page needs work. We're sorry we let you down.

If you've got a moment, please tell us how we can make the documentation better.

Feedback

Provide feedback

Edit this page on GitHub
Previous topic: Required AWS Config resources

Next topic: Controls that you might want to disable
Need help?

* Connect with an AWS IQ expert

Thanks for letting us know we're doing a good job!

If you've got a moment, please tell us what we did right so we can do more of
it.

Feedback

Did this page help you? - No

Thanks for letting us know this page needs work. We're sorry we let you down.

If you've got a moment, please tell us how we can make the documentation better.

Feedback

On this page
* 1.1 – Avoid the use of the "root" account
* 1.2 – Ensure multi-factor authentication (MFA) is enabled for all IAM users
that have a console password
* 1.3 – Ensure credentials unused for 90 days or greater are disabled
* 1.4 – Ensure access keys are rotated every 90 days or less
* 1.5 – Ensure IAM password policy requires at least one uppercase letter
* 1.6 – Ensure IAM password policy requires at least one lowercase letter
* 1.7 – Ensure IAM password policy requires at least one symbol
* 1.8 – Ensure IAM password policy requires at least one number
* 1.9 – Ensure IAM password policy requires a minimum length of 14 or greater
* 1.10 – Ensure IAM password policy prevents password reuse
* 1.11 – Ensure IAM password policy expires passwords within 90 days or less
* 1.12 – Ensure no root account access key exists
* 1.13 – Ensure MFA is enabled for the "root" account
* 1.14 – Ensure hardware MFA is enabled for the "root" account
* 1.16 – Ensure IAM policies are attached only to groups or roles
* 1.20 - Ensure a support role has been created to manage incidents with AWS
Support
* 1.22 – Ensure IAM policies that allow full "*:*" administrative privileges
are not created
* 2.1 – Ensure CloudTrail is enabled in all Regions
* 2.2. – Ensure CloudTrail log file validation is enabled
* 2.3 – Ensure the S3 bucket CloudTrail logs to is not publicly accessible
* 2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch Logs
* 2.5 – Ensure AWS Config is enabled
* 2.6 – Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket
* 2.7 – Ensure CloudTrail logs are encrypted at rest using AWS KMS keys
* 2.8 – Ensure rotation for customer-created KMS keys is enabled
* 2.9 – Ensure VPC flow logging is enabled in all VPCs
* 3.1 – Ensure a log metric filter and alarm exist for unauthorized API calls
* 3.2 – Ensure a log metric filter and alarm exist for AWS Management Console
sign-in without MFA
* 3.3 – Ensure a log metric filter and alarm exist for usage of "root" account
* 3.4 – Ensure a log metric filter and alarm exist for IAM policy changes
* 3.5 – Ensure a log metric filter and alarm exist for CloudTrail configuration
changes
* 3.6 – Ensure a log metric filter and alarm exist for AWS Management Console
authentication failures
* 3.7 – Ensure a log metric filter and alarm exist for disabling or scheduled
deletion of customer managed keys
* 3.8 – Ensure a log metric filter and alarm exist for S3 bucket policy changes
* 3.9 – Ensure a log metric filter and alarm exist for AWS Config configuration
changes
* 3.10 – Ensure a log metric filter and alarm exist for security group changes
* 3.11 – Ensure a log metric filter and alarm exist for changes to Network
Access Control Lists (NACL)
* 3.12 – Ensure a log metric filter and alarm exist for changes to network
gateways
* 3.13 – Ensure a log metric filter and alarm exist for route table changes
* 3.14 – Ensure a log metric filter and alarm exist for VPC changes
* 4.1 – Ensure no security groups allow ingress from 0.0.0.0/0 to port 22
* 4.2 – Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389
* 4.3 – Ensure the default security group of every VPC restricts all traffic

docs.aws.amazon.com Open in urlscan Pro 54.239.23.208 Public Scan

Form analysis 0 forms found in the DOM

Text Content

docs.aws.amazon.com Open in urlscan Pro
54.239.23.208 Public Scan

Form analysis
0 forms found in the DOM