CIS Amazon Web Services Foundations Benchmark v3.0.0
CIS Amazon Web Services Foundations Benchmark v3.0.0
Services Foundations
Benchmark
v3.0.0 - 01-31-2024
Terms of Use
Please see the below link for our current terms of use:
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/
Page 1
Table of Contents
Terms of Use ................................................................................................................. 1
Table of Contents .......................................................................................................... 2
Overview ........................................................................................................................ 5
Intended Audience................................................................................................................. 5
Consensus Guidance ............................................................................................................ 6
Typographical Conventions .................................................................................................. 7
Recommendation Definitions ....................................................................................... 8
Title ......................................................................................................................................... 8
Assessment Status................................................................................................................ 8
Automated .............................................................................................................................................. 8
Manual ..................................................................................................................................................... 8
Profile ..................................................................................................................................... 8
Description ............................................................................................................................. 8
Rationale Statement .............................................................................................................. 8
Impact Statement ................................................................................................................... 9
Audit Procedure ..................................................................................................................... 9
Remediation Procedure......................................................................................................... 9
Default Value .......................................................................................................................... 9
References ............................................................................................................................. 9
CIS Critical Security Controls® (CIS Controls®) ................................................................... 9
Additional Information........................................................................................................... 9
Profile Definitions .................................................................................................................10
Acknowledgements ..............................................................................................................11
Recommendations ...................................................................................................... 13
1 Identity and Access Management.....................................................................................13
1.1 Maintain current contact details (Manual) ........................................................................... 14
1.2 Ensure security contact information is registered (Manual)................................................ 16
1.3 Ensure security questions are registered in the AWS account (Manual) ........................... 18
1.4 Ensure no 'root' user account access key exists (Automated) ........................................... 20
1.5 Ensure MFA is enabled for the 'root' user account (Automated) ........................................ 22
1.6 Ensure hardware MFA is enabled for the 'root' user account (Manual) ............................. 25
1.7 Eliminate use of the 'root' user for administrative and daily tasks (Manual) ....................... 28
1.8 Ensure IAM password policy requires minimum length of 14 or greater (Automated) ....... 30
1.9 Ensure IAM password policy prevents password reuse (Automated) ................................ 32
1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console
password (Automated) .............................................................................................................. 34
Page 2
1.11 Do not setup access keys during initial user setup for all IAM users that have a console
password (Manual) ................................................................................................................... 37
1.12 Ensure credentials unused for 45 days or greater are disabled (Automated) .................. 40
1.13 Ensure there is only one active access key available for any single IAM user (Automated)
.................................................................................................................................................. 43
1.14 Ensure access keys are rotated every 90 days or less (Automated) ............................... 46
1.15 Ensure IAM Users Receive Permissions Only Through Groups (Automated) ................. 49
1.16 Ensure IAM policies that allow full "*:*" administrative privileges are not attached
(Automated) .............................................................................................................................. 52
1.17 Ensure a support role has been created to manage incidents with AWS Support
(Automated) .............................................................................................................................. 55
1.18 Ensure IAM instance roles are used for AWS resource access from instances
(Automated) .............................................................................................................................. 58
1.19 Ensure that all the expired SSL/TLS certificates stored in AWS IAM are removed
(Automated) .............................................................................................................................. 61
1.20 Ensure that IAM Access analyzer is enabled for all regions (Automated)........................ 64
1.21 Ensure IAM users are managed centrally via identity federation or AWS Organizations for
multi-account environments (Manual) ....................................................................................... 67
1.22 Ensure access to AWSCloudShellFullAccess is restricted (Manual) ............................... 69
2 Storage ...............................................................................................................................71
2.1 Simple Storage Service (S3) ......................................................................................................... 72
2.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests (Automated) ............................. 73
2.1.2 Ensure MFA Delete is enabled on S3 buckets (Manual) ................................................. 77
2.1.3 Ensure all data in Amazon S3 has been discovered, classified and secured when
required. (Manual) ..................................................................................................................... 79
2.1.4 Ensure that S3 Buckets are configured with 'Block public access (bucket settings)'
(Automated) .............................................................................................................................. 82
2.2 Elastic Compute Cloud (EC2) ....................................................................................................... 86
2.2.1 Ensure EBS Volume Encryption is Enabled in all Regions (Automated) ........................ 87
2.3 Relational Database Service (RDS) .............................................................................................. 90
2.3.1 Ensure that encryption-at-rest is enabled for RDS Instances (Automated)..................... 91
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled for RDS Instances (Automated)
.................................................................................................................................................. 95
2.3.3 Ensure that public access is not given to RDS Instance (Automated) ............................ 98
2.4 Elastic File System (EFS) ............................................................................................................ 103
2.4.1 Ensure that encryption is enabled for EFS file systems (Automated) ........................... 104
3 Logging ............................................................................................................................108
3.1 Ensure CloudTrail is enabled in all regions (Automated) ................................................. 109
3.2 Ensure CloudTrail log file validation is enabled (Automated) ........................................... 112
3.3 Ensure AWS Config is enabled in all regions (Automated) .............................................. 114
3.4 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket (Automated) 118
3.5 Ensure CloudTrail logs are encrypted at rest using KMS CMKs (Automated) ................. 122
3.6 Ensure rotation for customer-created symmetric CMKs is enabled (Automated) ............ 126
3.7 Ensure VPC flow logging is enabled in all VPCs (Automated) ......................................... 129
3.8 Ensure that Object-level logging for write events is enabled for S3 bucket (Automated) 133
3.9 Ensure that Object-level logging for read events is enabled for S3 bucket (Automated) . 137
4 Monitoring ........................................................................................................................140
4.1 Ensure unauthorized API calls are monitored (Manual) ................................................... 141
4.2 Ensure management console sign-in without MFA is monitored (Manual) ...................... 145
4.3 Ensure usage of 'root' account is monitored (Manual) ..................................................... 149
4.4 Ensure IAM policy changes are monitored (Manual) ........................................................ 153
4.5 Ensure CloudTrail configuration changes are monitored (Manual) .................................. 157
4.6 Ensure AWS Management Console authentication failures are monitored (Manual) ...... 161
Page 3
4.7 Ensure disabling or scheduled deletion of customer created CMKs is monitored (Manual)
................................................................................................................................................ 165
4.8 Ensure S3 bucket policy changes are monitored (Manual) .............................................. 169
4.9 Ensure AWS Config configuration changes are monitored (Manual) ............................... 173
4.10 Ensure security group changes are monitored (Manual)................................................ 177
4.11 Ensure Network Access Control Lists (NACL) changes are monitored (Manual) .......... 181
4.12 Ensure changes to network gateways are monitored (Manual) ..................................... 185
4.13 Ensure route table changes are monitored (Manual) ..................................................... 189
4.14 Ensure VPC changes are monitored (Manual) ............................................................... 193
4.15 Ensure AWS Organizations changes are monitored (Manual) ....................................... 197
4.16 Ensure AWS Security Hub is enabled (Automated) ....................................................... 201
5 Networking .......................................................................................................................204
5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration
ports (Automated) ................................................................................................................... 205
5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration
ports (Automated) ................................................................................................................... 207
5.3 Ensure no security groups allow ingress from ::/0 to remote server administration ports
(Automated) ............................................................................................................................ 209
5.4 Ensure the default security group of every VPC restricts all traffic (Automated) ............. 211
5.5 Ensure routing tables for VPC peering are "least access" (Manual) ................................ 214
5.6 Ensure that EC2 Metadata Service only allows IMDSv2 (Automated) ............................. 216
Appendix: Summary Table ....................................................................................... 219
Appendix: CIS Controls v7 IG 1 Mapped Recommendations ................................ 224
Appendix: CIS Controls v7 IG 2 Mapped Recommendations ................................ 226
Appendix: CIS Controls v7 IG 3 Mapped Recommendations ................................ 228
Appendix: CIS Controls v7 Unmapped Recommendations ................................... 231
Appendix: CIS Controls v8 IG 1 Mapped Recommendations ................................ 232
Appendix: CIS Controls v8 IG 2 Mapped Recommendations ................................ 234
Appendix: CIS Controls v8 IG 3 Mapped Recommendations ................................ 237
Appendix: CIS Controls v8 Unmapped Recommendations ................................... 240
Appendix: Change History ....................................................................................... 241
Page 4
Overview
All CIS Benchmarks focus on technical configuration settings used to maintain and/or
increase the security of the addressed technology, and they should be used in
conjunction with other essential cyber hygiene tasks like:
• Monitoring the base operating system for vulnerabilities and quickly updating with
the latest security patches
• Monitoring applications and libraries for vulnerabilities and quickly updating with
the latest security patches
In the end, the CIS Benchmarks are designed as a key component of a comprehensive
cybersecurity program.
This document provides prescriptive guidance for configuring security options for a
subset of Amazon Web Services with an emphasis on foundational, testable, and
architecture agnostic settings. Some of the specific Amazon Web Services in scope for
this document include:
Intended Audience
This document is intended for system and application administrators, security
specialists, auditors, help desk, platform deployment, and/or DevOps personnel who
plan to develop, deploy, assess, or secure solutions in Amazon Web Services.
Page 5
Consensus Guidance
This CIS Benchmark was created using a consensus review process comprised of a
global community of subject matter experts. The process combines real world
experience with data-based information to create technology specific guidance to assist
users to secure their environments. Consensus participants provide perspective from a
diverse set of backgrounds including consulting, software development, audit and
compliance, security research, operations, government, and legal.
Each CIS Benchmark undergoes two phases of consensus review. The first phase
occurs during initial Benchmark development. During this phase, subject matter experts
convene to discuss, create, and test working drafts of the Benchmark. This discussion
occurs until consensus has been reached on Benchmark recommendations. The
second phase begins after the Benchmark has been published. During this phase, all
feedback provided by the Internet community is reviewed by the consensus team for
incorporation in the Benchmark. If you are interested in participating in the consensus
process, please visit https://workbench.cisecurity.org/.
Page 6
Typographical Conventions
The following typographical conventions are used throughout this guide:
Convention Meaning
Page 7
Recommendation Definitions
The following defines the various components included in a CIS recommendation as
applicable. If any of the components are not applicable it will be noted or the
component will not be included in the recommendation.
Title
Concise description for the recommendation's intended configuration.
Assessment Status
An assessment status is included for every recommendation. The assessment status
indicates whether the given recommendation can be automated or requires manual
steps to implement. Both statuses are equally important and are determined and
supported as defined below:
Automated
Represents recommendations for which assessment of a technical control can be fully
automated and validated to a pass/fail state. Recommendations will include the
necessary information to implement automation.
Manual
Represents recommendations for which assessment of a technical control cannot be
fully automated and requires all or some manual steps to validate that the configured
state is set as expected. The expected state can vary depending on the environment.
Profile
A collection of recommendations for securing a technology or a supporting platform.
Most benchmarks include at least a Level 1 and Level 2 Profile. Level 2 extends Level 1
recommendations and is not a standalone profile. The Profile Definitions section in the
benchmark provides the definitions as they pertain to the recommendations included for
the technology.
Description
Detailed information pertaining to the setting with which the recommendation is
concerned. In some cases, the description will include the recommended value.
Rationale Statement
Detailed reasoning for the recommendation to provide the user a clear and concise
understanding on the importance of the recommendation.
Page 8
Impact Statement
Any security, functionality, or operational consequences that can result from following
the recommendation.
Audit Procedure
Systematic instructions for determining if the target system complies with the
recommendation.
Remediation Procedure
Systematic instructions for applying recommendations to the target system to bring it
into compliance according to the recommendation.
Default Value
Default value for the given setting in this recommendation, if known. If not known, either
not configured or not defined will be applied.
References
Additional documentation relative to the recommendation.
Additional Information
Supplementary information that does not correspond to any other field but may be
useful to the user.
Page 9
Profile Definitions
The following configuration profiles are defined by this Benchmark:
• Level 1
• Level 2
This profile extends the "Level 1" profile. Items in this profile exhibit one or more
of the following characteristics:
o are intended for environments or use cases where security is more critical
than manageability and usability
o acts as defense in depth measure
o may impact the utility or performance of the technology
o may include additional licensing, cost, or addition of third party software
Page 10
Acknowledgements
This Benchmark exemplifies the great things a community of users, vendors, and
subject matter experts can accomplish through consensus collaboration. The CIS
community thanks the entire consensus team with special recognition to the following
individuals who contributed greatly to the creation of this guide:
Contributor
Amol Pathak
Rob Witoff
John Martinez
Darwin Sanoy
Ionut Dragoi
John Robel
Mike Wicks
Aditi Sahasrabudhe
Parag Patil
Pradeep R B
Jeremy Phillips
Maril Vernon
Paul Campbell
Ankit Rao
Steve Laino
Lawrence Sica
Nick Gibbon
Lewis Hardy
Logan McMillan
Darren Joyce
Rachel Rice
Bhushan Bhat
Sagar Chhatrala
Nirbhay Kumar
Ian McRee
Jason Kao
Cody Bruno
Lawrence Grim
SnowWolf Wagner
Gareth Boyes
Chantel Duckworth
Editor
Iben Rodriguez
Gregory Carpenter
Zan Liffick
Page 11
Page 12
Recommendations
1 Identity and Access Management
This section contains recommendations for configuring identity and access
management related options.
Page 13
1.1 Maintain current contact details (Manual)
Profile Applicability:
• Level 1
Description:
Ensure contact email and telephone details for AWS accounts are current and map to
more than one individual in your organization.
An AWS account supports a number of contact details, and AWS will use these to
contact the account owner if activity judged to be in breach of Acceptable Use Policy or
indicative of likely security compromise is observed by the AWS Abuse team. Contact
details should not be for a single individual, as circumstances may arise where that
individual is unavailable. Email contact details should point to a mail alias which
forwards email to multiple individuals within the organization; where feasible, phone
contact details should point to a PABX hunt group or other call-forwarding system.
Rationale:
If an AWS account is observed to be behaving in a prohibited or suspicious manner,
AWS will attempt to contact the account owner by email and phone using the contact
details listed. If this is unsuccessful and the account behavior needs urgent mitigation,
proactive measures may be taken, including throttling of traffic between the account
exhibiting suspicious behavior and the AWS API endpoints and the Internet. This will
result in impaired service to and from the account in question, so it is in both the
customers' and AWS' best interests that prompt contact can be established. This is best
achieved by setting AWS account contact details to point to resources which have
multiple individuals as recipients, such as email aliases and PABX hunt groups.
Audit:
This activity can only be performed via the AWS Console, with a user who has
permission to read and write Billing information (aws-portal:*Billing )
1. Sign in to the AWS Management Console and open the Billing and Cost
Management console at https://console.aws.amazon.com/billing/home#/.
2. On the navigation bar, choose your account name, and then choose Account.
3. On the Account Settings page, review and verify the current details.
4. Under Contact Information, review and verify the current details.
Remediation:
This activity can only be performed via the AWS Console, with a user who has
permission to read and write Billing information (aws-portal:*Billing ).
Page 14
1. Sign in to the AWS Management Console and open the Billing and Cost
Management console at https://console.aws.amazon.com/billing/home#/.
2. On the navigation bar, choose your account name, and then choose Account.
3. On the Account Settings page, next to Account Settings, choose Edit.
4. Next to the field that you need to update, choose Edit.
5. After you have entered your changes, choose Save changes.
6. After you have made your changes, choose Done.
7. To edit your contact information, under Contact Information, choose Edit.
8. For the fields that you want to change, type your updated information, and then
choose Update.
References:
1. https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-
payment.html#contact-info
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 15
1.2 Ensure security contact information is registered (Manual)
Profile Applicability:
• Level 1
Description:
AWS provides customers with the option of specifying the contact information for
account's security team. It is recommended that this information be provided.
Rationale:
Specifying security-specific contact information will help ensure that security advisories
sent by AWS reach the team in your organization that is best equipped to respond to
them.
Audit:
Perform the following to determine if security contact information is present:
From Console:
1. Click on your account name at the top right corner of the console
2. From the drop-down menu Click My Account
3. Scroll down to the Alternate Contacts section
4. Ensure contact information is specified in the Security section
Remediation:
Perform the following to establish security contact information:
From Console:
1. Click on your account name at the top right corner of the console.
2. From the drop-down menu Click My Account
3. Scroll down to the Alternate Contacts section
4. Enter contact information in the Security section
Page 16
aws account put-alternate-contact --alternate-contact-type SECURITY
Note: Consider specifying an internal email distribution list to ensure emails are
regularly monitored by more than one individual.
References:
1. CCE-79200-2
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 17
1.3 Ensure security questions are registered in the AWS account
(Manual)
Profile Applicability:
• Level 1
Description:
The AWS support portal allows account owners to establish security questions that can
be used to authenticate individuals calling AWS customer service for support. It is
recommended that security questions be established.
Rationale:
When creating a new AWS account, a default super user is automatically created. This
account is referred to as the 'root user' or 'root' account. It is recommended that the use
of this account be limited and highly controlled. During events in which the 'root'
password is no longer accessible or the MFA token associated with 'root' is
lost/destroyed it is possible, through authentication using secret questions and
associated answers, to recover 'root' user login access.
Audit:
From Console:
Remediation:
From Console:
Page 18
• Enter an appropriate answer
o Follow process for all 3 questions
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 19
1.4 Ensure no 'root' user account access key exists (Automated)
Profile Applicability:
• Level 1
Description:
The 'root' user account is the most privileged user in an AWS account. AWS Access
Keys provide programmatic access to a given AWS account. It is recommended that all
access keys associated with the 'root' user account be deleted.
Rationale:
Deleting access keys associated with the 'root' user account limits vectors by which the
account can be compromised. Additionally, deleting the 'root' access keys encourages
the creation and use of role based accounts that are least privileged.
Audit:
Perform the following to determine if the 'root' user account has access keys:
From Console:
1. Sign in to the AWS Management Console as 'root' and open the IAM console at
https://console.aws.amazon.com/iam/.
2. Click on <root_account> at the top right and select My Security Credentials
from the drop down list.
3. On the pop out screen Click on Continue to Security Credentials.
Page 20
4. Click on Access Keys (Access Key ID and Secret Access Key).
5. Under the Status column (if there are any Keys which are active).
6. Click Delete (Note: Deleted keys cannot be recovered).
Note: While a key can be made inactive, this inactive key will still show up in the CLI
command from the audit procedure, and may lead to a key being falsely flagged as
being non-compliant.
References:
1. http://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-
practices.html
2. http://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html
3. http://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountSummary
.html
4. CCE-78910-7
5. https://aws.amazon.com/blogs/security/an-easier-way-to-determine-the-
presence-of-aws-account-access-keys/
Additional Information:
IAM User account "root" for us-gov cloud regions is not enabled by default. However, on
request to AWS support enables 'root' access only through access-keys (CLI, API
methods) for us-gov cloud region.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 21
1.5 Ensure MFA is enabled for the 'root' user account
(Automated)
Profile Applicability:
• Level 1
Description:
The 'root' user account is the most privileged user in an AWS account. Multi-factor
Authentication (MFA) adds an extra layer of protection on top of a username and
password. With MFA enabled, when a user signs in to an AWS website, they will be
prompted for their username and password as well as for an authentication code from
their AWS MFA device.
Note: When virtual MFA is used for 'root' accounts, it is recommended that the device
used is NOT a personal device, but rather a dedicated mobile device (tablet or phone)
that is managed to be kept charged and secured independent of any individual personal
devices. ("non-personal virtual MFA") 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.
Rationale:
Enabling MFA provides increased security for console access as it requires the
authenticating principal to possess a device that emits a time-sensitive key and have
knowledge of a credential.
Audit:
Perform the following to determine if the 'root' user account has MFA setup:
From Console:
Page 22
2. Ensure the AccountMFAEnabled property is set to 1
Remediation:
Perform the following to establish MFA for the 'root' user account:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/iam/.
Note: to manage MFA devices for the 'root' AWS account, you must use your 'root'
account credentials to sign in to AWS. You cannot manage MFA devices for the 'root'
account using other credentials.
2. Choose Dashboard , and under Security Status , expand Activate MFA on your
root account.
3. Choose Activate MFA
4. In the wizard, choose A virtual MFA device and then choose Next Step .
5. IAM generates and displays configuration information for the virtual MFA device,
including a QR code graphic. The graphic is a representation of the 'secret
configuration key' that is available for manual entry on devices that do not
support QR codes.
6. Open your virtual MFA application. (For a list of apps that you can use for hosting
virtual MFA devices, see Virtual MFA Applications.) If the virtual MFA application
supports multiple accounts (multiple virtual MFA devices), choose the option to
create a new account (a new virtual MFA device).
7. Determine whether the MFA app supports QR codes, and then do one of the
following:
o Use the app to scan the QR code. For example, you might choose the
camera icon or choose an option similar to Scan code, and then use the
device's camera to scan the code.
o In the Manage MFA Device wizard, choose Show secret key for manual
configuration, and then type the secret configuration key into your MFA
application.
When you are finished, the virtual MFA device starts generating one-time passwords.
In the Manage MFA Device wizard, in the Authentication Code 1 box, type the one-time
password that currently appears in the virtual MFA device. Wait up to 30 seconds for
the device to generate a new one-time password. Then type the second one-time
password into the Authentication Code 2 box. Choose Assign Virtual MFA.
References:
1. CCE-78911-5
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-
user_manage_mfa
3. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_
virtual.html#enable-virt-mfa-for-root
Page 23
Additional Information:
IAM User account "root" for us-gov cloud regions does not have console access. This
recommendation is not applicable for us-gov cloud regions.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 24
1.6 Ensure hardware MFA is enabled for the 'root' user account
(Manual)
Profile Applicability:
• Level 2
Description:
The 'root' user account is the most privileged user in an AWS account. MFA adds an
extra layer of protection on top of a user name and password. With MFA enabled, when
a user signs in to an AWS website, they will be prompted for their user name and
password as well as for an authentication code from their AWS MFA device. For Level
2, it is recommended that the 'root' user account be protected with a hardware MFA.
Rationale:
A hardware MFA has a smaller attack surface than a virtual MFA. For example, a
hardware MFA does not suffer the attack surface introduced by the mobile smartphone
on which a virtual MFA resides.
Note: Using hardware MFA for many, many AWS accounts may create a logistical
device management issue. If this is the case, consider implementing this Level 2
recommendation selectively to the highest security AWS accounts and the Level 1
recommendation applied to the remaining accounts.
Audit:
Perform the following to determine if the 'root' user account has a hardware MFA setup:
1. Run the following command to determine if the 'root' account has MFA setup:
Page 25
Remediation:
Perform the following to establish a hardware MFA for the 'root' user account:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/iam/.
Note: to manage MFA devices for the AWS 'root' user account, you must use
your 'root' account credentials to sign in to AWS. You cannot manage MFA
devices for the 'root' account using other credentials.
2. Choose Dashboard , and under Security Status , expand Activate MFA on your
root account.
3. Choose Activate MFA
4. In the wizard, choose A hardware MFA device and then choose Next Step .
5. In the Serial Number box, enter the serial number that is found on the back of the
MFA device.
6. In the Authentication Code 1 box, enter the six-digit number displayed by the
MFA device. You might need to press the button on the front of the device to
display the number.
7. Wait 30 seconds while the device refreshes the code, and then enter the next
six-digit number into the Authentication Code 2 box. You might need to press
the button on the front of the device again to display the second number.
8. Choose Next Step . The MFA device is now associated with the AWS account.
The next time you use your AWS account credentials to sign in, you must type a
code from the hardware MFA device.
1. CCE-78911-5
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_
virtual.html
3. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_
physical.html#enable-hw-mfa-for-root
Additional Information:
IAM User account 'root' for us-gov cloud regions does not have console access. This
control is not applicable for us-gov cloud regions.
Page 26
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 27
1.7 Eliminate use of the 'root' user for administrative and daily
tasks (Manual)
Profile Applicability:
• Level 1
Description:
With the creation of an AWS account, a 'root user' is created that cannot be disabled or
deleted. That user has unrestricted access to and control over all resources in the AWS
account. It is highly recommended that the use of this account be avoided for everyday
tasks.
Rationale:
The 'root user' has unrestricted access to and control over all account resources. Use of
it is inconsistent with the principles of least privilege and separation of duties, and can
lead to unnecessary harm due to error or account compromise.
Audit:
From Console:
Page 28
Remediation:
If you find that the 'root' user account is being used for daily activity to include
administrative tasks that do not require the 'root' user:
**Remember, anyone who has 'root' user credentials for your AWS account has
unrestricted access to and control of all the resources in your account, including billing
information.
References:
1. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html
3. https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html
Additional Information:
The 'root' user for us-gov cloud regions is not enabled by default. However, on request
to AWS support, they can enable the 'root' user and grant access only through access-
keys (CLI, API methods) for us-gov cloud region. If the 'root' user for us-gov cloud
regions is enabled, this recommendation is applicable.
Monitoring usage of the 'root' user can be accomplished by implementing
recommendation 3.3 Ensure a log metric filter and alarm exist for usage of the 'root'
user.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 29
1.8 Ensure IAM password policy requires minimum length of 14 or
greater (Automated)
Profile Applicability:
• Level 1
Description:
Password policies are, in part, used to enforce password complexity requirements. IAM
password policies can be used to ensure password are at least a given length. It is
recommended that the password policy require a minimum password length 14.
Rationale:
Setting a password complexity policy increases account resiliency against brute force
login attempts.
Audit:
Perform the following to ensure the password policy is configured as prescribed:
From Console:
Page 30
From Command Line:
aws iam update-account-password-policy --minimum-password-length 14
Note: All commands starting with "aws iam update-account-password-policy" can be
combined into a single command.
References:
1. CCE-78907-3
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_a
ccount-policy.html
3. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-
practices.html#configure-strong-password-policy
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
5 Account Management
v8 Use processes and tools to assign and manage authorization to credentials for
user accounts, including administrator accounts, as well as service accounts, to
enterprise assets and software.
Page 31
1.9 Ensure IAM password policy prevents password reuse
(Automated)
Profile Applicability:
• Level 1
Description:
IAM password policies can prevent the reuse of a given password by the same user. It
is recommended that the password policy prevent the reuse of passwords.
Rationale:
Preventing password reuse increases account resiliency against brute force login
attempts.
Audit:
Perform the following to ensure the password policy is configured as prescribed:
From Console:
Page 32
From Command Line:
aws iam update-account-password-policy --password-reuse-prevention 24
Note: All commands starting with "aws iam update-account-password-policy" can be
combined into a single command.
References:
1. CCE-78908-1
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_a
ccount-policy.html
3. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-
practices.html#configure-strong-password-policy
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 33
1.10 Ensure multi-factor authentication (MFA) is enabled for all
IAM users that have a console password (Automated)
Profile Applicability:
• Level 1
Description:
Multi-Factor Authentication (MFA) adds an extra layer of authentication assurance
beyond traditional credentials. With MFA enabled, when a user signs in to the AWS
Console, they will be prompted for their user name and password as well as for an
authentication code from their physical or virtual MFA token. It is recommended that
MFA be enabled for all accounts that have a console password.
Rationale:
Enabling MFA provides increased security for console access as it requires the
authenticating principal to possess a device that displays a time-sensitive key and have
knowledge of a credential.
Impact:
AWS will soon end support for SMS multi-factor authentication (MFA). New customers
are not allowed to use this feature. We recommend that existing customers switch to
one of the following alternative methods of MFA.
Audit:
Perform the following to determine if a MFA device is enabled for all IAM users having a
console password:
From Console:
1. Run the following command (OSX/Linux/UNIX) to generate a list of all IAM users
along with their password and MFA status:
Page 34
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d |
cut -d, -f1,4,8
2. The output of this command will produce a table similar to the following:
user,password_enabled,mfa_active
elise,false,false
brandon,true,true
rakesh,false,false
helene,false,false
paras,true,true
anitha,false,false
3. For any column having password_enabled set to true , ensure mfa_active is also
set to true.
Remediation:
Perform the following to enable MFA:
From Console:
1. Sign in to the AWS Management Console and open the IAM console at
'https://console.aws.amazon.com/iam/'
2. In the left pane, select Users.
3. In the User Name list, choose the name of the intended MFA user.
4. Choose the Security Credentials tab, and then choose Manage MFA Device.
5. In the Manage MFA Device wizard, choose Virtual MFA device, and then choose
Continue.
IAM generates and displays configuration information for the virtual MFA device,
including a QR code graphic. The graphic is a representation of the 'secret configuration
key' that is available for manual entry on devices that do not support QR codes.
6. Open your virtual MFA application. (For a list of apps that you can use for hosting
virtual MFA devices, see Virtual MFA Applications at
https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications). If the
virtual MFA application supports multiple accounts (multiple virtual MFA devices),
choose the option to create a new account (a new virtual MFA device).
7. Determine whether the MFA app supports QR codes, and then do one of the
following:
• Use the app to scan the QR code. For example, you might choose the camera
icon or choose an option similar to Scan code, and then use the device's camera
to scan the code.
• In the Manage MFA Device wizard, choose Show secret key for manual
configuration, and then type the secret configuration key into your MFA
application.
Page 35
When you are finished, the virtual MFA device starts generating one-time passwords.
8. In the Manage MFA Device wizard, in the MFA Code 1 box, type the one-time
password that currently appears in the virtual MFA device. Wait up to 30 seconds
for the device to generate a new one-time password. Then type the second one-
time password into the MFA Code 2 box.
9. Click Assign MFA.
References:
1. https://tools.ietf.org/html/rfc6238
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html
3. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-
mfa-for-privileged-users
4. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_
virtual.html
5. CCE-78901-6
6. https://blogs.aws.amazon.com/security/post/Tx2SJJYE082KBUK/How-to-
Delegate-Management-of-Multi-Factor-Authentication-to-AWS-IAM-Users
Additional Information:
Forced IAM User Self-Service Remediation
Amazon has published a pattern that forces users to self-service setup MFA before they
have access to their complete permissions set. Until they complete this step, they
cannot access their full permissions. This pattern can be used on new AWS accounts. It
can also be used on existing accounts - it is recommended users are given instructions
and a grace period to accomplish MFA enrollment before active enforcement on existing
AWS accounts.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 36
1.11 Do not setup access keys during initial user setup for all IAM
users that have a console password (Manual)
Profile Applicability:
• Level 1
Description:
AWS console defaults to no check boxes selected when creating a new IAM user.
When creating the IAM User credentials you have to determine what type of access
they require.
Programmatic access: The IAM user might need to make API calls, use the AWS CLI,
or use the Tools for Windows PowerShell. In that case, create an access key (access
key ID and a secret access key) for that user.
AWS Management Console access: If the user needs to access the AWS Management
Console, create a password for the user.
Rationale:
Requiring the additional steps be taken by the user for programmatic access after their
profile has been created will give a stronger indication of intent that access keys are [a]
necessary for their work and [b] once the access key is established on an account that
the keys may be in use somewhere in the organization.
Note: Even if it is known the user will need access keys, require them to create the keys
themselves or put in a support ticket to have them created as a separate step from user
creation.
Audit:
Perform the following to determine if access keys were created upon user creation and
are being used and rotated as prescribed:
From Console:
• Keys that were created at the same time as the user profile and do not have a
last used date should be deleted. Refer to the remediation below.
Page 37
From Command Line:
1. Run the following command (OSX/Linux/UNIX) to generate a list of all IAM users
along with their access keys utilization:
2. The output of this command will produce a table similar to the following:
user,password_enabled,access_key_1_active,access_key_1_last_used_date,access_
key_2_active,access_key_2_last_used_date
elise,false,true,2015-04-16T15:14:00+00:00,false,N/A
brandon,true,true,N/A,false,N/A
rakesh,false,false,N/A,false,N/A
helene,false,true,2015-11-18T17:47:00+00:00,false,N/A
paras,true,true,2016-08-28T12:04:00+00:00,true,2016-03-04T10:11:00+00:00
anitha,true,true,2016-06-08T11:43:00+00:00,true,N/A
Remediation:
Perform the following to delete access keys that do not pass the audit:
From Console:
• Click on the X (Delete) for keys that were created at the same time as the user
profile but have not been used.
7. As an IAM User
• Click on the X (Delete) for keys that were created at the same time as the user
profile but have not been used.
Page 38
References:
1. https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html
Additional Information:
Credential report does not appear to contain "Key Creation Date"
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 39
1.12 Ensure credentials unused for 45 days or greater are
disabled (Automated)
Profile Applicability:
• Level 1
Description:
AWS IAM users can access AWS resources using different types of credentials, such
as passwords or access keys. It is recommended that all credentials that have been
unused in 45 or greater days be deactivated or removed.
Rationale:
Disabling or removing unnecessary credentials will reduce the window of opportunity for
credentials associated with a compromised or abandoned account to be used.
Audit:
Perform the following to determine if unused credentials exist:
From Console:
9. Check and ensure that Access key age is less than 45 days and that Access key
last used does not say None
If the user hasn't signed into the Console in the last 45 days or Access keys are over 45
days old refer to the remediation.
From Command Line:
Download Credential Report:
Page 40
aws iam generate-credential-report
Remediation:
From Console:
Perform the following to manage Unused Password (IAM user console access)
Page 41
• Click on Make Inactive
7. Select any access keys that are over 45 days old and that have not been used
and
References:
1. CCE-78900-8
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-
credentials
3. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-
unused.html
4. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_a
dmin-change-user.html
5. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-
keys.html
Additional Information:
<root_account> is excluded in the audit since the root account should not be used for
day to day business and would likely be unused for more than 45 days.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 42
1.13 Ensure there is only one active access key available for any
single IAM user (Automated)
Profile Applicability:
• Level 1
Description:
Access keys are long-term credentials for an IAM user or the AWS account 'root' user.
You can use access keys to sign programmatic requests to the AWS CLI or AWS API
(directly or using the AWS SDK)
Rationale:
Access keys are long-term credentials for an IAM user or the AWS account 'root' user.
You can use access keys to sign programmatic requests to the AWS CLI or AWS API.
One of the best ways to protect your account is to not allow users to have multiple
access keys.
Audit:
From Console:
• Repeat steps no. 3 – 5 for each IAM user in your AWS account.
1. Run list-users command to list all IAM users within your account:
2. Run list-access-keys command using the IAM user name list to return the
current status of each access key associated with the selected IAM user:
Page 43
aws iam list-access-keys --user-name <user-name>
3. Check the Status property value for each key returned to determine each keys
current state. If the Status property value for more than one IAM access key is
set to Active, the user access configuration does not adhere to this
recommendation, refer to the remediation below.
• Repeat steps no. 2 and 3 for each IAM user in your AWS account.
Remediation:
From Console:
1. Using the IAM user and access key information provided in the Audit CLI,
choose one access key that is less than 90 days old. This should be the only
active key used by this IAM user to access AWS resources programmatically.
Test your application(s) to make sure that the chosen access key is working.
2. Run the update-access-key command below using the IAM user name and the
non-operational access key IDs to deactivate the unnecessary key(s). Refer to
the Audit section to identify the unnecessary access key ID for the selected IAM
user
Page 44
Note - the command does not return any output:
aws iam update-access-key --access-key-id <access-key-id> --status Inactive -
-user-name <user-name>
3. To confirm that the selected access key pair has been successfully deactivated
run the list-access-keys audit command again for that IAM User:
• The command output should expose the metadata for each access key
associated with the IAM user. If the non-operational key pair(s) Status is set to
Inactive, the key has been successfully deactivated and the IAM user access
configuration adheres now to this recommendation.
4. Repeat steps no. 1 – 3 for each IAM user in your AWS account.
References:
1. https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-
practices.html
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-
keys.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
5 Account Management
v8 Use processes and tools to assign and manage authorization to credentials for
user accounts, including administrator accounts, as well as service accounts, to
enterprise assets and software.
Page 45
1.14 Ensure access keys are rotated every 90 days or less
(Automated)
Profile Applicability:
• Level 1
Description:
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. It is recommended that all access keys be regularly rotated.
Rationale:
Rotating access keys will reduce the window of opportunity for an access key that is
associated with a compromised or terminated account to be used.
Access keys should be rotated to ensure that data cannot be accessed with an old key
which might have been lost, cracked, or stolen.
Audit:
Perform the following to determine if access keys are rotated as prescribed:
From Console:
Page 46
From Console:
1. While the first access key is still active, create a second access key, which is
active by default. Run the following command:
2. Update all applications and tools to use the new access key.
3. Determine whether the first access key is still in use by using this command:
4. One approach is to wait several days and then check the old access key for any
use before proceeding.
Even if step Step 3 indicates no use of the old key, it is recommended that you do not
immediately delete the first access key. Instead, change the state of the first access key
to Inactive using this command:
aws iam update-access-key
5. Use only the new access key to confirm that your applications are working. Any
applications and tools that still use the original access key will stop working at
this point because they no longer have access to AWS resources. If you find
such an application or tool, you can switch its state back to Active to reenable the
first access key. Then return to step Step 2 and update this application to use the
new key.
6. After you wait some period of time to ensure that all applications and tools have
been updated, you can delete the first access key with this command:
Page 47
aws iam delete-access-key
References:
1. CCE-78902-4
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-
credentials
3. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-
unused.html
4. https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html
5. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-
keys.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
5 Account Management
v8 Use processes and tools to assign and manage authorization to credentials for
user accounts, including administrator accounts, as well as service accounts, to
enterprise assets and software.
Page 48
1.15 Ensure IAM Users Receive Permissions Only Through
Groups (Automated)
Profile Applicability:
• Level 1
Description:
IAM users are granted access to services, functions, and data through IAM policies.
There are four ways to define policies for a user: 1) Edit the user policy directly, aka an
inline, or user, policy; 2) attach a policy directly to a user; 3) add the user to an IAM
group that has an attached policy; 4) add the user to an IAM group that has an inline
policy.
Only the third implementation is recommended.
Rationale:
Assigning IAM policy only through groups unifies permissions management to a single,
flexible layer consistent with organizational functional roles. By unifying permissions
management, the likelihood of excessive permissions is reduced.
Audit:
Perform the following to determine if an inline policy is set or a policy is directly attached
to users:
2. For each user returned, run the following command to determine if any policies
are attached to them:
3. If any policies are returned, the user has an inline policy or direct policy
attachment.
Remediation:
Perform the following to create an IAM group and assign a policy to it:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/iam/.
2. In the navigation pane, click Groups and then click Create New Group .
Page 49
3. In the Group Name box, type the name of the group and then click Next Step .
4. In the list of policies, select the check box for each policy that you want to apply
to all members of the group. Then click Next Step .
5. Click Create Group
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/iam/.
2. In the navigation pane, click Groups
3. Select the group to add a user to
4. Click Add Users To Group
5. Select the users to be added to the group
6. Click Add Users
Perform the following to remove a direct association between a user and policy:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/iam/.
2. In the left navigation pane, click on Users
3. For each user:
o Select the user
o Click on the Permissions tab
o Expand Permissions policies
o Click X for each policy; then click Detach or Remove (depending on policy
type)
References:
1. http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
2. http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-
vs-inline.html
3. CCE-78912-3
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 50
Controls
Control IG 1 IG 2 IG 3
Version
Page 51
1.16 Ensure IAM policies that allow full "*:*" administrative
privileges are not attached (Automated)
Profile Applicability:
• Level 1
Description:
IAM policies are the means by which privileges are granted to users, groups, or roles. It
is recommended and considered a standard security advice to grant least privilege -that
is, granting only the permissions required to perform a task. Determine what users need
to do and then craft policies for them that let the users perform only those tasks, instead
of allowing full administrative privileges.
Rationale:
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.
IAM policies that have a statement with "Effect": "Allow" with "Action": "*" over
"Resource": "*" should be removed.
Audit:
Perform the following to determine what policies are created:
From Command Line:
2. For each policy returned, run the following command to determine if any policies
is allowing full administrative privileges on the account:
3. In output ensure policy should not have any Statement block with "Effect":
"Allow" and Action set to "*" and Resource set to "*"
Page 52
Remediation:
From Console:
Perform the following to detach the policy that has full administrative privileges:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/iam/.
2. In the navigation pane, click Policies and then search for the policy name found
in the audit step.
3. Select the policy that needs to be deleted.
4. In the policy action menu, select first Detach
5. Select all Users, Groups, Roles that have this policy attached
6. Click Detach Policy
7. In the policy action menu, select Detach
8. Select the newly detached policy and select Delete
1. Lists all IAM users, groups, and roles that the specified managed policy is
attached to.
References:
1. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-
vs-inline.html
3. CCE-78912-3
4. https://docs.aws.amazon.com/cli/latest/reference/iam/index.html#cli-aws-iam
Page 53
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 54
1.17 Ensure a support role has been created to manage incidents
with AWS Support (Automated)
Profile Applicability:
• Level 1
Description:
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, with the
appropriate policy assigned, to allow authorized users to manage incidents with AWS
Support.
Rationale:
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.
Impact:
All AWS Support plans include an unlimited number of account and billing support
cases, with no long-term contracts. Support billing calculations are performed on a per-
account basis for all plans. Enterprise Support plan customers have the option to
include multiple enabled accounts in an aggregated monthly billing calculation. Monthly
charges for the Business and Enterprise support plans are based on each month's AWS
usage charges, subject to a monthly minimum, billed in advance.
When assigning rights, keep in mind that other policies may grant access to Support as
well. This may include AdministratorAccess and other policies including customer
managed policies. Utilizing the AWS managed 'AWSSupportAccess' role is one simple
way of ensuring that this permission is properly granted.
To better support the principle of separation of duties, it would be best to only attach this
role where necessary.
Audit:
From Command Line:
1. List IAM policies, filter for the 'AWSSupportAccess' managed policy, and note the
"Arn" element value:
Page 55
aws iam list-entities-for-policy --policy-arn
arn:aws:iam::aws:policy/AWSSupportAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "<iam_user>"
},
"Action": "sts:AssumeRole"
}
]
}
References:
1. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-
vs-inline.html
2. https://aws.amazon.com/premiumsupport/pricing/
3. https://docs.aws.amazon.com/cli/latest/reference/iam/list-policies.html
4. https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html
5. https://docs.aws.amazon.com/cli/latest/reference/iam/list-entities-for-policy.html
Page 56
Additional Information:
AWSSupportAccess policy is a global AWS resource. It has same ARN as
arn:aws:iam::aws:policy/AWSSupportAccess for every account.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 57
1.18 Ensure IAM instance roles are used for AWS resource
access from instances (Automated)
Profile Applicability:
• Level 2
Description:
AWS access from within AWS instances can be done by either encoding AWS keys into
AWS API calls or by assigning the instance to a role which has an appropriate
permissions policy for the required access. "AWS Access" means accessing the APIs of
AWS in order to access AWS resources or manage AWS account resources.
Rationale:
AWS IAM roles reduce the risks associated with sharing and rotating credentials that
can be used outside of AWS itself. If credentials are compromised, they can be used
from outside of the AWS account they give access to. In contrast, in order to leverage
role permissions an attacker would need to gain and maintain access to a specific
instance to use the privileges associated with it.
Additionally, if credentials are encoded into compiled applications or other hard to
change mechanisms, then they are even more unlikely to be properly rotated due to
service disruption risks. As time goes on, credentials that cannot be rotated are more
likely to be known by an increasing number of individuals who no longer work for the
organization owning the credentials.
Audit:
From Console:
• If the value for Instance profile arn is an instance profile ARN, then an instance
profile (that contains an IAM role) is attached.
• If the value for IAM Role is blank, no role is attached.
• If the value for IAM Role contains a role
• If the value for IAM Role is "No roles attached to instance profile: <Instance-
Profile-Name>", then an instance profile is attached to the instance, but it does
not contain an IAM role.
Page 58
7. Repeat steps 3 to 6 for each EC2 instance in your AWS account.
1. Run the describe-instances command to list all EC2 instance IDs, available in
the selected AWS region. The command output will return each instance ID:
2. Run the describe-instances command again for each EC2 instance using the
IamInstanceProfile identifier in the query filter to check if an IAM role is
attached:
3. If an IAM role is attached, the command output will show the IAM instance profile
ARN and ID.
4. Repeat steps 1 to 3 for each EC2 instance in your AWS account.
Remediation:
From Console:
1. Run the describe-instances command to list all EC2 instance IDs, available in
the selected AWS region:
Page 59
2. Run the associate-iam-instance-profile command to attach an instance profile
(which is attached to an IAM role) to the EC2 instance:
3. Run the describe-instances command again for the recently modified EC2
instance. The command output should return the instance profile ARN and ID:
4. Repeat steps 1 to 3 for each EC2 instance in your AWS account that requires an
IAM role to be attached.
References:
1. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-
ec2.html
2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-
ec2.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 60
1.19 Ensure that all the expired SSL/TLS certificates stored in
AWS IAM are removed (Automated)
Profile Applicability:
• Level 1
Description:
To enable HTTPS connections to your website or application in AWS, you need an
SSL/TLS server certificate. You can use ACM or IAM to store and deploy server
certificates. Use IAM as a certificate manager only when you must support HTTPS
connections in a region that is not supported by ACM. IAM securely encrypts your
private keys and stores the encrypted version in IAM SSL certificate storage. IAM
supports deploying server certificates in all regions, but you must obtain your certificate
from an external provider for use with AWS. You cannot upload an ACM certificate to
IAM. Additionally, you cannot manage your certificates from the IAM Console.
Rationale:
Removing expired SSL/TLS certificates eliminates the risk that an invalid certificate will
be deployed accidentally to a resource such as AWS Elastic Load Balancer (ELB),
which can damage the credibility of the application/website behind the ELB. As a best
practice, it is recommended to delete expired certificates.
Impact:
Deleting the certificate could have implications for your application if you are using an
expired server certificate with Elastic Load Balancing, CloudFront, etc. One has to make
configurations at respective services to ensure there is no interruption in application
functionality.
Audit:
From Console:
Getting the certificates expiration information via AWS Management Console is not
currently supported.
To request information about the SSL/TLS certificates stored in IAM via the AWS API
use the Command Line Interface (CLI).
From Command Line:
Run list-server-certificates command to list all the IAM-stored server certificates:
aws iam list-server-certificates
Page 61
The command output should return an array that contains all the SSL/TLS certificates
currently stored in IAM and their metadata (name, ID, expiration date, etc):
{
"ServerCertificateMetadataList": [
{
"ServerCertificateId": "EHDGFRW7EJFYTE88D",
"ServerCertificateName": "MyServerCertificate",
"Expiration": "2018-07-10T23:59:59Z",
"Path": "/",
"Arn": "arn:aws:iam::012345678910:server-
certificate/MySSLCertificate",
"UploadDate": "2018-06-10T11:56:08Z"
}
]
}
Verify the ServerCertificateName and Expiration parameter value (expiration date) for
each SSL/TLS certificate returned by the list-server-certificates command and
determine if there are any expired server certificates currently stored in AWS IAM. If so,
use the AWS API to remove them.
If this command returns:
{ { "ServerCertificateMetadataList": [] }
This means that there are no expired certificates, It DOES NOT mean that no
certificates exist.
Remediation:
From Console:
Removing expired certificates via AWS Management Console is not currently
supported. To delete SSL/TLS certificates stored in IAM via the AWS API use the
Command Line Interface (CLI).
From Command Line:
To delete Expired Certificate run following command by replacing
<CERTIFICATE_NAME> with the name of the certificate to delete:
aws iam delete-server-certificate --server-certificate-name
<CERTIFICATE_NAME>
When the preceding command is successful, it does not return any output.
Default Value:
By default, expired certificates won't get deleted.
References:
1. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-
certs.html
2. https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-
certificate.html
Page 62
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
v7 13 Data Protection
Data Protection
Page 63
1.20 Ensure that IAM Access analyzer is enabled for all regions
(Automated)
Profile Applicability:
• Level 1
Description:
Enable IAM Access analyzer for IAM policies about all resources in each active AWS
region.
IAM Access Analyzer is a technology introduced at AWS reinvent 2019. After the
Analyzer is enabled in IAM, scan results are displayed on the console showing the
accessible resources. Scans show resources that other accounts and federated users
can access, such as KMS keys and IAM roles. So the results allow you to determine if
an unintended user is allowed, making it easier for administrators to monitor least
privileges access. Access Analyzer analyzes only policies that are applied to resources
in the same AWS Region.
Rationale:
AWS IAM Access Analyzer helps you identify the resources in your organization and
accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external
entity. This lets you identify unintended access to your resources and data. Access
Analyzer identifies resources that are shared with external principals by using logic-
based reasoning to analyze the resource-based policies in your AWS environment. IAM
Access Analyzer continuously monitors all policies for S3 bucket, IAM roles, KMS (Key
Management Service) keys, AWS Lambda functions, and Amazon SQS(Simple Queue
Service) queues.
Audit:
From Console:
Page 64
2. Ensure that at least one Analyzer the status is set to ACTIVE
3. Repeat the steps above for each active region.
If an Access analyzer is not listed for each region or the status is not set to active refer
to the remediation procedure below.
Remediation:
From Console:
Perform the following to enable IAM Access analyzer for IAM policies:
1. https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-
analyzer.html
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-
started.html
3. https://docs.aws.amazon.com/cli/latest/reference/accessanalyzer/get-
analyzer.html
4. https://docs.aws.amazon.com/cli/latest/reference/accessanalyzer/create-
analyzer.html
Page 65
Additional Information:
Some regions in AWS are enabled by default and some are disabled by default.
Regions introduced prior to March 20, 2019 are enabled by default and cannot be
disabled. Regions introduced after can be disabled by default. For more information on
managing AWS Regions, please see AWS's documentation on managing AWS
Regions.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 66
1.21 Ensure IAM users are managed centrally via identity
federation or AWS Organizations for multi-account environments
(Manual)
Profile Applicability:
• Level 2
Description:
In multi-account environments, IAM user centralization facilitates greater user control.
User access beyond the initial account is then provided via role assumption.
Centralization of users can be accomplished through federation with an external identity
provider or through the use of AWS Organizations.
Rationale:
Centralizing IAM user management to a single identity store reduces complexity and
thus the likelihood of access management errors.
Audit:
For multi-account AWS environments with an external identity provider:
1. Determine the master account for identity federation or IAM user management
2. Login to that account through the AWS Management Console
3. Click Services
4. Click IAM
5. Click Identity providers
6. Verify the configuration
Then, determine all accounts that should not have local users present. For each
account:
1. Determine all accounts that should not have local users present
2. Log into the AWS Management Console
3. Switch role into each identified account
4. Click Services
5. Click IAM
6. Click Users
7. Confirm that no IAM users representing individuals are present
1. Determine all accounts that should not have local users present
2. Log into the AWS Management Console
Page 67
3. Switch role into each identified account
4. Click Services
5. Click IAM
6. Click Users
7. Confirm that no IAM users representing individuals are present
Remediation:
The remediation procedure will vary based on the individual organization's
implementation of identity federation and/or AWS Organizations with the acceptance
criteria that no non-service IAM users, and non-root accounts, are present outside the
account providing centralized IAM user management.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 68
1.22 Ensure access to AWSCloudShellFullAccess is restricted
(Manual)
Profile Applicability:
• Level 1
Description:
AWS CloudShell is a convenient way of running CLI commands against AWS services;
a managed IAM policy ('AWSCloudShellFullAccess') provides full access to CloudShell,
which allows file upload and download capability between a user's local system and the
CloudShell environment. Within the CloudShell environment a user has sudo
permissions, and can access the internet. So it is feasible to install file transfer software
(for example) and move data from CloudShell to external internet servers.
Rationale:
Access to this policy should be restricted as it presents a potential channel for data
exfiltration by malicious cloud admins that are given full permissions to the service.
AWS documentation describes how to create a more restrictive IAM policy which denies
file transfer permissions.
Audit:
From Console
1. List IAM policies, filter for the 'AWSCloudShellFullAccess' managed policy, and
note the "Arn" element value:
Page 69
If it does not return empty refer to the remediation below.
Note: Keep in mind that other policies may grant access.
Remediation:
From Console
References:
1. https://docs.aws.amazon.com/cloudshell/latest/userguide/sec-auth-with-
identities.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 70
2 Storage
This section contains recommendations for configuring AWS Storage.
Page 71
2.1 Simple Storage Service (S3)
This section contains recommendations for configuring AWS Simple Storage Service
(S3) Buckets
Page 72
2.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests
(Automated)
Profile Applicability:
• Level 2
Description:
At the Amazon S3 bucket level, you can configure permissions through a bucket policy
making the objects accessible only through HTTPS.
Rationale:
By default, Amazon S3 allows both HTTP and HTTPS requests. To achieve only
allowing access to Amazon S3 objects through HTTPS you also have to explicitly deny
access to HTTP requests. Bucket policies that allow HTTPS requests without explicitly
denying HTTP requests will not comply with this recommendation.
Audit:
To allow access to HTTPS you can use a condition that checks for the key
"aws:SecureTransport: true". This means that the request is sent through HTTPS but
that HTTP can still be used. So to make sure you do not allow HTTP access confirm
that there is a bucket policy that explicitly denies access for HTTP requests and that it
contains the key "aws:SecureTransport": "false".
From Console:
1. Login to AWS Management Console and open the Amazon S3 console using
https://console.aws.amazon.com/s3/
2. Select the Check box next to the Bucket.
3. Click on 'Permissions', then Click on Bucket Policy.
4. Ensure that a policy is listed that matches:
'{
"Sid": <optional>,
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::<bucket_name>/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}'
<optional> and <bucket_name> will be specific to your account
Page 73
From Command Line:
aws s3 ls
Remediation:
From Console:
1. Login to AWS Management Console and open the Amazon S3 console using
https://console.aws.amazon.com/s3/
2. Select the Check box next to the Bucket.
3. Click on 'Permissions'.
4. Click 'Bucket Policy'
5. Add this to the existing policy filling in the required information
{
"Sid": <optional>",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::<bucket_name>/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
6. Save
7. Repeat for all the buckets in your AWS account that contain sensitive data.
From Console
using AWS Policy Generator:
Page 74
3. Select Policy Type
S3 Bucket Policy
4. Add Statements
•
Effect = Deny
•
Principal =*
•
AWS Service = Amazon S3
•
Actions =*
•
Amazon Resource Name = <ARN of the S3 Bucket>
5. Generate Policy
6. Copy the text and add it to the Bucket Policy.
{
"Sid": <optional>",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::<bucket_name>/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
Default Value:
Both HTTP and HTTPS Request are allowed
Page 75
References:
1. https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-policy-for-
config-rule/
2. https://aws.amazon.com/blogs/security/how-to-use-bucket-policies-and-apply-
defense-in-depth-to-help-secure-your-amazon-s3-data/
3. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/get-
bucket-policy.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 76
2.1.2 Ensure MFA Delete is enabled on S3 buckets (Manual)
Profile Applicability:
• Level 2
Description:
Once MFA Delete is enabled on your sensitive and classified S3 bucket it requires the
user to have two forms of authentication.
Rationale:
Adding MFA delete to an S3 bucket, requires additional authentication when you
change the version state of your bucket or you delete and object version adding another
layer of security in the event your security credentials are compromised or unauthorized
access is granted.
Impact:
Enabling MFA delete on an S3 bucket could required additional administrator oversight.
Enabling MFA delete may impact other services that automate the creation and/or
deletion of S3 buckets.
Audit:
Perform the steps below to confirm MFA delete is configured on an S3 Bucket
From Console:
Page 77
Remediation:
Perform the steps below to enable MFA delete on an S3 bucket.
Note:
-You cannot enable MFA Delete using the AWS Management Console. You must use
the AWS CLI or API.
-You must use your 'root' account to enable MFA Delete on S3 buckets.
From Command line:
References:
1. https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html#MultiFactor
AuthenticationDelete
2. https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMFADelete.html
3. https://aws.amazon.com/blogs/security/securing-access-to-aws-using-mfa-part-3/
4. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_lost-or-
broken.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 78
2.1.3 Ensure all data in Amazon S3 has been discovered,
classified and secured when required. (Manual)
Profile Applicability:
• Level 2
Description:
Amazon S3 buckets can contain sensitive data, that for security purposes should be
discovered, monitored, classified and protected. Macie along with other 3rd party tools
can automatically provide an inventory of Amazon S3 buckets.
Rationale:
Using a Cloud service or 3rd Party software to continuously monitor and automate the
process of data discovery and classification for S3 buckets using machine learning and
pattern matching is a strong defense in protecting that information.
Amazon Macie is a fully managed data security and data privacy service that uses
machine learning and pattern matching to discover and protect your sensitive data in
AWS.
Impact:
There is a cost associated with using Amazon Macie. There is also typically a cost
associated with 3rd Party tools that perform similar processes and protection.
Audit:
Perform the following steps to determine if Macie is running:
From Console:
1. Login to the Macie console at https://console.aws.amazon.com/macie/
Page 79
3. Click Enable Macie.
1. In the left pane, click S3 buckets. Macie displays a list of all the S3 buckets for
your account.
2. Select the check box for each bucket that you want Macie to analyze as part of
the job
3. Click Create job.
4. Click Quick create.
5. For the Name and description step, enter a name and, optionally, a description of
the job.
6. Then click Next.
7. For the Review and create step, click Submit.
If you are using a 3rd Party tool to manage and protect your s3 data, follow the Vendor
documentation for implementing and configuring that tool.
References:
1. https://aws.amazon.com/macie/getting-started/
2. https://docs.aws.amazon.com/workspaces/latest/adminguide/data-protection.html
3. https://docs.aws.amazon.com/macie/latest/user/data-classification.html
Page 80
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 81
2.1.4 Ensure that S3 Buckets are configured with 'Block public
access (bucket settings)' (Automated)
Profile Applicability:
• Level 1
Description:
Amazon S3 provides Block public access (bucket settings) and Block public
access (account settings) to help you manage public access to Amazon S3
resources. By default, S3 buckets and objects are created with public access disabled.
However, an IAM principal with sufficient S3 permissions can enable public access at
the bucket and/or object level. While enabled, Block public access (bucket settings)
prevents an individual bucket, and its contained objects, from becoming publicly
accessible. Similarly, Block public access (account settings) prevents all buckets,
and contained objects, from becoming publicly accessible across the entire account.
Rationale:
Amazon S3 Block public access (bucket settings) prevents the accidental or
malicious public exposure of data contained within the respective bucket(s).
Amazon S3 Block public access (account settings) prevents the accidental or
malicious public exposure of data contained within all buckets of the respective AWS
account.
Whether blocking public access to all or some buckets is an organizational decision that
should be based on data sensitivity, least privilege, and use case.
Impact:
When you apply Block Public Access settings to an account, the settings apply to all
AWS Regions globally. The settings might not take effect in all Regions immediately or
simultaneously, but they eventually propagate to all Regions.
Audit:
If utilizing Block Public Access (bucket settings)
From Console:
1. Login to AWS Management Console and open the Amazon S3 console using
https://console.aws.amazon.com/s3/
2. Select the Check box next to the Bucket.
3. Click on 'Edit public access settings'.
4. Ensure that block public access settings are set appropriately for this bucket
5. Repeat for all the buckets in your AWS account.
Page 82
From Command Line:
aws s3 ls
1. Login to AWS Management Console and open the Amazon S3 console using
https://console.aws.amazon.com/s3/
2. Choose Block public access (account settings)
3. Ensure that block public access settings are set appropriately for your AWS
account.
Page 83
Remediation:
If utilizing Block Public Access (bucket settings)
From Console:
1. Login to AWS Management Console and open the Amazon S3 console using
https://console.aws.amazon.com/s3/
2. Select the Check box next to the Bucket.
3. Click on 'Edit public access settings'.
4. Click 'Block all public access'
5. Repeat for all the buckets in your AWS account that contain sensitive data.
aws s3 ls
1. Login to AWS Management Console and open the Amazon S3 console using
https://console.aws.amazon.com/s3/
2. Choose Block Public Access (account settings)
3. Choose Edit to change the block public access settings for all the buckets in
your AWS account
4. Choose the settings you want to change, and then choose Save. For details
about each setting, pause on the i icons.
5. When you're asked for confirmation, enter confirm. Then Click Confirm to save
your changes.
Page 84
aws s3control put-public-access-block
--public-access-block-configuration BlockPublicAcls=true,
IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true
--account-id <value>
References:
1. https://docs.aws.amazon.com/AmazonS3/latest/user-guide/block-public-access-
account.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 85
2.2 Elastic Compute Cloud (EC2)
This section contains recommendations for configuring AWS Elastic Compute Cloud
(EC2)
Page 86
2.2.1 Ensure EBS Volume Encryption is Enabled in all Regions
(Automated)
Profile Applicability:
• Level 1
Description:
Elastic Compute Cloud (EC2) supports encryption at rest when using the Elastic Block
Store (EBS) service. While disabled by default, forcing encryption at EBS volume
creation is supported.
Rationale:
Encrypting data at rest reduces the likelihood that it is unintentionally exposed and can
nullify the impact of disclosure if the encryption remains unbroken.
Impact:
Losing access or removing the KMS key in use by the EBS volumes will result in no
longer being able to access the volumes.
Audit:
From Console:
1. Login to AWS Management Console and open the Amazon EC2 console using
https://console.aws.amazon.com/ec2/
2. Under Account attributes, click EBS encryption.
3. Verify Always encrypt new EBS volumes displays Enabled.
4. Review every region in-use.
1. Run
Page 87
Remediation:
From Console:
1. Login to AWS Management Console and open the Amazon EC2 console using
https://console.aws.amazon.com/ec2/
2. Under Account attributes, click EBS encryption.
3. Click Manage.
4. Click the Enable checkbox.
5. Click Update EBS encryption
6. Repeat for every region requiring the change.
1. Run
1. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html
2. https://aws.amazon.com/blogs/aws/new-opt-in-to-default-encryption-for-new-ebs-
volumes/
Additional Information:
Default EBS volume encryption only applies to newly created EBS volumes. Existing
EBS volumes are not converted automatically.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 88
Controls
Control IG 1 IG 2 IG 3
Version
Page 89
2.3 Relational Database Service (RDS)
Page 90
2.3.1 Ensure that encryption-at-rest is enabled for RDS Instances
(Automated)
Profile Applicability:
• Level 1
Description:
Amazon RDS encrypted DB instances use the industry standard AES-256 encryption
algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances.
After your data is encrypted, Amazon RDS handles authentication of access and
decryption of your data transparently with a minimal impact on performance.
Rationale:
Databases are likely to hold sensitive and critical data, it is highly recommended to
implement encryption in order to protect your data from unauthorized access or
disclosure. With RDS encryption enabled, the data stored on the instance's underlying
storage, the automated backups, read replicas, and snapshots, are all encrypted.
Audit:
From Console:
1. Login to the AWS Management Console and open the RDS dashboard at
https://console.aws.amazon.com/rds/
2. In the navigation pane, under RDS dashboard, click Databases.
3. Select the RDS Instance that you want to examine
4. Click Instance Name to see details, then click on Configuration tab.
5. Under Configuration Details section, In Storage pane search for the Encryption
Enabled Status.
6. If the current status is set to Disabled, Encryption is not enabled for the selected
RDS Instance database instance.
7. Repeat steps 3 to 7 to verify encryption status of other RDS Instance in same
region.
8. Change region from the top of the navigation bar and repeat audit for other
regions.
Page 91
aws rds describe-db-instances --region <region-name> --query
'DBInstances[*].DBInstanceIdentifier'
Remediation:
From Console:
1. Login to the AWS Management Console and open the RDS dashboard at
https://console.aws.amazon.com/rds/.
2. In the left navigation panel, click on Databases
3. Select the Database instance that needs to be encrypted.
4. Click on Actions button placed at the top right and select Take Snapshot.
5. On the Take Snapshot page, enter a database name of which you want to take a
snapshot in the Snapshot Name field and click on Take Snapshot.
6. Select the newly created snapshot and click on the Action button placed at the
top right and select Copy snapshot from the Action menu.
7. On the Make Copy of DB Snapshot page, perform the following:
• In the New DB Snapshot Identifier field, Enter a name for the new snapshot.
• Check Copy Tags, New snapshot must have the same tags as the source
snapshot.
• Select Yes from the Enable Encryption dropdown list to enable encryption, You
can choose to use the AWS default encryption key or custom key from Master
Key dropdown list.
Page 92
12. As the new instance provisioning process is completed can update application
configuration to refer to the endpoint of the new Encrypted database instance
Once the database endpoint is changed at the application level, can remove the
unencrypted instance.
3. Now run list-aliases command to list the KMS keys aliases available in a
specified region, The command output should return each key alias currently
available. For our RDS encryption activation process, locate the ID of the AWS
default KMS key.
4. Run copy-db-snapshot command using the default KMS key ID for RDS
instances returned earlier to create an encrypted copy of the database instance
snapshot, The command output will return the encrypted instance snapshot
configuration.
Page 93
6. Run describe-db-instances command to list all RDS database names, available
in the selected AWS region, Output will return database instance identifier name
Select encrypted database name that we just created DB-Name-Encrypted.
References:
1. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryptio
n.html
2. https://aws.amazon.com/blogs/database/selecting-the-right-encryption-options-
for-amazon-rds-and-amazon-aurora-database-
engines/#:~:text=With%20RDS%2Dencrypted%20resources%2C%20data,transp
arent%20to%20your%20database%20engine.
3. https://aws.amazon.com/rds/features/security/
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 94
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled for
RDS Instances (Automated)
Profile Applicability:
• Level 1
Description:
Ensure that RDS database instances have the Auto Minor Version Upgrade flag
enabled in order to receive automatically minor engine upgrades during the specified
maintenance window. So, RDS instances can get the new features, bug fixes, and
security patches for their database engines.
Rationale:
AWS RDS will occasionally deprecate minor engine versions and provide new ones for
an upgrade. When the last version number within the release is replaced, the version
changed is considered minor. With Auto Minor Version Upgrade feature enabled, the
version upgrades will occur automatically during the specified maintenance window so
your RDS instances can get the new features, bug fixes, and security patches for their
database engines.
Audit:
From Console:
1. Log in to the AWS management console and navigate to the RDS dashboard at
https://console.aws.amazon.com/rds/.
2. In the left navigation panel, click on Databases.
3. Select the RDS instance that wants to examine.
4. Click on the Maintenance and backups panel.
5. Under the Maintenance section, search for the Auto Minor Version Upgrade
status.
• If the current status is set to Disabled, means the feature is not set and the minor
engine upgrades released will not be applied to the selected RDS instance
Page 95
2. The command output should return each database instance identifier.
3. Run again describe-db-instances command using the RDS instance identifier
returned earlier to determine the Auto Minor Version Upgrade status for the
selected instance:
4. The command output should return the feature current status. If the current
status is set to true, the feature is enabled and the minor engine upgrades will
be applied to the selected RDS instance.
Remediation:
From Console:
1. Log in to the AWS management console and navigate to the RDS dashboard at
https://console.aws.amazon.com/rds/.
2. In the left navigation panel, click on Databases.
3. Select the RDS instance that wants to update.
4. Click on the Modify button placed on the top right side.
5. On the Modify DB Instance: <instance identifier> page, In the Maintenance
section, select Auto minor version upgrade click on the Yes radio button.
6. At the bottom of the page click on Continue, check to Apply Immediately to apply
the changes immediately, or select Apply during the next scheduled
maintenance window to avoid any downtime.
7. Review the changes and click on Modify DB Instance. The instance status
should change from available to modifying and back to available. Once the
feature is enabled, the Auto Minor Version Upgrade status should change to
Yes.
Page 96
aws rds modify-db-instance --region <regionName> --db-instance-identifier
<dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately
4. The command output should reveal the new configuration metadata for the RDS
instance and check AutoMinorVersionUpgrade parameter value.
5. Run describe-db-instances command to check if the Auto Minor Version
Upgrade feature has been successfully enable:
6. The command output should return the feature current status set to true, the
feature is enabled and the minor engine upgrades will be applied to the selected
RDS instance.
References:
1. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Mana
ging.html
2. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDB
Instance.Upgrading.html
3. https://aws.amazon.com/rds/faqs/
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 97
2.3.3 Ensure that public access is not given to RDS Instance
(Automated)
Profile Applicability:
• Level 1
Description:
Ensure and verify that RDS database instances provisioned in your AWS account do
restrict unauthorized access in order to minimize security risks. To restrict access to any
publicly accessible RDS database instance, you must disable the database Publicly
Accessible flag and update the VPC security group associated with the instance.
Rationale:
Ensure that no public-facing RDS database instances are provisioned in your AWS
account and restrict unauthorized access in order to minimize security risks. When the
RDS instance allows unrestricted access (0.0.0.0/0), everyone and everything on the
Internet can establish a connection to your database and this can increase the
opportunity for malicious activities such as brute force attacks, PostgreSQL injections,
or DoS/DDoS attacks.
Audit:
From Console:
1. Log in to the AWS management console and navigate to the RDS dashboard at
https://console.aws.amazon.com/rds/.
2. Under the navigation panel, On RDS Dashboard, click Databases.
3. Select the RDS instance that you want to examine.
4. Click Instance Name from the dashboard, Under `Connectivity and Security.
5. On the Security, check if the Publicly Accessible flag status is set to Yes, follow
the below-mentioned steps to check database subnet access.
• In the networking section, click the subnet link available under Subnets
• The link will redirect you to the VPC Subnets page.
• Select the subnet listed on the page and click the Route Table tab from the
dashboard bottom panel. If the route table contains any entries with the
destination CIDR block set to 0.0.0.0/0 and with an Internet Gateway
attached.
• The selected RDS database instance was provisioned inside a public subnet,
therefore is not running within a logically isolated environment and can be
accessible from the Internet.
Page 98
6. Repeat steps no. 4 and 5 to determine the type (public or private) and subnet for
other RDS database instances provisioned in the current region.
7. Change the AWS region from the navigation bar and repeat the audit process for
other regions.
4. Check for the Publicly Accessible parameter status, If the Publicly Accessible flag
is set to Yes. Then selected RDS database instance is publicly accessible and
insecure, follow the below-mentioned steps to check database subnet access
5. Run again describe-db-instances command using the RDS database instance
identifier that you want to check and appropriate filtering to describe the VPC
subnet(s) associated with the selected instance:
• The command output should list the subnets available in the selected database
subnet group.
• If the command returns the route table associated with database instance subnet
ID. Check the GatewayId and DestinationCidrBlock attributes values returned in
the output. If the route table contains any entries with the GatewayId value set to
igw-xxxxxxxx and the DestinationCidrBlock value set to 0.0.0.0/0, the
selected RDS database instance was provisioned inside a public subnet.
Page 99
• Or
• If the command returns empty results, the route table is implicitly associated with
subnet, therefore the audit process continues with the next step
• The command output should show the VPC ID in the selected database subnet
group
• The command output returns the VPC main route table implicitly associated with
database instance subnet ID. Check the GatewayId and DestinationCidrBlock
attributes values returned in the output. If the route table contains any entries
with the GatewayId value set to igw-xxxxxxxx and the DestinationCidrBlock
value set to 0.0.0.0/0, the selected RDS database instance was provisioned
inside a public subnet, therefore is not running within a logically isolated
environment and does not adhere to AWS security best practices.
Remediation:
From Console:
1. Log in to the AWS management console and navigate to the RDS dashboard at
https://console.aws.amazon.com/rds/.
2. Under the navigation panel, On RDS Dashboard, click Databases.
3. Select the RDS instance that you want to update.
4. Click Modify from the dashboard top menu.
5. On the Modify DB Instance panel, under the Connectivity section, click on
Additional connectivity configuration and update the value for Publicly
Accessible to Not publicly accessible to restrict public access. Follow the below
steps to update subnet configurations:
• Select the Connectivity and security tab, and click on the VPC attribute value
inside the Networking section.
Page 100
• Select the Details tab from the VPC dashboard bottom panel and click on Route
table configuration attribute value.
• On the Route table details page, select the Routes tab from the dashboard
bottom panel and click on Edit routes.
• On the Edit routes page, update the Destination of Target which is set to igw-
xxxxx and click on Save routes.
• Select Apply during the next scheduled maintenance window to apply the
changes automatically during the next scheduled maintenance window.
• Select Apply immediately to apply the changes right away. With this option, any
pending modifications will be asynchronously applied as soon as possible,
regardless of the maintenance window setting for this RDS database instance.
Note that any changes available in the pending modifications queue are also
applied. If any of the pending modifications require downtime, choosing this
option can cause unexpected downtime for the application.
7. Repeat steps 3 to 6 for each RDS instance available in the current region.
8. Change the AWS region from the navigation bar to repeat the process for other
regions.
Page 101
5. Updating the Internet Gateway Destination via AWS CLI is not currently
supported To update information about Internet Gateway use the AWS Console
Procedure.
6. Repeat steps 1 to 5 for each RDS instance provisioned in the current region.
7. Change the AWS region by using the --region filter to repeat the process for
other regions.
References:
1. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.htm
l
2. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
3. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.Worki
ngWithRDSInstanceinaVPC.html
4. https://aws.amazon.com/rds/faqs/
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 102
2.4 Elastic File System (EFS)
Page 103
2.4.1 Ensure that encryption is enabled for EFS file systems
(Automated)
Profile Applicability:
• Level 1
Description:
EFS data should be encrypted at rest using AWS KMS (Key Management Service).
Rationale:
Data should be encrypted at rest to reduce the risk of a data breach via direct access to
the storage device.
Audit:
From Console:
1. Login to the AWS Management Console and Navigate to `Elastic File System
(EFS) dashboard.
2. Select File Systems from the left navigation panel.
3. Each item on the list has a visible Encrypted field that displays data at rest
encryption status.
4. Validate that this field reads Encrypted for all EFS file systems in all AWS
regions.
From CLI:
2. The command output should return a table with the requested file system IDs.
3. Run describe-file-systems command using the ID of the file system that you want
to examine as identifier and the necessary query filters:
Page 104
4. The command output should return the file system encryption status true or false.
If the returned value is false, the selected AWS EFS file system is not encrypted
and if the returned value is true, the selected AWS EFS file system is encrypted.
Remediation:
It is important to note that EFS file system data at rest encryption must be turned
on when creating the file system.
If an EFS file system has been created without data at rest encryption enabled then you
must create another EFS file system with the correct configuration and transfer the data.
Steps to create an EFS file system with data encrypted at rest:
From Console:
1. Login to the AWS Management Console and Navigate to Elastic File System
(EFS) dashboard.
2. Select File Systems from the left navigation panel.
3. Click Create File System button from the dashboard top menu to start the file
system setup process.
4. On the Configure file system access configuration page, perform the following
actions.
6. Review the file system configuration details on the review and create page and
then click Create File System to create your new AWS EFS file system.
7. Copy the data from the old unencrypted EFS file system onto the newly create
encrypted file system.
8. Remove the unencrypted file system as soon as your data migration to the newly
create encrypted file system is completed.
9. Change the AWS region from the navigation bar and repeat the entire process
for other aws regions.
From CLI:
Page 105
1. Run describe-file-systems command to describe the configuration information
available for the selected (unencrypted) file system (see Audit section to identify
the right resource):
5. The command output should return the new file system configuration metadata.
6. Run create-mount-target command using the newly created EFS file system ID
returned at the previous step as identifier and the ID of the Availability Zone (AZ)
that will represent the mount target:
7. The command output should return the new mount target metadata.
8. Now you can mount your file system from an EC2 instance.
9. Copy the data from the old unencrypted EFS file system onto the newly create
encrypted file system.
10. Remove the unencrypted file system as soon as your data migration to the newly
create encrypted file system is completed.
11. Change the AWS region by updating the --region and repeat the entire process
for other aws regions.
Default Value:
EFS file system data is encrypted at rest by default when creating a file system via the
Console. Encryption at rest is not enabled by default when creating a new file system
using the AWS CLI, API, and SDKs.
Page 106
References:
1. https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html
2. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/efs/index.ht
ml#efs
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 107
3 Logging
This section contains recommendations for configuring AWS logging features.
Page 108
3.1 Ensure CloudTrail is enabled in all regions (Automated)
Profile Applicability:
• Level 1
Description:
AWS CloudTrail is a web service that records AWS API calls for your account and
delivers log files to you. The recorded information includes the identity of the API caller,
the time of the API call, the source IP address of the API caller, the request parameters,
and the response elements returned by the AWS service. CloudTrail provides a history
of AWS API calls for an account, including API calls made via the Management
Console, SDKs, command line tools, and higher-level AWS services (such as
CloudFormation).
Rationale:
The AWS API call history produced by CloudTrail enables security analysis, resource
change tracking, and compliance auditing. Additionally,
• ensuring that a multi-regions trail exists will ensure that unexpected activity
occurring in otherwise unused regions is detected
• ensuring that a multi-regions trail exists will ensure that Global Service Logging
is enabled for a trail by default to capture recording of events generated on AWS
global services
• for a multi-regions 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
Impact:
S3 lifecycle features can be used to manage the accumulation and management of logs
over time. See the following AWS resource for more information on these features:
1. https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html
Audit:
Perform the following to determine if CloudTrail is enabled for all regions:
From Console:
1. Sign in to the AWS Management Console and open the CloudTrail console at
https://console.aws.amazon.com/cloudtrail
2. Click on Trails on the left navigation pane
Page 109
3. Ensure at least one Trail has Yes specified in the Multi-region trail column
4. Click on a trail via the link in the Name column
5. Ensure Logging is set to ON
6. Ensure Multi-region trail is set to Yes
7. In section Management Events ensure API activity set to ALL
Remediation:
Perform the following to enable global (Multi-region) CloudTrail logging:
From Console:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/cloudtrail
2. Click on Trails on the left navigation pane
3. Click Get Started Now , if presented
Page 110
4. Ensure Management events check box is selected.
5. Ensure both Read and Write are check under API activity
6. Click Next
7. review your trail settings and click Create trail
Default Value:
Not Enabled
References:
1. CCE-78913-1
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-
concepts.html#cloudtrail-concepts-management-events
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-
management-and-data-events-with-
cloudtrail.html?icmpid=docs_cloudtrail_console#logging-management-events
4. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-
services.html#cloud-trail-supported-services-data-events
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 111
3.2 Ensure CloudTrail log file validation is enabled (Automated)
Profile Applicability:
• Level 2
Description:
CloudTrail log file validation creates a digitally signed digest file containing a hash of
each log that CloudTrail writes to S3. These digest files can be used to determine
whether a log file was changed, deleted, or unchanged after CloudTrail delivered the
log. It is recommended that file validation be enabled on all CloudTrails.
Rationale:
Enabling log file validation will provide additional integrity checking of CloudTrail logs.
Audit:
Perform the following on each trail to determine if log file validation is enabled:
From Console:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/cloudtrail
2. Click on Trails on the left navigation pane
3. For Every Trail:
Remediation:
Perform the following to enable log file validation on a given trail:
From Console:
1. Sign in to the AWS Management Console and open the IAM console at
https://console.aws.amazon.com/cloudtrail
2. Click on Trails on the left navigation pane
3. Click on target trail
4. Within the General details section click edit
5. Under the Advanced settings section
6. Check the enable box under Log file validation
7. Click Save changes
Page 112
From Command Line:
aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation
Note that periodic validation of logs using these digests can be performed by running
the following command:
aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time
<start_time> --end-time <end_time>
Default Value:
Not Enabled
References:
1. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-
validation-enabling.html
2. CCE-78914-9
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 113
3.3 Ensure AWS Config is enabled in all regions (Automated)
Profile Applicability:
• Level 2
Description:
AWS Config is a web service that performs configuration management of supported
AWS resources within your account and delivers log files to you. The recorded
information includes the configuration item (AWS resource), relationships between
configuration items (AWS resources), any configuration changes between resources. It
is recommended AWS Config be enabled in all regions.
Rationale:
The AWS configuration item history captured by AWS Config enables security analysis,
resource change tracking, and compliance auditing.
Impact:
It is recommended AWS Config be enabled in all regions.
Audit:
Process to evaluate AWS Config configuration per region
From Console:
1. Sign in to the AWS Management Console and open the AWS Config console at
https://console.aws.amazon.com/config/.
2. On the top right of the console select target Region.
3. If a Config recorder is enabled in this region, you should navigate to the Settings
page from the navigation menu on the left hand side. If a Config recorder is not
yet enabled in this region then you should select "Get Started".
4. Ensure "Record all resources supported in this region" is checked.
5. Ensure "Include global resources (e.g., AWS IAM resources)" is checked, unless
it is enabled in another region (this is only required in one region)
6. Ensure the correct S3 bucket has been defined.
7. Ensure the correct SNS topic has been defined.
8. Repeat steps 2 to 7 for each region.
1. Run this command to show all AWS Config recorders and their properties:
Page 114
2. Evaluate the output to ensure that all recorders have a recordingGroup object
which includes "allSupported": true. Additionally, ensure that at least one
recorder has "includeGlobalResourceTypes": true
3. Run this command to show the status for all AWS Config recorders:
4. In the output, find recorders with name key matching the recorders that were
evaluated in step 2. Ensure that they include "recording": true and
"lastStatus": "SUCCESS"
Remediation:
To implement AWS Config configuration:
From Console:
1. Select the region you want to focus on in the top right of the console
2. Click Services
3. Click Config
4. If a Config recorder is enabled in this region, you should navigate to the Settings
page from the navigation menu on the left hand side. If a Config recorder is not
yet enabled in this region then you should select "Get Started".
5. Select "Record all resources supported in this region"
6. Choose to include global resources (IAM resources)
7. Specify an S3 bucket in the same account or in another managed AWS account
8. Create an SNS Topic from the same AWS account or another managed AWS
account
Page 115
From Command Line:
1. Ensure there is an appropriate S3 bucket, SNS topic, and IAM role per the AWS
Config Service prerequisites.
2. Run this command to create a new configuration recorder:
3. Create a delivery channel configuration file locally which specifies the channel
attributes, populated from the prerequisites set up previously:
{
"name": "default",
"s3BucketName": "my-config-bucket",
"snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
"configSnapshotDeliveryProperties": {
"deliveryFrequency": "Twelve_Hours"
}
}
4. Run this command to create a new delivery channel, referencing the json
configuration file made in the previous step:
References:
1. CCE-78917-2
2. https://docs.aws.amazon.com/cli/latest/reference/configservice/describe-
configuration-recorder-status.html
3. https://docs.aws.amazon.com/cli/latest/reference/configservice/describe-
configuration-recorders.html
4. https://docs.aws.amazon.com/config/latest/developerguide/gs-cli-prereq.html
Page 116
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 117
3.4 Ensure S3 bucket access logging is enabled on the CloudTrail
S3 bucket (Automated)
Profile Applicability:
• Level 1
Description:
S3 Bucket Access Logging generates a log that contains access records for each
request made to your S3 bucket. An access log record contains details about the
request, such as the request type, the resources specified in the request worked, and
the time and date the request was processed. It is recommended that bucket access
logging be enabled on the CloudTrail S3 bucket.
Rationale:
By enabling S3 bucket logging on target S3 buckets, it is possible to capture all events
which may affect objects within any target buckets. Configuring logs to be placed in a
separate bucket allows access to log information which can be useful in security and
incident response workflows.
Audit:
Perform the following ensure the CloudTrail S3 bucket has access logging is enabled:
From Console:
Page 118
aws s3api get-bucket-logging --bucket <s3_bucket_for_cloudtrail>
Remediation:
Perform the following to enable S3 bucket logging:
From Console:
2. Copy and add target bucket name at <Logging_BucketName>, Prefix for logfile at
<LogFilePrefix> and optionally add an email address in the following template
and save it as <FileName.Json>:
Page 119
{
"LoggingEnabled": {
"TargetBucket": "<Logging_BucketName>",
"TargetPrefix": "<LogFilePrefix>",
"TargetGrants": [
{
"Grantee": {
"Type": "AmazonCustomerByEmail",
"EmailAddress": "<EmailID>"
},
"Permission": "FULL_CONTROL"
}
]
}
}
Default Value:
Logging is disabled.
References:
1. CCE-78918-0
2. https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 120
Controls
Control IG 1 IG 2 IG 3
Version
Page 121
3.5 Ensure CloudTrail logs are encrypted at rest using KMS
CMKs (Automated)
Profile Applicability:
• Level 2
Description:
AWS 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 (KMS) is a managed service that helps create and control the
encryption keys used to encrypt account data, and uses Hardware Security Modules
(HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to
leverage server side encryption (SSE) and KMS customer created master keys (CMK)
to further protect CloudTrail logs. It is recommended that CloudTrail be configured to
use SSE-KMS.
Rationale:
Configuring CloudTrail to use SSE-KMS provides additional confidentiality controls on
log data as a given user must have S3 read permission on the corresponding log bucket
and must be granted decrypt permission by the CMK policy.
Impact:
Customer created keys incur an additional cost. See
https://aws.amazon.com/kms/pricing/ for more information.
Audit:
Perform the following to determine if CloudTrail is configured to use SSE-KMS:
From Console:
1. Sign in to the AWS Management Console and open the CloudTrail console at
https://console.aws.amazon.com/cloudtrail
2. In the left navigation pane, choose Trails .
3. Select a Trail
4. Under the S3 section, ensure Encrypt log files is set to Yes and a KMS key ID
is specified in the KSM Key Id field.
Page 122
2. For each trail listed, SSE-KMS is enabled if the trail has a KmsKeyId property
defined.
Remediation:
Perform the following to configure CloudTrail to use SSE-KMS:
From Console:
1. Sign in to the AWS Management Console and open the CloudTrail console at
https://console.aws.amazon.com/cloudtrail
2. In the left navigation pane, choose Trails .
3. Click on a Trail
4. Under the S3 section click on the edit button (pencil icon)
5. Click Advanced
6. Select an existing CMK from the KMS key Id drop-down menu
• Note: Ensure the CMK is located in the same region as the S3 bucket
• Note: You will need to apply a KMS Key policy on the selected CMK in order for
CloudTrail as a service to encrypt and decrypt log files using the CMK provided.
Steps are provided here for editing the selected CMK Key policy
7. Click Save
8. You will see a notification message stating that you need to have decrypt
permissions on the specified KMS key to decrypt log files.
9. Click Yes
References:
1. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/encrypting-
cloudtrail-log-files-with-aws-kms.html
2. https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html
3. CCE-78919-8
Page 123
Additional Information:
3 statements which need to be added to the CMK policy:
1. Enable Cloudtrail to describe CMK properties
<pre class="programlisting" style="font-style: normal;">{
"Sid": "Allow CloudTrail access",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "kms:DescribeKey",
"Resource": "*"
}
2. Granting encrypt permissions
<pre class="programlisting" style="font-style: normal;">{
"Sid": "Allow CloudTrail to encrypt logs",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "kms:GenerateDataKey*",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": [
"arn:aws:cloudtrail:*:aws-account-id:trail/*"
]
}
}
}
3. Granting decrypt permissions
<pre class="programlisting" style="font-style: normal;">{
"Sid": "Enable CloudTrail log decrypt permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:user/username"
},
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"Null": {
"kms:EncryptionContext:aws:cloudtrail:arn": "false"
}
}
}
Page 124
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 125
3.6 Ensure rotation for customer-created symmetric CMKs is
enabled (Automated)
Profile Applicability:
• Level 2
Description:
AWS Key Management Service (KMS) allows customers to rotate the backing key
which is key material stored within the KMS which is tied to the key ID of the customer-
created customer master key (CMK). It is the backing key that is used to perform
cryptographic operations such as encryption and decryption. Automated key rotation
currently retains all prior backing keys so that decryption of encrypted data can take
place transparently. It is recommended that CMK key rotation be enabled for symmetric
keys. Key rotation can not be enabled for any asymmetric CMK.
Rationale:
Rotating encryption keys helps reduce the potential impact of a compromised key as
data encrypted with a new key cannot be accessed with a previous key that may have
been exposed. Keys should be rotated every year, or upon event that would result in the
compromise of that key.
Impact:
Creation, management, and storage of CMKs may require additional time from an
administrator.
Audit:
From Console:
1. Sign in to the AWS Management Console and open the KMS console at:
https://console.aws.amazon.com/kms.
2. In the left navigation pane, click Customer-managed keys.
3. Select a customer managed CMK where Key spec = SYMMETRIC_DEFAULT.
4. Select the Key rotation tab.
5. Ensure the Automatically rotate this KMS key every year checkbox is
checked.
6. Repeat steps 3–5 for all customer-managed CMKs where "Key spec =
SYMMETRIC_DEFAULT".
Page 126
From Command Line:
1. Run the following command to get a list of all keys and their associated KeyIds:
2. For each key, note the KeyId and run the following command:
Remediation:
From Console:
1. Sign in to the AWS Management Console and open the KMS console at:
https://console.aws.amazon.com/kms.
2. In the left navigation pane, click Customer-managed keys.
3. Select a key where Key spec = SYMMETRIC_DEFAULT that does not have automatic
rotation enabled.
4. Select the Key rotation tab.
5. Check the Automatically rotate this KMS key every year checkbox.
6. Click Save.
7. Repeat steps 3–6 for all customer-managed CMKs that do not have automatic
rotation enabled.
References:
1. https://aws.amazon.com/kms/pricing/
2. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
3. CCE-78920-6
Page 127
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 128
3.7 Ensure VPC flow logging is enabled in all VPCs (Automated)
Profile Applicability:
• Level 2
Description:
VPC Flow Logs is a feature that enables you to capture information about the IP traffic
going to and from network interfaces in your VPC. After you've created a flow log, you
can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that
VPC Flow Logs be enabled for packet "Rejects" for VPCs.
Rationale:
VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be
used to detect anomalous traffic or insight during security workflows.
Impact:
By default, CloudWatch Logs will store Logs indefinitely unless a specific retention
period is defined for the log group. When choosing the number of days to retain, keep in
mind the average days it takes an organization to realize they have been breached is
210 days (at the time of this writing). Since additional time is required to research a
breach, a minimum 365 day retention policy allows time for detection and research. You
may also wish to archive the logs to a cheaper storage service rather than simply
deleting them. See the following AWS resource to manage CloudWatch Logs retention
periods:
1. https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/Settin
gLogRetention.html
Audit:
Perform the following to determine if VPC Flow logs are enabled:
From Console:
Page 129
aws ec2 describe-vpcs --region <region> --query Vpcs[].VpcId
2. The command output returns the VpcId available in the selected region.
3. Run describe-flow-logs command (OSX/Linux/UNIX) using the VPC ID to
determine if the selected virtual network has the Flow Logs feature enabled:
4. If there are no Flow Logs created for the selected VPC, the command output will
return an empty list [].
5. Repeat step 3 for other VPCs available in the same region.
6. Change the region by updating --region and repeat steps 1 - 5 for all the VPCs.
Remediation:
Perform the following to determine if VPC Flow logs is enabled:
From Console:
Note: Setting the filter to "Reject" will dramatically reduce the logging data accumulation
for this recommendation and provide sufficient information for the purposes of breach
detection, research and remediation. However, during periods of least privilege security
group engineering, setting this the filter to "All" can be very helpful in discovering
existing traffic flows required for proper operation of an already running environment.
Page 130
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "test",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
2. Create another policy document and name it as iam_policy.json and paste the
following content:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action":[
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:FilterLogEvents"
],
"Resource": "*"
}
]
}
5. Run attach-group-policy command using the IAM policy ARN returned at the
previous step to attach the policy to the IAM role (if the command succeeds, no
output is returned):
Page 131
aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-
id>:policy/<iam-policy-name> --group-name <group-name>
7. The command output should return the VPC Id available in the selected region.
8. Run create-flow-logs to create a flow log for the vpc:
References:
1. CCE-79202-8
2. https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 132
3.8 Ensure that Object-level logging for write events is enabled for
S3 bucket (Automated)
Profile Applicability:
• Level 2
Description:
S3 object-level API operations such as GetObject, DeleteObject, and PutObject are
called data events. By default, CloudTrail trails don't log data events and so it is
recommended to enable Object-level logging for S3 buckets.
Rationale:
Enabling object-level logging will help you meet data compliance requirements within
your organization, perform comprehensive security analysis, monitor specific patterns of
user behavior in your AWS account or take immediate actions on any object-level API
activity within your S3 Buckets using Amazon CloudWatch Events.
Impact:
Enabling logging for these object level events may significantly increase the number of
events logged and may incur additional cost.
Audit:
From Console:
Data Events:S3
Log selector template
Log all events
If 'basic events selectors' is being used it should read:
Data events: S3
Bucket Name: All current and future S3 buckets
Write: Enabled
Page 133
7. Repeat steps 2 to 6 to verify that Multi-region trail and Data events logging of S3
buckets in CloudTrail.
If the CloudTrails do not have multi-region and data events configured for S3
refer to the remediation below.
1. Run list-trails command to list the names of all Amazon CloudTrail trails
currently available in all AWS regions:
2. The command output will be a list of all the trail names to include.
"TrailARN": "arn:aws:cloudtrail::<account#>:trail/",
"Name": "",
"HomeRegion": ""
3. Next run 'get-trail- command to determine Multi-region.
6. The command output should be an array that contains the configuration of the
AWS resource(S3 bucket) defined for the Data events selector.
"Type": "AWS::S3::Object",
"Values": [
"arn:aws:s3"
7. If the get-event-selectors command returns an empty array '[]', the Data events
are not included in the selected AWS Cloudtrail trail logging configuration,
therefore the S3 object-level API operations performed within your AWS account
are not recorded.
8. Repeat steps 1 to 5 for auditing each CloudTrail to determine if Data events for
S3 are covered.
If Multi-region is not set to true and the Data events does not show S3 defined as
shown refer to the remediation procedure below.
Page 134
Remediation:
From Console:
1. To enable object-level data events logging for S3 buckets within your AWS
account, run put-event-selectors command using the name of the trail that you
want to reconfigure as identifier:
References:
1. https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-cloudtrail-
events.html
Page 135
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 136
3.9 Ensure that Object-level logging for read events is enabled for
S3 bucket (Automated)
Profile Applicability:
• Level 2
Description:
S3 object-level API operations such as GetObject, DeleteObject, and PutObject are
called data events. By default, CloudTrail trails don't log data events and so it is
recommended to enable Object-level logging for S3 buckets.
Rationale:
Enabling object-level logging will help you meet data compliance requirements within
your organization, perform comprehensive security analysis, monitor specific patterns of
user behavior in your AWS account or take immediate actions on any object-level API
activity using Amazon CloudWatch Events.
Impact:
Enabling logging for these object level events may significantly increase the number of
events logged and may incur additional cost.
Audit:
From Console:
Data Events:S3
Log selector template
Log all events
If 'basic events selectors' is being used it should read:
Data events: S3
Bucket Name: All current and future S3 buckets
Write: Enabled
Page 137
7. Repeat steps 2 to 6 to verify that Multi-region trail and Data events logging of S3
buckets in CloudTrail.
If the CloudTrails do not have multi-region and data events configured for S3
refer to the remediation below.
1. Run describe-trails command to list the names of all Amazon CloudTrail trails
currently available in the selected AWS region:
4. The command output should be an array that contains the configuration of the
AWS resource(S3 bucket) defined for the Data events selector.
5. If the get-event-selectors command returns an empty array, the Data events
are not included into the selected AWS Cloudtrail trail logging configuration,
therefore the S3 object-level API operations performed within your AWS account
are not recorded.
6. Repeat steps 1 to 5 for auditing each s3 bucket to identify other trails that are
missing the capability to log Data events.
7. Change the AWS region by updating the --region command parameter and
perform the audit process for other regions.
Remediation:
From Console:
Page 138
5. Once the Cloudtrail is selected, Select the data Data Events check box.
6. Select S3 from the `Data event type drop down.
7. Select Log all events from the Log selector template drop down.
8. Repeat steps 2 to 5 to enable object-level logging of write events for other S3
buckets.
1. To enable object-level data events logging for S3 buckets within your AWS
account, run put-event-selectors command using the name of the trail that you
want to reconfigure as identifier:
References:
1. https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-cloudtrail-
events.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 139
4 Monitoring
This section contains recommendations for configuring AWS to assist with monitoring
and responding to account activities.
Metric filter-related recommendations in this section are dependent on the Ensure
CloudTrail is enabled in all regions and Ensure CloudTrail trails are
integrated with CloudWatch Logs recommendation in the "Logging" section.
Page 140
4.1 Ensure unauthorized API calls are monitored (Manual)
Profile Applicability:
• Level 2
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established for unauthorized API
calls.
Rationale:
Monitoring unauthorized API calls will help reduce time to detect malicious activity and
can alert you to a potential security incident.
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Impact:
This alert may be triggered by normal read-only console activities that attempt to
opportunistically gather optional information, but gracefully fail if they don't have
permissions.
If an excessive number of alerts are being generated then an organization may wish to
consider adding read access to the limited IAM user permissions simply to quiet the
alerts.
In some cases doing this may allow the users to actually view some areas of the system
- any additional access given should be reviewed for alignment with the original limited
IAM user intent.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 141
• From value associated with "CloudWatchLogsLogGroupArn" note
<cloudtrail_log_group_name>
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Page 142
Example of valid "SubscriptionArn":
"arn:aws:sns:<region>:<aws_account_number>:<SnsTopicName>:<SubscriptionID>"
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for
unauthorized API calls and the <cloudtrail_log_group_name> taken from audit
step 1.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
Page 143
References:
1. https://aws.amazon.com/sns/
2. CCE-79186-3
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
4. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
5. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 144
4.2 Ensure management console sign-in without MFA is
monitored (Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established for console logins that
are not protected by multi-factor authentication (MFA).
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring for single-factor console logins will increase visibility into accounts that are
not protected by MFA. These type of accounts are more susceptible to compromise and
unauthorized access.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 145
aws cloudtrail get-trail-status --name <Name of a Multi-region CloudTrail>
Ensure in the output that IsLogging is set to TRUE
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
Page 146
1. Create a metric filter based on filter pattern provided which checks for AWS
Management Console sign-in without MFA and the
<cloudtrail_log_group_name> taken from audit step 1.
Use Command:
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<no_mfa_console_signin_metric>` --metric-transformations
metricName= `<no_mfa_console_signin_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") }'
Or (To reduce false positives incase Single Sign-On (SSO) is used in organization):
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<no_mfa_console_signin_metric>` --metric-transformations
metricName= `<no_mfa_console_signin_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") &&
($.userIdentity.type = "IAMUser") && ($.responseElements.ConsoleLogin =
"Success") }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
Page 147
References:
1. https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/viewin
g_metrics_with_cloudwatch.html
2. CCE-79187-1
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
4. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
5. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored -Filter
pattern set to { ($.eventName = "ConsoleLogin") &&
($.additionalEventData.MFAUsed != "Yes") && ($.userIdentity.type =
"IAMUser") && ($.responseElements.ConsoleLogin = "Success"} reduces false
alarms raised when user logs in via SSO account.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 148
4.3 Ensure usage of 'root' account is monitored (Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established for 'root' login attempts
to detect the unauthorized use, or attempts to use the root account.
Rationale:
Monitoring for 'root' account logins will provide visibility into the use of a fully privileged
account and an opportunity to reduce the use of it.
Cloud Watch is an AWS native service that allows you to observe and monitor
resources and applications. CloudTrail Logs can also be sent to an external Security
information and event management (SIEM) environment for monitoring and alerting.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 149
• Ensure identified Multi-region Cloudtrail captures all Management Events
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for 'Root'
account usage and the <cloudtrail_log_group_name> taken from audit step 1.
Page 150
aws logs put-metric-filter --log-group-name `<cloudtrail_log_group_name>` --
filter-name `<root_usage_metric>` --metric-transformations metricName=
`<root_usage_metric>` ,metricNamespace='CISBenchmark',metricValue=1 --filter-
pattern '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT
EXISTS && $.eventType != "AwsServiceEvent" }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79188-9
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
Page 151
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 152
4.4 Ensure IAM policy changes are monitored (Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established changes made to
Identity and Access Management (IAM) policies.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring changes to IAM policies will help ensure authentication and authorization
controls remain intact.
Impact:
Monitoring these changes may cause a number of "false positives" more so in larger
environments. This alert may need more tuning then others to eliminate some of those
erroneous alerts.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 153
• Ensure Identified Multi region CloudTrail is active
3. Ensure the output from the above command contains the following:
"filterPattern":
"{($.eventName=DeleteGroupPolicy)||($.eventName=DeleteRolePolicy)||($.eventNa
me=DeleteUserPolicy)||($.eventName=PutGroupPolicy)||($.eventName=PutRolePolic
y)||($.eventName=PutUserPolicy)||($.eventName=CreatePolicy)||($.eventName=Del
etePolicy)||($.eventName=CreatePolicyVersion)||($.eventName=DeletePolicyVersi
on)||($.eventName=AttachRolePolicy)||($.eventName=DetachRolePolicy)||($.event
Name=AttachUserPolicy)||($.eventName=DetachUserPolicy)||($.eventName=AttachGr
oupPolicy)||($.eventName=DetachGroupPolicy)}"
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
Page 154
1. Create a metric filter based on filter pattern provided which checks for IAM policy
changes and the <cloudtrail_log_group_name> taken from audit step 1.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79189-7
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Page 155
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 156
4.5 Ensure CloudTrail configuration changes are monitored
(Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, where metric filters and alarms can be established.
It is recommended that a metric filter and alarm be utilized for detecting changes to
CloudTrail's configurations.
Rationale:
Monitoring changes to CloudTrail's configuration will help ensure sustained visibility to
activities performed in the AWS account.
Impact:
These steps can be performed manually in a company's existing SIEM platform in cases
where CloudTrail logs are monitored outside of the AWS monitoring tools within
CloudWatch.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured, or that the filters are configured in the appropriate SIEM alerts:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 157
• Ensure identified Multi-region Cloudtrail captures all Management Events
3. Ensure the filterPattern output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for cloudtrail
configuration changes and the <cloudtrail_log_group_name> taken from audit
step 1.
Page 158
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<cloudtrail_cfg_changes_metric>` --metric-transformations
metricName= `<cloudtrail_cfg_changes_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventName = CreateTrail) || ($.eventName = UpdateTrail) || ($.eventName =
DeleteTrail) || ($.eventName = StartLogging) || ($.eventName = StopLogging)
}'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79190-5
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
Page 159
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 160
4.6 Ensure AWS Management Console authentication failures are
monitored (Manual)
Profile Applicability:
• Level 2
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established for failed console
authentication attempts.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring failed console logins may decrease lead time to detect an attempt to brute
force a credential, which may provide an indicator, such as source IP address, that can
be used in other event correlation.
Impact:
Monitoring for these failures may create a large number of alerts, more so in larger
environments.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 161
• Ensure Identified Multi region CloudTrail is active
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for AWS
management Console Login Failures and the <cloudtrail_log_group_name>
taken from audit step 1.
Page 162
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<console_signin_failure_metric>` --metric-transformations
metricName= `<console_signin_failure_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79191-3
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
Page 163
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 164
4.7 Ensure disabling or scheduled deletion of customer created
CMKs is monitored (Manual)
Profile Applicability:
• Level 2
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established for customer created
CMKs which have changed state to disabled or scheduled deletion.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Data encrypted with disabled or deleted keys will no longer be accessible. Changes in
the state of a CMK should be monitored to make sure the change is intentional.
Impact:
Creation, storage, and management of CMK may create additional labor requirements
compared to the use of Provide Managed Keys.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 165
aws cloudtrail get-trail-status --name <Name of a Multi-region CloudTrail>
ensure IsLogging is set to TRUE
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for disabled or
scheduled for deletion CMK's and the <cloudtrail_log_group_name> taken from
audit step 1.
Page 166
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<disable_or_delete_cmk_changes_metric>` --metric-
transformations metricName= `<disable_or_delete_cmk_changes_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern
'{($.eventSource = kms.amazonaws.com) &&
(($.eventName=DisableKey)||($.eventName=ScheduleKeyDeletion)) }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79192-1
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
Page 167
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 168
4.8 Ensure S3 bucket policy changes are monitored (Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established for changes to S3 bucket
policies.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring changes to S3 bucket policies may reduce time to detect and correct
permissive policies on sensitive S3 buckets.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 169
aws cloudtrail get-event-selectors --trail-name <trailname shown in describe-
trails>
Ensure there is at least one Event Selector for a Trail with IncludeManagementEvents set
to true and ReadWriteType set to All
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for S3 bucket
policy changes and the <cloudtrail_log_group_name> taken from audit step 1.
Page 170
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<s3_bucket_policy_changes_metric>` --metric-transformations
metricName= `<s3_bucket_policy_changes_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventSource = s3.amazonaws.com) && (($.eventName = PutBucketAcl) ||
($.eventName = PutBucketPolicy) || ($.eventName = PutBucketCors) ||
($.eventName = PutBucketLifecycle) || ($.eventName = PutBucketReplication) ||
($.eventName = DeleteBucketPolicy) || ($.eventName = DeleteBucketCors) ||
($.eventName = DeleteBucketLifecycle) || ($.eventName =
DeleteBucketReplication)) }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79193-9
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
Page 171
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 172
4.9 Ensure AWS Config configuration changes are monitored
(Manual)
Profile Applicability:
• Level 2
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms.
It is recommended that a metric filter and alarm be established for detecting changes to
AWS Config's configurations.
Rationale:
Monitoring changes to AWS Config configuration will help ensure sustained visibility of
configuration items within the AWS account.
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 173
aws cloudtrail get-event-selectors --trail-name <trailname shown in describe-
trails>
Ensure there is at least one Event Selector for a Trail with IncludeManagementEvents set
to true and ReadWriteType set to All
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for AWS
Configuration changes and the <cloudtrail_log_group_name> taken from audit
step 1.
Page 174
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<aws_config_changes_metric>` --metric-transformations
metricName= `<aws_config_changes_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventSource = config.amazonaws.com) &&
(($.eventName=StopConfigurationRecorder)||($.eventName=DeleteDeliveryChannel)
||($.eventName=PutDeliveryChannel)||($.eventName=PutConfigurationRecorder))
}'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79194-7
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
Page 175
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 176
4.10 Ensure security group changes are monitored (Manual)
Profile Applicability:
• Level 2
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms. Security Groups
are a stateful packet filter that controls ingress and egress traffic within a VPC.
It is recommended that a metric filter and alarm be established for detecting changes to
Security Groups.
Rationale:
Monitoring changes to security group will help ensure that resources and services are
not unintentionally exposed.
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Impact:
This may require additional 'tuning' to eliminate false positive and filter out expected
activity so anomalies are easier to detect.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 177
aws cloudtrail get-trail-status --name <Name of a Multi-region CloudTrail>
ensure IsLogging is set to TRUE
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for security
groups changes and the <cloudtrail_log_group_name> taken from audit step 1.
Page 178
aws logs put-metric-filter --log-group-name "<cloudtrail_log_group_name>" --
filter-name "<security_group_changes_metric>" --metric-transformations
metricName= "<security_group_changes_metric>"
,metricNamespace="CISBenchmark",metricValue=1 --filter-pattern "{
($.eventName = AuthorizeSecurityGroupIngress) || ($.eventName =
AuthorizeSecurityGroupEgress) || ($.eventName = RevokeSecurityGroupIngress)
|| ($.eventName = RevokeSecurityGroupEgress) || ($.eventName =
CreateSecurityGroup) || ($.eventName = DeleteSecurityGroup) }"
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79195-4
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
Page 179
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 180
4.11 Ensure Network Access Control Lists (NACL) changes are
monitored (Manual)
Profile Applicability:
• Level 2
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms. NACLs are used
as a stateless packet filter to control ingress and egress traffic for subnets within a VPC.
It is recommended that a metric filter and alarm be established for changes made to
NACLs.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring changes to NACLs will help ensure that AWS resources and services are not
unintentionally exposed.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 181
• Ensure identified Multi-region Cloudtrail captures all Management Events
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for NACL
changes and the <cloudtrail_log_group_name> taken from audit step 1.
Page 182
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<nacl_changes_metric>` --metric-transformations metricName=
`<nacl_changes_metric>` ,metricNamespace='CISBenchmark',metricValue=1 --
filter-pattern '{ ($.eventName = CreateNetworkAcl) || ($.eventName =
CreateNetworkAclEntry) || ($.eventName = DeleteNetworkAcl) || ($.eventName =
DeleteNetworkAclEntry) || ($.eventName = ReplaceNetworkAclEntry) ||
($.eventName = ReplaceNetworkAclAssociation) }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79196-2
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
Page 183
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 184
4.12 Ensure changes to network gateways are monitored
(Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms. Network
gateways are required to send/receive traffic to a destination outside of a VPC. It is
recommended that a metric filter and alarm be established for changes to network
gateways.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring changes to network gateways will help ensure that all ingress/egress traffic
traverses the VPC border via a controlled path.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 185
• Ensure identified Multi-region Cloudtrail captures all Management Events
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for network
gateways changes and the <cloudtrail_log_group_name> taken from audit step
1.
Page 186
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<network_gw_changes_metric>` --metric-transformations
metricName= `<network_gw_changes_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventName = CreateCustomerGateway) || ($.eventName =
DeleteCustomerGateway) || ($.eventName = AttachInternetGateway) ||
($.eventName = CreateInternetGateway) || ($.eventName =
DeleteInternetGateway) || ($.eventName = DetachInternetGateway) }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79197-0
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
Page 187
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 188
4.13 Ensure route table changes are monitored (Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms. Routing tables
are used to route network traffic between subnets and to network gateways. It is
recommended that a metric filter and alarm be established for changes to route tables.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring changes to route tables will help ensure that all VPC traffic flows through an
expected path and prevent any accidental or intentional modifications that may lead to
uncontrolled network traffic. An alarm should be triggered every time an AWS API call is
performed to create, replace, delete, or disassociate a Route Table.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 189
aws cloudtrail get-event-selectors --trail-name <trailname shown in describe-
trails>
Ensure there is at least one Event Selector for a Trail with IncludeManagementEvents set
to true and ReadWriteType set to All
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for route table
changes and the <cloudtrail_log_group_name> taken from audit step 1.
Page 190
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<route_table_changes_metric>` --metric-transformations
metricName= `<route_table_changes_metric>`
,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{
($.eventName = CreateRoute) || ($.eventName = CreateRouteTable) ||
($.eventName = ReplaceRoute) || ($.eventName = ReplaceRouteTableAssociation)
|| ($.eventName = DeleteRouteTable) || ($.eventName = DeleteRoute) ||
($.eventName = DisassociateRouteTable) }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79198-8
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
• ensures that activities from all regions (used as well as unused) are monitored
Page 191
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 192
4.14 Ensure VPC changes are monitored (Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, or an external Security information and event management (SIEM)
environment, and establishing corresponding metric filters and alarms. It is possible to
have more than 1 VPC within an account, in addition it is also possible to create a peer
connection between 2 VPCs enabling network traffic to route between VPCs. It is
recommended that a metric filter and alarm be established for changes made to VPCs.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
VPCs in AWS are logically isolated virtual networks that can be used to launch AWS
resources. Monitoring changes to VPC configuration will help ensure VPC traffic flow is
not getting impacted. Changes to VPCs can impact network accessibility from the public
internet and additionally impact VPC traffic flow to and from resources launched in the
VPC.
Audit:
If you are using CloudTrails and CloudWatch, perform the following to ensure that there
is at least one active multi-region CloudTrail with prescribed metric filters and alarms
configured:
1. Identify the log group name configured for use with active multi-region CloudTrail:
Page 193
• Ensure identified Multi-region Cloudtrail captures all Management Events
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
1. Create a metric filter based on filter pattern provided which checks for VPC
changes and the <cloudtrail_log_group_name> taken from audit step 1.
Page 194
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --
filter-name `<vpc_changes_metric>` --metric-transformations metricName=
`<vpc_changes_metric>` ,metricNamespace='CISBenchmark',metricValue=1 --
filter-pattern '{ ($.eventName = CreateVpc) || ($.eventName = DeleteVpc) ||
($.eventName = ModifyVpcAttribute) || ($.eventName =
AcceptVpcPeeringConnection) || ($.eventName = CreateVpcPeeringConnection) ||
($.eventName = DeleteVpcPeeringConnection) || ($.eventName =
RejectVpcPeeringConnection) || ($.eventName = AttachClassicLinkVpc) ||
($.eventName = DetachClassicLinkVpc) || ($.eventName = DisableVpcClassicLink)
|| ($.eventName = EnableVpcClassicLink) }'
Note: You can choose your own metricName and metricNamespace strings. Using the
same metricNamespace for all Foundations Benchmark metrics will group them
together.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2
References:
1. CCE-79199-6
2. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-
log-files-from-multiple-regions.html
3. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
4. https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html
Additional Information:
Configuring log metric filter and alarm on Multi-region (global) CloudTrail
Page 195
• ensures that activities from all regions (used as well as unused) are monitored
• ensures that activities on all supported global services are monitored
• ensures that all management events across all regions are monitored
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 196
4.15 Ensure AWS Organizations changes are monitored (Manual)
Profile Applicability:
• Level 1
Description:
Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to
CloudWatch Logs, and establishing corresponding metric filters and alarms. It is
recommended that a metric filter and alarm be established for AWS Organizations
changes made in the master AWS Account.
Rationale:
CloudWatch is an AWS native service that allows you to observe and monitor resources
and applications. CloudTrail Logs can also be sent to an external Security information
and event management (SIEM) environment for monitoring and alerting.
Monitoring AWS Organizations changes can help you prevent any unwanted, accidental
or intentional modifications that may lead to unauthorized access or other security
breaches. This monitoring technique helps you to ensure that any unexpected changes
performed within your AWS Organizations can be investigated and any unwanted
changes can be rolled back.
Audit:
If you are using CloudTrails and CloudWatch, perform the following:
1. Ensure that there is at least one active multi-region CloudTrail with prescribed
metric filters and alarms configured:
• Identify the log group name configured for use with active multi-region CloudTrail:
• List all CloudTrails:
Page 197
• Ensure identified Multi-region Cloudtrail captures all Management Events:
3. Ensure the output from the above command contains the following:
6. Note the AlarmActions value - this will provide the SNS topic ARN value.
7. Ensure there is at least one active subscriber to the SNS topic:
Remediation:
If you are using CloudTrails and CloudWatch, perform the following to setup the metric
filter, alarm, SNS topic, and subscription:
Page 198
1. Create a metric filter based on filter pattern provided which checks for AWS
Organizations changes and the <cloudtrail_log_group_name> taken from audit
step 1:
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter
created in step 1 and an SNS topic created in step 2:
References:
1. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-
for-cloudtrail.html
Page 199
2. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_security_incid
ent-response.html
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 200
4.16 Ensure AWS Security Hub is enabled (Automated)
Profile Applicability:
• Level 2
Description:
Security Hub collects security data from across AWS accounts, services, and supported
third-party partner products and helps you analyze your security trends and identify the
highest priority security issues. When you enable Security Hub, it begins to consume,
aggregate, organize, and prioritize findings from AWS services that you have enabled,
such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie. You can also
enable integrations with AWS partner security products.
Rationale:
AWS Security Hub provides you with a comprehensive view of your security state in
AWS and helps you check your environment against security industry standards and
best practices - enabling you to quickly assess the security posture across your AWS
accounts.
Impact:
It is recommended AWS Security Hub be enabled in all regions. AWS Security Hub
requires AWS Config to be enabled.
Audit:
The process to evaluate AWS Security Hub configuration per region
From Console:
1. Sign in to the AWS Management Console and open the AWS Security Hub
console at https://console.aws.amazon.com/securityhub/.
2. On the top right of the console, select the target Region.
3. If presented with the Security Hub > Summary page then Security Hub is set-up
for the selected region.
4. If presented with Setup Security Hub or Get Started With Security Hub - follow
the online instructions.
5. Repeat steps 2 to 4 for each region.
Page 201
{
"HubArn": "<Securityhub ARN>",
"SubscribedAt": "2022-08-19T17:06:42.398Z",
"AutoEnableControls": true
}
An error will be returned if Securityhub is not enabled.
Example error:
An error occurred (InvalidAccessException) when calling the DescribeHub
operation: Account <Account ID> is not subscribed to AWS Security Hub
Remediation:
To grant the permissions required to enable Security Hub, attach the Security Hub
managed policy AWSSecurityHubFullAccess to an IAM user, group, or role.
Enabling Security Hub
From Console:
1. Use the credentials of the IAM identity to sign in to the Security Hub console.
2. When you open the Security Hub console for the first time, choose Enable AWS
Security Hub.
3. On the welcome page, Security standards list the security standards that Security
Hub supports.
4. Choose Enable Security Hub.
2. To enable the security hub without the default standards, include --no-enable-
default-standards.
References:
1. https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-get-
started.html
2. https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-
enable.html#securityhub-enable-api
3. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/securityhub
/enable-security-hub.html
Page 202
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 203
5 Networking
This section contains recommendations for configuring security-related aspects of AWS
Virtual Private Cloud (VPC).
Page 204
5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to
remote server administration ports (Automated)
Profile Applicability:
• Level 1
Description:
The Network Access Control List (NACL) function provide stateless filtering of ingress
and egress network traffic to AWS resources. It is recommended that no NACL allows
unrestricted ingress access to remote server administration ports, such as SSH to port
22 and RDP to port 3389, using either the TDP (6), UDP (17) or ALL (-1) protocols
Rationale:
Public access to remote server administration ports, such as 22 and 3389, increases
resource attack surface and unnecessarily raises the risk of resource compromise.
Audit:
From Console:
Perform the following to determine if the account is configured as prescribed:
Note: A Port value of ALL or a port range such as 0-1024 are inclusive of port 22, 3389,
and other remote server administration ports
Remediation:
From Console:
Perform the following:
Page 205
o Click the Inbound Rules tab
o Click Edit inbound rules
o Either A) update the Source field to a range other than 0.0.0.0/0, or, B)
Click Delete to remove the offending inbound rule
o Click Save
References:
1. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
2. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html#VPC_Sec
urity_Comparison
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 206
5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to
remote server administration ports (Automated)
Profile Applicability:
• Level 1
Description:
Security groups provide stateful filtering of ingress and egress network traffic to AWS
resources. It is recommended that no security group allows unrestricted ingress access
to remote server administration ports, such as SSH to port 22 and RDP to port 3389,
using either the TDP (6), UDP (17) or ALL (-1) protocols
Rationale:
Public access to remote server administration ports, such as 22 and 3389, increases
resource attack surface and unnecessarily raises the risk of resource compromise.
Impact:
When updating an existing environment, ensure that administrators have access to
remote server administration ports through another mechanism before removing access
by deleting the 0.0.0.0/0 inbound rule.
Audit:
Perform the following to determine if the account is configured as prescribed:
Note: A Port value of ALL or a port range such as 0-1024 are inclusive of port 22, 3389,
and other remote server administration ports.
Remediation:
Perform the following to implement the prescribed state:
Page 207
2. In the left pane, click Security Groups
3. For each security group, perform the following:
4. Select the security group
5. Click the Inbound Rules tab
6. Click the Edit inbound rules button
7. Identify the rules to be edited or removed
8. Either A) update the Source field to a range other than 0.0.0.0/0, or, B) Click
Delete to remove the offending inbound rule
9. Click Save rules
References:
1. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-
groups.html#deleting-security-group-rule
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 208
5.3 Ensure no security groups allow ingress from ::/0 to remote
server administration ports (Automated)
Profile Applicability:
• Level 1
Description:
Security groups provide stateful filtering of ingress and egress network traffic to AWS
resources. It is recommended that no security group allows unrestricted ingress access
to remote server administration ports, such as SSH to port 22 and RDP to port 3389.
Rationale:
Public access to remote server administration ports, such as 22 and 3389, increases
resource attack surface and unnecessarily raises the risk of resource compromise.
Impact:
When updating an existing environment, ensure that administrators have access to
remote server administration ports through another mechanism before removing access
by deleting the ::/0 inbound rule.
Audit:
Perform the following to determine if the account is configured as prescribed:
Note: A Port value of ALL or a port range such as 0-1024 are inclusive of port 22, 3389,
and other remote server administration ports.
Remediation:
Perform the following to implement the prescribed state:
Page 209
4. Select the security group
5. Click the Inbound Rules tab
6. Click the Edit inbound rules button
7. Identify the rules to be edited or removed
8. Either A) update the Source field to a range other than ::/0, or, B) Click Delete to
remove the offending inbound rule
9. Click Save rules
References:
1. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-
groups.html#deleting-security-group-rule
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 210
5.4 Ensure the default security group of every VPC restricts all
traffic (Automated)
Profile Applicability:
• Level 2
Description:
A VPC comes with a default security group whose initial settings deny all inbound traffic,
allow all outbound traffic, and allow all traffic between instances assigned to the security
group. If you don't specify a security group when you launch an instance, the instance is
automatically assigned to this default security group. Security groups provide stateful
filtering of ingress/egress network traffic to AWS resources. It is recommended that the
default security group restrict all traffic.
The default VPC in every region should have its default security group updated to
comply. Any newly created VPCs will automatically contain a default security group that
will need remediation to comply with this recommendation.
NOTE: When implementing this recommendation, VPC flow logging is invaluable in
determining the least privilege port access required by systems to work properly
because it can log all packet acceptances and rejections occurring under the current
security groups. This dramatically reduces the primary barrier to least privilege
engineering - discovering the minimum ports required by systems in the environment.
Even if the VPC flow logging recommendation in this benchmark is not adopted as a
permanent security measure, it should be used during any period of discovery and
engineering for least privileged security groups.
Rationale:
Configuring all VPC default security groups to restrict all traffic will encourage least
privilege security group development and mindful placement of AWS resources into
security groups which will in-turn reduce the exposure of those resources.
Impact:
Implementing this recommendation in an existing VPC containing operating resources
requires extremely careful migration planning as the default security groups are likely to
be enabling many ports that are unknown. Enabling VPC flow logging (of accepts) in an
existing environment that is known to be breach free will reveal the current pattern of
ports being used for each instance to communicate successfully.
Audit:
Perform the following to determine if the account is configured as prescribed:
Security Group State
Page 211
1. Login to the AWS Management Console at
https://console.aws.amazon.com/vpc/home
2. Repeat the next steps for all VPCs - including the default VPC in each AWS
region:
3. In the left pane, click Security Groups
4. For each default security group, perform the following:
5. Select the default security group
6. Click the Inbound Rules tab
7. Ensure no rule exist
8. Click the Outbound Rules tab
9. Ensure no rules exist
Remediation:
Security Group Members
Perform the following to implement the prescribed state:
1. Identify AWS resources that exist within the default security group
2. Create a set of least privilege security groups for those resources
3. Place the resources in those security groups
4. Remove the resources noted in #1 from the default security group
Page 212
9. Remove any Outbound rules
Recommended:
IAM groups allow you to edit the "name" field. After remediating default groups rules for
all VPCs in all regions, edit this field to add text similar to "DO NOT USE. DO NOT ADD
RULES"
References:
1. CCE-79201-0
2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-
security.html
3. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-
groups.html#default-security-group
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 213
5.5 Ensure routing tables for VPC peering are "least access"
(Manual)
Profile Applicability:
• Level 2
Description:
Once a VPC peering connection is established, routing tables must be updated to
establish any connections between the peered VPCs. These routes can be as specific
as desired - even peering a VPC to only a single host on the other side of the
connection.
Rationale:
Being highly selective in peering routing tables is a very effective way of minimizing the
impact of breach as resources outside of these routes are inaccessible to the peered
VPC.
Audit:
Review routing tables of peered VPCs for whether they route all subnets of each VPC
and whether that is necessary to accomplish the intended purposes for peering the
VPCs.
From Command Line:
1. List all the route tables from a VPC and check if "GatewayId" is pointing to a
<peering_connection_id> (e.g. pcx-1a2b3c4d) and if "DestinationCidrBlock" is as
specific as desired.
Remediation:
Remove and add route table entries to ensure that the least number of subnets or hosts
as is required to accomplish the purpose for peering are routable.
From Command Line:
1. For each <route_table_id> containing routes non compliant with your routing
policy (which grants more than desired "least access"), delete the non compliant
route:
Page 214
2. Create a new compliant route:
References:
1. https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/peering-
configurations-partial-access.html
2. https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc-peering-
connection.html
Additional Information:
If an organization has AWS transit gateway implemented in their VPC architecture they
should look to apply the recommendation above for "least access" routing architecture
at the AWS transit gateway level in combination with what must be implemented at the
standard VPC route table. More specifically, to route traffic between two or more VPCs
via a transit gateway VPCs must have an attachment to a transit gateway route table as
well as a route, therefore to avoid routing traffic between VPCs an attachment to the
transit gateway route table should only be added where there is an intention to route
traffic between the VPCs. As transit gateways are able to host multiple route tables it is
possible to group VPCs by attaching them to a common route table.
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
Page 215
5.6 Ensure that EC2 Metadata Service only allows IMDSv2
(Automated)
Profile Applicability:
• Level 1
Description:
When enabling the Metadata Service on AWS EC2 instances, users have the option of
using either Instance Metadata Service Version 1 (IMDSv1; a request/response
method) or Instance Metadata Service Version 2 (IMDSv2; a session-oriented method).
Rationale:
Instance metadata is data about your instance that you can use to configure or manage
the running instance. Instance metadata is divided into categories, for example, host
name, events, and security groups.
When enabling the Metadata Service on AWS EC2 instances, users have the option of
using either Instance Metadata Service Version 1 (IMDSv1; a request/response
method) or Instance Metadata Service Version 2 (IMDSv2; a session-oriented method).
With IMDSv2, every request is now protected by session authentication. A session
begins and ends a series of requests that software running on an EC2 instance uses to
access the locally-stored EC2 instance metadata and credentials.
Allowing Version 1 of the service may open EC2 instances to Server-Side Request
Forgery (SSRF) attacks, so Amazon recommends utilizing Version 2 for better instance
security.
Audit:
From Console:
1. Sign in to the AWS Management Console and navigate to the EC2 dashboard at
https://console.aws.amazon.com/ec2/.
2. In the left navigation panel, under the INSTANCES section, choose Instances.
3. Select the EC2 instance that you want to examine.
4. Check for the IMDSv2 status, and ensure that it is set to Required.
1. Run the describe-instances command using appropriate filtering to list the IDs
of all the existing EC2 instances currently available in the selected region:
Page 216
2. The command output should return a table with the requested instance IDs.
3. Now run the describe-instances command using an instance ID returned at the
previous step and custom filtering to determine whether the selected instance
has IMDSv2:
4. Ensure for all ec2 instances HttpTokens is set to required and State is set to
applied.
5. Repeat steps no. 3 and 4 to verify other EC2 instances provisioned within the
current region.
6. Repeat steps no. 1 – 5 to perform the audit process for other AWS regions.
Remediation:
From Console:
1. Sign in to the AWS Management Console and navigate to the EC2 dashboard at
https://console.aws.amazon.com/ec2/.
2. In the left navigation panel, under the INSTANCES section, choose Instances.
3. Select the EC2 instance that you want to examine.
4. Choose Actions > Instance Settings > Modify instance metadata options.
5. Ensure Instance metadata service is set to Enable and set IMDSv2 to Required.
6. Repeat steps no. 1 – 5 to perform the remediation process for other EC2
Instances in the all applicable AWS region(s).
1. Run the describe-instances command using appropriate filtering to list the IDs
of all the existing EC2 instances currently available in the selected region:
2. The command output should return a table with the requested instance IDs.
3. Now run the modify-instance-metadata-options command using an instance ID
returned at the previous step to update the Instance Metadata Version:
4. Repeat steps no. 1 – 3 to perform the remediation process for other EC2
Instances in the same AWS region.
5. Change the region by updating --region and repeat the entire process for other
regions.
Page 217
References:
1. https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-
proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
2. https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html
CIS Controls:
Page 218
Appendix: Summary Table
CIS Benchmark Recommendation Set
Correctly
Yes No
1.11 Do not setup access keys during initial user setup for all
IAM users that have a console password (Manual)
Page 219
CIS Benchmark Recommendation Set
Correctly
Yes No
1.13 Ensure there is only one active access key available for
any single IAM user (Automated)
1.18 Ensure IAM instance roles are used for AWS resource
access from instances (Automated)
2 Storage
Page 220
CIS Benchmark Recommendation Set
Correctly
Yes No
3 Logging
Page 221
CIS Benchmark Recommendation Set
Correctly
Yes No
4 Monitoring
Page 222
CIS Benchmark Recommendation Set
Correctly
Yes No
5 Networking
5.5 Ensure routing tables for VPC peering are "least access"
(Manual)
Page 223
Appendix: CIS Controls v7 IG 1 Mapped
Recommendations
Recommendation Set
Correctly
Yes No
1.1 Maintain current contact details
1.4 Ensure no 'root' user account access key exists
1.7 Eliminate use of the 'root' user for administrative and
daily tasks
1.12 Ensure credentials unused for 45 days or greater are
disabled
1.20 Ensure that IAM Access analyzer is enabled for all
regions
2.1.2 Ensure MFA Delete is enabled on S3 buckets
2.1.3 Ensure all data in Amazon S3 has been discovered,
classified and secured when required.
2.1.4 Ensure that S3 Buckets are configured with 'Block public
access (bucket settings)'
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled
for RDS Instances
2.3.3 Ensure that public access is not given to RDS Instance
3.1 Ensure CloudTrail is enabled in all regions
3.3 Ensure AWS Config is enabled in all regions
3.4 Ensure S3 bucket access logging is enabled on the
CloudTrail S3 bucket
3.7 Ensure VPC flow logging is enabled in all VPCs
3.8 Ensure that Object-level logging for write events is
enabled for S3 bucket
3.9 Ensure that Object-level logging for read events is
enabled for S3 bucket
4.8 Ensure S3 bucket policy changes are monitored
4.9 Ensure AWS Config configuration changes are monitored
4.10 Ensure security group changes are monitored
4.12 Ensure changes to network gateways are monitored
Page 224
Recommendation Set
Correctly
Yes No
4.13 Ensure route table changes are monitored
4.15 Ensure AWS Organizations changes are monitored
5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to
remote server administration ports
5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to
remote server administration ports
5.3 Ensure no security groups allow ingress from ::/0 to
remote server administration ports
5.4 Ensure the default security group of every VPC restricts
all traffic
5.5 Ensure routing tables for VPC peering are "least access"
Page 225
Appendix: CIS Controls v7 IG 2 Mapped
Recommendations
Recommendation Set
Correctly
Yes No
1.1 Maintain current contact details
1.2 Ensure security contact information is registered
1.4 Ensure no 'root' user account access key exists
1.5 Ensure MFA is enabled for the 'root' user account
1.6 Ensure hardware MFA is enabled for the 'root' user
account
1.7 Eliminate use of the 'root' user for administrative and
daily tasks
1.9 Ensure IAM password policy prevents password reuse
1.10 Ensure multi-factor authentication (MFA) is enabled for
all IAM users that have a console password
1.12 Ensure credentials unused for 45 days or greater are
disabled
1.20 Ensure that IAM Access analyzer is enabled for all
regions
1.21 Ensure IAM users are managed centrally via identity
federation or AWS Organizations for multi-account
environments
2.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests
2.1.2 Ensure MFA Delete is enabled on S3 buckets
2.1.3 Ensure all data in Amazon S3 has been discovered,
classified and secured when required.
2.1.4 Ensure that S3 Buckets are configured with 'Block public
access (bucket settings)'
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled
for RDS Instances
2.3.3 Ensure that public access is not given to RDS Instance
3.1 Ensure CloudTrail is enabled in all regions
3.3 Ensure AWS Config is enabled in all regions
Page 226
Recommendation Set
Correctly
Yes No
3.4 Ensure S3 bucket access logging is enabled on the
CloudTrail S3 bucket
3.7 Ensure VPC flow logging is enabled in all VPCs
3.8 Ensure that Object-level logging for write events is
enabled for S3 bucket
3.9 Ensure that Object-level logging for read events is
enabled for S3 bucket
4.1 Ensure unauthorized API calls are monitored
4.3 Ensure usage of 'root' account is monitored
4.8 Ensure S3 bucket policy changes are monitored
4.9 Ensure AWS Config configuration changes are monitored
4.10 Ensure security group changes are monitored
4.11 Ensure Network Access Control Lists (NACL) changes
are monitored
4.12 Ensure changes to network gateways are monitored
4.13 Ensure route table changes are monitored
4.14 Ensure VPC changes are monitored
4.15 Ensure AWS Organizations changes are monitored
4.16 Ensure AWS Security Hub is enabled
5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to
remote server administration ports
5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to
remote server administration ports
5.3 Ensure no security groups allow ingress from ::/0 to
remote server administration ports
5.4 Ensure the default security group of every VPC restricts
all traffic
5.5 Ensure routing tables for VPC peering are "least access"
Page 227
Appendix: CIS Controls v7 IG 3 Mapped
Recommendations
Recommendation Set
Correctly
Yes No
1.1 Maintain current contact details
1.2 Ensure security contact information is registered
1.4 Ensure no 'root' user account access key exists
1.5 Ensure MFA is enabled for the 'root' user account
1.6 Ensure hardware MFA is enabled for the 'root' user
account
1.7 Eliminate use of the 'root' user for administrative and
daily tasks
1.9 Ensure IAM password policy prevents password reuse
1.10 Ensure multi-factor authentication (MFA) is enabled for
all IAM users that have a console password
1.12 Ensure credentials unused for 45 days or greater are
disabled
1.20 Ensure that IAM Access analyzer is enabled for all
regions
1.21 Ensure IAM users are managed centrally via identity
federation or AWS Organizations for multi-account
environments
2.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests
2.1.2 Ensure MFA Delete is enabled on S3 buckets
2.1.3 Ensure all data in Amazon S3 has been discovered,
classified and secured when required.
2.1.4 Ensure that S3 Buckets are configured with 'Block public
access (bucket settings)'
2.2.1 Ensure EBS Volume Encryption is Enabled in all Regions
2.3.1 Ensure that encryption-at-rest is enabled for RDS
Instances
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled
for RDS Instances
2.3.3 Ensure that public access is not given to RDS Instance
Page 228
Recommendation Set
Correctly
Yes No
2.4.1 Ensure that encryption is enabled for EFS file systems
3.1 Ensure CloudTrail is enabled in all regions
3.3 Ensure AWS Config is enabled in all regions
3.4 Ensure S3 bucket access logging is enabled on the
CloudTrail S3 bucket
3.5 Ensure CloudTrail logs are encrypted at rest using KMS
CMKs
3.6 Ensure rotation for customer-created symmetric CMKs is
enabled
3.7 Ensure VPC flow logging is enabled in all VPCs
3.8 Ensure that Object-level logging for write events is
enabled for S3 bucket
3.9 Ensure that Object-level logging for read events is
enabled for S3 bucket
4.1 Ensure unauthorized API calls are monitored
4.3 Ensure usage of 'root' account is monitored
4.8 Ensure S3 bucket policy changes are monitored
4.9 Ensure AWS Config configuration changes are monitored
4.10 Ensure security group changes are monitored
4.11 Ensure Network Access Control Lists (NACL) changes
are monitored
4.12 Ensure changes to network gateways are monitored
4.13 Ensure route table changes are monitored
4.14 Ensure VPC changes are monitored
4.15 Ensure AWS Organizations changes are monitored
4.16 Ensure AWS Security Hub is enabled
5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to
remote server administration ports
5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to
remote server administration ports
5.3 Ensure no security groups allow ingress from ::/0 to
remote server administration ports
5.4 Ensure the default security group of every VPC restricts
all traffic
Page 229
Recommendation Set
Correctly
Yes No
5.5 Ensure routing tables for VPC peering are "least access"
Page 230
Appendix: CIS Controls v7 Unmapped
Recommendations
Recommendation Set
Correctly
Yes No
Page 231
Appendix: CIS Controls v8 IG 1 Mapped
Recommendations
Recommendation Set
Correctly
Yes No
1.1 Maintain current contact details
1.2 Ensure security contact information is registered
1.3 Ensure security questions are registered in the AWS
account
1.4 Ensure no 'root' user account access key exists
1.5 Ensure MFA is enabled for the 'root' user account
1.6 Ensure hardware MFA is enabled for the 'root' user
account
1.7 Eliminate use of the 'root' user for administrative and
daily tasks
1.8 Ensure IAM password policy requires minimum length of
14 or greater
1.9 Ensure IAM password policy prevents password reuse
1.10 Ensure multi-factor authentication (MFA) is enabled for
all IAM users that have a console password
1.11 Do not setup access keys during initial user setup for all
IAM users that have a console password
1.12 Ensure credentials unused for 45 days or greater are
disabled
1.16 Ensure IAM policies that allow full "*:*" administrative
privileges are not attached
1.17 Ensure a support role has been created to manage
incidents with AWS Support
1.19 Ensure that all the expired SSL/TLS certificates stored in
AWS IAM are removed
1.20 Ensure that IAM Access analyzer is enabled for all
regions
2.1.2 Ensure MFA Delete is enabled on S3 buckets
2.1.3 Ensure all data in Amazon S3 has been discovered,
classified and secured when required.
Page 232
Recommendation Set
Correctly
Yes No
2.1.4 Ensure that S3 Buckets are configured with 'Block public
access (bucket settings)'
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled
for RDS Instances
2.3.3 Ensure that public access is not given to RDS Instance
3.3 Ensure AWS Config is enabled in all regions
3.4 Ensure S3 bucket access logging is enabled on the
CloudTrail S3 bucket
3.7 Ensure VPC flow logging is enabled in all VPCs
4.10 Ensure security group changes are monitored
5.4 Ensure the default security group of every VPC restricts
all traffic
5.5 Ensure routing tables for VPC peering are "least access"
Page 233
Appendix: CIS Controls v8 IG 2 Mapped
Recommendations
Recommendation Set
Correctly
Yes No
1.1 Maintain current contact details
1.2 Ensure security contact information is registered
1.3 Ensure security questions are registered in the AWS
account
1.4 Ensure no 'root' user account access key exists
1.5 Ensure MFA is enabled for the 'root' user account
1.6 Ensure hardware MFA is enabled for the 'root' user
account
1.7 Eliminate use of the 'root' user for administrative and
daily tasks
1.8 Ensure IAM password policy requires minimum length of
14 or greater
1.9 Ensure IAM password policy prevents password reuse
1.10 Ensure multi-factor authentication (MFA) is enabled for
all IAM users that have a console password
1.11 Do not setup access keys during initial user setup for all
IAM users that have a console password
1.12 Ensure credentials unused for 45 days or greater are
disabled
1.16 Ensure IAM policies that allow full "*:*" administrative
privileges are not attached
1.17 Ensure a support role has been created to manage
incidents with AWS Support
1.19 Ensure that all the expired SSL/TLS certificates stored in
AWS IAM are removed
1.20 Ensure that IAM Access analyzer is enabled for all
regions
1.21 Ensure IAM users are managed centrally via identity
federation or AWS Organizations for multi-account
environments
Page 234
Recommendation Set
Correctly
Yes No
2.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests
2.1.2 Ensure MFA Delete is enabled on S3 buckets
2.1.3 Ensure all data in Amazon S3 has been discovered,
classified and secured when required.
2.1.4 Ensure that S3 Buckets are configured with 'Block public
access (bucket settings)'
2.2.1 Ensure EBS Volume Encryption is Enabled in all Regions
2.3.1 Ensure that encryption-at-rest is enabled for RDS
Instances
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled
for RDS Instances
2.3.3 Ensure that public access is not given to RDS Instance
2.4.1 Ensure that encryption is enabled for EFS file systems
3.1 Ensure CloudTrail is enabled in all regions
3.2 Ensure CloudTrail log file validation is enabled
3.3 Ensure AWS Config is enabled in all regions
3.4 Ensure S3 bucket access logging is enabled on the
CloudTrail S3 bucket
3.5 Ensure CloudTrail logs are encrypted at rest using KMS
CMKs
3.6 Ensure rotation for customer-created symmetric CMKs is
enabled
3.7 Ensure VPC flow logging is enabled in all VPCs
3.8 Ensure that Object-level logging for write events is
enabled for S3 bucket
3.9 Ensure that Object-level logging for read events is
enabled for S3 bucket
4.1 Ensure unauthorized API calls are monitored
4.2 Ensure management console sign-in without MFA is
monitored
4.3 Ensure usage of 'root' account is monitored
4.4 Ensure IAM policy changes are monitored
4.5 Ensure CloudTrail configuration changes are monitored
Page 235
Recommendation Set
Correctly
Yes No
4.6 Ensure AWS Management Console authentication
failures are monitored
4.7 Ensure disabling or scheduled deletion of customer
created CMKs is monitored
4.8 Ensure S3 bucket policy changes are monitored
4.9 Ensure AWS Config configuration changes are monitored
4.10 Ensure security group changes are monitored
4.11 Ensure Network Access Control Lists (NACL) changes
are monitored
4.12 Ensure changes to network gateways are monitored
4.13 Ensure route table changes are monitored
4.14 Ensure VPC changes are monitored
4.15 Ensure AWS Organizations changes are monitored
5.4 Ensure the default security group of every VPC restricts
all traffic
5.5 Ensure routing tables for VPC peering are "least access"
Page 236
Appendix: CIS Controls v8 IG 3 Mapped
Recommendations
Recommendation Set
Correctly
Yes No
1.1 Maintain current contact details
1.2 Ensure security contact information is registered
1.3 Ensure security questions are registered in the AWS
account
1.4 Ensure no 'root' user account access key exists
1.5 Ensure MFA is enabled for the 'root' user account
1.6 Ensure hardware MFA is enabled for the 'root' user
account
1.7 Eliminate use of the 'root' user for administrative and
daily tasks
1.8 Ensure IAM password policy requires minimum length of
14 or greater
1.9 Ensure IAM password policy prevents password reuse
1.10 Ensure multi-factor authentication (MFA) is enabled for
all IAM users that have a console password
1.11 Do not setup access keys during initial user setup for all
IAM users that have a console password
1.12 Ensure credentials unused for 45 days or greater are
disabled
1.15 Ensure IAM Users Receive Permissions Only Through
Groups
1.16 Ensure IAM policies that allow full "*:*" administrative
privileges are not attached
1.17 Ensure a support role has been created to manage
incidents with AWS Support
1.18 Ensure IAM instance roles are used for AWS resource
access from instances
1.19 Ensure that all the expired SSL/TLS certificates stored in
AWS IAM are removed
Page 237
Recommendation Set
Correctly
Yes No
1.20 Ensure that IAM Access analyzer is enabled for all
regions
1.21 Ensure IAM users are managed centrally via identity
federation or AWS Organizations for multi-account
environments
2.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests
2.1.2 Ensure MFA Delete is enabled on S3 buckets
2.1.3 Ensure all data in Amazon S3 has been discovered,
classified and secured when required.
2.1.4 Ensure that S3 Buckets are configured with 'Block public
access (bucket settings)'
2.2.1 Ensure EBS Volume Encryption is Enabled in all Regions
2.3.1 Ensure that encryption-at-rest is enabled for RDS
Instances
2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled
for RDS Instances
2.3.3 Ensure that public access is not given to RDS Instance
2.4.1 Ensure that encryption is enabled for EFS file systems
3.1 Ensure CloudTrail is enabled in all regions
3.2 Ensure CloudTrail log file validation is enabled
3.3 Ensure AWS Config is enabled in all regions
3.4 Ensure S3 bucket access logging is enabled on the
CloudTrail S3 bucket
3.5 Ensure CloudTrail logs are encrypted at rest using KMS
CMKs
3.6 Ensure rotation for customer-created symmetric CMKs is
enabled
3.7 Ensure VPC flow logging is enabled in all VPCs
3.8 Ensure that Object-level logging for write events is
enabled for S3 bucket
3.9 Ensure that Object-level logging for read events is
enabled for S3 bucket
4.1 Ensure unauthorized API calls are monitored
4.2 Ensure management console sign-in without MFA is
monitored
Page 238
Recommendation Set
Correctly
Yes No
4.3 Ensure usage of 'root' account is monitored
4.4 Ensure IAM policy changes are monitored
4.5 Ensure CloudTrail configuration changes are monitored
4.6 Ensure AWS Management Console authentication
failures are monitored
4.7 Ensure disabling or scheduled deletion of customer
created CMKs is monitored
4.8 Ensure S3 bucket policy changes are monitored
4.9 Ensure AWS Config configuration changes are monitored
4.10 Ensure security group changes are monitored
4.11 Ensure Network Access Control Lists (NACL) changes
are monitored
4.12 Ensure changes to network gateways are monitored
4.13 Ensure route table changes are monitored
4.14 Ensure VPC changes are monitored
4.15 Ensure AWS Organizations changes are monitored
5.4 Ensure the default security group of every VPC restricts
all traffic
5.5 Ensure routing tables for VPC peering are "least access"
Page 239
Appendix: CIS Controls v8 Unmapped
Recommendations
Recommendation Set
Correctly
Yes No
4.16 Ensure AWS Security Hub is enabled
5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to
remote server administration ports
5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to
remote server administration ports
5.3 Ensure no security groups allow ingress from ::/0 to
remote server administration ports
Page 240
Appendix: Change History
Date Version Changes for this version
Dec 13, 2023 3.0.0 UPDATE - Ensure S3 Bucket Policy is set to deny HTTP
requests - Update CLI result text (Ticket 19410)
Jan 17, 2024 3.0.0 DELETE - Ensure CloudTrail trails are integrated with
CloudWatch Logs (Ticket 19982)
Jan 17, 2024 3.0.0 DELETE - Ensure the S3 bucket used to store CloudTrail
logs is not publicly accessible (Ticket 19344)
Jan 25, 2024 3.0.0 UPDATE - Ensure there is only one active access key
available for any single IAM user - MITRE mapping appears
to have incorrect Tactic in spreadsheet (Ticket 15678)
Jan 29, 2024 3.0.0 UPDATE - Ensure security questions are registered in the
AWS account - Setting being deprecated (Ticket 20741)
Jan 30, 2024 3.0.0 UPDATE - Ensure that Object-level logging for write events
is enabled for S3 bucket - Update console steps (Ticket
19422)
Jan 30, 2024 3.0.0 UPDATE - Ensure route table changes are monitored - filter
update (Ticket 18980)
Jan 30, 2024 3.0.0 UPDATE - Ensure a support role has been created to
manage incidents with AWS Support - add impact
statement wording (Ticket 19275)
Jan 30, 2024 3.0.0 UPDATE - Ensure that EC2 Metadata Service only allows
IMDSv2 - Rationale and Audit/Remediation steps (Ticket
19111)
Jan 31, 2024 3.0.0 UPDATE - Ensure that EC2 Metadata Service only allows
IMDSv2 - Needs to have controls mapped (Ticket 20204)
Jan 31, 2024 3.0.0 UPDATE - Ensure IAM users are managed centrally via
identity federation or AWS Organizations for multi-account
environments - audit step updates made (Ticket 20713)
Page 241
Date Version Changes for this version
Jan 31, 2024 3.0.0 UPDATE - Ensure that encryption is enabled for EFS file
systems Change Assessment Status (Ticket 20721)
Jan 31, 2024 3.0.0 UPDATE - Ensure that public access is not given to RDS
Instance - Public accessibility may be required for Data
Lakes, instead of blocking PublicAccess, focus on the
associated Security Group for 0.0.0.0/0 (Ticket 18651)
Jan 31, 2024 3.0.0 UPDATE - Ensure rotation for customer-created symmetric
CMKs is enabled - small updates to audit and remediation
(Ticket 19859)
Mar 21, 2023 2.0.0 UPDATE - Ensure CloudTrail trails are integrated with
CloudWatch Logs - correct property name (Ticket 17189)
Apr 3, 2023 2.0.0 UPDATE - Ensure access keys are rotated every 90 days
or less - add last rotated 2nd value (Ticket 18223)
Apr 18, 2023 2.0.0 UPDATE - Ensure IAM Users Receive Permissions Only
Through Groups - Add method to description (Ticket 18224)
Apr 25, 2023 2.0.0 UPDATE - Ensure MFA Delete is enabled on S3 buckets -
make L2 and expand impact statement (Ticket 18442)
May 16, 2023 2.0.0 UPDATE - Ensure hardware MFA is enabled for the 'root'
user account - change to manual assessment status (Ticket
17360)
May 16, 2023 2.0.0 UPDATE - Eliminate use of the 'root' user for administrative
and daily tasks - Change to Manual (Ticket 16559)
May 16, 2023 2.0.0 UPDATE - Ensure IAM instance roles are used for AWS
resource access from instances - Add CLI steps for audit
and remediation (Ticket 17698)
May 22, 2023 2.0.0 UPDATE - Ensure that encryption is enabled for RDS
Instances - Change Tile to include At Rest (Ticket 17648)
May 22, 2023 2.0.0 UPDATE - Ensure security contact information is registered
- Add CLI step for remediation (Ticket 18087)
Page 242
Date Version Changes for this version
May 22, 2023 2.0.0 UPDATE - Ensure that IAM Access analyzer is enabled for
all regions - Add Additional Language for All Enabled
Regions (Ticket 17184)
May 22, 2023 2.0.0 UPDATE - Ensure AWS Security Hub is enabled -
Recommend to change this check to Manual instead of
Automated (Ticket 16590)
Jun 2, 2023 2.0.0 UPDATE - Ensure AWS Config is enabled in all regions -
Correct Remediation Steps (Ticket 16320)
Jun 2, 2023 2.0.0 ADD - Ensure that EC2 Metadata Service only allows
IMDSv2 (Ticket 15900)
Jun 2, 2023 2.0.0 UPDATE - Ensure a log metric filter and alarm exist for
unauthorized API calls - Fix metric filter to avoid including
all events (Ticket 16623)
Jun 5, 2023 2.0.0 UPDATE - Do not setup access keys during initial user
setup for all IAM users that have a console password -
change assessment status to manual (Ticket 16561)
Jun 6, 2023 2.0.0 Update - Ensure no 'root' user account access key exists -
Re-wording of audit section (Ticket 18719)
Jun 14, 2023 2.0.0 ADD - Restrict use of AWS CloudShell (Ticket 17641)
Jun 14, 2023 2.0.0 UPDATE - All recommendations in the monitoring section -
changing wording to be more agnostic (Ticket 18846)
Jun 27, 2023 2.0.0 UPDATE - Ensure route table changes are monitored -
expand rational (Ticket 18946)
Jun 28, 2023 2.0.0 UPDATE - Ensure a support role has been created to
manage incidents with AWS Support - change language to
note other ways to assign AWS Support role (Ticket 17185)
Jun 28, 2023 2.0.0 UPDATE - Ensure the S3 bucket used to store CloudTrail
logs is not publicly accessible - add PrincipalOrgID wording
(Ticket 19073)
Page 243
Date Version Changes for this version
Jun 28, 2023 2.0.0 UPDATE - Ensure no Network ACLs allow ingress from
0.0.0.0/0 to remote server administration ports - Inclusion of
protocols for the ports (Ticket 19035)
Jun 28, 2023 2.0.0 UPDATE - Ensure no security groups allow ingress from
0.0.0.0/0 to remote server administration ports - Inclusion of
protocols for the ports (Ticket 19036)
Page 244