diff --git a/README.md b/README.md index 95dec690..0f458620 100644 --- a/README.md +++ b/README.md @@ -9,9 +9,10 @@ Or in a terminal: ![image](https://raw.githubusercontent.com/turbot/steampipe-mod-aws-compliance/main/docs/aws_cis_v140_console.png) Includes support for: +* [AWS CIS v1.2.0](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.cis_v120) 🚀 New! * [AWS CIS v1.3.0](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.cis_v130) * [AWS CIS v1.4.0](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.cis_v140) -* [AWS CIS v1.5.0](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.cis_v150) 🚀 New! +* [AWS CIS v1.5.0](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.cis_v150) * [Audit Manager Control Tower](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.control_tower) * [CISA Cyber Essentials](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.cisa_cyber_essentials) * [FedRAMP Low Revision 4](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.fedramp_low_rev_4) diff --git a/cis_v120/cis.sp b/cis_v120/cis.sp new file mode 100644 index 00000000..158da787 --- /dev/null +++ b/cis_v120/cis.sp @@ -0,0 +1,22 @@ +locals { + cis_v120_common_tags = merge(local.aws_compliance_common_tags, { + cis = "true" + cis_version = "v1.2.0" + }) +} + +benchmark "cis_v120" { + title = "CIS v1.2.0" + description = "The CIS Amazon Web Services Foundations Benchmark provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings." + documentation = file("./cis_v120/docs/cis_overview.md") + children = [ + benchmark.cis_v120_1, + benchmark.cis_v120_2, + benchmark.cis_v120_3, + benchmark.cis_v120_4 + ] + + tags = merge(local.cis_v120_common_tags, { + type = "Benchmark" + }) +} diff --git a/cis_v120/docs/cis_overview.md b/cis_v120/docs/cis_overview.md new file mode 100644 index 00000000..dad26bd9 --- /dev/null +++ b/cis_v120/docs/cis_overview.md @@ -0,0 +1,29 @@ +To obtain the latest version of the official guide, please visit http://benchmarks.cisecurity.org. + +## Overview + +The CIS Amazon Web Services Foundations Benchmark provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings. Specific Amazon Web Services in scope include: + +- AWS Identity and Access Management (IAM) +- AWS Config +- AWS CloudTrail +- AWS CloudWatch +- AWS Simple Notification Service (SNS) +- AWS Simple Storage Service (S3) +- AWS VPC (Default) + +## Profiles + +### Level 1 + +Items in this profile intend to: +- be practical and prudent; +- provide a clear security benefit; and +- not inhibit the utility of the technology beyond acceptable means. + +### Level 2 + +This profile extends the "Level 1" profile. Items in this profile exhibit one or more of the following characteristics: +- are intended for environments or use cases where security is paramount +- acts as defense in depth measure +- may negatively inhibit the utility or performance of the technology. \ No newline at end of file diff --git a/cis_v120/docs/cis_v120_1.md b/cis_v120/docs/cis_v120_1.md new file mode 100644 index 00000000..47ec3e90 --- /dev/null +++ b/cis_v120/docs/cis_v120_1.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring identity and access management related options. diff --git a/cis_v120/docs/cis_v120_1_1.md b/cis_v120/docs/cis_v120_1_1.md new file mode 100644 index 00000000..a16244fc --- /dev/null +++ b/cis_v120/docs/cis_v120_1_1.md @@ -0,0 +1,9 @@ +## Description + +The "root" account has unrestricted access to all resources in the AWS account. It is highly recommended that the use of this account be avoided. + +The "root" account is the most privileged AWS account. Minimizing the use of this account and adopting the principle of least privilege for access management will reduce the risk of accidental changes and unintended disclosure of highly privileged credentials. + +## Remediation + +Follow the remediation instructions of the Ensure IAM policies are attached only to groups or roles recommendation. diff --git a/cis_v120/docs/cis_v120_1_10.md b/cis_v120/docs/cis_v120_1_10.md new file mode 100644 index 00000000..912c40ce --- /dev/null +++ b/cis_v120/docs/cis_v120_1_10.md @@ -0,0 +1,25 @@ +## Description + +IAM password policies can prevent the reuse of a given password by the same user. It is recommended that the password policy prevent the reuse of passwords. + +Preventing password reuse increases account resiliency against brute force login attempts. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### Via AWS Console + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Click on Account Settings on the Left Pane. +4. Check "Prevent password reuse". +5. Set "Number of passwords to remember" is set to `24`. + +### Via CLI + +```bash +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. diff --git a/cis_v120/docs/cis_v120_1_11.md b/cis_v120/docs/cis_v120_1_11.md new file mode 100644 index 00000000..eb27d941 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_11.md @@ -0,0 +1,30 @@ +## Description + +IAM password policies can require passwords to be rotated or expired after a given number of days. It is recommended that the password policy expire passwords after 90 days or less. + +Reducing the password lifetime increases account resiliency against brute force login attempts. Additionally, requiring regular password changes help in the following scenarios: + +- Passwords can be stolen or compromised sometimes without your knowledge. This can happen via a system compromise, software vulnerability, or internal threat. +- Certain corporate and government web filters or proxy servers have the ability to intercept and record traffic even if it's encrypted. +- Many people use the same password for many systems such as work, email, and personal. +- Compromised end user workstations might have a keystroke logger. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### Via AWS Console: + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Click on Account Settings on the Left Pane. +4. Check "Enable password expiration". +5. Set "Password expiration period (in days):" to 90 or less. + +### Via CLI + +```bash +aws iam update-account-password-policy --max-password-age 90 +``` + +**Note**: All commands starting with "aws iam update-account-password-policy" can be combined into a single command. diff --git a/cis_v120/docs/cis_v120_1_12.md b/cis_v120/docs/cis_v120_1_12.md new file mode 100644 index 00000000..d7b02729 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_12.md @@ -0,0 +1,21 @@ +## Description + +The root 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 account be removed. + +Removing access keys associated with the root account limits vectors by which the account can be compromised. Additionally, removing the root access keys encourages the creation and use of role based accounts that are least privileged. + +## Remediation + +Perform the following to delete or disable active root access keys being + +### Via the AWS Console + +Perform the following action to disable user console password: + +1. Sign in to the AWS Management Console as Root and open the [IAM console](https://console.aws.amazon.com/iam/). +2. Click on `` at the top right and select `Security Credentials` from the drop down list. +3. On the pop out screen Click on `Continue to Security Credentials`. +4. Click on `Access Keys` (Access Key ID and Secret Access Key). +5. Under the `Status` column if there are any Keys which are Active + - Click on `Make Inactive` - (Temporarily disable Key - may be needed again). + - Click `Delete` - (Deleted keys cannot be recovered). diff --git a/cis_v120/docs/cis_v120_1_13.md b/cis_v120/docs/cis_v120_1_13.md new file mode 100644 index 00000000..0dd5bd11 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_13.md @@ -0,0 +1,30 @@ +## Description + +The root account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. + +**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. + +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. + +## Remediation + +Perform the following to establish MFA for the root account: + +### From Console: + +Perform the following action to deactivate access keys: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). +**Note**: to manage MFA devices for the root AWS account, you must use your root account credentials to sign in to AWS. You cannot manage MFA devices for the root account using other credentials. +2. Choose `Dashboard` , and under `Security Status` , expand `Activate MFA` on your root account. +3. Choose `Activate MFA`. +4. In the wizard, choose `A virtual MFA` device and then choose `Next Step`. +5. IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. The graphic is a representation of the 'secret configuration key' that is available for manual entry on devices that do not support QR codes. +6. Open your virtual MFA application. (For a list of apps that you can use for hosting virtual MFA devices, see [Virtual MFA Applications](https://aws.amazon.com/iam/features/mfa/?audit=2019q1#Virtual_MFA_Applications).) If the virtual MFA application supports multiple accounts (multiple virtual MFA devices), choose the option to create a new account (a new virtual MFA device). +7. Determine whether the MFA app supports QR codes, and then do one of the following: + - Use the app to scan the QR code. For example, you might choose the camera icon or choose an option similar to Scan code, and then use the device's camera to scan the code. + - In the Manage MFA Device wizard, choose Show secret key for manual configuration, and then type the secret configuration key into your MFA application. + +When you are finished, the virtual MFA device starts generating one-time passwords. + +1. 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 Active Virtual MFA. diff --git a/cis_v120/docs/cis_v120_1_14.md b/cis_v120/docs/cis_v120_1_14.md new file mode 100644 index 00000000..9a54623e --- /dev/null +++ b/cis_v120/docs/cis_v120_1_14.md @@ -0,0 +1,25 @@ +## Description + +The root account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. For Level 2, it is recommended that the root account be protected with a hardware MFA. + +A hardware MFA has a smaller attack surface than a virtual MFA. For example, a hardware MFA does not suffer the attack surface introduced by the mobile smartphone on which a virtual MFA resides. + +**Note**: Using hardware MFA for many, many AWS accounts may create a logistical device management issue. If this is the case, consider implementing this Level 2 recommendation selectively to the highest security AWS accounts and the Level 1 recommendation applied to the remaining accounts. + +Link to order AWS compatible hardware MFA device: http://onlinenoram.gemalto.com/ + +## Remediation + +Perform the following to establish a hardware MFA for the root account: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). + +**Note**: To manage MFA devices for the root AWS account, you must use your root account credentials to sign in to AWS. You cannot manage MFA devices for the root account using other credentials. + +2. Choose `Dashboard` , and under `Security Status` , expand `Activate MFA` on your root account. +3. Choose `Activate MFA`. +4. In the wizard, choose `A hardware MFA` device and then choose `Next Step`. +5. In the `Serial Number` box, enter the serial number that is found on the back of the MFA device. +6. In the `Authentication Code` 1 box, enter the six-digit number displayed by the MFA device. You might need to press the button on the front of the device to display the number. +7. Wait 30 seconds while the device refreshes the code, and then enter the next six-digit number into the `Authentication Code 2` box. You might need to press the button on the front of the device again to display the second number. +8. Choose `Next Step`. The MFA device is now associated with the AWS account. The next time you use your AWS account credentials to sign in, you must type a code from the hardware MFA device. diff --git a/cis_v120/docs/cis_v120_1_15.md b/cis_v120/docs/cis_v120_1_15.md new file mode 100644 index 00000000..49571225 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_15.md @@ -0,0 +1,22 @@ +## Description + +The AWS support portal allows account owners to establish security questions that can be used to authenticate individuals calling AWS customer service for support. It is recommended that security questions be established. + +When creating a new AWS account, a default super user is automatically created. This account is referred to as the "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 login access. + +## Remediation + +Perform the following in the AWS Management Console: + +1. Login to the AWS Account as root. +2. Click on the `` from the top right of the console. +3. From the drop-down menu Click My Account. +4. Scroll down to the `Configure Security Questions` section. +5. Click on `Edit`. +6. 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 +7. Click `Update` when complete. +8. Place Questions and Answers and place in a secure physical location. diff --git a/cis_v120/docs/cis_v120_1_16.md b/cis_v120/docs/cis_v120_1_16.md new file mode 100644 index 00000000..b8ed6d76 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_16.md @@ -0,0 +1,36 @@ +## Description + +By default, IAM users, groups, and roles have no access to AWS resources. IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended that IAM policies be applied directly to groups and roles but not users. + +Assigning privileges at the group or role level reduces the complexity of access management as the number of users grow. Reducing access management complexity may in-turn reduce opportunity for a principal to inadvertently receive or retain excessive privileges. + +## Remediation + +Perform the following to create an IAM group and assign a policy to it: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). +2. In the navigation pane, click Groups and then click `Create New Group`. +3. In the `Group Name` box, type the name of the group and then click `Next Step`. +4. In the list of policies, select the check box for each policy that you want to apply to all members of the group. Then click `Next Step`. +5. Click `Create Group`. + +Perform the following to add a user to a given group: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). +2. In the navigation pane, click `Groups`. +3. Select the group to add a user to. +4. Click `Add Users To Group`. +5. Select the users to be added to the group. +6. Click `Add Users`. + +Perform the following to remove a direct association between a user and policy: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). +2. In the left navigation pane, click on Users. +3. For each user: + - Select the user. + - Click on the `Permissions` tab. + - Expand `Managed Policies`. + - Click `Detach Policy` for each policy. + - Expand `Inline Policies`. + - Click `Remove Policy` for each policy. diff --git a/cis_v120/docs/cis_v120_1_17.md b/cis_v120/docs/cis_v120_1_17.md new file mode 100644 index 00000000..feb48336 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_17.md @@ -0,0 +1,20 @@ +## Description + +Ensure contact email and telephone details for AWS accounts are current and map to more than one individual in your organization. + +An AWS account supports a number of contact details, and AWS will use these to contact the account owner if activity judged to be in breach of Acceptable Use Policy or indicative of likely security compromise is observed by the AWS Abuse team. Contact details should not be for a single individual, as circumstances may arise where that individual is unavailable. Email contact details should point to a mail alias which forwards email to multiple individuals within the organization; where feasible, phone contact details should point to a PABX hunt group or other call-forwarding system. + +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. + +## Remediation + +This activity can only be performed via the AWS Console, with a user who has permission to read and write Billing information (aws-portal:*Billing ). + +- Sign in to the AWS Management Console and open the [Billing and Cost Management console](https://console.aws.amazon.com/billing/home#/). +- On the navigation bar, choose your account name, and then choose My 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. diff --git a/cis_v120/docs/cis_v120_1_18.md b/cis_v120/docs/cis_v120_1_18.md new file mode 100644 index 00000000..353860dc --- /dev/null +++ b/cis_v120/docs/cis_v120_1_18.md @@ -0,0 +1,16 @@ +## Description + +AWS provides customers with the option of specifying the contact information for account's security team. It is recommended that this information be provided. + +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. + +## Remediation + +Perform the following in the AWS Management Console to establish security contact information: + +1. Click on your account name at the top right corner of the console. +2. From the drop-down menu Click `My Account`. +3. Scroll down to the `Alternate Contacts` section. +4. Enter contact information in the `Security` section. + +**Note**: Consider specifying an internal email distribution list to ensure emails are regularly monitored by more than one individual. diff --git a/cis_v120/docs/cis_v120_1_19.md b/cis_v120/docs/cis_v120_1_19.md new file mode 100644 index 00000000..036bfaf8 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_19.md @@ -0,0 +1,23 @@ +## Description + +AWS access from within AWS instances can be done by either encoding AWS keys into AWS API calls or by assigning the instance to a role which has an appropriate permissions policy for the required access. "AWS Access" means accessing the APIs of AWS in order to access AWS resources or manage AWS account resources. + +AWS IAM roles reduce the risks associated with sharing and rotating credentials that can be used outside of AWS itself. If credentials are compromised, they can be used from outside of the AWS account they give access to. In contrast, in order to leverage role permissions an attacker would need to gain and maintain access to a specific instance to use the privileges associated with it. + +Additionally, if credentials are encoded into compiled applications or other hard to change mechanisms, then they are even more unlikely to be properly rotated due to service disruption risks. As time goes on, credentials that cannot be rotated are more likely to be known by an increasing number of individuals who no longer work for the organization owning the credentials. + +## Remediation + +IAM roles can only be associated at the launch of an instance. To remediate an instance to add it to a role you must create a new instance. +If the instance has no external dependencies on its current private ip or public addresses are elastic IPs: + +1. In AWS IAM create a new role. Assign a permissions policy if needed permissions are already known. +2. In the AWS console launch a new instance with identical settings to the existing instance, and ensure that the newly created role is selected. +3. Shutdown both the existing instance and the new instance. +4. Detach disks from both instances. +5. Attach the existing instance disks to the new instance. +6. Boot the new instance and you should have the same machine, but with the associated role. + +**Note**: If your environment has dependencies on a dynamically assigned PRIVATE IP address you can create an AMI from the existing instance, destroy the old one and then when launching from the AMI, manually assign the previous private IP address. + +**Note**: If your environment has dependencies on a dynamically assigned PUBLIC IP address there is not a way ensure the address is retained and assign an instance role. Dependencies on dynamically assigned public IP addresses are a bad practice and, if possible, you may wish to rebuild the instance with a new elastic IP address and make the investment to remediate affected systems while assigning the system to a role. diff --git a/cis_v120/docs/cis_v120_1_2.md b/cis_v120/docs/cis_v120_1_2.md new file mode 100644 index 00000000..99945133 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_2.md @@ -0,0 +1,28 @@ +## Description + +Multi-Factor Authentication (MFA) adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. It is recommended that MFA be enabled for all accounts that have a console password. + +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. + +## Remediation + +Perform the following to enable MFA: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). +2. In the navigation pane, choose Users. +3. In the User Name list, choose the name of the intended MFA user. +4. Choose the Security Credentials tab, and then choose Manage MFA Device. +5. In the Manage MFA Device wizard, choose 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. + +6. Open your virtual MFA application. (For a list of apps that you can use for hosting virtual MFA devices, see [Virtual MFA Applications](https://aws.amazon.com/iam/features/mfa/?audit=2019q1#Virtual_MFA_Applications).) If the virtual MFA application supports multiple accounts (multiple virtual MFA devices), choose the option to create a new account (a new virtual MFA device). +7. Determine whether the MFA app supports QR codes, and then do one of the following: + - Use the app to scan the QR code. For example, you might choose the camera icon or choose an option similar to Scan code, and then use the device's camera to scan the code. + - In the Manage MFA Device wizard, choose Show secret key for manual configuration, and then type the secret configuration key into your MFA application. +When you are finished, the virtual MFA device starts generating one-time passwords. +8. 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 Active Virtual MFA. + +### Forced IAM User Self-Service Remediation + +Amazon has published a pattern that forces users to self-service setup MFA before they have access to their complete permissions set. Until they complete this step, they cannot access their full permissions. This pattern can be used on new AWS accounts. It can also be used on existing accounts - it is recommended users are given instructions and a grace period to accomplish MFA enrollment before active enforcement on existing AWS accounts. [How to Delegate Management of Multi-Factor Authentication to AWS IAM Users](http://blogs.aws.amazon.com/security/post/Tx2SJJYE082KBUK/How-to-Delegate-Management-of-Multi-Factor-Authentication-to-AWS-IAM-Users). diff --git a/cis_v120/docs/cis_v120_1_20.md b/cis_v120/docs/cis_v120_1_20.md new file mode 100644 index 00000000..d244fd0f --- /dev/null +++ b/cis_v120/docs/cis_v120_1_20.md @@ -0,0 +1,39 @@ +## Description + +AWS provides a support center that can be used for incident notification and response, as well as technical support and customer services. Create an IAM Role to allow authorized users to manage incidents with AWS Support. + +By implementing least privilege for access control, an IAM Role will require an appropriate IAM Policy to allow Support Center Access in order to manage Incidents with AWS Support. + +## Remediation + +### Using the Amazon unified command line interface: + +- 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: + + ```bash + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "" + }, + "Action": "sts:AssumeRole" + } + ] + } + ``` + + - Create the IAM role using the above trust policy: + + ```bash + aws iam create-role --role-name --assume-role- policy-document file:///tmp/TrustPolicy.json + ``` + + - Attach 'AWSSupportAccess' managed policy to the created IAM role: + + ```bash + aws iam attach-role-policy --policy-arn --role-name + ``` diff --git a/cis_v120/docs/cis_v120_1_21.md b/cis_v120/docs/cis_v120_1_21.md new file mode 100644 index 00000000..ebd323ae --- /dev/null +++ b/cis_v120/docs/cis_v120_1_21.md @@ -0,0 +1,27 @@ +## Description + +AWS console defaults the checkbox for creating access keys to enabled. This results in many access keys being generated unnecessarily. In addition to unnecessary credentials, it also generates unnecessary management work in auditing and rotating these keys. + +Requiring that additional steps be taken by the user 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 the created as a separate step from user creation. + +## Remediation + +Perform the following to delete access keys that do not pass the audit: + +1. Login to the AWS Management Console: +2. Click `Services`. +3. Click `IAM`. +4. Click on `Users`. +5. Click on `Security Credentials`. +6. As an Administrator + - Click on `Delete` for keys that were created at the same time as the user profile but have not been used. +7. As an IAM User + - Click on `Delete` for keys that were created at the same time as the user profile but have not been used. + +### Via CLI + +```bash +aws iam delete-access-key +``` diff --git a/cis_v120/docs/cis_v120_1_22.md b/cis_v120/docs/cis_v120_1_22.md new file mode 100644 index 00000000..f53d4bd9 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_22.md @@ -0,0 +1,51 @@ +## Description + +IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege—that is, granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges. + +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. + +## Remediation + +### Using the GUI + +Perform the following to detach the policy that has full administrative privileges: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). +2. In the navigation pane, click Policies and then search for the policy name found in the audit step. +3. Select the policy that needs to be deleted. +4. In the policy action menu, select first `Detach` +5. Select all Users, Groups, Roles that have this policy attached +6. Click `Detach Policy`. +7. In the policy action menu, select `Detach`. + +### Using the CLI + +Perform the following to detach the policy that has full administrative privileges: + +1. Lists all IAM users, groups, and roles that the specified managed policy is attached to. + +```bash +aws iam list-entities-for-policy --policy-arn +``` + +2. Detach the policy from all IAM Users: + +```bash +aws iam detach-user-policy --user-name --policy-arn +``` + +3. Detach the policy from all IAM Groups: + +```bash +aws iam detach-group-policy --group-name --policy-arn +``` + +4. Detach the policy from all IAM Roles: + +```bash +aws iam detach-role-policy --role-name --policy-arn +``` diff --git a/cis_v120/docs/cis_v120_1_3.md b/cis_v120/docs/cis_v120_1_3.md new file mode 100644 index 00000000..e22c312a --- /dev/null +++ b/cis_v120/docs/cis_v120_1_3.md @@ -0,0 +1,19 @@ +## Description + +AWS IAM users can access AWS resources using different types of credentials, such as passwords or access keys. It is recommended that all credentials that have been unused in 90 or greater days be removed or deactivated. + +Disabling or removing unnecessary credentials will reduce the window of opportunity for credentials associated with a compromised or abandoned account to be used. + +## Remediation + +Perform the following to remove or deactivate credentials: + +1. Login to the AWS Management Console: +2. Click `Services`. +3. Click `IAM`. +4. Click on `Users`. +5. Click on `Security Credentials`. +6. As an Administrator. + - Click on `Make Inactive` for credentials that have not been used in `90` Days. +7. As an IAM User. + - Click on `Make Inactive` or `Delete` for credentials which have not been used in `90` Days. diff --git a/cis_v120/docs/cis_v120_1_4.md b/cis_v120/docs/cis_v120_1_4.md new file mode 100644 index 00000000..d3d0f82f --- /dev/null +++ b/cis_v120/docs/cis_v120_1_4.md @@ -0,0 +1,30 @@ +## Description + +Access keys consist of an access key ID and secret access key, which are used to sign programmatic requests that you make to AWS. AWS users need their own access keys to make programmatic calls to AWS from the AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, the AWS SDKs, or direct HTTP calls using the APIs for individual AWS services. It is recommended that all access keys be regularly rotated. + +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. + +## Remediation + +Perform the following to rotate access keys: + +1. Login to the AWS Management Console: +2. Click `Services`. +3. Click `IAM`. +4. Click on `Users`. +5. Click on `Security Credentials`. +6. As an Administrator + - Click on `Make Inactive` for keys that have not been rotated in `90` Days. +7. As an IAM User + - Click on `Make Inactive` or `Delete` for keys which have not been rotated or used in `90` Days. +8. Click on `Create Access Key`. +9. Update programmatic call with new Access Key credentials. + +### Via CLI + +```bash +aws iam update-access-key +aws iam create-access-key +aws iam delete-access-key +``` diff --git a/cis_v120/docs/cis_v120_1_5.md b/cis_v120/docs/cis_v120_1_5.md new file mode 100644 index 00000000..aebd3aa0 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_5.md @@ -0,0 +1,25 @@ +## Description + +Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one uppercase letter. + +Setting a password complexity policy increases account resiliency against brute force login attempts. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### Via AWS Console + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Click on Account Settings on the Left Pane. +4. Check "Requires at least one uppercase letter". +5. Click "Apply password policy". + +### Via CLI + +```bash +aws iam update-account-password-policy --require-uppercase-characters +``` + +**Note**: All commands starting with "aws iam update-account-password-policy" can be combined into a single command. diff --git a/cis_v120/docs/cis_v120_1_6.md b/cis_v120/docs/cis_v120_1_6.md new file mode 100644 index 00000000..7ec15a3c --- /dev/null +++ b/cis_v120/docs/cis_v120_1_6.md @@ -0,0 +1,25 @@ +## Description + +Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one lowercase letter. + +Setting a password complexity policy increases account resiliency against brute force login attempts. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### Via the AWS Console + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Click on Account Settings on the Left Pane. +4. Check "Requires at least one lowercase letter". +5. Click "Apply password policy". + +### Via CLI + +```bash +aws iam update-account-password-policy --require-lowercase-characters +``` + +**Note**: All commands starting with "aws iam update-account-password-policy" can be combined into a single command. diff --git a/cis_v120/docs/cis_v120_1_7.md b/cis_v120/docs/cis_v120_1_7.md new file mode 100644 index 00000000..d78bfbc6 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_7.md @@ -0,0 +1,25 @@ +## Description + +Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one symbol. + +Setting a password complexity policy increases account resiliency against brute force login attempts. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### Via AWS Console + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Click on Account Settings on the Left Pane. +4. Check "Require at least one non-alphanumeric character". +5. Click "Apply password policy". + +### Via CLI + +```bash +aws iam update-account-password-policy --require-symbols +``` + +**Note**: All commands starting with "aws iam update-account-password-policy" can be combined into a single command. diff --git a/cis_v120/docs/cis_v120_1_8.md b/cis_v120/docs/cis_v120_1_8.md new file mode 100644 index 00000000..0915b115 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_8.md @@ -0,0 +1,25 @@ +## Description + +Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one number. + +Setting a password complexity policy increases account resiliency against brute force login attempts. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### Via AWS Console + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Click on Account Settings on the Left Pane. +4. Check "Require at least one number". +5. Click "Apply password policy". + +### Via CLI + +```bash +aws iam update-account-password-policy --require-numbers +``` + +**Note**: All commands starting with "aws iam update-account-password-policy" can be combined into a single command. diff --git a/cis_v120/docs/cis_v120_1_9.md b/cis_v120/docs/cis_v120_1_9.md new file mode 100644 index 00000000..e4c385e3 --- /dev/null +++ b/cis_v120/docs/cis_v120_1_9.md @@ -0,0 +1,25 @@ +## Description + +Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are at least a given length. It is recommended that the password policy require a minimum password length 14. + +Setting a password complexity policy increases account resiliency against brute force login attempts. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### Via AWS Console + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Click on Account Settings on the Left Pane. +4. Set "Minimum password length" to `14` or greater. +5. Click "Apply password policy". + +### Via CLI + +```bash +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. diff --git a/cis_v120/docs/cis_v120_2.md b/cis_v120/docs/cis_v120_2.md new file mode 100644 index 00000000..6457d90c --- /dev/null +++ b/cis_v120/docs/cis_v120_2.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS's account logging features. diff --git a/cis_v120/docs/cis_v120_2_1.md b/cis_v120/docs/cis_v120_2_1.md new file mode 100644 index 00000000..70a57b8d --- /dev/null +++ b/cis_v120/docs/cis_v120_2_1.md @@ -0,0 +1,39 @@ +## Description + +AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation). + +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 + +## Remediation + +Perform the following to enable global (Multi-region) CloudTrail logging: + +### Via the management Console + +1. Sign in to the AWS Management Console and open the IAM console at [cloudtrail](https://console.aws.amazon.com/cloudtrail) +2. Click on `Trails` on the left navigation pane +3. Click `Get Started Now` , if presented. + + - Click `Add new trail`. + - Enter a trail name in the `Trail name` box. + - Set the `Apply trail to all regions` option to `Yes`. + - Specify an S3 bucket name in the `S3 bucket` box. + - Click `Create`. + +4. If 1 or more trails already exist, select the target trail to enable for global logging. +5. Click the edit icon (pencil) next to `Apply trail to all regions`, Click `Yes` and Click `Save`. +6. Click the edit icon (pencil) next to `Management Events` click `All` for setting `Read/Write Events` and Click `Save`. + +### Via CLI + +```bash +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 diff --git a/cis_v120/docs/cis_v120_2_2.md b/cis_v120/docs/cis_v120_2_2.md new file mode 100644 index 00000000..efa45d0e --- /dev/null +++ b/cis_v120/docs/cis_v120_2_2.md @@ -0,0 +1,33 @@ +## Description + +CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to S3. These digest files can be used to determine whether a log file was changed, deleted, or unchanged after CloudTrail delivered the log. It is recommended that file validation be enabled on all CloudTrails. + +Enabling log file validation will provide additional integrity checking of CloudTrail logs. + +## Remediation + +Perform the following to enable log file validation on a given trail: + +### Via the management Console + +1. Sign in to the AWS Management Console and open the IAM console at [cloudtrail](https://console.aws.amazon.com/cloudtrail). +2. Click on `Trails` on the left navigation pane. +3. Click on target trail. +4. Within the `S3` section click on the edit icon (pencil). +5. Click `Advanced`. +6. Click on the `Yes` radio button in section `Enable log file validation`. +7. Click `Save`. + +### Via CLI + +```bash +aws cloudtrail update-trail --name --enable-log-file-validation +``` + +**Note**: that periodic validation of logs using these digests can be performed by running the following command: + +```bash +aws cloudtrail validate-logs --trail-arn --start-time --end-time +``` + +**Default Value**: Not Enabled diff --git a/cis_v120/docs/cis_v120_2_3.md b/cis_v120/docs/cis_v120_2_3.md new file mode 100644 index 00000000..cca362ad --- /dev/null +++ b/cis_v120/docs/cis_v120_2_3.md @@ -0,0 +1,21 @@ +## Description + +CloudTrail logs a record of every API call made in your AWS account. These logs file are stored in an S3 bucket. It is recommended that the bucket policy, or access control list (ACL), applied to the S3 bucket that CloudTrail logs to prevents public access to the CloudTrail logs. + +Allowing public access to CloudTrail log content may aid an adversary in identifying weaknesses in the affected account's use or configuration. + +## Remediation + +Perform the following to remove any public access that has been granted to the bucket via an ACL or S3 bucket policy: + +1. Go to [Amazon S3 console](https://console.aws.amazon.com/s3/home). +2. Right-click on the bucket and click Properties. +3. In the `Properties` pane, click the `Permissions` tab. +4. The tab shows a list of grants, one row per grant, in the bucket ACL. Each row identifies the grantee and the permissions granted. +5. Select the row that grants permission to Everyone or `Any Authenticated User`. +6. Uncheck all the permissions granted to `Everyone` or `Any Authenticated User` (click `x` to delete the row). +7. Click `Save` to save the ACL. +8. If the `Edit bucket policy` button is present, click it. +9. Remove any `Statement` having an `Effect` set to `Allow` and a `Principal` set to `"*"` or `{"AWS" : "*"}`. + +**Default Value**: By default, S3 buckets are not publicly accessible. diff --git a/cis_v120/docs/cis_v120_2_4.md b/cis_v120/docs/cis_v120_2_4.md new file mode 100644 index 00000000..825c2e7d --- /dev/null +++ b/cis_v120/docs/cis_v120_2_4.md @@ -0,0 +1,32 @@ +## Description + +AWS CloudTrail is a web service that records AWS API calls made in a given AWS account. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail uses Amazon S3 for log file storage and delivery, so log files are stored durably. In addition to capturing CloudTrail logs within a specified S3 bucket for long term analysis, realtime analysis can be performed by configuring CloudTrail to send logs to CloudWatch Logs. For a trail that is enabled in all regions in an account, CloudTrail sends log files from all those regions to a CloudWatch Logs log group. It is recommended that CloudTrail logs be sent to CloudWatch Logs. + +**Note**: The intent of this recommendation is to ensure AWS account activity is being captured, monitored, and appropriately alarmed on. CloudWatch Logs is a native way to accomplish this using AWS services but does not preclude the use of an alternate solution. + +Sending CloudTrail logs to CloudWatch Logs will facilitate real-time and historic activity logging based on user, API, resource, and IP address, and provides opportunity to establish alarms and notifications for anomalous or sensitivity account activity. + + +## Remediation + +Perform the following to establish the prescribed state: + +### Via the AWS management Console + +1. Sign in to the AWS Management Console and open the CloudTrail console at [cloudtrail](https://console.aws.amazon.com/cloudtrail/). +2. Under All Buckets, click on the target bucket you wish to evaluate. +3. Click Properties on the top right of the console. +4. Click `Trails` in the left menu. +5. Click on each trail where no `CloudWatch Logs` are defined. +6. Go to the `CloudWatch Logs` section and click on `Configure`. +7. Define a new or select an existing log group. +8. Click on `Continue`. +9. Configure IAM Role which will deliver CloudTrail events to CloudWatch Logs. + - Create/Select an `IAM Role` and `Policy Name`. + - Click `Allow` to continue. + +### Via CLI + +```bash +aws cloudtrail update-trail --name --cloudwatch-logs-log-group- arn --cloudwatch-logs-role-arn +``` diff --git a/cis_v120/docs/cis_v120_2_5.md b/cis_v120/docs/cis_v120_2_5.md new file mode 100644 index 00000000..279ef7ef --- /dev/null +++ b/cis_v120/docs/cis_v120_2_5.md @@ -0,0 +1,34 @@ +## Description + +AWS Config is a web service that performs configuration management of supported AWS resources within your account and delivers log files to you. The recorded information includes the configuration item (AWS resource), relationships between configuration items (AWS resources), any configuration changes between resources. It is recommended to enable AWS Config be enabled in all regions. + +The AWS configuration item history captured by AWS Config enables security analysis, resource change tracking, and compliance auditing. + +## Remediation + +To implement AWS Config configuration: + +### Via AWS Management Console: + +1. Select the region you want to focus on in the top right of the console. +2. Click `Services`. +3. Click `Config`. +4. Define which resources you want to record in the selected region. +5. Choose to include global resources (IAM resources). +6. Specify an S3 bucket in the same account or in another managed AWS account. +7. Create an SNS Topic from the same AWS account or another managed AWS account. + +### Via AWS Command Line Interface: + +1. Ensure there is an appropriate S3 bucket, SNS topic, and IAM role per the [AWS Config Service prerequisites](https://docs.aws.amazon.com/config/latest/developerguide/gs-cli-prereq.html). +2. Run this command to set up the configuration recorder + +```bash +aws configservice subscribe --s3-bucket my-config-bucket --sns-topic arn:aws:sns:us-east-1:012345678912:my-config-notice --iam-role arn:aws:iam::012345678912:role/myConfigRole + ``` + +3. Run this command to start the configuration recorder: + +```bash +start-configuration-recorder --configuration-recorder-name +``` diff --git a/cis_v120/docs/cis_v120_2_6.md b/cis_v120/docs/cis_v120_2_6.md new file mode 100644 index 00000000..da8cc6bf --- /dev/null +++ b/cis_v120/docs/cis_v120_2_6.md @@ -0,0 +1,23 @@ +## Description + +S3 Bucket Access Logging generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed. It is recommended that bucket access logging be enabled on the CloudTrail S3 bucket. + +By enabling S3 bucket logging on target S3 buckets, it is possible to capture all events which may affect objects within an 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. + +## Remediation + +Perform the following to enable S3 bucket logging: + +### Via the Management Console + +1. Sign in to the AWS Management Console and open the [S3 console](https://console.aws.amazon.com/s3). +2. Under `All Buckets` click on the target S3 bucket. +3. Click on `Properties` in the top right of the console. +4. Under `Bucket`: `` click on `Logging`. +5. Configure bucket logging + - Click on `Enabled` checkbox. + - Select Target Bucket from list. + - Enter a Target Prefix. +6. Click `Save`. + +**Default Value**: Logging is disabled. diff --git a/cis_v120/docs/cis_v120_2_7.md b/cis_v120/docs/cis_v120_2_7.md new file mode 100644 index 00000000..d677adcb --- /dev/null +++ b/cis_v120/docs/cis_v120_2_7.md @@ -0,0 +1,30 @@ +## Description + +AWS CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use SSE-KMS. + +Configuring CloudTrail to use SSE-KMS provides additional confidentiality controls on log data as a given user must have S3 read permission on the corresponding log bucket and must be granted decrypt permission by the CMK policy. + +## Remediation + +Perform the following to configure CloudTrail to use SSE-KMS: + +### Via the Management Console + +1. Sign in to the AWS Management Console and open the [CloudTrail console](https://console.aws.amazon.com/cloudtrail). +2. In the left navigation pane, choose `Trails`. +3. Click on a Trail. +4. Under the `S3` section click on the edit button (pencil icon). +5. Click `Advanced`. +6. Select an existing CMK from the `KMS key Id` drop-down menu. + - Note: Ensure the CMK is located in the same region as the S3 bucket + - Note: You will need to apply a KMS Key policy on the selected CMK in order for +CloudTrail as a service to encrypt and decrypt log files using the CMK provided. Steps are provided [here](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-kms-key-policy-for-cloudtrail.html) for editing the selected CMK Key policy. +7. Click `Save`. +8. You will see a notification message stating that you need to have decrypt permissions on the specified KMS key to decrypt log files. +9. Click `Yes`. + +### Via CLI + +```bash +aws cloudtrail update-trail --name --kms-id aws kms put-key-policy --key-id --policy +``` diff --git a/cis_v120/docs/cis_v120_2_8.md b/cis_v120/docs/cis_v120_2_8.md new file mode 100644 index 00000000..ef98a6d9 --- /dev/null +++ b/cis_v120/docs/cis_v120_2_8.md @@ -0,0 +1,23 @@ +## Description + +AWS Key Management Service (KMS) allows customers to rotate the backing key which is key material stored within the KMS which is tied to the key ID of the Customer Created customer master key (CMK). It is the backing key that is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all prior backing keys so that decryption of encrypted data can take place transparently. It is recommended that CMK key rotation be enabled. + +Rotating encryption keys helps reduce the potential impact of a compromised key as data encrypted with a new key cannot be accessed with a previous key that may have been exposed. + +## Remediation + +### Via the Management Console: + +1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam). +2. In the left navigation pane, choose `Encryption Keys`. +3. Select a customer created master key (CMK). +4. Under the `Key Policy` section, move down to `Key Rotation`. +5. Check the `Rotate this key every year` checkbox. + +### Via CLI + +1. Run the following command to enable key rotation: + +```bash +aws kms enable-key-rotation --key-id +``` diff --git a/cis_v120/docs/cis_v120_2_9.md b/cis_v120/docs/cis_v120_2_9.md new file mode 100644 index 00000000..88492682 --- /dev/null +++ b/cis_v120/docs/cis_v120_2_9.md @@ -0,0 +1,24 @@ +## Description + +VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet "Rejects" for VPCs. + +VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or insight during security workflows. + +## Remediation + +Perform the following to determine if VPC Flow logs is enabled: + +### Via the Management Console: + +1. Sign into the management console. +2. Select `Services` then `VPC`. +3. In the left navigation pane, select `Your VPCs`. +4. Select a VPC. +5. In the right pane, select the `Flow Logs` tab. +6. If no Flow Log exists, click `Create Flow Log`. +7. `For` Filter, select Reject. +8. Enter in a `Role` and `Destination Log Group`. +9. Click `Create Log Flow`. +10. Click on `CloudWatch Logs Group`. + +**Note**: Setting the filter to "Reject" will dramatically reduce the logging data accumulation for this recommendation and provide sufficient information for the purposes of breach detection, research and remediation. However, during periods of least privilege security group engineering, setting this the filter to "All" can be very helpful in discovering existing traffic flows required for proper operation of an already running environment. diff --git a/cis_v120/docs/cis_v120_3.md b/cis_v120/docs/cis_v120_3.md new file mode 100644 index 00000000..22cf44dc --- /dev/null +++ b/cis_v120/docs/cis_v120_3.md @@ -0,0 +1,3 @@ +## Overview + +For effectiveness and coverage of recommended metric-filters and alarms, recommendations in Section 3 should be implemented on Multi-region CloudTrail referred in `Ensure CloudTrail is enabled in all regions` Updated Overview should look like: This section contains recommendations for configuring AWS to assist with monitoring and responding to account activities. Metric filter-related recommendations in this section are dependent on the `Ensure CloudTrail is enabled in all regions` and `Ensure CloudTrail trails are integrated with CloudWatch Logs` recommendation in the "Logging" section. Additionally, step 3 of the remediation procedure for the same recommendations provides guidance for establishing an email-based subscription (-- `protocol email`). This is provided as an example and is not meant to suggest other protocols provide lesser value. diff --git a/cis_v120/docs/cis_v120_3_1.md b/cis_v120/docs/cis_v120_3_1.md new file mode 100644 index 00000000..9da76ecb --- /dev/null +++ b/cis_v120/docs/cis_v120_3_1.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for unauthorized API calls. + +Monitoring unauthorized API calls will help reveal application errors and may reduce time to detect malicious activity. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for unauthorized API calls and the `` taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name -- filter-name `` --metric-transformations metricName= `` ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.errorCode = "*UnauthorizedOperation") || ($.errorCode = "AccessDenied*") }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_10.md b/cis_v120/docs/cis_v120_3_10.md new file mode 100644 index 00000000..c2928d09 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_10.md @@ -0,0 +1,40 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Security Groups are a stateful packet filter that controls ingress and egress traffic within a VPC. It is recommended that a metric filter and alarm be established changes to Security Groups. + +Monitoring changes to security group will help ensure that resources and services are not unintentionally exposed. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for security groups changes and the `` taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name -- filter-name `` --metric-transformations metricName= `` ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{($.eventName = AuthorizeSecurityGroupIngress) || ($.eventName = AuthorizeSecurityGroupEgress) || ($.eventName = RevokeSecurityGroupIngress) || ($.eventName = RevokeSecurityGroupEgress) || ($.eventName = CreateSecurityGroup) || ($.eventName = DeleteSecurityGroup) }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_11.md b/cis_v120/docs/cis_v120_3_11.md new file mode 100644 index 00000000..66fe5f08 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_11.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. NACLs are used as a stateless packet filter to control ingress and egress traffic for subnets within a VPC. It is recommended that a metric filter and alarm be established for changes made to NACLs. + +Monitoring changes to NACLs will help ensure that AWS resources and services are not unintentionally exposed. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for NACL changes and the `` taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name -- filter-name `` --metric-transformations metricName= `` ,metricNamespace='CISBenchmark',metricValue=1 -- filter-pattern '{ ($.eventName = CreateNetworkAcl) || ($.eventName = CreateNetworkAclEntry) || ($.eventName = DeleteNetworkAcl) || ($.eventName = DeleteNetworkAclEntry) || ($.eventName = ReplaceNetworkAclEntry) || ($.eventName = ReplaceNetworkAclAssociation) }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_12.md b/cis_v120/docs/cis_v120_3_12.md new file mode 100644 index 00000000..f0b0cf18 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_12.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs 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. + +Monitoring changes to network gateways will help ensure that all ingress/egress traffic traverses the VPC border via a controlled path. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for network gateways changes and the `` taken from audit step 1. + +```bash +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. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_13.md b/cis_v120/docs/cis_v120_3_13.md new file mode 100644 index 00000000..674576a5 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_13.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs 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. + +Monitoring changes to route tables will help ensure that all VPC traffic flows through an expected path. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for route table changes and the `` taken from audit step 1. + +```bash +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. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_14.md b/cis_v120/docs/cis_v120_3_14.md new file mode 100644 index 00000000..28a7feb7 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_14.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is 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. + +Monitoring changes to IAM policies will help ensure authentication and authorization controls remain intact. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for VPC changes and the `` taken from audit step 1. + +```bash +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. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_2.md b/cis_v120/docs/cis_v120_3_2.md new file mode 100644 index 00000000..8f0789c8 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_2.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for console logins that are not protected by multi-factor authentication (MFA). + +Monitoring for single-factor console logins will increase visibility into accounts that are not protected by MFA. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for AWS Management Console sign-in without MFA and the `` taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name -- filter-name `` --metric-transformations metricName= `` ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_3.md b/cis_v120/docs/cis_v120_3_3.md new file mode 100644 index 00000000..ec56c760 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_3.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for root login attempts. + +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. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for "Root" account usage and the `` taken from audit step 1. + +```bash +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. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_4.md b/cis_v120/docs/cis_v120_3_4.md new file mode 100644 index 00000000..7333ce35 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_4.md @@ -0,0 +1,41 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established changes made to Identity and Access Management (IAM) policies. + +Monitoring changes to IAM policies will help ensure authentication and authorization controls remain intact. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for IAM policy changes and the taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name `` -- filter-name `` --metric-transformations metricName= `` ,metricNamespace='CISBenchmark',metricValue=1 -- filter-pattern '{($.eventName=DeleteGroupPolicy)||($.eventName=DeleteRolePolicy)||($.eventNa me=DeleteUserPolicy)||($.eventName=PutGroupPolicy)||($.eventName=PutRolePolic y)||($.eventName=PutUserPolicy)||($.eventName=CreatePolicy)||($.eventName=Del etePolicy)||($.eventName=CreatePolicyVersion)||($.eventName=DeletePolicyVersi on)||($.eventName=AttachRolePolicy)||($.eventName=DetachRolePolicy)||($.event Name=AttachUserPolicy)||($.eventName=DetachUserPolicy)||($.eventName=AttachGr oupPolicy)||($.eventName=DetachGroupPolicy)}' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_5.md b/cis_v120/docs/cis_v120_3_5.md new file mode 100644 index 00000000..959421c8 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_5.md @@ -0,0 +1,40 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for detecting changes to CloudTrail's configurations. + +Monitoring changes to CloudTrail's configuration will help ensure sustained visibility to activities performed in the AWS account. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for cloudtrail configuration changes and the `` taken from audit step 1. + +```bash +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. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_6.md b/cis_v120/docs/cis_v120_3_6.md new file mode 100644 index 00000000..e0f76135 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_6.md @@ -0,0 +1,40 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for failed console authentication attempts. + +Monitoring failed console logins may decrease lead time to detect an attempt to brute force a credential, which may provide an indicator, such as source IP, that can be used in other event correlation. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for AWS management Console Login Failures and the taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name -- filter-name `` --metric-transformations metricName= ``,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_7.md b/cis_v120/docs/cis_v120_3_7.md new file mode 100644 index 00000000..1ed27d61 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_7.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for customer created CMKs which have changed state to disabled or scheduled deletion. + +Data encrypted with disabled or deleted keys will no longer be accessible. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for disabled or scheduled for deletion CMK's and the taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name -- filter-name `` --metric- transformations metricName= `` ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{($.eventSource = kms.amazonaws.com) && (($.eventName=DisableKey)||($.eventName=ScheduleKeyDeletion)) }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_8.md b/cis_v120/docs/cis_v120_3_8.md new file mode 100644 index 00000000..8d80b990 --- /dev/null +++ b/cis_v120/docs/cis_v120_3_8.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for changes to S3 bucket policies. + +Monitoring changes to S3 bucket policies may reduce time to detect and correct permissive policies on sensitive S3 buckets. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for S3 bucket policy changes and the `` taken from audit step 1. + +```bash +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. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to the topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_3_9.md b/cis_v120/docs/cis_v120_3_9.md new file mode 100644 index 00000000..585cc4ad --- /dev/null +++ b/cis_v120/docs/cis_v120_3_9.md @@ -0,0 +1,39 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for detecting changes to CloudTrail's configurations. + +Monitoring changes to AWS Config configuration will help ensure sustained visibility of configuration items within the AWS account. + +## Remediation + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on filter pattern provided which checks for AWS Configuration changes and the taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name -- filter-name `` --metric-transformations metricName= `` ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventSource = config.amazonaws.com) && (($.eventName=StopConfigurationRecorder)||($.eventName=DeleteDeliveryChannel) ||($.eventName=PutDeliveryChannel)||($.eventName=PutConfigurationRecorder)) }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then re-use the same topic for all monitoring alarms. + +3. Create an SNS subscription to topic created in step 2 + +```bash +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. + +4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2 + +```bash +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 +``` diff --git a/cis_v120/docs/cis_v120_4.md b/cis_v120/docs/cis_v120_4.md new file mode 100644 index 00000000..73a3f162 --- /dev/null +++ b/cis_v120/docs/cis_v120_4.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring security-related aspects of the default Virtual Private Cloud (VPC). diff --git a/cis_v120/docs/cis_v120_4_1.md b/cis_v120/docs/cis_v120_4_1.md new file mode 100644 index 00000000..c4ed3030 --- /dev/null +++ b/cis_v120/docs/cis_v120_4_1.md @@ -0,0 +1,18 @@ +## Description + +Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to port 22. + +Removing unfettered connectivity to remote console services, such as SSH, reduces a server's exposure to risk. + +## Remediation + +Perform the following to implement the prescribed state: + +1. Login to the [AWS Management Console](https://console.aws.amazon.com/vpc/home). +2. In the left pane, click `Security Groups`. +3. For each security group, perform the following: +4. Select the security group. +5. Click the `Inbound Rule`s tab. +6. Identify the rules to be removed. +7. Click the x in the `Remove` column. +8. Click `Save`. diff --git a/cis_v120/docs/cis_v120_4_2.md b/cis_v120/docs/cis_v120_4_2.md new file mode 100644 index 00000000..3a59aad7 --- /dev/null +++ b/cis_v120/docs/cis_v120_4_2.md @@ -0,0 +1,18 @@ +## Description + +Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to port 3389. + +Removing unfettered connectivity to remote console services, such as RDP, reduces a server's exposure to risk. + +## Remediation + +Perform the following to implement the prescribed state: + +1. Login to the [AWS Management Console](https://console.aws.amazon.com/vpc/home). +2. In the left pane, click `Security Groups`. +3. For each security group, perform the following: +4. Select the security group. +5. Click the `Inbound Rules` tab +6. Identify the rules to be removed. +7. Click the `x` in the `Remove` column. +8. Click `Save`. diff --git a/cis_v120/docs/cis_v120_4_3.md b/cis_v120/docs/cis_v120_4_3.md new file mode 100644 index 00000000..d9a75eca --- /dev/null +++ b/cis_v120/docs/cis_v120_4_3.md @@ -0,0 +1,35 @@ +## Description + +A VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to this default security group. Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that the default security group restrict all traffic. + +The default VPC in every region should have its default security group updated to comply. Any newly created VPCs will automatically contain a default security group that will need remediation to comply with this recommendation. + +**Note**: When implementing this recommendation, VPC flow logging is invaluable in determining the least privilege port access required by systems to work properly because it can log all packet acceptances and rejections occurring under the current security groups. This dramatically reduces the primary barrier to least privilege engineering - discovering the minimum ports required by systems in the environment. Even if the VPC flow logging recommendation in this benchmark is not adopted as a permanent security measure, it should be used during any period of discovery and engineering for least privileged security groups. + +Configuring all VPC default security groups to restrict all traffic will encourage least privilege security group development and mindful placement of AWS resources into security groups which will in-turn reduce the exposure of those resources. + +## Remediation + +Security Group Members +Perform the following to implement the prescribed state: + +1. Identify AWS resources that exist within the default security group +2. Create a set of least privilege security groups for those resources +3. Place the resources in those security groups +4. Remove the resources noted in #1 from the default security group + +Security Group State + +1. Login to the [AWS Management Console](https://console.aws.amazon.com/vpc/home) +2. Repeat the next steps for all VPCs - including the default VPC in each AWS region: +3. In the left pane, click `Security Groups`. +4. For each default security group, perform the following: +5. Select the `default` security group. +6. Click the `Inbound Rules` tab. +7. Remove any inbound rules. +8. Click the `Outbound Rules` tab. +9. Remove any inbound rules. + +### Recommended: + +IAM groups allow you to edit the "name" field. After remediating default groups rules for all VPCs in all regions, edit this field to add text similar to "DO NOT USE. DO NOT ADD RULES" diff --git a/cis_v120/docs/cis_v120_4_4.md b/cis_v120/docs/cis_v120_4_4.md new file mode 100644 index 00000000..f3eecdea --- /dev/null +++ b/cis_v120/docs/cis_v120_4_4.md @@ -0,0 +1,23 @@ +## Description + +Once a VPC peering connection is established, routing tables must be updated to establish any connections between the peered VPCs. These routes can be as specific as desired - even peering a VPC to only a single host on the other side of the connection. + +Being highly selective in peering routing tables is a very effective way of minimizing the impact of breach as resources outside of these routes are inaccessible to the peered VPC. + +## Remediation + +Remove and add route table entries to ensure that the least number of subnets or hosts as is required to accomplish the purpose for peering are routable. + +### Via CLI + +1. For each `` containing routes non compliant with your routing policy (which grants more than desired "least access"), delete the non compliant route: + +```bash +aws ec2 delete-route --route-table-id --destination-cidr- block +``` + +2. Create a new compliant route: + +```bash +aws ec2 create-route --route-table-id --destination-cidr- block --vpc-peering-connection-id +``` diff --git a/cis_v120/section_1.sp b/cis_v120/section_1.sp new file mode 100644 index 00000000..cd08e6d7 --- /dev/null +++ b/cis_v120/section_1.sp @@ -0,0 +1,346 @@ +locals { + cis_v120_1_common_tags = merge(local.cis_v120_common_tags, { + cis_section_id = "1" + }) +} + +benchmark "cis_v120_1" { + title = "1 Identity and Access Management" + documentation = file("./cis_v120/docs/cis_v120_1.md") + children = [ + control.cis_v120_1_1, + control.cis_v120_1_2, + control.cis_v120_1_3, + control.cis_v120_1_4, + control.cis_v120_1_5, + control.cis_v120_1_6, + control.cis_v120_1_7, + control.cis_v120_1_8, + control.cis_v120_1_9, + control.cis_v120_1_10, + control.cis_v120_1_11, + control.cis_v120_1_12, + control.cis_v120_1_13, + control.cis_v120_1_14, + control.cis_v120_1_15, + control.cis_v120_1_16, + control.cis_v120_1_17, + control.cis_v120_1_18, + control.cis_v120_1_19, + control.cis_v120_1_20, + control.cis_v120_1_21, + control.cis_v120_1_22 + ] + + tags = merge(local.cis_v120_1_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v120_1_1" { + title = "1.1 Avoid the use of the \"root\" account" + description = "The \"root\" account has unrestricted access to all resources in the AWS account. It is highly recommended that the use of this account be avoided." + query = query.manual_control + documentation = file("./cis_v120/docs/cis_v120_1_1.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.1" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_2" { + title = "1.2 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password" + description = "Multi-Factor Authentication (MFA) adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. It is recommended that MFA be enabled for all accounts that have a console password." + query = query.iam_user_console_access_mfa_enabled + documentation = file("./cis_v120/docs/cis_v120_1_2.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.2" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_3" { + title = "1.3 Ensure credentials unused for 90 days or greater are disabled" + description = "AWS IAM users can access AWS resources using different types of credentials, such as passwords or access keys. It is recommended that all credentials that have been unused in 90 or greater days be removed or deactivated." + query = query.iam_user_unused_credentials_90 + documentation = file("./cis_v120/docs/cis_v120_1_3.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.3" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_4" { + title = "1.4 Ensure access keys are rotated every 90 days or less" + description = "Access keys consist of an access key ID and secret access key, which are used to sign programmatic requests that you make to AWS. AWS users need their own access keys to make programmatic calls to AWS from the AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, the AWS SDKs, or direct HTTP calls using the APIs for individual AWS services. It is recommended that all access keys be regularly rotated." + query = query.iam_user_access_key_age_90 + documentation = file("./cis_v120/docs/cis_v120_1_4.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.4" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_5" { + title = "1.5 Ensure IAM password policy requires at least one uppercase letter" + description = "Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one uppercase letter." + query = query.iam_account_password_policy_one_uppercase_letter + documentation = file("./cis_v120/docs/cis_v120_1_5.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.5" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_6" { + title = "1.6 Ensure IAM password policy require at least one lowercase letter" + description = "Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one lowercase letter." + query = query.iam_account_password_policy_one_lowercase_letter + documentation = file("./cis_v120/docs/cis_v120_1_6.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.6" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_7" { + title = "1.7 Ensure IAM password policy require at least one symbol" + description = "Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one symbol." + query = query.iam_account_password_policy_one_symbol + documentation = file("./cis_v120/docs/cis_v120_1_7.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.7" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_8" { + title = "1.8 Ensure IAM password policy require at least one number" + description = "Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are comprised of different character sets. It is recommended that the password policy require at least one number." + query = query.iam_account_password_policy_one_number + documentation = file("./cis_v120/docs/cis_v120_1_8.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.8" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_9" { + title = "1.9 Ensure IAM password policy requires minimum length of 14 or greater" + description = "Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure password are at least a given length. It is recommended that the password policy require a minimum password length 14." + query = query.iam_account_password_policy_min_length_14 + documentation = file("./cis_v120/docs/cis_v120_1_9.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.9" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_10" { + title = "1.10 Ensure IAM password policy prevents password reuse" + description = "IAM password policies can prevent the reuse of a given password by the same user. It is recommended that the password policy prevent the reuse of passwords." + query = query.iam_account_password_policy_reuse_24 + documentation = file("./cis_v120/docs/cis_v120_1_10.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.10" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_11" { + title = "1.11 Ensure IAM password policy expires passwords within 90 days or less" + description = "IAM password policies can require passwords to be rotated or expired after a given number of days. It is recommended that the password policy expire passwords after 90 days or less." + query = query.iam_account_password_policy_expire_90 + documentation = file("./cis_v120/docs/cis_v120_1_11.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.11" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_12" { + title = "1.12 Ensure no root account access key exists" + description = "The root 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 account be removed." + query = query.iam_root_user_no_access_keys + documentation = file("./cis_v120/docs/cis_v120_1_12.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.12" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_13" { + title = "1.13 Ensure MFA is enabled for the \"root\" account" + description = "The root account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device." + query = query.iam_root_user_mfa_enabled + documentation = file("./cis_v120/docs/cis_v120_1_13.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.13" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_14" { + title = "1.14 Ensure hardware MFA is enabled for the \"root\" account" + description = "The root account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. For Level 2, it is recommended that the root account be protected with a hardware MFA." + query = query.iam_root_user_hardware_mfa_enabled + documentation = file("./cis_v120/docs/cis_v120_1_14.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.14" + cis_level = "2" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_15" { + title = "1.15 Ensure security questions are registered in the AWS account" + description = "The AWS support portal allows account owners to establish security questions that can be used to authenticate individuals calling AWS customer service for support. It is recommended that security questions be established." + query = query.manual_control + documentation = file("./cis_v120/docs/cis_v120_1_15.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.15" + cis_level = "1" + cis_type = "not_scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_16" { + title = "1.16 Ensure IAM policies are attached only to groups or roles" + description = "By default, IAM users, groups, and roles have no access to AWS resources. IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended that IAM policies be applied directly to groups and roles but not users." + query = query.iam_user_no_policies + documentation = file("./cis_v120/docs/cis_v120_1_16.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.16" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_17" { + title = "1.17 Maintain current contact details" + description = "Ensure contact email and telephone details for AWS accounts are current and map to more than one individual in your organization. An AWS account supports a number of contact details, and AWS will use these to contact the account owner if activity judged to be in breach of Acceptable Use Policy or indicative of likely security compromise is observed by the AWS Abuse team. Contact details should not be for a single individual, as circumstances may arise where that individual is unavailable." + query = query.manual_control + documentation = file("./cis_v120/docs/cis_v120_1_17.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.17" + cis_level = "1" + cis_type = "not_scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_18" { + title = "1.18 Ensure security contact information is registered" + description = "AWS provides customers with the option of specifying the contact information for account's security team. It is recommended that this information be provided." + query = query.account_alternate_contact_security_registered + documentation = file("./cis_v120/docs/cis_v120_1_18.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.18" + cis_level = "1" + cis_type = "not_scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_19" { + title = "1.19 Ensure IAM instance roles are used for AWS resource access from instances" + description = "AWS access from within AWS instances can be done by either encoding AWS keys into AWS API calls or by assigning the instance to a role which has an appropriate permissions policy for the required access. \"AWS Access\" means accessing the APIs of AWS in order to access AWS resources or manage AWS account resources." + query = query.manual_control + documentation = file("./cis_v120/docs/cis_v120_1_19.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.19" + cis_level = "2" + cis_type = "not_scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_20" { + title = "1.20 Ensure a support role has been created to manage incidents with AWS Support" + description = "AWS provides a support center that can be used for incident notification and response, as well as technical support and customer services. Create an IAM Role to allow authorized users to manage incidents with AWS Support." + query = query.iam_support_role + documentation = file("./cis_v120/docs/cis_v120_1_20.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.20" + cis_level = "1" + cis_type = "scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_21" { + title = "1.21 Do not setup access keys during initial user setup for all IAM users that have a console password" + description = "AWS console defaults the checkbox for creating access keys to enabled. This results in many access keys being generated unnecessarily. In addition to unnecessary credentials, it also generates unnecessary management work in auditing and rotating these keys." + query = query.iam_user_access_keys_and_password_at_setup + documentation = file("./cis_v120/docs/cis_v120_1_21.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.21" + cis_level = "1" + cis_type = "not_scored" + service = "AWS/IAM" + }) +} + +control "cis_v120_1_22" { + title = "1.22 Ensure IAM policies that allow full \"*:*\" administrative privileges are not created" + description = "IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege—that is, granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges." + query = query.iam_policy_all_attached_no_star_star + documentation = file("./cis_v120/docs/cis_v120_1_22.md") + + tags = merge(local.cis_v120_1_common_tags, { + cis_item_id = "1.22" + cis_level = "2" + cis_type = "scored" + service = "AWS/IAM" + }) +} diff --git a/cis_v120/section_2.sp b/cis_v120/section_2.sp new file mode 100644 index 00000000..ee899bd8 --- /dev/null +++ b/cis_v120/section_2.sp @@ -0,0 +1,151 @@ +locals { + cis_v120_2_common_tags = merge(local.cis_v120_common_tags, { + cis_section_id = "2" + }) +} + +benchmark "cis_v120_2" { + title = "2 Logging" + documentation = file("./cis_v120/docs/cis_v120_2.md") + children = [ + control.cis_v120_2_1, + control.cis_v120_2_2, + control.cis_v120_2_3, + control.cis_v120_2_4, + control.cis_v120_2_5, + control.cis_v120_2_6, + control.cis_v120_2_7, + control.cis_v120_2_8, + control.cis_v120_2_9 + ] + + tags = merge(local.cis_v120_2_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v120_2_1" { + title = "2.1 Ensure CloudTrail is enabled in all regions" + description = "AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation)." + query = query.cloudtrail_multi_region_read_write_enabled + documentation = file("./cis_v120/docs/cis_v120_2_1.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.1" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudTrail" + }) +} + +control "cis_v120_2_2" { + title = "2.2 Ensure CloudTrail log file validation is enabled." + description = "CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to S3. These digest files can be used to determine whether a log file was changed, deleted, or unchanged after CloudTrail delivered the log. It is recommended that file validation be enabled on all CloudTrails." + query = query.cloudtrail_trail_validation_enabled + documentation = file("./cis_v120/docs/cis_v120_2_2.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.2" + cis_level = "2" + cis_type = "scored" + service = "AWS/CloudTrail" + }) +} + +control "cis_v120_2_3" { + title = "2.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible" + description = "CloudTrail logs a record of every API call made in your AWS account. These logs file are stored in an S3 bucket. It is recommended that the bucket policy, or access control list (ACL), applied to the S3 bucket that CloudTrail logs to prevents public access to the CloudTrail logs." + query = query.cloudtrail_bucket_not_public + documentation = file("./cis_v120/docs/cis_v120_2_3.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.3" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudTrail" + }) +} + +control "cis_v120_2_4" { + title = "2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs" + description = "AWS CloudTrail is a web service that records AWS API calls made in a given AWS account. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail uses Amazon S3 for log file storage and delivery, so log files are stored durably. In addition to capturing CloudTrail logs within a specified S3 bucket for long term analysis, realtime analysis can be performed by configuring CloudTrail to send logs to CloudWatch Logs. For a trail that is enabled in all regions in an account, CloudTrail sends log files from all those regions to a CloudWatch Logs log group. It is recommended that CloudTrail logs be sent to CloudWatch Logs." + query = query.cloudtrail_trail_integrated_with_logs + documentation = file("./cis_v120/docs/cis_v120_2_4.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.4" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudTrail" + }) +} + +control "cis_v120_2_5" { + title = "2.5 Ensure AWS Config is enabled in all regions" + description = "AWS Config is a web service that performs configuration management of supported AWS resources within your account and delivers log files to you. The recorded information includes the configuration item (AWS resource), relationships between configuration items (AWS resources), any configuration changes between resources. It is recommended to enable AWS Config be enabled in all regions." + query = query.config_enabled_all_regions + documentation = file("./cis_v120/docs/cis_v120_2_5.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.5" + cis_level = "1" + cis_type = "scored" + service = "AWS/Config" + }) +} + +control "cis_v120_2_6" { + title = "2.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket" + description = "S3 Bucket Access Logging generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed. It is recommended that bucket access logging be enabled on the CloudTrail S3 bucket." + query = query.cloudtrail_s3_logging_enabled + documentation = file("./cis_v120/docs/cis_v120_2_6.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.6" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudTrail" + }) +} + +control "cis_v120_2_7" { + title = "2.7 Ensure CloudTrail logs are encrypted at rest using KMS CMKs" + description = "AWS CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use SSE-KMS." + query = query.cloudtrail_trail_logs_encrypted_with_kms_cmk + documentation = file("./cis_v120/docs/cis_v120_2_7.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.7" + cis_level = "2" + cis_type = "scored" + service = "AWS/CloudTrail" + }) +} + +control "cis_v120_2_8" { + title = "2.8 Ensure rotation for customer created CMKs is enabled" + description = "AWS Key Management Service (KMS) allows customers to rotate the backing key which is key material stored within the KMS which is tied to the key ID of the Customer Created customer master key (CMK). It is the backing key that is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all prior backing keys so that decryption of encrypted data can take place transparently. It is recommended that CMK key rotation be enabled." + query = query.kms_cmk_rotation_enabled + documentation = file("./cis_v120/docs/cis_v120_2_8.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.8" + cis_level = "2" + cis_type = "scored" + service = "AWS/KMS" + }) +} + +control "cis_v120_2_9" { + title = "2.9 Ensure VPC flow logging is enabled in all VPCs" + description = "VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet \"Rejects\" for VPCs." + query = query.vpc_flow_logs_enabled + documentation = file("./cis_v120/docs/cis_v120_2_9.md") + + tags = merge(local.cis_v120_2_common_tags, { + cis_item_id = "2.9" + cis_level = "2" + cis_type = "scored" + service = "AWS/VPC" + }) +} diff --git a/cis_v120/section_3.sp b/cis_v120/section_3.sp new file mode 100644 index 00000000..2624462b --- /dev/null +++ b/cis_v120/section_3.sp @@ -0,0 +1,227 @@ +locals { + cis_v120_3_common_tags = merge(local.cis_v120_common_tags, { + cis_section_id = "3" + }) +} + +benchmark "cis_v120_3" { + title = "3 Monitoring" + documentation = file("./cis_v120/docs/cis_v120_3.md") + children = [ + control.cis_v120_3_1, + control.cis_v120_3_2, + control.cis_v120_3_3, + control.cis_v120_3_4, + control.cis_v120_3_5, + control.cis_v120_3_6, + control.cis_v120_3_7, + control.cis_v120_3_8, + control.cis_v120_3_9, + control.cis_v120_3_10, + control.cis_v120_3_11, + control.cis_v120_3_12, + control.cis_v120_3_13, + control.cis_v120_3_14 + ] + + tags = merge(local.cis_v120_3_common_tags, { + type = "Benchmark" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_1" { + title = "3.1 Ensure a log metric filter and alarm exist for unauthorized API calls" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for unauthorized API calls." + query = query.log_metric_filter_unauthorized_api + documentation = file("./cis_v120/docs/cis_v120_3_1.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.1" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_2" { + title = "3.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for console logins that are not protected by multi-factor authentication (MFA)." + query = query.log_metric_filter_console_login_mfa + documentation = file("./cis_v120/docs/cis_v120_3_2.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.2" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_3" { + title = "3.3 Ensure a log metric filter and alarm exist for usage of \"root\" account" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for root login attempts." + query = query.log_metric_filter_root_login + documentation = file("./cis_v120/docs/cis_v120_3_3.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.3" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_4" { + title = "3.4 Ensure a log metric filter and alarm exist for IAM policy changes" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established changes made to Identity and Access Management (IAM) policies." + query = query.log_metric_filter_iam_policy + documentation = file("./cis_v120/docs/cis_v120_3_4.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.4" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_5" { + title = "3.5 Ensure a log metric filter and alarm exist for CloudTrail configuration changes" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for detecting changes to CloudTrail's configurations." + query = query.log_metric_filter_cloudtrail_configuration + documentation = file("./cis_v120/docs/cis_v120_3_5.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.5" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_6" { + title = "3.6 Ensure a log metric filter and alarm exist for AWS Management Console authentication failures" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for failed console authentication attempts." + query = query.log_metric_filter_console_authentication_failure + documentation = file("./cis_v120/docs/cis_v120_3_6.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.6" + cis_level = "2" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_7" { + title = "3.7 Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for customer created CMKs which have changed state to disabled or scheduled deletion." + query = query.log_metric_filter_disable_or_delete_cmk + documentation = file("./cis_v120/docs/cis_v120_3_7.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.7" + cis_level = "2" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_8" { + title = "3.8 Ensure a log metric filter and alarm exist for S3 bucket policy changes" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for changes to S3 bucket policies." + query = query.log_metric_filter_bucket_policy + documentation = file("./cis_v120/docs/cis_v120_3_8.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.8" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_9" { + title = "3.9 Ensure a log metric filter and alarm exist for AWS Config configuration changes" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for detecting changes to CloudTrail's configurations." + query = query.log_metric_filter_config_configuration + documentation = file("./cis_v120/docs/cis_v120_3_9.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.9" + cis_level = "2" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_10" { + title = "3.10 Ensure a log metric filter and alarm exist for security group changes" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Security Groups are a stateful packet filter that controls ingress and egress traffic within a VPC. It is recommended that a metric filter and alarm be established changes to Security Groups." + query = query.log_metric_filter_security_group + documentation = file("./cis_v120/docs/cis_v120_3_10.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.10" + cis_level = "2" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_11" { + title = "3.11 Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. NACLs are used as a stateless packet filter to control ingress and egress traffic for subnets within a VPC. It is recommended that a metric filter and alarm be established for changes made to NACLs." + query = query.log_metric_filter_network_acl + documentation = file("./cis_v120/docs/cis_v120_3_11.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.11" + cis_level = "2" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_12" { + title = "3.12 Ensure a log metric filter and alarm exist for changes to network gateways" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs 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." + query = query.log_metric_filter_network_gateway + documentation = file("./cis_v120/docs/cis_v120_3_12.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.12" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_13" { + title = "3.13 Ensure a log metric filter and alarm exist for route table changes" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs 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." + query = query.log_metric_filter_route_table + documentation = file("./cis_v120/docs/cis_v120_3_13.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.13" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} + +control "cis_v120_3_14" { + title = "3.14 Ensure a log metric filter and alarm exist for VPC changes" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is 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." + query = query.log_metric_filter_vpc + documentation = file("./cis_v120/docs/cis_v120_3_14.md") + + tags = merge(local.cis_v120_3_common_tags, { + cis_item_id = "3.14" + cis_level = "1" + cis_type = "scored" + service = "AWS/CloudWatch" + }) +} diff --git a/cis_v120/section_4.sp b/cis_v120/section_4.sp new file mode 100644 index 00000000..b916c670 --- /dev/null +++ b/cis_v120/section_4.sp @@ -0,0 +1,77 @@ +locals { + cis_v120_4_common_tags = merge(local.cis_v120_common_tags, { + cis_section_id = "4" + }) +} + +benchmark "cis_v120_4" { + title = "4 Networking" + documentation = file("./cis_v120/docs/cis_v120_4.md") + children = [ + control.cis_v120_4_1, + control.cis_v120_4_2, + control.cis_v120_4_3, + control.cis_v120_4_4 + ] + + tags = merge(local.cis_v120_4_common_tags, { + service = "AWS/VPC" + type = "Benchmark" + }) +} + +control "cis_v120_4_1" { + title = "4.1 Ensure no security groups allow ingress from 0.0.0.0/0 to port 22" + description = "Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to port 22." + query = query.vpc_security_group_restrict_ingress_ssh_all + documentation = file("./cis_v120/docs/cis_v120_4_1.md") + + tags = merge(local.cis_v120_4_common_tags, { + cis_item_id = "4.1" + cis_level = "1" + cis_type = "scored" + service = "AWS/VPC" + }) +} + +control "cis_v120_4_2" { + title = "4.2 Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389" + description = "Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to port 3389." + query = query.vpc_security_group_restrict_ingress_rdp_all + documentation = file("./cis_v120/docs/cis_v120_4_2.md") + + tags = merge(local.cis_v120_4_common_tags, { + cis_item_id = "4.2" + cis_level = "1" + cis_type = "scored" + service = "AWS/VPC" + }) +} + +control "cis_v120_4_3" { + title = "4.3 Ensure the default security group of every VPC restricts all traffic" + description = "A VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to this default security group. Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that the default security group restrict all traffic. The default VPC in every region should have its default security group updated to comply. Any newly created VPCs will automatically contain a default security group that will need remediation to comply with this recommendation." + query = query.vpc_default_security_group_restricts_all_traffic + documentation = file("./cis_v120/docs/cis_v120_4_3.md") + + tags = merge(local.cis_v120_4_common_tags, { + cis_item_id = "4.3" + cis_level = "2" + cis_type = "scored" + service = "AWS/VPC" + }) +} + +control "cis_v120_4_4" { + title = "4.4 Ensure routing tables for VPC peering are \"least access\"" + description = "Once a VPC peering connection is established, routing tables must be updated to establish any connections between the peered VPCs. These routes can be as specific as desired - even peering a VPC to only a single host on the other side of the connection." + query = query.manual_control + documentation = file("./cis_v120/docs/cis_v120_4_4.md") + + tags = merge(local.cis_v120_4_common_tags, { + cis_item_id = "4.4" + cis_level = "2" + cis_type = "scored" + service = "AWS/VPC" + }) +} diff --git a/query/iam/iam_user_no_policies.sql b/query/iam/iam_user_no_policies.sql new file mode 100644 index 00000000..39383091 --- /dev/null +++ b/query/iam/iam_user_no_policies.sql @@ -0,0 +1,12 @@ +select + -- Required Columns + arn as resource, + case + when attached_policy_arns is null then 'ok' + else 'alarm' + end status, + name || ' has ' || coalesce(jsonb_array_length(attached_policy_arns),0) || ' attached policies.' as reason, + -- Additional Dimensions + account_id +from + aws_iam_user; diff --git a/query/vpc/vpc_security_group_restrict_ingress_rdp_all.sql b/query/vpc/vpc_security_group_restrict_ingress_rdp_all.sql new file mode 100644 index 00000000..c0492f54 --- /dev/null +++ b/query/vpc/vpc_security_group_restrict_ingress_rdp_all.sql @@ -0,0 +1,38 @@ +with ingress_rdp_rules as ( + select + group_id, + count(*) as num_rdp_rules + from + aws_vpc_security_group_rule + where + type = 'ingress' + and cidr_ipv4 = '0.0.0.0/0' + and ( + ( ip_protocol = '-1' + and from_port is null + ) + or ( + from_port >= 3389 + and to_port <= 3389 + ) + ) + group by + group_id +) +select + -- Required Columns + arn as resource, + case + when ingress_rdp_rules.group_id is null then 'ok' + else 'alarm' + end as status, + case + when ingress_rdp_rules.group_id is null then sg.group_id || ' ingress restricted for RDP from 0.0.0.0/0.' + else sg.group_id || ' contains ' || ingress_rdp_rules.num_rdp_rules || ' ingress rule(s) allowing RDP from 0.0.0.0/0.' + end as reason, + -- Additional Dimensions + sg.region, + sg.account_id +from + aws_vpc_security_group as sg + left join ingress_rdp_rules on ingress_rdp_rules.group_id = sg.group_id;