#TRUSTED 03cf4bda9c06caa34fb43389d10b774a3515a65cef7d18c3a04b7925a834234ee38822b2d4df61166d112814a326d421cac699ae3d19e479f45b03aefea4a5d734b79a49ca7c028ebee6d4204c0e3e0bdcd86dbfe24d295b5162b557539699367856be50a8298d1cfa773c782a242b9eaca81bd3a95e403a793e0e659e729924ff8a97919ac5db3ceb401f1f3595d60bf9d9c91b5fe9aac075d4f4fb78507741b9b5a0374cc882c3080543e899dfec651106b8e7b317e1fe033a392aac2e4d4f68135aa1020e8ae5d982c75ccae15b1a7dd317cede6400397c29be99d9c326a442e139ef42cc7f413f7fa5c2eb0feea07bf275bbea34552140f686537f710856c9c1915d02dbf8aa7f752a63de484bb79a00edc3cd1d4496f162facbcac1655f60c1b1c5c31c37ee236f163ef650787f5af62195c868a7bb6d3e25e9160891b710855feb79f29eab66904e6da49dabb7f5b6f151fe42a9a8bb9d738e1fc47017327da25daf94c36337e47364a2bb52a0a1095722ec5b4ffe137e4748adf7667b6330306053093231b0772b15cab54cbbe5460ca6a54105852c4e7470ea8cfc2839ccac5d0d46e0da2f2a288067a67537f996ca9da25db85dc8d4a608593d04a2f62fdea734ec3ace7cf5ed37693b4694eba84c2c030b8708cfd247b0cfbbe1be4bedc71b91b549e326894f2d07db01bc56cfb20968b4c9cdf34270c5e123fba7
#TRUST-RSA-SHA256 24e846cd5835fe3463414682b27c279c3667a5a73d28178b6d432c4956537d9f6b401d92aad07f97ff2e3a217db534eee57fd615cf222627785efe186977fd43363fe861cbd1dc69c3f013346b3c7166a32d0d14e7313da2b39cb8a3e611a920bf8f668b304cf95086480e87c24a431b5636afb963466366fbbc2363dac35fc1c176029bba0a2665e346ff4e5ed9d4298456027090a2ddcc06af92fc371f51dc4c846864ea2e891e9cf245b332863b31643b20b58379b1a7733698a4ff206b1d7d5cbf2ba6141933138966da504594d69911a9cbd158f6fef9c4822108ea744c6a74b2bc11b19e4ee4b3838bfbb78f361781b52567b0c745a57a9f6224e02d6114eec82d968d8a3a27b627114470aec5e1b66a210a6a011c33fa59f347985b2d841daed345c479428e990ccde3a988f12a9fa0887c8194a73341c52abc9aece04c3b515c3c9b367df5a104437f968ea066b1212c850f01558ed4dee08e9f7a2567ecda26ae422c6fff13075fb093e8012f2b163240f2e2abf7138ff140c087901bc95f17280ca3fb6682a953cebd13cc259fd0dea548785ece3c2e1ed9cbc918bbd9fd2681ff6b8db8a7840bb85d057fd5b495a973d3b8e751b025a8b9e16a33750f10699268235b49dd030f8adb7602460d44a6b623cf421394aff3217d811044e118faa906f800962208fb96fd25da923cd9fda6d9c54453c280a416c61546
#
# This script is Copyright (C) 2004-2024 and is owned by Tenable, Inc. or an Affiliate thereof.
#
# This script is released under the Tenable Subscription License and
# may not be used from within scripts released under another license
# without authorization from Tenable, Inc.
#
# See the following licenses for details:
#
# http://static.tenable.com/prod_docs/Nessus_6_SLA_and_Subscription_Agreement.pdf
#
# @PROFESSIONALFEED@
# $Revision: 1.2 $
# $Date: 2024/10/01 $
#
# description : This document implements the security configuration as recommended by the
# CIS Amazon Web Services Foundations Benchmark
#
#
#Safeguard AWS Foundations Audit File 2.0.0
#
# CIS
# Amazon Web Services Foundations
# L1
# 3.0.0
# https://workbench.cisecurity.org/benchmarks/14207
#
#amazon_aws,amazon,aws,security,cis,update_20230227
#CCE,CSCv6,CSCv7,CSCv8,LEVEL
#
#
# INACTIVE_ACCOUNT_DAYS
# 60
# Days without Account activity
# Inactive Days
# INTEGER
#
#
#
description : "1.1 Maintain current contact details"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "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 ).
Sign in to the AWS Management Console and open the Billing and Cost Management console at https://console.aws.amazon.com/billing/home#/.
On the navigation bar, choose your account name, and then choose Account.
On the Account Settings page, next to Account Settings, choose Edit.
Next to the field that you need to update, choose Edit.
After you have entered your changes, choose Save changes.
After you have made your changes, choose Done.
To edit your contact information, under Contact Information, choose Edit.
For the fields that you want to change, type your updated information, and then choose Update."
reference : "800-171|3.6.1,800-171|3.6.2,800-53|IR-6,800-53|IR-6(3),800-53r5|IR-6,800-53r5|IR-6(3),CSCv7|19.3,CSCv8|17.2,CSF|RS.CO-2,CSF2.0|RC.CO-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,CSF2.0|RS.CO-02,CSF2.0|RS.CO-03,CSF2.0|RS.MA-01,CSF2.0|RS.MA-02,CSF2.0|RS.MA-03,CSF2.0|RS.MA-04,GDPR|32.1.b,GDPR|32.1.d,HIPAA|164.306(a)(1),ITSG-33|IR-6,LEVEL|1M,NESA|M1.3.3,QCSC-v1|10.2.1,QCSC-v1|11.2"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "1.2 Ensure security contact information is registered"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "Perform the following to establish security contact information:
From Console:
Click on your account name at the top right corner of the console.
From the drop-down menu Click My Account
Scroll down to the Alternate Contacts section
Enter contact information in the Security section
From Command Line:
Run the following command with the following input parameters:
--email-address, --name, and --phone-number.
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."
reference : "800-171|3.6.1,800-171|3.6.2,800-53|CP-8,800-53|IR-6,800-53|IR-6(3),800-53|IR-8,800-53r5|CP-8,800-53r5|IR-6,800-53r5|IR-6(3),800-53r5|IR-8,CCE|CCE-79200-2,CSCv7|19,CSCv7|19.2,CSCv8|17.2,CSCv8|17.6,CSF|DE.AE-3,CSF|DE.AE-5,CSF|ID.BE-4,CSF|PR.IP-7,CSF|PR.IP-9,CSF|PR.PT-4,CSF|RC.IM-1,CSF|RC.IM-2,CSF|RC.RP-1,CSF|RS.AN-4,CSF|RS.CO-1,CSF|RS.CO-2,CSF|RS.CO-3,CSF|RS.CO-4,CSF|RS.IM-1,CSF|RS.IM-2,CSF|RS.RP-1,CSF2.0|DE.AE-03,CSF2.0|DE.AE-08,CSF2.0|ID.IM-01,CSF2.0|ID.IM-02,CSF2.0|ID.IM-03,CSF2.0|ID.IM-04,CSF2.0|PR.IR-04,CSF2.0|RC.CO-03,CSF2.0|RC.RP-01,CSF2.0|RC.RP-02,CSF2.0|RC.RP-04,CSF2.0|RC.RP-06,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,CSF2.0|RS.AN-08,CSF2.0|RS.CO-02,CSF2.0|RS.CO-03,CSF2.0|RS.MA,CSF2.0|RS.MA-01,CSF2.0|RS.MA-02,CSF2.0|RS.MA-03,CSF2.0|RS.MA-04,CSF2.0|RS.MA-05,GDPR|32.1.b,GDPR|32.1.c,GDPR|32.1.d,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(ii),ITSG-33|CP-8,ITSG-33|CP-8a.,ITSG-33|IR-6,ITSG-33|IR-8,LEVEL|1M,NESA|M1.3.3,NESA|T2.2.4,NESA|T4.5.1,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,SWIFT-CSCv1|7.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "1.3 Ensure security questions are registered in the AWS account"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "From Console:
Login to the AWS Account as the 'root' user
Click on the from the top right of the console
From the drop-down menu Click My Account
Scroll down to the Configure Security Questions section
Click on Edit
Click on each Question
From the drop-down select an appropriate question
Click on the Answer section
Enter an appropriate answer
Follow process for all 3 questions
Click Update when complete
Save Questions and Answers and place in a secure physical location"
reference : "800-171|3.6.1,800-171|3.6.2,800-53|IR-6,800-53|IR-6(3),800-53r5|IR-6,800-53r5|IR-6(3),CSCv7|16,CSCv8|17.2,CSF|RS.CO-2,CSF2.0|RC.CO-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,CSF2.0|RS.CO-02,CSF2.0|RS.CO-03,CSF2.0|RS.MA-01,CSF2.0|RS.MA-02,CSF2.0|RS.MA-03,CSF2.0|RS.MA-04,GDPR|32.1.b,GDPR|32.1.d,HIPAA|164.306(a)(1),ITSG-33|IR-6,LEVEL|1M,NESA|M1.3.3,QCSC-v1|10.2.1,QCSC-v1|11.2"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
type : IAM
description : "'Access Key 1'"
aws_action : "GetCredentialReport"
xsl_stmt : "[root_account] : Access Key 1 Active = [root_account] : Not Found"
regex : "\[root_account\] :"
expect : "\[root_account\] : Access Key 1 Active = false"
type : IAM
description : "'Access Key 2'"
aws_action : "GetCredentialReport"
xsl_stmt : "[root_account] : Access Key 2 Active = [root_account] : Not Found"
regex : "\[root_account\] :"
expect : "\[root_account\] : Access Key 2 Active = false"
description : "1.4 Ensure no 'root' user account access key exists"
info : "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."
solution : "Perform the following to delete active 'root' user access keys.
From Console:
Sign in to the AWS Management Console as 'root' and open the IAM console at https://console.aws.amazon.com/iam/.
Click on at the top right and select My Security Credentials from the drop down list.
On the pop out screen Click on Continue to Security Credentials.
Click on Access Keys (Access Key ID and Secret Access Key).
Under the Status column (if there are any Keys which are active).
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."
reference : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.1.6,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|AC-6(2),800-53|AC-6(5),800-53|MP-2,800-53r5|AC-3,800-53r5|AC-5,800-53r5|AC-6,800-53r5|AC-6(2),800-53r5|AC-6(5),800-53r5|MP-2,CCE|CCE-78910-7,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|4.3,CSCv8|3.3,CSCv8|5.4,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.2.3,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|AC-6(2),ITSG-33|AC-6(5),ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|AM32,NIAv2|AM33,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,NIAv2|VL3a,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|1.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
show_output : YES
type : IAM
description : "1.5 Ensure MFA is enabled for the 'root' user account"
info : "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."
solution : "Perform the following to establish MFA for the 'root' user account:
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.
Choose Dashboard , and under Security Status , expand Activate MFA on your root account.
Choose Activate MFA
In the wizard, choose A virtual MFA device and then choose Next Step .
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.
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).
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.
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."
reference : "800-171|3.5.3,800-53|IA-2(1),800-53r5|IA-2(1),CCE|CCE-78911-5,CN-L3|7.1.2.7(b),CSCv7|4.5,CSCv8|6.5,CSF|PR.AC-1,CSF2.0|PR.AA-01,CSF2.0|PR.AA-03,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-2(1),LEVEL|1A,NESA|T5.4.2,NIAv2|AM36,NIAv2|VL3c,QCSC-v1|5.2.2,QCSC-v1|13.2,SWIFT-CSCv1|1.2,TBA-FIISB|35.1,TBA-FIISB|36.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetAccountSummary"
xsl_stmt : "AccountMFAEnabled : AccountMFAEnabled : Not Found"
regex : "AccountMFAEnabled :"
expect : "AccountMFAEnabled : 1$"
description : "1.7 Eliminate use of the 'root' user for administrative and daily tasks"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "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:
Change the 'root' user password.
Deactivate or delete any access keys associated with 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."
reference : "800-171|3.1.5,800-171|3.1.6,800-53|AC-6(2),800-53|AC-6(5),800-53r5|AC-6(2),800-53r5|AC-6(5),CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.10.6(a),CSCv7|4.3,CSCv8|5.4,CSF|PR.AC-4,CSF2.0|PR.AA-05,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.3,ITSG-33|AC-6(2),ITSG-33|AC-6(5),LEVEL|1M,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.6.1,NIAv2|AM1,NIAv2|AM23f,NIAv2|AM32,NIAv2|AM33,NIAv2|SS13c,NIAv2|SS15c,NIAv2|VL3a,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|5.2.2,QCSC-v1|6.2,SWIFT-CSCv1|1.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
type : IAM
description : "1.8 Ensure IAM password policy requires minimum length of 14 or greater"
info : "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."
solution : "Perform the following to set the password policy as prescribed:
From Console:
Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings)
Go to IAM Service on the AWS Console
Click on Account Settings on the Left Pane
Set 'Minimum password length' to 14 or greater.
Click 'Apply password policy'
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."
reference : "800-171|3.5.2,800-53|IA-5(1),800-53r5|IA-5(1),CCE|CCE-78907-3,CSCv7|16,CSCv8|5,CSCv8|5.2,CSF|PR.AC-1,CSF2.0|PR.AA-01,CSF2.0|PR.AA-03,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-5(1),LEVEL|1A,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|13.2,SWIFT-CSCv1|4.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetAccountPasswordPolicy"
xsl_stmt : "
MinimumPasswordLength : MinimumPasswordLength : Not Found"
regex : "MinimumPasswordLength :"
expect : "MinimumPasswordLength : (1[4-9]|[2-9][0-9]|1[01][0-9]|12[0-8])$"
type : IAM
description : "1.9 Ensure IAM password policy prevents password reuse"
info : "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."
solution : "Perform the following to set the password policy as prescribed:
From Console:
Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings)
Go to IAM Service on the AWS Console
Click on Account Settings on the Left Pane
Check 'Prevent password reuse'
Set 'Number of passwords to remember' is set to 24
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."
reference : "800-171|3.5.2,800-53|IA-5(1),800-53r5|IA-5(1),CCE|CCE-78908-1,CSCv7|4.4,CSCv8|5.2,CSF|PR.AC-1,CSF2.0|PR.AA-01,CSF2.0|PR.AA-03,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-5(1),LEVEL|1A,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|13.2,SWIFT-CSCv1|4.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetAccountPasswordPolicy"
xsl_stmt : "
PasswordReusePrevention : PasswordReusePrevention : Not Found"
regex : "PasswordReusePrevention :"
expect : "PasswordReusePrevention : (2[4-9]|[3-9][0-9])$"
type : IAM
description : "1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password"
info : "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."
solution : "Perform the following to enable MFA:
From Console:
Sign in to the AWS Management Console and open the IAM console at 'https://console.aws.amazon.com/iam/'
In the left pane, select Users.
In the User Name list, choose the name of the intended MFA user.
Choose the Security Credentials tab, and then choose Manage MFA Device.
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.
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).
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.
When you are finished, the virtual MFA device starts generating one-time passwords.
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.
Click Assign MFA."
reference : "800-171|3.5.3,800-53|IA-2(1),800-53r5|IA-2(1),CCE|CCE-78901-6,CN-L3|7.1.2.7(b),CSCv7|4.5,CSCv8|6.5,CSF|PR.AC-1,CSF2.0|PR.AA-01,CSF2.0|PR.AA-03,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-2(1),LEVEL|1A,NESA|T5.4.2,NIAv2|AM36,NIAv2|VL3c,QCSC-v1|5.2.2,QCSC-v1|13.2,SWIFT-CSCv1|1.2,TBA-FIISB|35.1,TBA-FIISB|36.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetCredentialReport"
xsl_stmt : "Console user does not have MFA enabled
All console users have MFA enabled.
"
regex : ".+"
expect : "All console users have MFA enabled."
description : "1.11 Do not setup access keys during initial user setup for all IAM users that have a console password"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "Perform the following to delete access keys that do not pass the audit:
From Console:
Login to the AWS Management Console:
Click Services
Click IAM
Click on Users
Click on Security Credentials
As an Administrator
Click on the X (Delete) for keys that were created at the same time as the user profile but have not been used.
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.
From Command Line:
aws iam delete-access-key --access-key-id --user-name "
reference : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.1.6,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|AC-6(2),800-53|AC-6(5),800-53|MP-2,800-53r5|AC-3,800-53r5|AC-5,800-53r5|AC-6,800-53r5|AC-6(2),800-53r5|AC-6(5),800-53r5|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|16,CSCv8|3.3,CSCv8|5.4,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.2.3,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|AC-6(2),ITSG-33|AC-6(5),ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1M,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|AM32,NIAv2|AM33,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,NIAv2|VL3a,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|1.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
type : IAM
description : "1.12 Ensure credentials unused for 45 days or greater are disabled"
info : "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 60 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."
solution : "From Console:
Perform the following to manage Unused Password (IAM user console access)
Login to the AWS Management Console:
Click Services
Click IAM
Click on Users
Click on Security Credentials
Select user whose Console last sign-in is greater than 45 days
Click Security credentials
In section Sign-in credentials, Console password click Manage
Under Console Access select Disable
10.Click Apply
Perform the following to deactivate Access Keys:
Login to the AWS Management Console:
Click Services
Click IAM
Click on Users
Click on Security Credentials
Select any access keys that are over 45 days old and that have been used and
Click on Make Inactive
Select any access keys that are over 45 days old and that have not been used and
Click the X to Delete"
reference : "800-171|3.1.1,800-53|AC-2(3),800-53r5|AC-2(3),CCE|CCE-78900-8,CN-L3|7.1.3.2(e),CN-L3|8.1.4.2(c),CSCv7|16.9,CSCv8|5.3,CSF|PR.AC-1,CSF|PR.AC-4,CSF2.0|DE.CM-01,CSF2.0|DE.CM-03,CSF2.0|PR.AA-01,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ISO/IEC-27001|A.9.2.6,ITSG-33|AC-2(3),LEVEL|1A,NIAv2|AM26,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2,TBA-FIISB|36.2.2"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
name : INACTIVE_USERS_EX_ROOT_AUDIT_STRICT
days : "@INACTIVE_ACCOUNT_DAYS@"
type : IAM
description : "1.13 Ensure there is only one active access key available for any single IAM user"
info : "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."
solution : "From Console:
Sign in to the AWS Management Console and navigate to IAM dashboard at https://console.aws.amazon.com/iam/.
In the left navigation panel, choose Users.
Click on the IAM user name that you want to examine.
On the IAM user configuration page, select Security Credentials tab.
In Access Keys section, 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.
In the same Access Keys section, identify your non-operational access keys (other than the chosen one) and deactivate it by clicking the Make Inactive link.
If you receive the Change Key Status confirmation box, click Deactivate to switch off the selected key.
Repeat steps no. 3 - 7 for each IAM user in your AWS account.
From Command Line:
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.
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
Note - the command does not return any output:
aws iam update-access-key --access-key-id --status Inactive --user-name
To confirm that the selected access key pair has been successfully deactivated run the list-access-keys audit command again for that IAM User:
aws iam list-access-keys --user-name
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.
Repeat steps no. 1 - 3 for each IAM user in your AWS account."
reference : "800-171|3.1.1,800-53|AC-2,800-53r5|AC-2,CN-L3|7.1.3.2(d),CSCv7|4,CSCv8|5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|PR.AC-1,CSF|PR.AC-4,CSF2.0|DE.CM-01,CSF2.0|DE.CM-03,CSF2.0|PR.AA-01,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ITSG-33|AC-2,LEVEL|1A,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetCredentialReport"
xsl_stmt : " : Multiple access keys active
No users with multiple access keys active
"
not_expect : ".+ : Multiple access keys active"
type : IAM
description : "1.14 Ensure access keys are rotated every 90 days or less"
info : "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."
solution : "Perform the following to rotate access keys:
From Console:
Go to Management Console (https://console.aws.amazon.com/iam)
Click on Users
Click on Security Credentials
As an Administrator
Click on Make Inactive for keys that have not been rotated in 90 Days
As an IAM User
Click on Make Inactive or Delete for keys which have not been rotated or used in 90 Days
Click on Create Access Key
Update programmatic call with new Access Key credentials
From Command Line:
While the first access key is still active, create a second access key, which is active by default. Run the following command:
aws iam create-access-key
At this point, the user has two active access keys.
Update all applications and tools to use the new access key.
Determine whether the first access key is still in use by using this command:
aws iam get-access-key-last-used
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
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.
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:
aws iam delete-access-key"
reference : "800-171|3.1.1,800-53|AC-2,800-53r5|AC-2,CCE|CCE-78902-4,CN-L3|7.1.3.2(d),CSCv7|16,CSCv8|5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|PR.AC-1,CSF|PR.AC-4,CSF2.0|DE.CM-01,CSF2.0|DE.CM-03,CSF2.0|PR.AA-01,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ITSG-33|AC-2,LEVEL|1A,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetJSONCredentialReport"
json_transform : ".[] | if ((.access_key_1_last_rotated | iso_8601_days_ago) > 90) or ((.access_key_2_last_rotated | iso_8601_days_ago) > 90) then \"user has access keys older than 90 days: \" + .user else \"\" end"
regex : ".+"
not_expect : "user has access keys older than 90 days:"
type : IAM
description : "1.15 Ensure IAM Users Receive Permissions Only Through Groups"
info : "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."
solution : "Perform the following to create an IAM group and assign a policy to it:
Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
In the navigation pane, click Groups and then click Create New Group .
In the Group Name box, type the name of the group and then click Next Step .
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 .
Click Create Group
Perform the following to add a user to a given group:
Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
In the navigation pane, click Groups
Select the group to add a user to
Click Add Users To Group
Select the users to be added to the group
Click Add Users
Perform the following to remove a direct association between a user and policy:
Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
In the left navigation pane, click on Users
For each user:
Select the user
Click on the Permissions tab
Expand Permissions policies
Click X for each policy; then click Detach or Remove (depending on policy type)"
reference : "800-171|3.1.1,800-171|3.1.5,800-171|3.3.8,800-171|3.3.9,800-53|AC-2,800-53|AC-3,800-53|AC-6,800-53|AC-6(1),800-53|AC-6(7),800-53|AU-9(4),800-53r5|AC-2,800-53r5|AC-5,800-53r5|AC-6,800-53r5|AC-6(1),800-53r5|AC-6(7),800-53r5|AU-9(4),CCE|CCE-78912-3,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(d),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.3(d),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|16,CSCv8|6.8,CSF|DE.CM-1,CSF|DE.CM-3,CSF|PR.AC-1,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-1,CSF|PR.PT-3,CSF2.0|DE.CM-01,CSF2.0|DE.CM-03,CSF2.0|PR.AA-01,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),HIPAA|164.312(b),ISO/IEC-27001|A.9.2.1,ISO/IEC-27001|A.9.2.5,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.4,ISO/IEC-27001|A.9.4.5,ISO/IEC-27001|A.12.4.2,ITSG-33|AC-2,ITSG-33|AC-3,ITSG-33|AC-6,ITSG-33|AC-6(1),ITSG-33|AU-9(4),ITSG-33|AU-9(4)(a),ITSG-33|AU-9(4)(b),LEVEL|1A,NESA|M1.1.3,NESA|M1.2.2,NESA|M5.2.3,NESA|M5.5.2,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|AM28,NIAv2|AM31,NIAv2|GS3,NIAv2|GS4,NIAv2|GS8c,NIAv2|NS5j,NIAv2|SM5,NIAv2|SM6,NIAv2|SS13c,NIAv2|SS14e,NIAv2|SS15c,NIAv2|SS29,NIAv2|VL3b,PCI-DSSv3.2.1|7.1.2,PCI-DSSv3.2.1|10.5,PCI-DSSv3.2.1|10.5.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,PCI-DSSv4.0|10.3.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "ListUserPolicies"
xsl_stmt : " has inline policy has no inline policies
"
not_expect : ".* has inline policy"
type : IAM
description : "1.16 Ensure IAM policies that allow full '*:*' administrative privileges are not attached"
info : "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."
solution : "From Console:
Perform the following to detach the policy that has full administrative privileges:
Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
In the navigation pane, click Policies and then search for the policy name found in the audit step.
Select the policy that needs to be deleted.
In the policy action menu, select first Detach
Select all Users, Groups, Roles that have this policy attached
Click Detach Policy
In the policy action menu, select Detach
Select the newly detached policy and select Delete
From Command Line:
Perform the following to detach the policy that has full administrative privileges as found in the audit step:
Lists all IAM users, groups, and roles that the specified managed policy is attached to.
aws iam list-entities-for-policy --policy-arn
Detach the policy from all IAM Users:
aws iam detach-user-policy --user-name --policy-arn
Detach the policy from all IAM Groups:
aws iam detach-group-policy --group-name --policy-arn
Detach the policy from all IAM Roles:
aws iam detach-role-policy --role-name --policy-arn "
reference : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,800-53r5|AC-3,800-53r5|AC-5,800-53r5|AC-6,800-53r5|MP-2,CCE|CCE-78912-3,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|4,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetPolicyVersion_OnlyAttached"
json_transform : '.[] | if ((.Document.Statement[].Effect? == "Allow") and (.Document.Statement[].Resource | .. == "*") and (.Document.Statement[].Action | .. == "*")) then "full admin privileges allowed on " + .PolicyArn else "" end'
not_expect : "full admin privileges allowed on ."
type : IAM
description : "1.17 Ensure a support role has been created to manage incidents with AWS Support"
info : "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."
solution : "From Command Line:
Create an IAM role for managing incidents with AWS:
Create a trust relationship policy document that allows to manage AWS incidents, and save it locally as /tmp/TrustPolicy.json:
{
'Version': '2012-10-17',
'Statement': [
{
'Effect': 'Allow',
'Principal': {
'AWS': ''
},
'Action': 'sts:AssumeRole'
}
]
}
Create the IAM role using the above trust policy:
aws iam create-role --role-name --assume-role-policy-document file:///tmp/TrustPolicy.json
Attach 'AWSSupportAccess' managed policy to the created IAM role:
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AWSSupportAccess --role-name "
reference : "800-171|3.6.1,800-171|3.6.2,800-53|IR-1,800-53|IR-7,800-53|IR-8,800-53r5|IR-1,800-53r5|IR-7,800-53r5|IR-8,CSCv7|14,CSCv8|17.1,CSF|DE.AE-3,CSF|DE.AE-5,CSF|ID.GV-1,CSF|ID.GV-3,CSF|PR.IP-7,CSF|PR.IP-9,CSF|RC.IM-1,CSF|RC.IM-2,CSF|RC.RP-1,CSF|RS.AN-4,CSF|RS.CO-1,CSF|RS.CO-2,CSF|RS.CO-3,CSF|RS.CO-4,CSF|RS.IM-1,CSF|RS.IM-2,CSF|RS.RP-1,CSF2.0|DE.AE-03,CSF2.0|DE.AE-08,CSF2.0|GV.OC-03,CSF2.0|GV.OV-01,CSF2.0|GV.PO-01,CSF2.0|GV.PO-02,CSF2.0|GV.SC-03,CSF2.0|GV.SC-08,CSF2.0|ID.IM-01,CSF2.0|ID.IM-02,CSF2.0|ID.IM-03,CSF2.0|ID.IM-04,CSF2.0|RC.RP-01,CSF2.0|RC.RP-02,CSF2.0|RC.RP-04,CSF2.0|RC.RP-06,CSF2.0|RS.AN-08,CSF2.0|RS.CO-02,CSF2.0|RS.CO-03,CSF2.0|RS.MA,CSF2.0|RS.MA-01,CSF2.0|RS.MA-04,CSF2.0|RS.MA-05,GDPR|32.1.b,GDPR|32.1.d,HIPAA|164.306(a)(1),ITSG-33|IR-1,ITSG-33|IR-7,ITSG-33|IR-7a.,ITSG-33|IR-8,LEVEL|1A,NESA|M1.2.2,NESA|T8.2.6,NIAv2|IM9,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,SWIFT-CSCv1|7.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "ListEntitiesForPolicy"
xsl_stmt : "Pass - member is found under PolicyRolesFail - member is not found under PolicyRoles"
regex : "(Pass|Fail)"
expect : "Pass - member is found under PolicyRoles"
policy_arn : "arn:aws:iam::aws:policy/AWSSupportAccess"
type : IAM
description : "1.19 Ensure that all the expired SSL/TLS certificates stored in AWS IAM are removed"
info : "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.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
solution : "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 with the name of the certificate to delete:
aws iam delete-server-certificate --server-certificate-name
When the preceding command is successful, it does not return any output.
Default Value:
By default, expired certificates won't get deleted."
reference : "800-53|AU-11,800-53|SI-12,800-53r5|AU-11,800-53r5|CM-12,800-53r5|SI-12,CSCv7|13,CSCv8|3.1,CSF|PR.PT-1,CSF2.0|ID.AM-07,CSF2.0|ID.AM-08,CSF2.0|PR.PS-04,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-11,ITSG-33|SI-12,ITSG-33|SI-12a.,LEVEL|1A,NESA|M5.2.3,NESA|M5.2.4,NESA|M5.3.1,NESA|T3.6.2,NIAv2|DR1,NIAv2|DR1a,NIAv2|DR1b,NIAv2|DR1c,NIAv2|DR2,NIAv2|DR3,NIAv2|DR4,NIAv2|DR5,NIAv2|DR6,NIAv2|SM7,PCI-DSSv3.2.1|3.1,PCI-DSSv3.2.1|10.7,PCI-DSSv4.0|3.2.1,PCI-DSSv4.0|10.5.1,QCSC-v1|8.2.1,QCSC-v1|13.2"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "ListServerCertificates"
xsl_stmt : "Certificate Expiration:
: Server Certificates Not Found"
regex : ".+"
expect : "Server Certificates Not Found"
severity : MEDIUM
description : "1.20 Ensure that IAM Access analyzer is enabled for all regions"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "From Console:
Perform the following to enable IAM Access analyzer for IAM policies:
Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Access analyzer.
Choose Create analyzer.
On the Create analyzer page, confirm that the Region displayed is the Region where you want to enable Access Analyzer.
Enter a name for the analyzer. Optional as it will generate a name for you automatically.
Add any tags that you want to apply to the analyzer. Optional.
Choose Create Analyzer.
Repeat these step for each active region
From Command Line:
Run the following command:
aws accessanalyzer create-analyzer --analyzer-name --type
Repeat this command above for each active region.
Note: The IAM Access Analyzer is successfully configured only when the account you use has the necessary permissions."
reference : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,800-53r5|AC-3,800-53r5|AC-5,800-53r5|AC-6,800-53r5|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14,CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "1.22 Ensure access to AWSCloudShellFullAccess is restricted"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "From Console
Open the IAM console at https://console.aws.amazon.com/iam/
In the left pane, select Policies
Search for and select AWSCloudShellFullAccess
On the Entities attached tab, for each item, check the box and select Detach"
reference : "800-171|3.1.5,800-53|AC-6,800-53r5|AC-6,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.10.6(a),CSCv7|14,CSCv8|6,CSF|PR.AC-4,CSF|PR.DS-5,CSF2.0|PR.AA-05,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ITSG-33|AC-6,LEVEL|1M,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
type : S3
description : "2.1.4 Ensure that S3 Buckets are configured with 'Block public access (bucket settings)'"
info : "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."
solution : "If utilizing Block Public Access (bucket settings)
From Console:
Login to AWS Management Console and open the Amazon S3 console using https://console.aws.amazon.com/s3/
Select the Check box next to the Bucket.
Click on 'Edit public access settings'.
Click 'Block all public access'
Repeat for all the buckets in your AWS account that contain sensitive data.
From Command Line:
List all of the S3 Buckets
aws s3 ls
Set the Block Public Access to true on that bucket
aws s3api put-public-access-block --bucket --public-access-block-configuration 'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'
If utilizing Block Public Access (account settings)
From Console:
If the output reads true for the separate configuration settings then it is set on the account.
Login to AWS Management Console and open the Amazon S3 console using https://console.aws.amazon.com/s3/
Choose Block Public Access (account settings)
Choose Edit to change the block public access settings for all the buckets in your AWS account
Choose the settings you want to change, and then choose Save. For details about each setting, pause on the i icons.
When you're asked for confirmation, enter confirm. Then Click Confirm to save your changes.
From Command Line:
To set Block Public access settings for this account, run the following command:
aws s3control put-public-access-block
--public-access-block-configuration BlockPublicAcls=true, IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true
--account-id "
reference : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,800-53r5|AC-3,800-53r5|AC-5,800-53r5|AC-6,800-53r5|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetAllPublicAccessBlock"
xsl_stmt : "Bucket: BlockPublicAcls = false IgnorePublicAcls = false BlockPublicPolicy = false RestrictPublicBuckets = falseNo buckets found"
regex : ".+"
not_expect : "(BlockPublicAcls|IgnorePublicAcls|BlockPublicPolicy|RestrictPublicBuckets) = false"
type : EC2
description : "2.2.1 Ensure EBS Volume Encryption is Enabled in all Regions"
info : "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."
solution : "From Console:
Login to AWS Management Console and open the Amazon EC2 console using https://console.aws.amazon.com/ec2/
Under Account attributes, click EBS encryption.
Click Manage.
Click the Enable checkbox.
Click Update EBS encryption
Repeat for every region requiring the change.
Note: EBS volume encryption is configured per region.
From Command Line:
Run
aws --region ec2 enable-ebs-encryption-by-default
Verify that 'EbsEncryptionByDefault': true is displayed.
Repeat every region requiring the change.
Note: EBS volume encryption is configured per region."
reference : "800-171|3.5.2,800-171|3.13.16,800-53|IA-5(1),800-53|SC-28,800-53|SC-28(1),800-53r5|IA-5(1),800-53r5|SC-28,800-53r5|SC-28(1),CN-L3|8.1.4.7(b),CN-L3|8.1.4.8(b),CSCv7|14.8,CSCv8|3.11,CSF|PR.AC-1,CSF|PR.DS-1,CSF2.0|PR.AA-01,CSF2.0|PR.AA-03,CSF2.0|PR.DS-01,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(a)(2)(iv),HIPAA|164.312(d),HIPAA|164.312(e)(2)(ii),ITSG-33|IA-5(1),ITSG-33|SC-28,ITSG-33|SC-28a.,ITSG-33|SC-28(1),LEVEL|1A,NESA|T5.2.3,PCI-DSSv3.2.1|3.4,PCI-DSSv4.0|3.3.2,PCI-DSSv4.0|3.5.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|4.1,TBA-FIISB|28.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetEbsEncryptionByDefault"
xsl_stmt : "GetEbsEncryptionByDefault = GetEbsEncryptionByDefault = false"
regex : "GetEbsEncryptionByDefault ="
not_expect : "GetEbsEncryptionByDefault = false"
type : RDS
description : "2.3.1 Ensure that encryption-at-rest is enabled for RDS Instances"
info : "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."
solution : "From Console:
Login to the AWS Management Console and open the RDS dashboard at https://console.aws.amazon.com/rds/.
In the left navigation panel, click on Databases
Select the Database instance that needs to be encrypted.
Click on Actions button placed at the top right and select Take Snapshot.
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.
Select the newly created snapshot and click on the Action button placed at the top right and select Copy snapshot from the Action menu.
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.
Click Copy Snapshot to create an encrypted copy of the selected instance snapshot.
Select the new Snapshot Encrypted Copy and click on the Action button placed at the top right and select Restore Snapshot button from the Action menu, This will restore the encrypted snapshot to a new database instance.
On the Restore DB Instance page, enter a unique name for the new database instance in the DB Instance Identifier field.
Review the instance configuration details and click Restore DB Instance.
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.
From Command Line:
Run describe-db-instances command to list all RDS database names available in the selected AWS region, The command output should return the database instance identifier.
aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier'
Run create-db-snapshot command to create a snapshot for the selected database instance, The command output will return the new snapshot with name DB Snapshot Name.
aws rds create-db-snapshot --region --db-snapshot-identifier --db-instance-identifier
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.
aws kms list-aliases --region
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.
aws rds copy-db-snapshot --region --source-db-snapshot-identifier --target-db-snapshot-identifier --copy-tags --kms-key-id
Run restore-db-instance-from-db-snapshot command to restore the encrypted snapshot created at the previous step to a new database instance, If successful, the command output should return the new encrypted database instance configuration.
aws rds restore-db-instance-from-db-snapshot --region --db-instance-identifier --db-snapshot-identifier
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.
aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier'
Run again describe-db-instances command using the RDS instance identifier returned earlier, to determine if the selected database instance is encrypted, The command output should return the encryption status True.
aws rds describe-db-instances --region --db-instance-identifier --query 'DBInstances[*].StorageEncrypted'"
reference : "800-171|3.5.2,800-171|3.13.16,800-53|IA-5(1),800-53|SC-28,800-53|SC-28(1),800-53r5|IA-5(1),800-53r5|SC-28,800-53r5|SC-28(1),CN-L3|8.1.4.7(b),CN-L3|8.1.4.8(b),CSCv7|14.8,CSCv8|3.11,CSF|PR.AC-1,CSF|PR.DS-1,CSF2.0|PR.AA-01,CSF2.0|PR.AA-03,CSF2.0|PR.DS-01,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(a)(2)(iv),HIPAA|164.312(d),HIPAA|164.312(e)(2)(ii),ITSG-33|IA-5(1),ITSG-33|SC-28,ITSG-33|SC-28a.,ITSG-33|SC-28(1),LEVEL|1A,NESA|T5.2.3,PCI-DSSv3.2.1|3.4,PCI-DSSv4.0|3.3.2,PCI-DSSv4.0|3.5.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|4.1,TBA-FIISB|28.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "DescribeDBInstances"
xsl_stmt : " : Storage Encrypted = Storage Encrypted = No DB Instance Found"
regex : "Storage Encrypted ="
not_expect : "Storage Encrypted = false"
type : RDS
description : "2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled for RDS Instances"
info : "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."
solution : "From Console:
Log in to the AWS management console and navigate to the RDS dashboard at https://console.aws.amazon.com/rds/.
In the left navigation panel, click on Databases.
Select the RDS instance that wants to update.
Click on the Modify button placed on the top right side.
On the Modify DB Instance: page, In the Maintenance section, select Auto minor version upgrade click on the Yes radio button.
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.
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.
From Command Line:
Run describe-db-instances command to list all RDS database instance names, available in the selected AWS region:
aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier'
The command output should return each database instance identifier.
Run the modify-db-instance command to modify the selected RDS instance configuration this command will apply the changes immediately, Remove --apply-immediately to apply changes during the next scheduled maintenance window and avoid any downtime:
aws rds modify-db-instance --region --db-instance-identifier --auto-minor-version-upgrade --apply-immediately
The command output should reveal the new configuration metadata for the RDS instance and check AutoMinorVersionUpgrade parameter value.
Run describe-db-instances command to check if the Auto Minor Version Upgrade feature has been successfully enable:
aws rds describe-db-instances --region --db-instance-identifier --query 'DBInstances[*].AutoMinorVersionUpgrade'
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."
reference : "800-171|3.11.2,800-171|3.11.3,800-171|3.14.1,800-53|RA-5,800-53|SI-2,800-53|SI-2(2),800-53r5|RA-5,800-53r5|RA-7,800-53r5|SI-2,800-53r5|SI-2(2),CN-L3|8.1.4.4(e),CN-L3|8.1.10.5(a),CN-L3|8.1.10.5(b),CN-L3|8.5.4.1(b),CN-L3|8.5.4.1(d),CN-L3|8.5.4.1(e),CSCv7|3.5,CSCv8|7.4,CSF|DE.CM-8,CSF|DE.DP-4,CSF|DE.DP-5,CSF|ID.RA-1,CSF|PR.IP-12,CSF|RS.CO-3,CSF|RS.MI-3,CSF2.0|GV.SC-10,CSF2.0|ID.IM-01,CSF2.0|ID.IM-02,CSF2.0|ID.IM-03,CSF2.0|ID.RA-01,CSF2.0|ID.RA-08,CSF2.0|PR.PS-02,GDPR|32.1.b,GDPR|32.1.d,HIPAA|164.306(a)(1),ISO/IEC-27001|A.12.6.1,ITSG-33|RA-5,ITSG-33|SI-2,ITSG-33|SI-2(2),LEVEL|1A,NESA|M1.2.2,NESA|M5.4.1,NESA|T7.6.2,NESA|T7.7.1,NIAv2|PR9,PCI-DSSv3.2.1|6.1,PCI-DSSv3.2.1|6.2,PCI-DSSv4.0|6.3,PCI-DSSv4.0|6.3.1,PCI-DSSv4.0|6.3.3,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,SWIFT-CSCv1|2.2,SWIFT-CSCv1|2.7"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "DescribeDBInstances"
xsl_stmt : " : Auto Minor Version Upgrade = Auto Minor Version Upgrade = No DB Instance Found"
regex : "Auto Minor Version Upgrade ="
not_expect : "Auto Minor Version Upgrade = false"
type : RDS
description : "2.3.3 Ensure that public access is not given to RDS Instance"
info : "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."
solution : "From Console:
Log in to the AWS management console and navigate to the RDS dashboard at https://console.aws.amazon.com/rds/.
Under the navigation panel, On RDS Dashboard, click Databases.
Select the RDS instance that you want to update.
Click Modify from the dashboard top menu.
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.
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.
On the Modify DB Instance panel Click on Continue and In the Scheduling of modifications section, perform one of the following actions based on your requirements:
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.
Repeat steps 3 to 6 for each RDS instance available in the current region.
Change the AWS region from the navigation bar to repeat the process for other regions.
From Command Line:
Run describe-db-instances command to list all RDS database names identifiers, available in the selected AWS region:
aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier'
The command output should return each database instance identifier.
Run modify-db-instance command to modify the selected RDS instance configuration. Then use the following command to disable the Publicly Accessible flag for the selected RDS instances. This command use the apply-immediately flag. If you want to avoid any downtime --no-apply-immediately flag can be used:
aws rds modify-db-instance --region --db-instance-identifier --no-publicly-accessible --apply-immediately
The command output should reveal the PubliclyAccessible configuration under pending values and should get applied at the specified time.
Updating the Internet Gateway Destination via AWS CLI is not currently supported To update information about Internet Gateway use the AWS Console Procedure.
Repeat steps 1 to 5 for each RDS instance provisioned in the current region.
Change the AWS region by using the --region filter to repeat the process for other regions."
reference : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,800-53r5|AC-3,800-53r5|AC-5,800-53r5|AC-6,800-53r5|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,CSF2.0|PR.AA-05,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,PCI-DSSv3.2.1|7.1.2,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "DescribeDBInstances"
xsl_stmt : " : Publicly Accessible = Publicly Accessible = No DB Instance Found"
regex : "Publicly Accessible ="
not_expect : "Publicly Accessible = true"
description : "2.4.1 Ensure that encryption is enabled for EFS file systems"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "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:
Login to the AWS Management Console and Navigate to Elastic File System (EFS) dashboard.
Select File Systems from the left navigation panel.
Click Create File System button from the dashboard top menu to start the file system setup process.
On the Configure file system access configuration page, perform the following actions.
Choose the right VPC from the VPC dropdown list.
Within Create mount targets section, select the checkboxes for all of the Availability Zones (AZs) within the selected VPC. These will be your mount targets.
Click Next step to continue.
Perform the following on the Configure optional settings page.
Create tags to describe your new file system.
Choose performance mode based on your requirements.
Check Enable encryption checkbox and choose aws/elasticfilesystem from Select KMS master key dropdown list to enable encryption for the new file system using the default master key provided and managed by AWS KMS.
Click Next step to continue.
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.
Copy the data from the old unencrypted EFS file system onto the newly create encrypted file system.
Remove the unencrypted file system as soon as your data migration to the newly create encrypted file system is completed.
Change the AWS region from the navigation bar and repeat the entire process for other aws regions.
From CLI:
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):
aws efs describe-file-systems --region --file-system-id
The command output should return the requested configuration information.
To provision a new AWS EFS file system, you need to generate a universally unique identifier (UUID) in order to create the token required by the create-file-system command. To create the required token, you can use a randomly generated UUID from 'https://www.uuidgenerator.net'.
Run create-file-system command using the unique token created at the previous step.
aws efs create-file-system --region --creation-token --performance-mode generalPurpose --encrypted
The command output should return the new file system configuration metadata.
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:
aws efs create-mount-target --region --file-system-id --subnet-id
The command output should return the new mount target metadata.
Now you can mount your file system from an EC2 instance.
Copy the data from the old unencrypted EFS file system onto the newly create encrypted file system.
Remove the unencrypted file system as soon as your data migration to the newly create encrypted file system is completed.
aws efs delete-file-system --region --file-system-id
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."
reference : "800-171|3.5.2,800-171|3.13.16,800-53|IA-5(1),800-53|SC-28,800-53|SC-28(1),800-53r5|IA-5(1),800-53r5|SC-28,800-53r5|SC-28(1),CN-L3|8.1.4.7(b),CN-L3|8.1.4.8(b),CSCv7|14.8,CSCv8|3.11,CSF|PR.AC-1,CSF|PR.DS-1,CSF2.0|PR.AA-01,CSF2.0|PR.AA-03,CSF2.0|PR.DS-01,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(a)(2)(iv),HIPAA|164.312(d),HIPAA|164.312(e)(2)(ii),ITSG-33|IA-5(1),ITSG-33|SC-28,ITSG-33|SC-28a.,ITSG-33|SC-28(1),LEVEL|1A,NESA|T5.2.3,PCI-DSSv3.2.1|3.4,PCI-DSSv4.0|3.3.2,PCI-DSSv4.0|3.5.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|4.1,TBA-FIISB|28.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
type : CLOUDTRAIL
description : "IsMultiRegionTrail"
aws_action : "DescribeTrails"
json_transform : 'if .[0].trailList == [] then "No Trails defined" else (.[0].trailList[] |
"\(.Name) - IsMultiRegionTrail = \(.IsMultiRegionTrail)") end'
regex : "IsMultiRegionTrail = "
expect : "IsMultiRegionTrail = true"
any_region : "YES"
type : CLOUDTRAIL
description : "IsLogging"
aws_action : "GetTrailStatus"
json_transform : 'if .[0] == null then "No Trails defined" else (.[] |
"\(.Name) - IsLogging = \(.IsLogging)") end'
regex : ".+"
not_expect : "IsLogging = false"
type : CLOUDTRAIL
description : "IsMultiRegionTrail"
aws_action : "GetEventSelectors"
json_transform : 'if .[0].AdvancedEventSelectors == [] then "No Event selector" else (.[0].AdvancedEventSelectors[].FieldSelectors[] |
"Equals = \(.Equals[]) Field = \(.Field)") end'
regex : "Equals = "
not_expect : "Equals = (true|false) Field = readOnly"
description : "3.1 Ensure CloudTrail is enabled in all regions"
info : "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:
https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html"
solution : "Perform the following to enable global (Multi-region) CloudTrail logging:
From Console:
Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/cloudtrail
Click on Trails on the left navigation pane
Click Get Started Now , if presented
Click Add new trail
Enter a trail name in the Trail name box
A trail created in the console is a multi-region trail by default
Specify an S3 bucket name in the S3 bucket box
Specify the AWS KMS alias under the Log file SSE-KMS encryption section or create a new key
Click Next
Ensure Management events check box is selected.
Ensure both Read and Write are check under API activity
Click Next
review your trail settings and click Create trail
From Command Line:
aws cloudtrail create-trail --name --bucket-name --is-multi-region-trail
aws cloudtrail update-trail --name --is-multi-region-trail
Note: Creating CloudTrail via CLI without providing any overriding options configures Management Events to set All type of Read/Writes by default.
Default Value:
Not Enabled"
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,800-53r5|AU-3,800-53r5|AU-3(1),800-53r5|AU-7,800-53r5|AU-12,CCE|CCE-78913-1,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,CSF2.0|DE.CM-01,CSF2.0|DE.CM-03,CSF2.0|DE.CM-09,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,PCI-DSSv3.2.1|10.1,PCI-DSSv3.2.1|10.3,PCI-DSSv3.2.1|10.3.1,PCI-DSSv3.2.1|10.3.2,PCI-DSSv3.2.1|10.3.3,PCI-DSSv3.2.1|10.3.4,PCI-DSSv3.2.1|10.3.5,PCI-DSSv3.2.1|10.3.6,PCI-DSSv4.0|10.2.2,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
show_output : YES
type : S3
description : "3.4 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket"
info : "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."
solution : "Perform the following to enable S3 bucket logging:
From Console:
Sign in to the AWS Management Console and open the S3 console at https://console.aws.amazon.com/s3.
Under All Buckets click on the target S3 bucket
Click on Properties in the top right of the console
Under Bucket: click on Logging
Configure bucket logging
Click on the Enabled checkbox
Select Target Bucket from list
Enter a Target Prefix
Click Save.
From Command Line:
Get the name of the S3 bucket that CloudTrail is logging to:
aws cloudtrail describe-trails --region --query trailList[*].S3BucketName
Copy and add target bucket name at , Prefix for logfile at and optionally add an email address in the following template and save it as :
{
'LoggingEnabled': {
'TargetBucket': '',
'TargetPrefix': '',
'TargetGrants': [
{
'Grantee': {
'Type': 'AmazonCustomerByEmail',
'EmailAddress': ''
},
'Permission': 'FULL_CONTROL'
}
]
}
}
Run the put-bucket-logging command with bucket name and as input: for more information refer to put-bucket-logging:
aws s3api put-bucket-logging --bucket --bucket-logging-status file://
Default Value:
Logging is disabled."
reference : "800-171|3.1.7,800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AC-6(9),800-53|AU-2,800-53|AU-7,800-53|AU-12,800-53r5|AC-6(9),800-53r5|AU-2,800-53r5|AU-7,800-53r5|AU-12,CCE|CCE-78918-0,CN-L3|7.1.2.3(c),CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.3(a),CN-L3|8.1.10.6(a),CSCv7|6.2,CSCv7|14.9,CSCv8|3.14,CSCv8|8.2,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.AC-4,CSF|PR.PT-1,CSF|RS.AN-3,CSF2.0|DE.CM-01,CSF2.0|DE.CM-03,CSF2.0|DE.CM-09,CSF2.0|PR.AA-05,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),HIPAA|164.312(b),ISO/IEC-27001|A.12.4.3,ITSG-33|AC-6,ITSG-33|AU-2,ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.5.4,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS30,NIAv2|VL8,PCI-DSSv3.2.1|7.1.2,PCI-DSSv3.2.1|10.1,PCI-DSSv4.0|7.2.1,PCI-DSSv4.0|7.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,SWIFT-CSCv1|6.4,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "GetCloudTrailBucketLogging"
xsl_stmt : "Bucket: TargetBucket = logging is disabled No buckets found"
regex : ".+"
not_expect : "logging is disabled"
description : "4.2 Ensure management console sign-in without MFA is monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for AWS Management Console sign-in without MFA and the taken from audit step 1.
Use Command:
aws logs put-metric-filter --log-group-name --filter-name '' --metric-transformations metricName= '' ,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 --filter-name '' --metric-transformations metricName= '' ,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.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79187-1,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|16,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.3 Ensure usage of 'root' account is monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for 'Root' account usage and the taken from audit step 1.
aws logs put-metric-filter --log-group-name '' --filter-name '' --metric-transformations metricName= '' ,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.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79188-9,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|4.9,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.4 Ensure IAM policy changes are monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for IAM policy changes and the taken from audit step 1.
aws logs put-metric-filter --log-group-name '' --filter-name '' --metric-transformations metricName= '' ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{($.eventName=DeleteGroupPolicy)||($.eventName=DeleteRolePolicy)||($.eventName=DeleteUserPolicy)||($.eventName=PutGroupPolicy)||($.eventName=PutRolePolicy)||($.eventName=PutUserPolicy)||($.eventName=CreatePolicy)||($.eventName=DeletePolicy)||($.eventName=CreatePolicyVersion)||($.eventName=DeletePolicyVersion)||($.eventName=AttachRolePolicy)||($.eventName=DetachRolePolicy)||($.eventName=AttachUserPolicy)||($.eventName=DetachUserPolicy)||($.eventName=AttachGroupPolicy)||($.eventName=DetachGroupPolicy)}'
Note: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79189-7,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|16,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.5 Ensure CloudTrail configuration changes are monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for cloudtrail configuration changes and the taken from audit step 1.
aws logs put-metric-filter --log-group-name --filter-name '' --metric-transformations metricName= '' ,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.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79190-5,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|6,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.8 Ensure S3 bucket policy changes are monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for S3 bucket policy changes and the taken from audit step 1.
aws logs put-metric-filter --log-group-name --filter-name '' --metric-transformations metricName= '' ,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.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79193-9,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|6.2,CSCv7|14,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.12 Ensure changes to network gateways are monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for network gateways changes and the taken from audit step 1.
aws logs put-metric-filter --log-group-name --filter-name '' --metric-transformations metricName= '' ,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.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79197-0,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|6.2,CSCv7|11.3,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.13 Ensure route table changes are monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for route table changes and the taken from audit step 1.
aws logs put-metric-filter --log-group-name --filter-name '' --metric-transformations metricName= '' ,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.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79198-8,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|6.2,CSCv7|11.3,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.14 Ensure VPC changes are monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for VPC changes and the taken from audit step 1.
aws logs put-metric-filter --log-group-name --filter-name '' --metric-transformations metricName= '' ,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.
Create an SNS topic that the alarm will notify
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CCE|CCE-79199-6,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|5.5,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
description : "4.15 Ensure AWS Organizations changes are monitored"
info : "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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "If you are using CloudTrails and CloudWatch, perform the following to setup the metric filter, alarm, SNS topic, and subscription:
Create a metric filter based on filter pattern provided which checks for AWS Organizations changes and the taken from audit step 1:
aws logs put-metric-filter --log-group-name --filter-name '' --metric-transformations metricName= '' ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventSource = organizations.amazonaws.com) && (($.eventName = 'AcceptHandshake') || ($.eventName = 'AttachPolicy') || ($.eventName = 'CreateAccount') || ($.eventName = 'CreateOrganizationalUnit') || ($.eventName = 'CreatePolicy') || ($.eventName = 'DeclineHandshake') || ($.eventName = 'DeleteOrganization') || ($.eventName = 'DeleteOrganizationalUnit') || ($.eventName = 'DeletePolicy') || ($.eventName = 'DetachPolicy') || ($.eventName = 'DisablePolicyType') || ($.eventName = 'EnablePolicyType') || ($.eventName = 'InviteAccountToOrganization') || ($.eventName = 'LeaveOrganization') || ($.eventName = 'MoveAccount') || ($.eventName = 'RemoveAccountFromOrganization') || ($.eventName = 'UpdatePolicy') || ($.eventName = 'UpdateOrganizationalUnit')) }'
Note: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together.
Create an SNS topic that the alarm will notify:
aws sns create-topic --name
Note: you can execute this command once and then re-use the same topic for all monitoring alarms.
Create an SNS subscription to the topic created in step 2:
aws sns subscribe --topic-arn --protocol --notification-endpoint
Note: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2:
aws cloudwatch put-metric-alarm --alarm-name '' --metric-name '' --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions "
reference : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-6,800-53|AU-6(1),800-53|AU-7(1),800-53r5|AU-6,800-53r5|AU-6(1),800-53r5|AU-7(1),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CSCv7|6.2,CSCv7|14.6,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,CSF2.0|DE.AE-02,CSF2.0|DE.AE-03,CSF2.0|PR.PS-04,CSF2.0|RS.AN-03,CSF2.0|RS.AN-06,CSF2.0|RS.AN-07,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7(1),LEVEL|1M,NESA|M5.2.5,QCSC-v1|5.2.3,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
type : EC2
description : "5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports"
info : "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."
solution : "From Console:
Perform the following:
Login to the AWS Management Console at https://console.aws.amazon.com/vpc/home
In the left pane, click Network ACLs
For each network ACL to remediate, perform the following:
Select the network ACL
Click the Inbound Rules tab
Click Edit inbound rules
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
Click Save"
reference : "800-171|3.4.6,800-171|3.4.7,800-171|3.13.1,800-171|3.13.5,800-53|CM-7b.,800-53|SC-7,800-53r5|CM-7b.,800-53r5|SC-7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CN-L3|8.1.4.4(b),CN-L3|8.1.10.6(j),CSCv7|9.2,CSCv7|12.4,CSF|DE.CM-1,CSF|PR.AC-5,CSF|PR.DS-5,CSF|PR.IP-1,CSF|PR.PT-3,CSF|PR.PT-4,CSF2.0|DE.CM-01,CSF2.0|PR.DS-01,CSF2.0|PR.DS-02,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,CSF2.0|PR.PS-01,GDPR|32.1.b,HIPAA|164.306(a)(1),ISO/IEC-27001|A.13.1.3,ITSG-33|CM-7a.,ITSG-33|SC-7,LEVEL|1A,NESA|T4.5.4,NIAv2|GS1,NIAv2|GS2a,NIAv2|GS2b,NIAv2|SS13b,NIAv2|SS14a,NIAv2|SS14c,PCI-DSSv3.2.1|1.1,PCI-DSSv3.2.1|1.2,PCI-DSSv3.2.1|1.2.1,PCI-DSSv3.2.1|1.3,PCI-DSSv3.2.1|2.2.2,PCI-DSSv4.0|1.2.1,PCI-DSSv4.0|1.4.1,PCI-DSSv4.0|2.2.4,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|8.2.1,SWIFT-CSCv1|2.3,TBA-FIISB|43.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "DescribeNetworkAcls"
xsl_stmt : "Allow Ingress ACLs:
ACL ID: - Rule Number: - to -all ports/all protocols/tcp/udpNo Allow Ingress ACLs"
regex : ".+"
not_expect : "allow 0\.0\.0\.0/0 to ((([0-9]|1[0-9]|2[0-2])-(2[2-9]|[3-9][0-9]|[1-9][0-9]{2,}+))|all ports|(([0-9]|[1-2][0-9]{0,3}|3[0-2][0-9]{2,}|33[0-8][0-9])-(3389|339[0-9]|3[4-9][0-9]{2,}|[1-9][0-9]{4,}+)))/(all protocols|tcp|udp)"
type : EC2
description : "5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports"
info : "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."
solution : "Perform the following to implement the prescribed state:
Login to the AWS Management Console at https://console.aws.amazon.com/vpc/home
In the left pane, click Security Groups
For each security group, perform the following:
Select the security group
Click the Inbound Rules tab
Click the Edit inbound rules button
Identify the rules to be edited or removed
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
Click Save rules"
reference : "800-171|3.4.6,800-171|3.4.7,800-171|3.13.1,800-171|3.13.5,800-53|CM-7b.,800-53|SC-7,800-53r5|CM-7b.,800-53r5|SC-7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CN-L3|8.1.4.4(b),CN-L3|8.1.10.6(j),CSCv7|9.2,CSCv7|12.4,CSF|DE.CM-1,CSF|PR.AC-5,CSF|PR.DS-5,CSF|PR.IP-1,CSF|PR.PT-3,CSF|PR.PT-4,CSF2.0|DE.CM-01,CSF2.0|PR.DS-01,CSF2.0|PR.DS-02,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,CSF2.0|PR.PS-01,GDPR|32.1.b,HIPAA|164.306(a)(1),ISO/IEC-27001|A.13.1.3,ITSG-33|CM-7a.,ITSG-33|SC-7,LEVEL|1A,NESA|T4.5.4,NIAv2|GS1,NIAv2|GS2a,NIAv2|GS2b,NIAv2|SS13b,NIAv2|SS14a,NIAv2|SS14c,PCI-DSSv3.2.1|1.1,PCI-DSSv3.2.1|1.2,PCI-DSSv3.2.1|1.2.1,PCI-DSSv3.2.1|1.3,PCI-DSSv3.2.1|2.2.2,PCI-DSSv4.0|1.2.1,PCI-DSSv4.0|1.4.1,PCI-DSSv4.0|2.2.4,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|8.2.1,SWIFT-CSCv1|2.3,TBA-FIISB|43.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "DescribeSecurityGroups"
xsl_stmt : "Security Group: - allow to all ports-/all protocolsNo security groups found"
regex : ".+"
not_expect : "allow 0\.0\.0\.0/0 to ((([0-9]|1[0-9]|2[0-2])-(2[2-9]|[3-9][0-9]|[1-9][0-9]{2,}+))|all ports|(([0-9]|[1-2][0-9]{0,3}|3[0-2][0-9]{2,}|33[0-8][0-9])-(3389|339[0-9]|3[4-9][0-9]{2,}|[1-9][0-9]{4,}+)))/(all protocols|tcp|udp)"
type : EC2
description : "5.3 Ensure no security groups allow ingress from ::/0 to remote server administration ports"
info : "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."
solution : "Perform the following to implement the prescribed state:
Login to the AWS Management Console at https://console.aws.amazon.com/vpc/home
In the left pane, click Security Groups
For each security group, perform the following:
Select the security group
Click the Inbound Rules tab
Click the Edit inbound rules button
Identify the rules to be edited or removed
Either A) update the Source field to a range other than ::/0, or, B) Click Delete to remove the offending inbound rule
Click Save rules"
reference : "800-171|3.4.6,800-171|3.4.7,800-171|3.13.1,800-171|3.13.5,800-53|CM-7b.,800-53|SC-7,800-53r5|CM-7b.,800-53r5|SC-7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CN-L3|8.1.4.4(b),CN-L3|8.1.10.6(j),CSCv7|9.2,CSCv7|12.4,CSF|DE.CM-1,CSF|PR.AC-5,CSF|PR.DS-5,CSF|PR.IP-1,CSF|PR.PT-3,CSF|PR.PT-4,CSF2.0|DE.CM-01,CSF2.0|PR.DS-01,CSF2.0|PR.DS-02,CSF2.0|PR.DS-10,CSF2.0|PR.IR-01,CSF2.0|PR.PS-01,GDPR|32.1.b,HIPAA|164.306(a)(1),ISO/IEC-27001|A.13.1.3,ITSG-33|CM-7a.,ITSG-33|SC-7,LEVEL|1A,NESA|T4.5.4,NIAv2|GS1,NIAv2|GS2a,NIAv2|GS2b,NIAv2|SS13b,NIAv2|SS14a,NIAv2|SS14c,PCI-DSSv3.2.1|1.1,PCI-DSSv3.2.1|1.2,PCI-DSSv3.2.1|1.2.1,PCI-DSSv3.2.1|1.3,PCI-DSSv3.2.1|2.2.2,PCI-DSSv4.0|1.2.1,PCI-DSSv4.0|1.4.1,PCI-DSSv4.0|2.2.4,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|8.2.1,SWIFT-CSCv1|2.3,TBA-FIISB|43.1"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "DescribeSecurityGroups"
xsl_stmt : "Security Group: - allow to all ports-/all protocolsNo security groups found"
regex : ".+"
not_expect : "allow ::/0 to ((([0-9]|1[0-9]|2[0-2])-(2[2-9]|[3-9][0-9]|[1-9][0-9]{2,}+))|all ports|(([0-9]|[1-2][0-9]{0,3}|3[0-2][0-9]{2,}|33[0-8][0-9])-(3389|339[0-9]|3[4-9][0-9]{2,}|[1-9][0-9]{4,}+))|-)/(all protocols|tcp|udp)"
type : EC2
description : "5.6 Ensure that EC2 Metadata Service only allows IMDSv2"
info : "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."
solution : "From Console:
Sign in to the AWS Management Console and navigate to the EC2 dashboard at https://console.aws.amazon.com/ec2/.
In the left navigation panel, under the INSTANCES section, choose Instances.
Select the EC2 instance that you want to examine.
Choose Actions > Instance Settings > Modify instance metadata options.
Ensure Instance metadata service is set to Enable and set IMDSv2 to Required.
Repeat steps no. 1 - 5 to perform the remediation process for other EC2 Instances in the all applicable AWS region(s).
From Command Line:
Run the describe-instances command using appropriate filtering to list the IDs of all the existing EC2 instances currently available in the selected region:
aws ec2 describe-instances --region --output table --query 'Reservations[*].Instances[*].InstanceId'
The command output should return a table with the requested instance IDs.
Now run the modify-instance-metadata-options command using an instance ID returned at the previous step to update the Instance Metadata Version:
aws ec2 modify-instance-metadata-options --instance-id --http-tokens required --region
Repeat steps no. 1 - 3 to perform the remediation process for other EC2 Instances in the same AWS region.
Change the region by updating --region and repeat the entire process for other regions."
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7b.,800-53r5|CM-7b.,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CN-L3|8.1.4.4(b),CSF|PR.IP-1,CSF|PR.PT-3,CSF2.0|PR.PS-01,GDPR|32.1.b,HIPAA|164.306(a)(1),ITSG-33|CM-7a.,LEVEL|1A,NIAv2|SS13b,NIAv2|SS14a,NIAv2|SS14c,PCI-DSSv3.2.1|2.2.2,PCI-DSSv4.0|2.2.4,QCSC-v1|3.2,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/benchmarks/14207"
aws_action : "DescribeInstances"
xsl_stmt : "Instance: - - No instances found"
regex : ".+"
not_expect : "optional - applied"