From b483819ab9d57223ad2fe05eaef59c174857d56b Mon Sep 17 00:00:00 2001 From: Venu <40973863+vkumbha@users.noreply.github.com> Date: Wed, 31 Aug 2022 04:45:46 +0530 Subject: [PATCH] Add AWS > CIS v1.5.0 benchmark (#496) --- README.md | 13 +- cis_v150/cis.sp | 24 ++ cis_v150/docs/cis_overview.md | 34 ++ cis_v150/docs/cis_v150_1.md | 3 + cis_v150/docs/cis_v150_1_1.md | 21 ++ cis_v150/docs/cis_v150_1_10.md | 24 ++ cis_v150/docs/cis_v150_1_11.md | 38 ++ cis_v150/docs/cis_v150_1_12.md | 26 ++ cis_v150/docs/cis_v150_1_13.md | 27 ++ cis_v150/docs/cis_v150_1_14.md | 35 ++ cis_v150/docs/cis_v150_1_15.md | 40 +++ cis_v150/docs/cis_v150_1_16.md | 45 +++ cis_v150/docs/cis_v150_1_17.md | 53 +++ cis_v150/docs/cis_v150_1_18.md | 36 ++ cis_v150/docs/cis_v150_1_19.md | 21 ++ cis_v150/docs/cis_v150_1_2.md | 17 + cis_v150/docs/cis_v150_1_20.md | 30 ++ cis_v150/docs/cis_v150_1_21.md | 36 ++ cis_v150/docs/cis_v150_1_3.md | 15 + cis_v150/docs/cis_v150_1_4.md | 19 + cis_v150/docs/cis_v150_1_5.md | 26 ++ cis_v150/docs/cis_v150_1_6.md | 27 ++ cis_v150/docs/cis_v150_1_7.md | 14 + cis_v150/docs/cis_v150_1_8.md | 24 ++ cis_v150/docs/cis_v150_1_9.md | 25 ++ cis_v150/docs/cis_v150_2.md | 3 + cis_v150/docs/cis_v150_2_1.md | 3 + cis_v150/docs/cis_v150_2_1_1.md | 30 ++ cis_v150/docs/cis_v150_2_1_2.md | 75 ++++ cis_v150/docs/cis_v150_2_1_3.md | 20 ++ cis_v150/docs/cis_v150_2_1_4.md | 14 + cis_v150/docs/cis_v150_2_1_5.md | 55 +++ cis_v150/docs/cis_v150_2_2.md | 3 + cis_v150/docs/cis_v150_2_2_1.md | 27 ++ cis_v150/docs/cis_v150_2_3.md | 3 + cis_v150/docs/cis_v150_2_3_1.md | 70 ++++ cis_v150/docs/cis_v150_2_3_2.md | 41 +++ cis_v150/docs/cis_v150_2_3_3.md | 44 +++ cis_v150/docs/cis_v150_2_4.md | 3 + cis_v150/docs/cis_v150_2_4_1.md | 66 ++++ cis_v150/docs/cis_v150_3.md | 3 + cis_v150/docs/cis_v150_3_1.md | 40 +++ cis_v150/docs/cis_v150_3_10.md | 35 ++ cis_v150/docs/cis_v150_3_11.md | 33 ++ cis_v150/docs/cis_v150_3_2.md | 32 ++ cis_v150/docs/cis_v150_3_3.md | 34 ++ cis_v150/docs/cis_v150_3_4.md | 36 ++ cis_v150/docs/cis_v150_3_5.md | 37 ++ cis_v150/docs/cis_v150_3_6.md | 19 + cis_v150/docs/cis_v150_3_7.md | 29 ++ cis_v150/docs/cis_v150_3_8.md | 33 ++ cis_v150/docs/cis_v150_3_9.md | 23 ++ cis_v150/docs/cis_v150_4.md | 3 + cis_v150/docs/cis_v150_4_1.md | 82 +++++ cis_v150/docs/cis_v150_4_10.md | 82 +++++ cis_v150/docs/cis_v150_4_11.md | 83 +++++ cis_v150/docs/cis_v150_4_12.md | 82 +++++ cis_v150/docs/cis_v150_4_13.md | 82 +++++ cis_v150/docs/cis_v150_4_14.md | 82 +++++ cis_v150/docs/cis_v150_4_15.md | 82 +++++ cis_v150/docs/cis_v150_4_16.md | 30 ++ cis_v150/docs/cis_v150_4_2.md | 85 +++++ cis_v150/docs/cis_v150_4_3.md | 84 +++++ cis_v150/docs/cis_v150_4_4.md | 85 +++++ cis_v150/docs/cis_v150_4_5.md | 82 +++++ cis_v150/docs/cis_v150_4_6.md | 82 +++++ cis_v150/docs/cis_v150_4_7.md | 82 +++++ cis_v150/docs/cis_v150_4_8.md | 82 +++++ cis_v150/docs/cis_v150_4_9.md | 83 +++++ cis_v150/docs/cis_v150_5.md | 3 + cis_v150/docs/cis_v150_5_1.md | 21 ++ cis_v150/docs/cis_v150_5_2.md | 20 ++ cis_v150/docs/cis_v150_5_3.md | 19 + cis_v150/docs/cis_v150_5_4.md | 26 ++ cis_v150/docs/cis_v150_5_5.md | 23 ++ cis_v150/section_1.sp | 331 ++++++++++++++++++ cis_v150/section_2.sp | 233 ++++++++++++ cis_v150/section_3.sp | 181 ++++++++++ cis_v150/section_4.sp | 257 ++++++++++++++ cis_v150/section_5.sp | 92 +++++ docs/index.md | 4 +- query/iam/iam_user_one_active_key.sql | 2 +- ...urity_group_remote_administration_ipv4.sql | 44 +++ ...urity_group_remote_administration_ipv6.sql | 44 +++ 84 files changed, 4048 insertions(+), 9 deletions(-) create mode 100644 cis_v150/cis.sp create mode 100644 cis_v150/docs/cis_overview.md create mode 100644 cis_v150/docs/cis_v150_1.md create mode 100644 cis_v150/docs/cis_v150_1_1.md create mode 100644 cis_v150/docs/cis_v150_1_10.md create mode 100644 cis_v150/docs/cis_v150_1_11.md create mode 100644 cis_v150/docs/cis_v150_1_12.md create mode 100644 cis_v150/docs/cis_v150_1_13.md create mode 100644 cis_v150/docs/cis_v150_1_14.md create mode 100644 cis_v150/docs/cis_v150_1_15.md create mode 100644 cis_v150/docs/cis_v150_1_16.md create mode 100644 cis_v150/docs/cis_v150_1_17.md create mode 100644 cis_v150/docs/cis_v150_1_18.md create mode 100644 cis_v150/docs/cis_v150_1_19.md create mode 100644 cis_v150/docs/cis_v150_1_2.md create mode 100644 cis_v150/docs/cis_v150_1_20.md create mode 100644 cis_v150/docs/cis_v150_1_21.md create mode 100644 cis_v150/docs/cis_v150_1_3.md create mode 100644 cis_v150/docs/cis_v150_1_4.md create mode 100644 cis_v150/docs/cis_v150_1_5.md create mode 100644 cis_v150/docs/cis_v150_1_6.md create mode 100644 cis_v150/docs/cis_v150_1_7.md create mode 100644 cis_v150/docs/cis_v150_1_8.md create mode 100644 cis_v150/docs/cis_v150_1_9.md create mode 100644 cis_v150/docs/cis_v150_2.md create mode 100644 cis_v150/docs/cis_v150_2_1.md create mode 100644 cis_v150/docs/cis_v150_2_1_1.md create mode 100644 cis_v150/docs/cis_v150_2_1_2.md create mode 100644 cis_v150/docs/cis_v150_2_1_3.md create mode 100644 cis_v150/docs/cis_v150_2_1_4.md create mode 100644 cis_v150/docs/cis_v150_2_1_5.md create mode 100644 cis_v150/docs/cis_v150_2_2.md create mode 100644 cis_v150/docs/cis_v150_2_2_1.md create mode 100644 cis_v150/docs/cis_v150_2_3.md create mode 100644 cis_v150/docs/cis_v150_2_3_1.md create mode 100644 cis_v150/docs/cis_v150_2_3_2.md create mode 100644 cis_v150/docs/cis_v150_2_3_3.md create mode 100644 cis_v150/docs/cis_v150_2_4.md create mode 100644 cis_v150/docs/cis_v150_2_4_1.md create mode 100644 cis_v150/docs/cis_v150_3.md create mode 100644 cis_v150/docs/cis_v150_3_1.md create mode 100644 cis_v150/docs/cis_v150_3_10.md create mode 100644 cis_v150/docs/cis_v150_3_11.md create mode 100644 cis_v150/docs/cis_v150_3_2.md create mode 100644 cis_v150/docs/cis_v150_3_3.md create mode 100644 cis_v150/docs/cis_v150_3_4.md create mode 100644 cis_v150/docs/cis_v150_3_5.md create mode 100644 cis_v150/docs/cis_v150_3_6.md create mode 100644 cis_v150/docs/cis_v150_3_7.md create mode 100644 cis_v150/docs/cis_v150_3_8.md create mode 100644 cis_v150/docs/cis_v150_3_9.md create mode 100644 cis_v150/docs/cis_v150_4.md create mode 100644 cis_v150/docs/cis_v150_4_1.md create mode 100644 cis_v150/docs/cis_v150_4_10.md create mode 100644 cis_v150/docs/cis_v150_4_11.md create mode 100644 cis_v150/docs/cis_v150_4_12.md create mode 100644 cis_v150/docs/cis_v150_4_13.md create mode 100644 cis_v150/docs/cis_v150_4_14.md create mode 100644 cis_v150/docs/cis_v150_4_15.md create mode 100644 cis_v150/docs/cis_v150_4_16.md create mode 100644 cis_v150/docs/cis_v150_4_2.md create mode 100644 cis_v150/docs/cis_v150_4_3.md create mode 100644 cis_v150/docs/cis_v150_4_4.md create mode 100644 cis_v150/docs/cis_v150_4_5.md create mode 100644 cis_v150/docs/cis_v150_4_6.md create mode 100644 cis_v150/docs/cis_v150_4_7.md create mode 100644 cis_v150/docs/cis_v150_4_8.md create mode 100644 cis_v150/docs/cis_v150_4_9.md create mode 100644 cis_v150/docs/cis_v150_5.md create mode 100644 cis_v150/docs/cis_v150_5_1.md create mode 100644 cis_v150/docs/cis_v150_5_2.md create mode 100644 cis_v150/docs/cis_v150_5_3.md create mode 100644 cis_v150/docs/cis_v150_5_4.md create mode 100644 cis_v150/docs/cis_v150_5_5.md create mode 100644 cis_v150/section_1.sp create mode 100644 cis_v150/section_2.sp create mode 100644 cis_v150/section_3.sp create mode 100644 cis_v150/section_4.sp create mode 100644 cis_v150/section_5.sp create mode 100644 query/vpc/vpc_security_group_remote_administration_ipv4.sql create mode 100644 query/vpc/vpc_security_group_remote_administration_ipv6.sql diff --git a/README.md b/README.md index 9fb31b62..95dec690 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # AWS Compliance Mod for Steampipe -475+ checks covering industry defined security best practices across all AWS regions. Includes full support for multiple best practice benchmarks including PCI DSS, AWS Foundational Security, CISA Cyber Essentials, FedRAMP, FFIEC, GxP 21 CFR Part 11, GxP EU Annex 11, HIPAA, NIST 800-53, NIST CSF, Reserve Bank of India, Audit Manager Control Tower **and the latest (v1.4.0) CIS benchmarks**. +475+ checks covering industry defined security best practices across all AWS regions. Includes full support for multiple best practice benchmarks including PCI DSS, AWS Foundational Security, CISA Cyber Essentials, FedRAMP, FFIEC, GxP 21 CFR Part 11, GxP EU Annex 11, HIPAA, NIST 800-53, NIST CSF, Reserve Bank of India, Audit Manager Control Tower **and the latest (v1.5.0) CIS benchmarks**. Run checks in a dashboard: ![image](https://raw.githubusercontent.com/turbot/steampipe-mod-aws-compliance/main/docs/aws_cis_v140_dashboard.png) @@ -11,8 +11,9 @@ Or in a terminal: Includes support for: * [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! * [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) ๐Ÿš€ New! +* [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) * [FedRAMP Moderate Revision 4](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.fedramp_moderate_rev_4) * [Federal Financial Institutions Examination Council (FFIEC)](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.ffiec) @@ -22,9 +23,9 @@ Includes support for: * [HIPAA](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.hipaa) * [NIST 800-53 Revision 4](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.nist_800_53_rev_4) * [NIST 800-53 Revision 5](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.nist_800_53_rev_5) -* [NIST 800-171 Revision 2](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.nist_800_171_rev_2) ๐Ÿš€ New! +* [NIST 800-171 Revision 2](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.nist_800_171_rev_2) * [NIST Cybersecurity Framework (CSF)](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.nist_csf) -* [Other Compliance Checks](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.other) ๐Ÿš€ New! +* [Other Compliance Checks](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.other) * [PCI DSS v3.2.1](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.pci_v321) * [AWS Foundational Security Best Practices](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.foundational_security) * [Reserve Bank of India (RBI) Cyber Security Framework](https://hub.steampipe.io/mods/turbot/aws_compliance/controls/benchmark.rbi_cyber_security) @@ -84,13 +85,13 @@ steampipe check all Run a single benchmark: ```sh -steampipe check benchmark.cis_v140 +steampipe check benchmark.cis_v150 ``` Run a specific control: ```sh -steampipe check control.cis_v140_2_1_1 +steampipe check control.cis_v150_2_1_1 ``` Different output formats are also available, for more information please see diff --git a/cis_v150/cis.sp b/cis_v150/cis.sp new file mode 100644 index 00000000..cdd0c8ac --- /dev/null +++ b/cis_v150/cis.sp @@ -0,0 +1,24 @@ +locals { + cis_v150_common_tags = merge(local.aws_compliance_common_tags, { + cis = "true" + cis_version = "v1.5.0" + }) +} + + +benchmark "cis_v150" { + title = "CIS v1.5.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_v150/docs/cis_overview.md") + children = [ + benchmark.cis_v150_1, + benchmark.cis_v150_2, + benchmark.cis_v150_3, + benchmark.cis_v150_4, + benchmark.cis_v150_5 + ] + + tags = merge(local.cis_v150_common_tags, { + type = "Benchmark" + }) +} diff --git a/cis_v150/docs/cis_overview.md b/cis_v150/docs/cis_overview.md new file mode 100644 index 00000000..6682b7d4 --- /dev/null +++ b/cis_v150/docs/cis_overview.md @@ -0,0 +1,34 @@ +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) +- IAM Access Analyzer +- AWS Config +- AWS CloudTrail +- AWS CloudWatch +- AWS Simple Notification Service (SNS) +- AWS Simple Storage Service (S3) +- Elastic Compute Cloud (EC2) +- Elastic File System (EFS) +- Relational Database Service (RDS) +- AWS VPC (Default) + +## Profiles + +### Level 1 + +Items in this profile intend to: +- be practical and prudent; +- provide security focused best practice hardening of a technology; and +- limit impact to the utility of the technology beyond acceptable means. + +### Level 2 (extends Level 1) + +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 more critical than manageability and usability +- acts as defense in depth measure +- may impact the utility or performance of the technology +- may include additional licensing, cost, or addition of third party software. diff --git a/cis_v150/docs/cis_v150_1.md b/cis_v150/docs/cis_v150_1.md new file mode 100644 index 00000000..47ec3e90 --- /dev/null +++ b/cis_v150/docs/cis_v150_1.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring identity and access management related options. diff --git a/cis_v150/docs/cis_v150_1_1.md b/cis_v150/docs/cis_v150_1_1.md new file mode 100644 index 00000000..5c9e6a3b --- /dev/null +++ b/cis_v150/docs/cis_v150_1_1.md @@ -0,0 +1,21 @@ +## Description + +Ensure your *Contact Information* and *Alternate Contacts* are correct in the AWS account settings page of your AWS account. + +In addition to the primary contact information, you may enter the following contacts: + +- **Billing**: When your monthly invoice is available, or your payment method needs to be updated. If your Receive PDF Invoice By Email is turned on in your Billing preferences, your alternate billing contact will receive the PDF invoices as well. +- **Operations**: When your service is, or will be, temporarily unavailable in one of more Regions. Any notification related to operations. +- **Security**: When you have notifications from the AWS Abuse team for potentially fraudulent activity on your AWS account. Any notification related to security. + +As a best practice, avoid using contact information for individuals, and instead use group email addresses and shared company phone numbers. + +AWS uses the contact information to inform you of important service events, billing issues, and security issues. Keeping your contact information up to date ensure timely delivery of important information to the relevant stakeholders. Incorrect contact information may result in communications delays that could impact your ability to operate. + +## Remediation + +There is no API available for setting contact information - you must log in to the AWS console to verify and set your contact information. + +1. Sign into the AWS console, and navigate to [Account Settings](https://console.aws.amazon.com/billing/home?#/account). +2. Verify that the information in the **Contact Information** section is correct and complete. If changes are required, click **Edit**, make your changes, and then click **Update**. +3. Verify that the information in the **Alternate Contacts** section is correct and complete. If changes are required, click **Edit**, make your changes, and then click **Update**. diff --git a/cis_v150/docs/cis_v150_1_10.md b/cis_v150/docs/cis_v150_1_10.md new file mode 100644 index 00000000..24654f62 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_10.md @@ -0,0 +1,24 @@ +## Description + +Multi-factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS console, they will be prompted for their username and password as well as for an authentication code from their virtual or physical MFA device. It is recommended that MFA to be enabled for all users that have a console password. + +Enabling MFA provides increased security for console access as it requires the authenticating principal to possess a device that creates a time-sensitive key and have knowledge of a credential. + +## Remediation + +### From Console + +Perform the following action to enabled virtual MFA for the intended user: + +1. Sign into the AWS console, and navigate to [IAM Console](https://console.aws.amazon.com/iam/home#/). +2. In the left navigation pane, choose Users. +3. In the user name list, choose the **name** of the intended user. +4. Choose the **Security credentials** tab, and then choose **Manage** for `Assigned MFA Device`. +5. In the Manage MFA device wizard, choose **virtual MFA device** and click on **continue**. +6. IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. +7. 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). +8. 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. +9. Once you configure, the virtual MFA device starts generating MFA codes. +10. Type two consecutive MFA codes, MFA code 1 and MFA code 2 fields. Then click **Assign MFA**. Now the virtual MFA is enabled for the AWS account. diff --git a/cis_v150/docs/cis_v150_1_11.md b/cis_v150/docs/cis_v150_1_11.md new file mode 100644 index 00000000..0dad2445 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_11.md @@ -0,0 +1,38 @@ +## Description + +AWS console defaults to no check boxes selected when creating a new IAM user. When creating the IAM user access type you have to determine what type of access they require. + +**Programmatic access**:The IAM user might need to make API calls, use the AWS CLI, or use the tools for windows powershell. In that case, create an access key (access key ID and a secret access key) for that user. +**AWS Management Console access**: If the user needs to access the AWS Management Console, create a password for the user. + +After user profile is created, user can create access keys for programmatic access which will provide an indication that it is needed for their work. User can also put a support ticket to have access keys created for them. + +## Remediation + +### From Console: + +Perform the following action to check if an access key is created during user creation: + +1. Sign into the AWS console and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, choose Users. +3. Click on the **User name** where column `Password age` and `Access key age` is not set to **None**. +4. Click on **Security credentials** tab. +5. Compare the user `Creation time` to the Access Key `Created` date and time. +6. For any that match, the key was created during initial user setup. + +**Note**: Keys that were created at the same time as the user profile and do not have a last used date should be deleted. + +Perform the following action to delete access keys: + +1. Sign into the AWS console as an **Administrator** and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, choose Users. +3. Click on the **User name** for which access key is to be deleted. +4. Click on **Security credentials** tab. +5. Click on the **Make inactive** to `deactivate` the keys that were created at the same time as the user profile but have not been used. +6. Now click X (delete) for the `Inactive` keys. + +### From Command Line: + +```bash +aws iam delete-access-key --access-key-id --user-name +``` diff --git a/cis_v150/docs/cis_v150_1_12.md b/cis_v150/docs/cis_v150_1_12.md new file mode 100644 index 00000000..b24cc62b --- /dev/null +++ b/cis_v150/docs/cis_v150_1_12.md @@ -0,0 +1,26 @@ +## Description + +AWS IAM users can access AWS resources using different types of credentials, such as passwords or access keys. It is recommended that all credentials that have been unused in 45 or greater days to be deactivated or removed. + +Disabling or removing unnecessary credentials will reduce the window of opportunity for credentials associated with a compromised or abandoned users to be used. + +## Remediation + +### From Console: + +Perform the following action to disable user console password: + +1. Sign into the AWS console and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, choose Users. +3. Select the **User name** whose `Console last sign-in` is greater than 45 days. +4. Click on **Security credentials** tab. +5. In section `Sign-in credentials`, `Console password` click **Manage**. +6. Select `Disable`, click **Apply** + +Perform the following action to deactivate access keys: + +1. Sign into the AWS console as an **Administrator** and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, choose Users. +3. Click on the **User name** for which access key is over 45 days old. +4. Click on **Security credentials** tab. +5. Click on the **Make inactive** to `deactivate` the key that is over 45 days old and that have not been used. diff --git a/cis_v150/docs/cis_v150_1_13.md b/cis_v150/docs/cis_v150_1_13.md new file mode 100644 index 00000000..e096deaf --- /dev/null +++ b/cis_v150/docs/cis_v150_1_13.md @@ -0,0 +1,27 @@ +## Description + +Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK). + +One of the best ways to protect your account is to not allow users to have multiple access keys as this is being used for programmatic requests. + +## Remediation + +### From Console: + +Perform the following action to deactivate access keys: + +1. Sign into the AWS console as an **Administrator** and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, choose Users. +3. Click on the **User name** for which more than one active access key exists. +4. Click on **Security credentials** tab. +5. Click on the **Make inactive** to `deactivate` the non-operational key. + +**Note**: Test your application to make sure that the active access key is working. + +### From Command Line: + +Run the `update-access-key` command below using the IAM user name and the non-operational access key IDs to deactivate the unnecessary key. + +```bash +aws iam update-access-key --access-key-id --status Inactive - -user-name +``` diff --git a/cis_v150/docs/cis_v150_1_14.md b/cis_v150/docs/cis_v150_1_14.md new file mode 100644 index 00000000..3ddc4c99 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_14.md @@ -0,0 +1,35 @@ +## 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 to be rotated within 90 days. + +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 + +### From Console: + +Perform the following action to deactivate access keys: + +1. Sign into the AWS console as an **Administrator** and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, choose Users. +3. Click on the **User name** for which access key exists that have not been rotated in 90 days. +4. Click on **Security credentials** tab. +5. Click on the **Make inactive** to `deactivate` the key that have not been rotated in 90 days. +6. Click **Create access key** and update programmatic call with new key pair. + +**Note**: Test your application to make sure that the new key pair is working. + +### From Command Line: + +While the first access key is still active, create a second access key, which is active by default. Run the following command: + +```bash +aws iam create-access-key +``` + +At this point, the user has two active access keys. + - Update all applications and tools to use the new access key pair. + - Change the state of the first access key to `Inactive` using below command: + ```bash + aws iam update-access-key + ``` diff --git a/cis_v150/docs/cis_v150_1_15.md b/cis_v150/docs/cis_v150_1_15.md new file mode 100644 index 00000000..4413d6ba --- /dev/null +++ b/cis_v150/docs/cis_v150_1_15.md @@ -0,0 +1,40 @@ +## Description + +IAM users are granted access to services, functions, and data through IAM policies. There are multiple ways to define policies for an user, such as: + - Add the user to an IAM group that has an attached policy. + - Attach an inline policy directly to an user. + - Attach a managed policy directly to an user. + +Only the first implementation is recommended. + +Assigning IAM policy only through groups simplifies permissions management to a single, flexible layer consistent with organizational functional roles. By simplifying permissions management, the likelihood of excessive permissions is reduced. + +## Remediation + +### From Console + +Perform the following to create an IAM group and assign a list of policies to it: + +1. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, click **User groups** and then click **Create group**. +3. In the `User group name` box, type the name of the group. +4. In the list of policies, select the `check box` for each policy that you want to apply to all members of the group (You can attach up to 10 policies to this user group). +5. Click **Create group**. Group is created with the list of permissions. + +Perform the following to add a user to a given group: + +1. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, click **User groups**. +3. Select the `Group name` to add an user to. +4. Click `Add users` to group. +5. Select the users to be added to the group. +6. Click **Add users**. Users are added to the group. + +Perform the following to remove a direct association between an user and the policy: + +1. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, click on **Users**. +3. For each user: + - Select the user, it will take you to `Permissions` tab. + - Expand Permissions policies. + - Click `X` for each policy and then click **Remove** (depending on policy type). diff --git a/cis_v150/docs/cis_v150_1_16.md b/cis_v150/docs/cis_v150_1_16.md new file mode 100644 index 00000000..94984ff8 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_16.md @@ -0,0 +1,45 @@ +## Description + +IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security practice to grant least privilege that is, granting only the permissions required to perform a task. Determine what users need to do what and then accordingly create policies for them 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 + +### From Console: + +Perform the following action to detach the policy that has full administrative privileges: + +1. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, click **Policies** and then search for the policy name having administrative privileges. +3. Select the policy that needs to be detached. Go to **Policy usage** tab. +4. Select all `Users`, `Groups`, `Roles` that have this policy attached. +5. Click **Detach**. It will ask for re-confirmation. +6. Click **Detach** again. + +Repeat the above steps for all the policies having administrative privileges. + +### From Command Line: + +Perform the following action 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_v150/docs/cis_v150_1_17.md b/cis_v150/docs/cis_v150_1_17.md new file mode 100644 index 00000000..e5c477f5 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_17.md @@ -0,0 +1,53 @@ +## 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. + +All AWS Support plans include an unlimited number of account and billing support cases, with no long-term contracts. Support billing calculations are performed on a per-account basis for all plans. Enterprise Support plan customers have the option to include multiple enabled accounts in an aggregated monthly billing calculation. Monthly charges for the Business and Enterprise support plans are based on each month's AWS usage charges, subject to a monthly minimum, billed in advance. + +## Remediation + +### From Console + +Perform the following action to attach 'AWSSupportAccess' managed policy to the created IAM role : + +1. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, click **Roles** and then choose **Create Role**. +3. For Role type, choose the Another AWS account. +4. For Account ID, enter the AWS account ID of the AWS account to which you want to grant access to your resources. +5. Choose **Next: Permissions**. +6. Search for the managed policy `AWSSupportAccess`. +7. Select the check box for the `AWSSupportAccess` managed policy. +8. Choose **Next: Tags**. +9. Choose **Next: Review**. +10. For `Role name`, enter a name for your role. Then click **Create role**. + +You can attach the above role to any user you want that is needed. + +### From Command Line + +1. Create a IAM policy 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. + ```json + { + "Version":"2012-10-17", + "Statement":[ + { + "Effect":"Allow", + "Principal":{ + "AWS":"" + }, + "Action":"sts:AssumeRole" + } + ] + } + ``` +2. Create the IAM role using the above trust policy. +```bash +aws iam create-role --role-name --assume-role-policy- document file:///tmp/TrustPolicy.json +``` +3. Attach 'AWSSupportAccess' managed policy to the created IAM role. +```bash +aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AWSSupportAccess --role-name +``` diff --git a/cis_v150/docs/cis_v150_1_18.md b/cis_v150/docs/cis_v150_1_18.md new file mode 100644 index 00000000..e2b72af1 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_18.md @@ -0,0 +1,36 @@ +## Description + +AWS access from 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 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 + +### From Console + +Perform the following action to check whether an Instance is associated with a role: + +1. Sign into the AWS console as a user(with appropriate permissions to view identity access management account settings). +2. Open the EC2 Dashboard and choose **Instances**. +3. Click the EC2 instance that performs AWS actions, in the lower pane details you can find **IAM Role**. +4. If the IAM Role is blank, the instance is not assigned to any role. +5. If the Role is filled in, it does not mean the instance might not also have credentials encoded on it for some activities. +6. Audit all scripts and environment variables to ensure that none of them contain AWS credentials. +7. Also examine all source code and configuration files of the application to verify if there is any credentials stored. + +**Note**: IAM roles can only be associated at the launch of an instance. To add a role to an instance, you must create a new instance. + +Perform the following action to create and attach a role to an Instance: + +1. In AWS IAM create a new role. Attach the right permissions policy as needed. +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 in **Configure Instance Details** page. +3. Shutdown both the existing and the new instances. +4. Detach disks from both the 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 with right level of permissions. + +**Note**: +- When 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. +- When your environment has dependencies on a dynamically assigned **PUBLIC IP** address, 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_v150/docs/cis_v150_1_19.md b/cis_v150/docs/cis_v150_1_19.md new file mode 100644 index 00000000..39039b37 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_19.md @@ -0,0 +1,21 @@ +## Description + +SSL/TLS server certificate is required to enable HTTPS connections to your website or application in AWS. You can use ACM or IAM to store and deploy server certificates. IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage. IAM supports deploying server certificates in all regions, but you must obtain your certificate from an external provider for use with AWS. + +You cannot upload an ACM certificate to IAM. Additionally, you cannot manage your certificates from the IAM Console. Use IAM as a certificate manager only when you need HTTPS connections in a region that is not supported by ACM. + +Removing expired SSL/TLS certificates eliminates the risk that an invalid certificate will be deployed accidentally to a resource such as AWS Elastic Load Balancer (ELB), which can damage the credibility of the application/website behind the ELB. As a best practice, it is recommended to delete expired certificates. + +Also have to update configurations at respective services to ensure there is no interruption in application/website access. + +## Remediation + +### From Command Line + +Run the following command to delete the expired certificate: +```bash +aws iam delete-server-certificate --server-certificate-name +``` +When the preceding command is successful, it does not return any output. + +**Note**: By default, expired certificates never get deleted. diff --git a/cis_v150/docs/cis_v150_1_2.md b/cis_v150/docs/cis_v150_1_2.md new file mode 100644 index 00000000..eb20a52c --- /dev/null +++ b/cis_v150/docs/cis_v150_1_2.md @@ -0,0 +1,17 @@ +## Description + +Ensure your *Alternate Contacts* for security are correct in the AWS account settings page of your AWS account. + +In addition to the primary contact information, you must enter the security contacts: +- **Security**: When you have notifications from the AWS Abuse team for potentially fraudulent activity on your AWS account. Any notification related to security. + +As a best practice, avoid using contact information for individuals, and instead use group email addresses and shared company phone numbers. + +AWS uses the security contact information to inform you of critical service events such as security issues. Keeping your security contact information up to date ensure timely delivery of critical information to the relevant stakeholders. Incorrect security contact information may result in communications delays that could impact your organization security. + +## Remediation + +There is no API available for setting security contact information - you must log in to the AWS console to verify and set your security contact information. + +1. Sign into the AWS console, and navigate to the [Account Settings](https://console.aws.amazon.com/billing/home?#/account). +2. Verify that the information in the **Alternate Contacts** *Security* section is correct and complete. If changes are required, click **Edit**, make your changes and then click **Update**. diff --git a/cis_v150/docs/cis_v150_1_20.md b/cis_v150/docs/cis_v150_1_20.md new file mode 100644 index 00000000..8f90742c --- /dev/null +++ b/cis_v150/docs/cis_v150_1_20.md @@ -0,0 +1,30 @@ +## Description + +Access Analyzer generates a finding when a policy on a resource within your zone of trust allows access from outside your zone of trust. +Enable IAM Access analyzer for IAM policies about all resources. After the Analyzer is enabled in IAM, scan results are displayed on the console. + +AWS IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. This lets you identify unintended access to your resources and data. IAM Access Analyzer continuously monitors all policies for S3 bucket, IAM roles, KMS(Key Management Service) keys, AWS Lambda functions, and Amazon SQS(Simple Queue Service) queues. + +## Remediation + +### From Console + +Perform the following to enable IAM Access analyzer for IAM policies: + +1. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. In the left navigation pane, choose **Access analyzer**. +3. Click **Create analyzer**. +4. On the `Create analyzer` page, confirm that the region displayed is the region where you want to enable Access Analyzer. +5. Enter a name for the analyzer or can keep the system generated. +6. Optional. add any tags that you want to apply to the analyzer. +7. Choose **Create analyzer**. + +### From Command Line + +Run the following command: + +```bash +aws accessanalyzer create-analyzer --analyzer-name --type +``` + +**Note**: The type of analyzer to create. Only ACCOUNT and ORGANIZATION analyzers are supported. You can create only one analyzer per account per Region. You can create up to 5 analyzers per organization per Region. diff --git a/cis_v150/docs/cis_v150_1_21.md b/cis_v150/docs/cis_v150_1_21.md new file mode 100644 index 00000000..22afeb1f --- /dev/null +++ b/cis_v150/docs/cis_v150_1_21.md @@ -0,0 +1,36 @@ +## Description + +In multi-account environments, IAM user centralization facilitates greater user control. User access beyond the initial account is then provide via role assumption. Centralization of users can be accomplished through federation with an external identity provider or through the use of AWS Organizations. + +Centralizing IAM user management to a single identity provider, reduces complexity and thus less access management errors. + +## Remediation + +### From Console + +Perform the following action to check: + +For multi-account AWS environments with an external identity provider + +1. Determine the master account for identity federation or IAM user management. +2. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +3. In the left navigation pane, choose **Identity providers**. +4. Verify the configuration. + +For all accounts that should not have local users present. For each account + +1. Determine all accounts that should not have local users present +2. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +3. Switch role into each identified account. +4. Click **Users**. +5. Confirm that no IAM users representing individuals are present. + +For multi-account AWS environments implementing AWS Organizations without an external identity provider + +1. Determine all accounts that should not have local users present. +2. Sign into the AWS console and open the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +3. Switch role into each identified account. +4. Click **Users**. +5. Confirm that no IAM users representing individuals are present. + +**Note**: The remediation procedure might vary based on the individual organization's implementation of identity federation and/or AWS Organizations with the acceptance criteria that no non-service IAM users, and non-root accounts, are present outside the account providing centralized IAM user management. diff --git a/cis_v150/docs/cis_v150_1_3.md b/cis_v150/docs/cis_v150_1_3.md new file mode 100644 index 00000000..d82daf7a --- /dev/null +++ b/cis_v150/docs/cis_v150_1_3.md @@ -0,0 +1,15 @@ +## Description + +Ensure *Security Challenge Questions* are set up in the AWS account settings page of your AWS account. + +By adding security challenge questions improve the security of your account. It can be used to authenticate individuals calling AWS customer service for support. It is highly 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 user" account. It is recommended that the use of this account to be limited. During events in case the root password is no longer accessible or the MFA token associated with root user is lost or destroyed it is possible, through authentication using secret questions and associated answers, root user login access can be recovered. + +## Remediation + +There is no API available for setting security questions - you must log in to the AWS console to verify, and set your security questions and answers. + +1. Sign into the AWS console as a root user, and navigate to the [Account Settings](https://console.aws.amazon.com/billing/home?#/account). +2. Verify that the information in the **Configure Security Challenge Questions** section is complete and you have the answers with you. If changes are required, click **Edit**, make your changes, and then click **Update**. +3. Keep the questions and answers in a secure location. diff --git a/cis_v150/docs/cis_v150_1_4.md b/cis_v150/docs/cis_v150_1_4.md new file mode 100644 index 00000000..af9066ce --- /dev/null +++ b/cis_v150/docs/cis_v150_1_4.md @@ -0,0 +1,19 @@ +## Description + +The root user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the root user account be removed. + +By default IAM *root user* account for us-gov cloud regions is not enabled. However, on request AWS support can enable *root user* access keys only through CLI or API methods. + +Removing access keys associated with the *root user* 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 + +### From Console + +Perform the following action to delete or disable active root user access keys: + +1. Sign into the AWS console as a root user, and navigate to [Your Security Credentials](https://console.aws.amazon.com/iam/home#/security_credentials). +2. Click on Access Keys (access key ID and secret access key) section. +3. Under the Status column if there are any Keys which are Active + - Click on **Make Inactive** to make it inactive. + - Click **Delete** to delete it permanently (deleted keys cannot be recovered). diff --git a/cis_v150/docs/cis_v150_1_5.md b/cis_v150/docs/cis_v150_1_5.md new file mode 100644 index 00000000..638c98bd --- /dev/null +++ b/cis_v150/docs/cis_v150_1_5.md @@ -0,0 +1,26 @@ +## Description + +The root user account is the most privileged user in an AWS account. Multi-factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS console, they will be prompted for their username and password as well as for an authentication code from their MFA device. + +It is recommended that the device which is used for virtual MFA is NOT a personal device, but rather a dedicated device (phone or tablet). That can be managed to be kept charged and secured. It reduces the risks of losing access to the MFA code. + +IAM *root user* account for us-gov cloud regions does not have console access. This control is not applicable for us-gov cloud regions. + +Enabling virtual MFA provides increased security for console access as it requires the authenticating principal to possess a device that creates a time-sensitive key and have knowledge of a credential. + +## Remediation + +### From Console + +Perform the following action to enabled virtual MFA for the root user account: + +1. Sign into the AWS console as a root user, and navigate to [Your Security Credentials](https://console.aws.amazon.com/iam/home#/security_credentials). +2. Click on Multi-factor authentication (MFA) section and click **Activate MFA**. +3. In the Manage MFA device wizard, choose **virtual MFA device** and click on **continue**. +4. IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. +5. 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). +6. 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. +7. Once you configure, the virtual MFA device starts generating MFA codes. +8. Type two consecutive MFA codes, MFA code 1 and MFA code 2 fields. Then click **Assign MFA**. Now the virtual MFA is enabled for the AWS account. diff --git a/cis_v150/docs/cis_v150_1_6.md b/cis_v150/docs/cis_v150_1_6.md new file mode 100644 index 00000000..2ccaa3d7 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_6.md @@ -0,0 +1,27 @@ +## Description + +The root user account is the most privileged user in an AWS account. Multi-factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS console, they will be prompted for their username and password as well as for an authentication code from their MFA device. + +For Level 2, it is recommended that the root user account can be protected with a hardware MFA. + +It is recommended that the device which is used for virtual MFA is NOT a personal device, but rather a dedicated device (phone or tablet). That can be managed to be kept charged and secured. It reduces the risks of losing access to the MFA code. + +IAM *root user* account for us-gov cloud regions does not have console access. This control is not applicable for us-gov cloud regions. + +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 smartphone or tablet on which a virtual MFA resides. + +Using hardware MFA for many AWS accounts can create a logistical device management issue. In such cases, consider only implementing this Level 2 recommendation selectively to the highest secured AWS accounts and the Level 1 recommendation applied to the remaining accounts. + +## Remediation + +### From Console + +Perform the following action to enabled hardware MFA for the root user account: + +1. Sign into the AWS console as a root user, and navigate to [Your Security Credentials](https://console.aws.amazon.com/iam/home#/security_credentials). +2. Click on Multi-factor authentication (MFA) section and click **Activate MFA**. +3. In the Manage MFA device wizard, choose **Other hardware MFA device** and click on **continue**. +4. In the **Serial number** field, enter the serial number that is found on the back of the MFA device. +5. Press the button on the front of the device and type the 6-digit number that appears in **MFA code 1** field. +6. Wait for 30 seconds and then press the button again. Type the second number in **MFA code 2** field. +7. Click **Assign MFA**. Now the MFA device is assigned to the AWS account. diff --git a/cis_v150/docs/cis_v150_1_7.md b/cis_v150/docs/cis_v150_1_7.md new file mode 100644 index 00000000..0aba6c58 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_7.md @@ -0,0 +1,14 @@ +## Description + +With the creation of an AWS account, a root user account is created. This root user is the most privileged user in an AWS account and has unrestricted access to and control over all resources in the account. It is highly recommended that the use of this root user to be avoided for everyday tasks. + +By default IAM *root user* account for us-gov cloud regions is not enabled. However, on request AWS support can enable *root user* access keys only through CLI or API methods. + +As the root user has unrestricted access to all the resources, it is dangerous to use for daily task. To avoid this it better to deactivate or delete any access keys associated with it. Also to change the root user password as necessary. Use of it, is inconsistent with the principles of least privilege and separation of duties, and can lead to unnecessary harm due to mistakes. + +## Remediation + +When you find that the root user account is being used for daily activity that includes administrative tasks that do not require the root user, perform the following action: + +1. Change the root user password. +2. Deactivate or delete any access keys associated with the root user. diff --git a/cis_v150/docs/cis_v150_1_8.md b/cis_v150/docs/cis_v150_1_8.md new file mode 100644 index 00000000..ce369702 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_8.md @@ -0,0 +1,24 @@ +## Description + +Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are at least a given length. It is recommended that the password policy require a minimum password length of 14. + +Setting a complex password policy increases account resiliency against unethical password hackers. + +## Remediation + +Perform the following to set the password policy is configured as prescribed: + +### From Console: + +1. Sign into the AWS console and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. Choose **Account settings**. +3. Click **Change** or **Change password policy** (if no password policy set earlier). +4. Ensure in the `Enforce minimum password length` field is set to 14, then choose **Save changes**. + +### From Command Line: + +```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_v150/docs/cis_v150_1_9.md b/cis_v150/docs/cis_v150_1_9.md new file mode 100644 index 00000000..d30fa109 --- /dev/null +++ b/cis_v150/docs/cis_v150_1_9.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 unethical password hackers. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### From Console: + +1. Sign into the AWS console and navigate to the [IAM Dashboard](https://console.aws.amazon.com/iam/home#/home). +2. Choose **Account settings**. +3. Click **Change** or **Change password policy** (if no password policy set earlier). +4. Ensure `Prevent password reuse` is checked. +5. Ensure `Remember password(s)` is set to 24 and then choose **Save changes**. + +### From Command Line: + +```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_v150/docs/cis_v150_2.md b/cis_v150/docs/cis_v150_2.md new file mode 100644 index 00000000..3c5a8812 --- /dev/null +++ b/cis_v150/docs/cis_v150_2.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Storage. diff --git a/cis_v150/docs/cis_v150_2_1.md b/cis_v150/docs/cis_v150_2_1.md new file mode 100644 index 00000000..c5b50b55 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_1.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Simple Storage Service (S3) Buckets. diff --git a/cis_v150/docs/cis_v150_2_1_1.md b/cis_v150/docs/cis_v150_2_1_1.md new file mode 100644 index 00000000..6e3e4fec --- /dev/null +++ b/cis_v150/docs/cis_v150_2_1_1.md @@ -0,0 +1,30 @@ +## Description + +Amazon S3 provides multiple encryption options to protect data at rest. With default encryption, you can set the behavior for a S3 bucket so that all new objects are encrypted when they are stored in the bucket. The objects can be encrypted using server-side encryption with either Amazon S3-managed keys (SSE-S3) or customer master keys (CMKs) stored in AWS Key Management Service (AWS KMS) (SSE-KMS). + +Encrypting data at rest reduces the likelihood that it is unintentionally exposed and can nullify the impact of disclosure if the encryption remains unbroken. + +## Remediation + +### From Console + +1. Open AW S3 console [S3](https://console.aws.amazon.com/s3/). +2. In the buckets list, choose the **Name** of the bucket that you want. +3. Go to **Properties** tab and choose **Edit** under **Default encryption**. +4. Select **Enable** and either select `SSE-S3` or `SSE-KMS`. +5. Click **Save changes**. +6. Repeat for all the buckets in your AWS account lacking encryption. + +### From Command Line + +Run either +```bash +aws s3api put-bucket-encryption --bucket --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm": "AES256"}}]}' +``` + +or + +```bash +aws s3api put-bucket-encryption --bucket --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "aws:kms","KMSMasterKeyID": "aws/s3"}}]}' +``` +**Note**: The KMSMasterKeyID can be set to the master key of your choosing; aws/s3 is an AWS preconfigured default. diff --git a/cis_v150/docs/cis_v150_2_1_2.md b/cis_v150/docs/cis_v150_2_1_2.md new file mode 100644 index 00000000..a2be0259 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_1_2.md @@ -0,0 +1,75 @@ +## Description + +Amazon S3 provides multiple encryption options to protect data at rest, transit & it's access. At the Amazon S3 bucket level, you can restrict bucket policy making the objects accessible only through HTTPS. + +By default, Amazon S3 allows both HTTP and HTTPS requests. To achieve only allowing access to Amazon S3 objects through HTTPS you also have to explicitly deny access to HTTP requests. Bucket policies that allow HTTPS requests without explicitly denying HTTP requests will not comply with this recommendation. + +## Remediation + +### From Console + +1. Open the Amazon S3 console [S3](https://console.aws.amazon.com/s3/) +2. Select the **Check box** next to the Bucket. +3. Click on **Permissions**. +4. Click **Bucket Policy** +5. Add this to the existing policy filling in the required information +``` +{ + "Sid":"", + "Effect":"Deny", + "Principal":"*", + "Action":"s3:GetObject", + "Resource":"arn:aws:s3:::/*", + "Condition":{ + "Bool":{ + "aws:SecureTransport":"false" + } +.. +``` +6. Choose **Save** +7. Repeat for all the buckets in your AWS account that contain sensitive data. + +### Using AWS Policy Generator + +1. Repeat steps 1-4 above. +2. Click on **Policy Generator** at the bottom of the Bucket Policy Editor +3. Select Policy Type `S3 Bucket Policy` +4. Add Statements + - Effect = Deny + - Principal = * + - AWS Service = Amazon S3 + - Actions = GetObject + - Amazon Resource Name = +5. Generate Policy +6. Copy the text and add it to the Bucket Policy. + +### From Command Line + +1. Export the bucket policy to a json file. + +```bash +aws s3api get-bucket-policy --bucket --query Policy --output text > policy.json +``` + +2. Modify the policy.json file by adding in this statement + +``` +{ + "Sid": ", + "Effect": "Deny", + "Principal": "*", + "Action": "s3:GetObject", + "Resource": "arn:aws:s3:::/*", + "Condition": { + "Bool": { + "aws:SecureTransport": "false" + } + } + } +``` + +3. Apply this modified policy back to the S3 bucket: + +```bash +aws s3api put-bucket-policy --bucket --policy file://policy.json +``` diff --git a/cis_v150/docs/cis_v150_2_1_3.md b/cis_v150/docs/cis_v150_2_1_3.md new file mode 100644 index 00000000..5de71539 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_1_3.md @@ -0,0 +1,20 @@ +## Description + +Once MFA Delete is enable on your sensitive and classified S3 bucket it requires the user to have two forms of authentication. + +Adding MFA delete to an S3 bucket, requires additional authentication when you change the version state of your bucket or you delete and object version adding another layer of security in the event your security credentials are compromised or unauthorized access is granted. + +## Remediation + +### From Command Line + +Perform the steps below to enable MFA delete on an S3 bucket. +**Note:** You cannot enable MFA Delete using the AWS Management Console. You must use the AWS CLI or API. You must use your root account to enable MFA Delete on S3 buckets + +1. Run the s3ap put-bucket-versioning command + +```bash +aws s3api put-bucket-versioning --profile my-root-profile \ +--bucket Bucket_Name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa \ +โ€œarn:aws:iam::aws_account_id:mfa/root-account-mfa-device passcodeโ€ +``` diff --git a/cis_v150/docs/cis_v150_2_1_4.md b/cis_v150/docs/cis_v150_2_1_4.md new file mode 100644 index 00000000..77c7f77e --- /dev/null +++ b/cis_v150/docs/cis_v150_2_1_4.md @@ -0,0 +1,14 @@ +## Description + +Macie along with other 3rd party tools can be used to discover, monitor, classify, and inventory S3 buckets. + +Using a Cloud service or 3rd Party software to continuously monitor and automate the process of data discovery and classification for S3 buckets using machine learning and pattern matching is a strong defense in protecting that information. + +## Remediation + +### From Console + +1. Enable Macie through the [Macie console](https://console.aws.amazon.com/macie/). +2. Create an S3 bucket to use as a repository for sensitive data discovery results. +3. Select the buckets you want Macie to analyze and then create a job. +4. After the job has run, review the findings by selecting **Findings** in the left pane. diff --git a/cis_v150/docs/cis_v150_2_1_5.md b/cis_v150/docs/cis_v150_2_1_5.md new file mode 100644 index 00000000..b1cac0e9 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_1_5.md @@ -0,0 +1,55 @@ +## Description + +Amazon S3 provides *Block public access (bucket settings)* and *Block public access (account settings)* to help you manage public access to Amazon S3 resources. By default, S3 buckets and objects are created with public access disabled. However with an IAM principle with sufficient S3 permissions can enable public access at the bucket and/or object level. + +While enabled, Block public access (bucket settings) prevents an individual bucket and its objects, from becoming publicly accessible. +Similarly, Block public access (account settings) prevents all buckets and it's objects in an account, from becoming publicly accessible. + +Amazon S3 *Block public access (bucket settings)* prevents the accidental or malicious public exposure of data contained within the respective bucket(s). + +Amazon S3 *Block public access (account settings)* prevents the accidental or malicious public exposure of data contained within all buckets of the respective AWS account. + +Whether blocking public access to all or some buckets is an organizational decision that should be based on data sensitivity, least privilege, and use case. + +When you apply Block Public Access settings to an account, the settings apply to all AWS Regions globally. The settings might not take effect in all Regions immediately or simultaneously, but they eventually propagate to all Regions. + +## Remediation + +### From Console + +By using Block Public Access (bucket settings): + +1. Login to AWS Management Console and open the [Amazon S3 console](https://console.aws.amazon.com/s3/). +2. Click on the bucket name. +3. Go to **Permissions** tab. +4. Click **Edit** for `Block all public access (bucket setting)`. +5. Ensure that block public access settings are set appropriately for this bucket. +6. Repeat for all the buckets in your AWS account that contain sensitive data. + +By using Block Public Access (account settings): + +1. Login to AWS Management Console and open the [Amazon S3 console](https://console.aws.amazon.com/s3/). +2. In the left navigation pane, choose **Block Public Access settings for this account** +3. Ensure that block public access settings are set appropriately for your AWS account. + +### From Command Line + +To set Block Public access settings for the buckets, run the following commands: + +1. List all of the S3 Buckets + +```bash +aws s3 ls +``` + +2. Set the public access to true on that bucket + +```bash +aws s3api put-public-access-block --bucket --public-access- block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPu blicBuckets=true" +``` + +To set Block Public access settings for the account, run the following command: + +```bash +aws s3control put-public-access-block --public-access-block-configuration BlockPublicAcls=true, IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true --account-id +``` diff --git a/cis_v150/docs/cis_v150_2_2.md b/cis_v150/docs/cis_v150_2_2.md new file mode 100644 index 00000000..d2a6a929 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_2.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Elastic Compute Cloud (EC2). diff --git a/cis_v150/docs/cis_v150_2_2_1.md b/cis_v150/docs/cis_v150_2_2_1.md new file mode 100644 index 00000000..2972d175 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_2_1.md @@ -0,0 +1,27 @@ +## Description + +Elastic Compute Cloud (EC2) supports encryption at rest when using the Elastic Block Store(EBS) service. While disabled by default, forcing encryption at EBS volume creation is supported. + +Default EBS volume encryption only applies to newly created EBS volumes. Existing EBS volumes are not converted automatically. + +Encrypting data at rest reduces the likelihood that it is unintentionally exposed and can nullify the impact of disclosure if the encryption remains unbroken. + +## Remediation + +### From Console + +1. Open the Amazon EC2 console using [EC2](https://console.aws.amazon.com/ec2/) +2. Under **Account attributes**, click `EBS encryption`. +3. Click **Manage**. +4. Click the `Enable` checkbox. +5. Click `Update EBS encryption` +6. Repeat for every region requiring the change. + +### From Command Line + +1. Run +```bash +aws --region ec2 enable-ebs-encryption-by-default. +``` +2. Verify that **EbsEncryptionByDefault**: **true** is displayed. +3. Review every region in-use. diff --git a/cis_v150/docs/cis_v150_2_3.md b/cis_v150/docs/cis_v150_2_3.md new file mode 100644 index 00000000..9c7967af --- /dev/null +++ b/cis_v150/docs/cis_v150_2_3.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Relational Database Services (RDS). diff --git a/cis_v150/docs/cis_v150_2_3_1.md b/cis_v150/docs/cis_v150_2_3_1.md new file mode 100644 index 00000000..f3ea700d --- /dev/null +++ b/cis_v150/docs/cis_v150_2_3_1.md @@ -0,0 +1,70 @@ +## Description + +Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. After your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. + +Databases that hold sensitive and critical data, it is highly recommended to implement encryption in order to protect your data from unauthorized access. With RDS encryption enabled, the data stored on the instance underlying storage, the automated backups, Read Replicas, and snapshots, become all encrypted. + +## Remediation + +### From Console + +1. Login to the AWS [RDS console](https://console.aws.amazon.com/rds/). +2. In the left navigation panel, click on `Databases` +3. Select the Database instance that needs to encrypt. +4. Click on **Actions** button placed at the top right and select **Take Snapshot**. +5. On the Take Snapshot page, enter a database name of which want to take snapshot in the Snapshot Name field and click Take Snapshot. +6. Select the newly created snapshot and click the **Copy** from the dashboard top menu. +7. On the Make Copy of DB Snapshot page, perform the following: + 1. In the New DB Snapshot Identifier field, Enter a name for the `new snapshot`. + 2. Check `Copy Tags`, New snapshot must have the same tags as the source snapshot. + 3. Select Yes from the **Enable Encryption** dropdown list to enable encryption, Can choose to use the AWS default encryption key or custom key from Master Key dropdown list. +8. Click **Copy Snapshot** to create an encrypted copy of selected instance snapshot. +9. Select the new Snapshot Encrypted Copy and click Restore Snapshot button from the dashboard top menu, This will restore the encrypted snapshot to a new database instance. +10. On the Restore DB Instance page, enter a unique name for the new database instance in the DB Instance Identifier field. +11. Review the instance configuration details and click **Restore DB Instance**. +12. As the new instance provisioning process is completed can update application configuration to refer to the endpoint of the new Encrypted database instance once the database endpoint is changed at the application level, can remove the unencrypted instance. + +### From Command Line + +1. Run describe-db-instances command to list all RDS database names available in the selected AWS region, The command output should return database instance identifier. + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +2. Run create-db-snapshot command to create a snapshot for the selected database instance, The command output will return the new snapshot with name DB +Snapshot Name. + +```bash +aws rds create-db-snapshot --region --db-snapshot-identifier --db-instance-identifier +``` + +3. Now run list-aliases command to list the KMS keys aliases available in a specified region, The command output should return each key alias currently available. For our RDS encryption the activation process, locate the ID of the AWS default KMS key. + +```bash +aws kms list-aliases --region +``` + +4. Run copy-db-snapshot command using the default KMS key ID for RDS instances returned earlier to create an encrypted copy of the database instance snapshot, the command output will return the encrypted instance snapshot configuration. + +```bash +aws rds copy-db-snapshot --region --source-db-snapshotidentifier --target-db-snapshot-identifier --copy-tags --kms-key-id +``` + +5. Run restore-db-instance-from-db-snapshot command to restore the encrypted snapshot created at the previous step to a new database instance, if successful, the command output should return the new encrypted database instance configuration. + +```bash +aws rds restore-db-instance-from-db-snapshot --region --dbinstance-identifier --db-snapshot-identifier +``` + +6. Run describe-db-instances command to list all RDS database names, available in the selected AWS region, output will return database instance identifier name. Select encrypted database name that we just created DB-Name-Encrypted. + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +7. Run again describe-db-instances command using the RDS instance identifier returned earlier, to determine if the selected database instance is encrypted, the command output should return the encryption status True. + +```bash +aws rds describe-db-instances --region --db-instance-identifier --query 'DBInstances[*].StorageEncrypted' +``` diff --git a/cis_v150/docs/cis_v150_2_3_2.md b/cis_v150/docs/cis_v150_2_3_2.md new file mode 100644 index 00000000..f33e22fa --- /dev/null +++ b/cis_v150/docs/cis_v150_2_3_2.md @@ -0,0 +1,41 @@ +## Description + +Ensure that RDS database instances have the Auto Minor Version Upgrade flag enabled in order to receive automatically minor engine upgrades during the specified maintenance window. So, RDS instances can get the new features, bug fixes, and security patches for their database engines. + +AWS RDS will occasionally deprecate minor engine versions and provide new ones for an upgrade. When the last version number within the release is replaced, the version changed is considered minor. With Auto Minor Version Upgrade feature enabled, the version upgrades will occur automatically during the specified maintenance window so your RDS instances can get the new features, bug fixes, and security patches for their database engines. + +## Remediation + +### From Console + +1. Log in to the AWS management console and navigate to the RDS dashboard at https://console.aws.amazon.com/rds/. +2. In the left navigation panel, click on **Databases**. +3. Select the RDS instance that wants to update. +4. Click on the **Modify** button placed on the top right side. +5. On the **Modify DB Instance: instance identifier** page, In the **Maintenance** section, select **Auto minor version upgrade** click on the **Yes** radio button. +6. At the bottom of the page click on **Continue**, check to Apply Immediately to apply the changes immediately, or select **Apply during the next scheduled maintenance window** to avoid any downtime. +7. Review the changes and click on **Modify DB Instance**. The instance status should change from available to modifying and back to available. Once the feature is enabled, the **Auto Minor Version Upgrade** status should change to Yes. + +### From Command Line + +1. Run **describe-db-instances** command to list all RDS database instance names, available in the selected AWS region: + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +2. The command output should return each database instance identifier. +3. Run the **modify-db-instance** command to modify the selected RDS instance configuration this command will apply the changes immediately, Remove **--apply-immediately** to apply changes during the next scheduled maintenance window and avoid any downtime: + +```bash +aws rds modify-db-instance --region --db-instance-identifier --auto-minor-version-upgrade --apply-immediately +``` + +4. The command output should reveal the new configuration metadata for the RDS instance and check **AutoMinorVersionUpgrade** parameter value. +5. Run **describe-db-instances** command to check if the Auto Minor Version Upgrade feature has been successfully enable: + +```bash +aws rds describe-db-instances --region --db-instance-identifier --query 'DBInstances[*].AutoMinorVersionUpgrade' +``` + +6. The command output should return the feature current status set to **true**, the feature is **enabled** and the minor engine upgrades will be applied to the selected RDS instance. diff --git a/cis_v150/docs/cis_v150_2_3_3.md b/cis_v150/docs/cis_v150_2_3_3.md new file mode 100644 index 00000000..f96ff4d8 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_3_3.md @@ -0,0 +1,44 @@ +## Description + +Ensure and verify that RDS database instances provisioned in your AWS account do restrict unauthorized access in order to minimize security risks. To restrict access to any publicly accessible RDS database instance, you must disable the database Publicly Accessible flag and update the VPC security group associated with the instance. + +Ensure that no public-facing RDS database instances are provisioned in your AWS account and restrict unauthorized access in order to minimize security risks. When the RDS instance allows unrestricted access (0.0.0.0/0), everyone and everything on the Internet can establish a connection to your database and this can increase the opportunity for malicious activities such as brute force attacks, PostgreSQL injections, or DoS/DDoS attacks. + +## Remediation + +### From Console + +1. Log in to the AWS management console and navigate to the RDS dashboard at https://console.aws.amazon.com/rds/. +2. Under the navigation panel, On RDS Dashboard, click **Databases**. +3. Select the RDS instance that you want to update. +4. Click **Modify** from the dashboard top menu. +5. On the Modify DB Instance panel, under the **Connectivity** section, click on **Additional connectivity configuration** and update the value for **Publicly Accessible** to Not publicly accessible to restrict public access. Follow the below steps to update subnet configurations: + * Select the **Connectivity and security** tab, and click on the VPC attribute value inside the **Networking** section. + * Select the **Details** tab from the VPC dashboard bottom panel and click on Route table configuration attribute value. + * On the Route table details page, select the Routes tab from the dashboard bottom panel and click on **Edit routes**. + * On the Edit routes page, update the Destination of Target which is set to **igw-xxxxx** and click on **Save** routes. +6. On the Modify DB Instance panel Click on **Continue** and In the Scheduling of modifications section, perform one of the following actions based on your requirements: + * Select Apply during the next scheduled maintenance window to apply the changes automatically during the next scheduled maintenance window. + * Select Apply immediately to apply the changes right away. With this option, any pending modifications will be asynchronously applied as soon as possible, regardless of the maintenance window setting for this RDS database instance. Note that any changes available in the pending modifications queue are also applied. If any of the pending modifications require downtime, choosing this option can cause unexpected downtime for the application. +7. Repeat steps 3 to 6 for each RDS instance available in the current region. +8. Change the AWS region from the navigation bar to repeat the process for other regions. + +### From Command Line + +1. Run **describe-db-instances** command to list all RDS database names identifiers, available in the selected AWS region: + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +2. The command output should return each database instance identifier. +3. Run **modify-db-instance** command to modify the selected RDS instance configuration. Then use the following command to disable the **Publicly Accessible** flag for the selected RDS instances. This command use the apply-immediately flag. If you want **to avoid any downtime --no-apply-immediately flag can be used:** + +```bash +aws rds modify-db-instance --region --db-instance-identifier --no-publicly-accessible --apply-immediately +``` + +4. The command output should reveal the **PubliclyAccessible** configuration under pending values and should get applied at the specified time. +5. Updating the Internet Gateway Destination via AWS CLI is not currently supported To update information about Internet Gateway use the AWS Console Procedure. +6. Repeat steps 1 to 5 for each RDS instance provisioned in the current region. +7. Change the AWS region by using the --region filter to repeat the process for other regions. diff --git a/cis_v150/docs/cis_v150_2_4.md b/cis_v150/docs/cis_v150_2_4.md new file mode 100644 index 00000000..12307cd1 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_4.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Elastic File System (EFS). diff --git a/cis_v150/docs/cis_v150_2_4_1.md b/cis_v150/docs/cis_v150_2_4_1.md new file mode 100644 index 00000000..9020b4a6 --- /dev/null +++ b/cis_v150/docs/cis_v150_2_4_1.md @@ -0,0 +1,66 @@ +## Description + +EFS data should be encrypted at rest using AWS KMS (Key Management Service). + +Data should be encrypted at rest to reduce the risk of a data breach via direct access to the storage device. + +## Remediation + +It is important to note that EFS file system data at rest encryption must be turned on when creating the file system. +If an EFS file system has been created without data at rest encryption enabled then you must create another EFS file system with the correct configuration and transfer the data. + +Steps to create an EFS file system with data encrypted at rest: + +### From Console + +1. Login to the AWS Management Console and Navigate to **Elastic File System (EFS) dashboard**. +2. Select **File Systems** from the left navigation panel. +3. Click **Create File System** button from the dashboard top menu to start the file system setup process. +4. On the **Configure file system access** configuration page, perform the following actions. + * Choose the right VPC from the VPC dropdown list. + * Within Create mount targets section, select the checkboxes for all of the Availability Zones (AZs) within the selected VPC. These will be your mount targets. + * Click **Next step** to continue. +5. Perform the following on the **Configure optional settings** page. + * Create **tags** to describe your new file system. + * Choose **performance mode** based on your requirements. + * Check **Enable encryption** checkbox and choose **aws/elasticfilesystem** from Select KMS master key dropdown list to enable encryption for the new file system using the default master key provided and managed by AWS KMS. + * Click **Next step** to continue. +6. Review the file system configuration details on the **review and create** page and then click **Create File System** to create your new AWS EFS file system. +7. Copy the data from the old unencrypted EFS file system onto the newly create encrypted file system. +8. Remove the unencrypted file system as soon as your data migration to the newly create encrypted file system is completed. +9. Change the AWS region from the navigation bar and repeat the entire process for other aws regions. + + +### From Command Line + +1. Run describe-file-systems command to describe the configuration information available for the selected (unencrypted) file system (see Audit section to identify the right resource): + +```bash +aws efs describe-file-systems --region --file-system-id +``` + +2. The command output should return the requested configuration information. +3. To provision a new AWS EFS file system, you need to generate a universally unique identifier (UUID) in order to create the token required by the create-filesystem command. To create the required token, you can use a randomly generated UUID from "https://www.uuidgenerator.net". +4. Run create-file-system command using the unique token created at the previous step + +```bash +aws efs create-file-system --region --creation-token --performance-mode generalPurpose --encrypted +``` + +5. The command output should return the new file system configuration metadata. +6. Run create-mount-target command using the newly created EFS file system ID returned at the previous step as identifier and the ID of the Availability Zone (AZ) that will represent the mount target: + +```bash +aws efs create-mount-target --region --file-system-id --subnet-id +``` + +7. The command output should return the new mount target metadata. +8. Now you can mount your file system from an EC2 instance. +9. Copy the data from the old unencrypted EFS file system onto the newly create encrypted file system. +10. Remove the unencrypted file system as soon as your data migration to the newly create encrypted file system is completed. + +```bash +aws efs delete-file-system --region --file-system-id +``` + +11. Change the AWS region by updating the --region and repeat the entire process for other aws regions. diff --git a/cis_v150/docs/cis_v150_3.md b/cis_v150/docs/cis_v150_3.md new file mode 100644 index 00000000..6c1d7db9 --- /dev/null +++ b/cis_v150/docs/cis_v150_3.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS logging features. diff --git a/cis_v150/docs/cis_v150_3_1.md b/cis_v150/docs/cis_v150_3_1.md new file mode 100644 index 00000000..c85d4a46 --- /dev/null +++ b/cis_v150/docs/cis_v150_3_1.md @@ -0,0 +1,40 @@ +## 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: + +### From 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. + +### From Command Line + +```bash +aws cloudtrail create-trail --name --bucket-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 + +aws cloudtrail update-trail --name --is-multi-region-trail +``` diff --git a/cis_v150/docs/cis_v150_3_10.md b/cis_v150/docs/cis_v150_3_10.md new file mode 100644 index 00000000..2af2ffc1 --- /dev/null +++ b/cis_v150/docs/cis_v150_3_10.md @@ -0,0 +1,35 @@ +## Description + +S3 object-level API operations such as GetObject, DeleteObject, and PutObject are called data events. By default, CloudTrail trails don't log data events and so it is recommended to enable Object-level logging for S3 buckets. + +Enabling object-level logging will help you meet data compliance requirements within your organization, perform comprehensive security analysis, monitor specific patterns of user behavior in your AWS account or take immediate actions on any object-level API activity within your S3 Buckets using Amazon CloudWatch Events. + +## Remediation + +### From Console + +1. Open the Amazon S3 console [S3](https://console.aws.amazon.com/s3/) +2. Choose the required bucket from the bucket list. +3. Choose **Properties** tab to see in detail bucket configuration. +4. Navigate to `AWS CloudTrail data events` section to select the CloudTrail name for the recording activity. +5. You can choose an existing Cloudtrail or create a new one by navigating to the Cloudtrail console link from S3. +6. Once the Cloudtrail console, navigate to `Data events : S3` section. +7. If the current status for Object-level logging is set to Disabled, then object-level logging of write events for the selected s3 bucket is not set + - Select **Edit** to enable the `Write` event. + - You can choose to select `All current and future S3 buckets` or `Individual bucket`. +8. Repeat steps 2 to 7 to enable object-level logging of read events for other S3 buckets. + +### From Command Line + +### From Command Line + +1. To enable object-level data events logging for S3 buckets within your AWS account, run put-event-selectors command using the name of the trail that you want to reconfigure as identifier: + +```bash +aws cloudtrail put-event-selectors --region --trail-name --event-selectors '[{ "ReadWriteType": "WriteOnly", "IncludeManagementEvents":true, "DataResources": [{ "Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::/"] }] }]' +``` + +2. The command output will be object-level event trail configuration. +3. If you want to enable it for all buckets at once then change Values parameter to `["arn:aws:s3"]` in command given above. +4. Repeat step 1 for each s3 bucket to update `object-level` logging of write events. +5. Change the AWS region by updating the --region command parameter and perform the process for other regions. diff --git a/cis_v150/docs/cis_v150_3_11.md b/cis_v150/docs/cis_v150_3_11.md new file mode 100644 index 00000000..b03d4a24 --- /dev/null +++ b/cis_v150/docs/cis_v150_3_11.md @@ -0,0 +1,33 @@ +## Description + +S3 object-level API operations such as GetObject, DeleteObject, and PutObject are called data events. By default, CloudTrail trails don't log data events and so it is recommended to enable Object-level logging for S3 buckets. + +Enabling object-level logging will help you meet data compliance requirements within your organization, perform comprehensive security analysis, monitor specific patterns of user behavior in your AWS account or take immediate actions on any object-level API activity using Amazon CloudWatch Events. + +## Remediation + +### From Console + +1. Open the Amazon S3 console [S3](https://console.aws.amazon.com/s3/) +2. Choose the required bucket from the bucket list. +3. Choose `Properties` tab to see in detail bucket configuration. +4. Navigate to `AWS CloudTrail data events` section to select the CloudTrail name for the recording activity. +5. You can choose an existing Cloudtrail or create a new one by navigating to the Cloudtrail console link from S3. +6. Once the Cloudtrail console, navigate to `Data events : S3` section. +7. If the current status for Object-level logging is set to Disabled, then object-level logging of `read` events for the selected s3 bucket is not set + - Select **Edit** to enable the `Read` event. + - You can choose to select `All current and future S3 buckets` or `Individual bucket`. +8. Repeat steps 2 to 7 to enable object-level logging of read events for other S3 buckets. + +### From Command Line + +1. To enable object-level data events logging for S3 buckets within your AWS account, run put-event-selectors command using the name of the trail that you want to reconfigure as identifier: + +```bash +aws cloudtrail put-event-selectors --region --trail-name --event-selectors '[{ "ReadWriteType": "ReadOnly", "IncludeManagementEvents":true, "DataResources": [{ "Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::/"] }] }]' +``` + +2. The command output will be object-level event trail configuration. +3. If you want to enable it for all buckets at once then change Values parameter to `["arn:aws:s3"]` in command given above. +4. Repeat step 1 for each s3 bucket to update `object-level` logging of write events. +5. Change the AWS region by updating the --region command parameter and perform the process for other regions. diff --git a/cis_v150/docs/cis_v150_3_2.md b/cis_v150/docs/cis_v150_3_2.md new file mode 100644 index 00000000..fd304674 --- /dev/null +++ b/cis_v150/docs/cis_v150_3_2.md @@ -0,0 +1,32 @@ +## 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. + +The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing. Additionally, enabling log file validation will provide additional integrity checking of CloudTrail logs. + +## Remediation + +Perform the following to enable global (Multi-region) CloudTrail logging: + +### From Console + +1. Sign in to the AWS Management Console and open the IAM console at [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 + +### From Command Line + +```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 +``` diff --git a/cis_v150/docs/cis_v150_3_3.md b/cis_v150/docs/cis_v150_3_3.md new file mode 100644 index 00000000..0cda45de --- /dev/null +++ b/cis_v150/docs/cis_v150_3_3.md @@ -0,0 +1,34 @@ +## 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 prevent public access to the CloudTrail logs. + +Allowing public access to CloudTrail log content might aid an adversary in identifying weaknesses in the affected account's use or configuration. + +## Remediation + +Perform the following to remove any public access that has been granted to the bucket via an ACL or S3 bucket policy: + +### From Console + +Using **Block public access** settings. + +1. Go to Amazon S3 console at [S3](https://console.aws.amazon.com/s3/home) +2. Choose the name of the bucket where your CloudTrail are stored. +3. Choose **Permissions** and then choose **Block public access** settings. +4. Choose Edit, select all four options under `Block all public access` check box, and then choose save changes. +5. If prompted, enter `confirm` and then choose **Confirm**. + +Using **ACL** and **Bucket Policy** settings. + +1. Go to Amazon S3 console at [S3](https://console.aws.amazon.com/s3/home) +2. Choose the name of the bucket where your CloudTrail are stored. +3. Choose **Permissions** and navigate to `Access control list (ACL)` +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. Ensure no rows exists that have the Grantee set to Everyone or the Grantee set to +Any Authenticated User. +6. If the Edit bucket policy button is present, click it to review the bucket policy. +7. Ensure the policy does not contain a Statement having an Effect set to Allow and a +Principal set to `"*"` or `{"AWS" : "*"}` diff --git a/cis_v150/docs/cis_v150_3_4.md b/cis_v150/docs/cis_v150_3_4.md new file mode 100644 index 00000000..d38bba5e --- /dev/null +++ b/cis_v150/docs/cis_v150_3_4.md @@ -0,0 +1,36 @@ +## Description + +CloudTrail is a web service that records AWS API calls made in a given account. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. + +CloudTrail uses Amazon S3 for log file storage and delivery, so log files are stored durably. In addition to capturing CloudTrail logs in a specified Amazon S3 bucket for long-term analysis, you can perform real-time analysis by configuring CloudTrail to send logs to CloudWatch Logs. + +For a trail that is enabled in all Regions in an account, CloudTrail sends log files from all those Regions to a CloudWatch Logs log group. + +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 + +To ensure that CloudTrail trails are integrated with CloudWatch Logs, perform the following to establish the prescribed state: + +### From Console + +1. Open the CloudTrail console at [CloudTrail](https://console.aws.amazon.com/cloudtrail/). +2. Choose Trails. +3. Choose a trail that there is no value for in the CloudWatch Logs Log group column. +4. Scroll down to the `CloudWatch Logs` section and then choose Edit. +5. Select the `Enabled` check box. +6. For Log group field, do one of the following: + - To use the default log group, keep the name as is. + - To use an existing log group, choose Existing and then enter the name of the log group to use. + - To create a new log group, choose New and then enter a name for the log group to create. +7. For IAM role, do one of the following: + - To use an existing role, choose Existing and then choose the role from the drop-down list. + - To create a new role, choose New and then enter a name for the role to create. The new role is assigned a policy that grants the necessary permissions. + - To view the permissions granted to the role, expand the Policy document. +8. Choose Save changes. + +### From Command Line + +```bash +aws cloudtrail update-trail --name --cloudwatch-logs-log-grouparn --cloudwatch-logs-role-arn +``` diff --git a/cis_v150/docs/cis_v150_3_5.md b/cis_v150/docs/cis_v150_3_5.md new file mode 100644 index 00000000..9e5f9573 --- /dev/null +++ b/cis_v150/docs/cis_v150_3_5.md @@ -0,0 +1,37 @@ +## Description + +AWS Config is a web service that performs configuration management of supported AWS resources in your account and delivers log files to you. The recorded information includes the configuration item (AWS resource), relationships between configuration items (AWS resources), and any configuration changes between resources. + +The AWS configuration item history captured by AWS Config enables security analysis, resource change tracking, and compliance auditing. + +## Remediation + +To implement AWS Config configuration: + +### From Console + +1. Open the AWS Config console at [Config](https://console.aws.amazon.com/config/). +2. Select the Region to configure AWS Config in. +3. On the Settings page, do the following: + - Under Resource types to record, select Record all resources supported in this region and Include global resources (e.g., AWS IAM resources). + - Under Amazon S3 bucket, specify the bucket to use or create a bucket and optionally include a prefix. + - Under Amazon SNS topic, select an Amazon SNS topic from your account or create one. + - Under AWS Config role, either choose Create AWS Config service-linked role or choose Choose a role from your account and then select the role to use. +4. Choose Next. +5. On the AWS Config rules page, choose Skip. +6. Choose **Confirm**. + +### From Command Line + +1. Ensure there is an appropriate S3 bucket, SNS topic, and IAM role per the AWS Config Service prerequisites. +2. Run this command to 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_v150/docs/cis_v150_3_6.md b/cis_v150/docs/cis_v150_3_6.md new file mode 100644 index 00000000..2540400e --- /dev/null +++ b/cis_v150/docs/cis_v150_3_6.md @@ -0,0 +1,19 @@ +## Description + +AWS 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 any target buckets. Configuring logs to be placed in a separate bucket allows access to log information which can be useful in security and incident response workflows. + +## Remediation + +Perform the following to enable S3 bucket logging: + +### From Console + +1. Open the Amazon S3 console at [S3](https://console.aws.amazon.com/s3/). +2. Choose the bucket used for CloudTrail. +3. Choose **Properties**. +4. Choose **Server access logging**. +5. Choose **Edit**, then select `Enable`. +6. Select a bucket from the `Target bucket` list, and optionally enter a prefix. +7. Choose Save. diff --git a/cis_v150/docs/cis_v150_3_7.md b/cis_v150/docs/cis_v150_3_7.md new file mode 100644 index 00000000..0c0dfb69 --- /dev/null +++ b/cis_v150/docs/cis_v150_3_7.md @@ -0,0 +1,29 @@ +## Description + +CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (AWS KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses hardware security modules (HSMs) to protect the security of encryption keys. + +You can configure CloudTrail logs to leverage server-side encryption (SSE) and AWS KMS customer-created master keys (CMKs) to further protect CloudTrail logs. + +Configuring CloudTrail to use SSE-KMS provides additional confidentiality controls on log data because a given user must have S3 read permission on the corresponding log bucket and must be granted decrypt permission by the CMK policy. + +## Remediation + +Perform the following to configure CloudTrail to use SSE-KMS: + +### From Console + +1. Open the CloudTrail console at [CloudTrail](https://console.aws.amazon.com/cloudtrail) +2. Choose Trails, select the trail to update, by clicking **Edit** button in `General details`. +3. In the `Storage location`, + - For `Log file SSE-KMS encryption`, choose `Enabled`. +4. In `Customer managed AWS KMS key`, 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. + - To create a key, enter an alias for the key in the `KMS alias` field. The key is created in the same Region as the bucket. +5. Click Save + +### From Command Line + +```bash +aws cloudtrail update-trail --name --kms-id aws kms put-key-policy --key-id --policy +``` diff --git a/cis_v150/docs/cis_v150_3_8.md b/cis_v150/docs/cis_v150_3_8.md new file mode 100644 index 00000000..b9918bc9 --- /dev/null +++ b/cis_v150/docs/cis_v150_3_8.md @@ -0,0 +1,33 @@ +## Description + +AWS KMS enables customers to rotate the backing key, which is key material stored in AWS KMS and is tied to the key ID of the CMK. It's the backing key that is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all previous backing keys so that decryption of encrypted data can take place transparently. + +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 + +Perform the following to configure key rotation: + +### From Console + +1. Open the AWS KMS console at [KMS](https://console.aws.amazon.com/kms). +2. In the left navigation pane, choose `Customer managed keys`. +3. Choose the alias of the key to `update` in the Alias column. +4. Under the **Key rotation** section, move down to Key Rotation . +5. Select `Automatically rotate this CMK every year` and then choose Save. + +### From Command Line + +1. Run the following command to get a list of all keys and their associated KeyIds + +```bash + aws kms list-keys +``` + +2. For each key, note the KeyId and run the following command + +```bash + aws kms get-key-rotation-status --key-id + ``` + +3. Ensure KeyRotationEnabled is set to true diff --git a/cis_v150/docs/cis_v150_3_9.md b/cis_v150/docs/cis_v150_3_9.md new file mode 100644 index 00000000..afa5baab --- /dev/null +++ b/cis_v150/docs/cis_v150_3_9.md @@ -0,0 +1,23 @@ +## 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 have created a flow log, you can view and retrieve its data in CloudWatch Logs. + +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. + +While setting up the VPC flow log, setting 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. + +## Remediation + +Perform the following to determine if VPC Flow logs is enabled: + +### From Console + +1. Open the Amazon VPC console at [VPC](https://console.aws.amazon.com/vpc/) +2. Select required VPC to update from **Your VPCs** +3. Choose the Flow Logs tab in the bottom section of the page. +4. If no Flow Log exists, choose **Create flow log** +5. For Filter, choose `Reject`. +6. For `Destination log group`, select the log group to use. +7. For IAM role, select the IAM role to use. +8. Choose **Create flow log**. diff --git a/cis_v150/docs/cis_v150_4.md b/cis_v150/docs/cis_v150_4.md new file mode 100644 index 00000000..053b2ed8 --- /dev/null +++ b/cis_v150/docs/cis_v150_4.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS to assist with monitoring and responding to account activities. diff --git a/cis_v150/docs/cis_v150_4_1.md b/cis_v150/docs/cis_v150_4_1.md new file mode 100644 index 00000000..d214b402 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_1.md @@ -0,0 +1,82 @@ +## 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 enable global (Multi-region) CloudTrail logging: + +### From Console + +**To create an Amazon SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + {($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")} + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.1-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.errorCode = "*UnauthorizedOperation") || ($.errorCode = "AccessDenied*") || ($.sourceIPAddress!="delivery.logs.amazonaws.com") || ($.eventName!="HeadBucket") }' +``` + +**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. + +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_v150/docs/cis_v150_4_10.md b/cis_v150/docs/cis_v150_4_10.md new file mode 100644 index 00000000..b460a444 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_10.md @@ -0,0 +1,82 @@ +## 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 for detecting changes to Security Groups. + +Monitoring changes to security group will help ensure that resources and services are not unintentionally exposed. + +## Remediation + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + {($.eventName = AuthorizeSecurityGroupIngress) || ($.eventName =AuthorizeSecurityGroupEgress) || ($.eventName = RevokeSecurityGroupIngress) || ($.eventName = RevokeSecurityGroupEgress) || ($.eventName = CreateSecurityGroup) || ($.eventName = DeleteSecurityGroup) } + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.10-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_11.md b/cis_v150/docs/cis_v150_4_11.md new file mode 100644 index 00000000..b33d2cff --- /dev/null +++ b/cis_v150/docs/cis_v150_4_11.md @@ -0,0 +1,83 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + { ($.eventName = CreateNetworkAcl) || ($.eventName = CreateNetworkAclEntry) || ($.eventName = DeleteNetworkAcl) || ($.eventName = DeleteNetworkAclEntry) || ($.eventName = ReplaceNetworkAclEntry) || ($.eventName = ReplaceNetworkAclAssociation) } + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.11-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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 --evaluationperiods 1 --namespace 'CISBenchmark' --alarm-actions +``` diff --git a/cis_v150/docs/cis_v150_4_12.md b/cis_v150/docs/cis_v150_4_12.md new file mode 100644 index 00000000..7c569ad6 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_12.md @@ -0,0 +1,82 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + { ($.eventName = CreateCustomerGateway) || ($.eventName = DeleteCustomerGateway) || ($.eventName = AttachInternetGateway) || ($.eventName = CreateInternetGateway) || ($.eventName = DeleteInternetGateway) || ($.eventName = DetachInternetGateway) } + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.12-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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 --evaluationperiods 1 --namespace 'CISBenchmark' --alarm-actions +``` diff --git a/cis_v150/docs/cis_v150_4_13.md b/cis_v150/docs/cis_v150_4_13.md new file mode 100644 index 00000000..345d8760 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_13.md @@ -0,0 +1,82 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + { ($.eventName = CreateRoute) || ($.eventName = CreateRouteTable) || ($.eventName = ReplaceRoute) || ($.eventName = ReplaceRouteTableAssociation) || ($.eventName = DeleteRouteTable) || ($.eventName = DeleteRoute) || ($.eventName = DisassociateRouteTable) }" + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.13-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_14.md b/cis_v150/docs/cis_v150_4_14.md new file mode 100644 index 00000000..2f7d0f2d --- /dev/null +++ b/cis_v150/docs/cis_v150_4_14.md @@ -0,0 +1,82 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + { ($.eventName = CreateVpc) || ($.eventName = DeleteVpc) || ($.eventName = ModifyVpcAttribute) || ($.eventName = AcceptVpcPeeringConnection) || ($.eventName = CreateVpcPeeringConnection) || ($.eventName = DeleteVpcPeeringConnection) || ($.eventName = RejectVpcPeeringConnection) || ($.eventName = AttachClassicLinkVpc) || ($.eventName = DetachClassicLinkVpc) || ($.eventName = DisableVpcClassicLink) || ($.eventName = EnableVpcClassicLink) } + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.14-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_15.md b/cis_v150/docs/cis_v150_4_15.md new file mode 100644 index 00000000..76f29667 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_15.md @@ -0,0 +1,82 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs and establishing corresponding metric filters and alarms. It is recommended that a metric filter and alarm be established for AWS Organizations changes made in the master AWS Account. + +Monitoring AWS Organizations changes can help you prevent any unwanted, accidental or intentional modifications that may lead to unauthorized access or other security breaches. This monitoring technique helps you to ensure that any unexpected changes performed within your AWS Organizations can be investigated and any unwanted changes can be rolled back. + +## Remediation + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + { ($.eventSource = organizations.amazonaws.com) && (($.eventName = "AcceptHandshake") || ($.eventName = "AttachPolicy") || ($.eventName = "CreateAccount") || ($.eventName = "CreateOrganizationalUnit") || ($.eventName = "CreatePolicy") || ($.eventName = "DeclineHandshake") || ($.eventName = "DeleteOrganization") || ($.eventName = "DeleteOrganizationalUnit") || ($.eventName = "DeletePolicy") || ($.eventName = "DetachPolicy") || ($.eventName = "DisablePolicyType") || ($.eventName = "EnablePolicyType") || ($.eventName = "InviteAccountToOrganization") || ($.eventName = "LeaveOrganization") || ($.eventName = "MoveAccount") || ($.eventName = "RemoveAccountFromOrganization") || ($.eventName = "UpdatePolicy") || ($.eventName = "UpdateOrganizationalUnit")) } + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.15-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```bash +aws logs put-metric-filter --log-group-name --filter-name `` --metric-transformations metricName=`` ,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventSource = organizations.amazonaws.com) && (($.eventName = "AcceptHandshake") || ($.eventName = "AttachPolicy") || ($.eventName = "CreateAccount") || ($.eventName = "CreateOrganizationalUnit") || ($.eventName = "CreatePolicy") || ($.eventName = "DeclineHandshake") || ($.eventName = "DeleteOrganization") || ($.eventName = "DeleteOrganizationalUnit") || ($.eventName = "DeletePolicy") || ($.eventName = "DetachPolicy") || ($.eventName = "DisablePolicyType") || ($.eventName = "EnablePolicyType") || ($.eventName ="InviteAccountToOrganization") || ($.eventName = "LeaveOrganization") || ($.eventName = "MoveAccount") || ($.eventName = "RemoveAccountFromOrganization") || ($.eventName = "UpdatePolicy") || ($.eventName = "UpdateOrganizationalUnit")) }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +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. + +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_v150/docs/cis_v150_4_16.md b/cis_v150/docs/cis_v150_4_16.md new file mode 100644 index 00000000..e269de33 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_16.md @@ -0,0 +1,30 @@ +## Description + +Security Hub collects security data from across AWS accounts, services, and supported third-party partner products and helps you analyze your security trends and identify the highest priority security issues. When you enable Security Hub, it begins to consume, aggregate, organize, and prioritize findings from AWS services that you have enabled, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie. You can also enable integrations with AWS partner security products. + +AWS Security Hub provides you with a comprehensive view of your security state in AWS and helps you check your environment against security industry standards and best practices - enabling you to quickly assess the security posture across your AWS accounts. + +## Remediation + +To grant the permissions required to enable Security Hub, attach the Security Hub managed policy AWSSecurityHubFullAccess to an IAM user, group, or role. Enabling Security Hub + +### From Console + +1. Use the credentials of the IAM identity to sign in to the Security Hub console. +2. When you open the Security Hub console for the first time, choose Enable AWS Security Hub. +3. On the welcome page, Security standards list the security standards that Security Hub supports. +4. Choose Enable Security Hub. + +### From Command Line + +1. Run the enable-security-hub command. To enable the default standards, include **--enable-default-standards**. + +```bash +aws securityhub enable-security-hub --enable-default-standards +``` + +2. To enable the security hub without the default standards, include **--no-enable-default-standards**. + +```bash +aws securityhub enable-security-hub --no-enable-default-standards +``` diff --git a/cis_v150/docs/cis_v150_4_2.md b/cis_v150/docs/cis_v150_4_2.md new file mode 100644 index 00000000..299935df --- /dev/null +++ b/cis_v150/docs/cis_v150_4_2.md @@ -0,0 +1,85 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + + ``` + {($.eventName="ConsoleLogin") && ($.additionalEventData.MFAUsed !="Yes")} + ``` + + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.2-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_3.md b/cis_v150/docs/cis_v150_4_3.md new file mode 100644 index 00000000..964649e4 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_3.md @@ -0,0 +1,84 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + + ``` + { $.userIdentity.type = "Root" && $.userIdentity.invokedByNOT EXISTS && $.eventType != "AwsServiceEvent" } + ``` + + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.3-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```bash +aws logs put-metric-filter --log-group-name `` --filter-name `` --metric-transformations metricName=`` ,metricNamespace='CISBenchmark',metricValue=1 --filterpattern '{ $.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. + +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_v150/docs/cis_v150_4_4.md b/cis_v150/docs/cis_v150_4_4.md new file mode 100644 index 00000000..7c5b1c32 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_4.md @@ -0,0 +1,85 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + + ``` + {($.eventName=DeleteGroupPolicy) || ($.eventName=DeleteRolePolicy) || ($.eventName=DeleteUserPolicy) || ($.eventName=PutGroupPolicy) || ($.eventName=PutRolePolicy) || ($.eventName=PutUserPolicy) || ($.eventName=CreatePolicy) || ($.eventName=DeletePolicy) || ($.eventName=CreatePolicyVersion) || ($.eventName=DeletePolicyVersion) || ($.eventName=AttachRolePolicy) || ($.eventName=DetachRolePolicy) || ($.eventName=AttachUserPolicy) || ($.eventName=DetachUserPolicy) || ($.eventName=AttachGroupPolicy) || ($.eventName=DetachGroupPolicy)} + ``` + + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.4-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```bash +aws logs put-metric-filter --log-group-name `` --filter-name `` --metric-transformations metricName=`` ,metricNamespace='CISBenchmark',metricValue=1 -- +filter-pattern'{($.eventName=DeleteGroupPolicy)||($.eventName=DeleteRolePolicy)||($.eventName=DeleteUserPolicy)||($.eventName=PutGroupPolicy)||($.eventName=PutRolePolicy)||($.eventName=PutUserPolicy)||($.eventName=CreatePolicy)||($.eventName=DeletePolicy)||($.eventName=CreatePolicyVersion)||($.eventName=DeletePolicyVersion)||($.eventName=AttachRolePolicy)||($.eventName=DetachRolePolicy)||($.eventName=AttachUserPolicy)||($.eventName=DetachUserPolicy)||($.eventName=AttachGroupPolicy)||($.eventName=DetachGroupPolicy)}' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +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. + +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_v150/docs/cis_v150_4_5.md b/cis_v150/docs/cis_v150_4_5.md new file mode 100644 index 00000000..110219c1 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_5.md @@ -0,0 +1,82 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + {($.eventName=CreateTrail) || ($.eventName=UpdateTrail) || ($.eventName=DeleteTrail) || ($.eventName=StartLogging) || ($.eventName=StopLogging)} + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.5-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_6.md b/cis_v150/docs/cis_v150_4_6.md new file mode 100644 index 00000000..c1648089 --- /dev/null +++ b/cis_v150/docs/cis_v150_4_6.md @@ -0,0 +1,82 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + {($.eventName=ConsoleLogin) && ($.errorMessage="Failed authentication")} + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.6-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_7.md b/cis_v150/docs/cis_v150_4_7.md new file mode 100644 index 00000000..646062bb --- /dev/null +++ b/cis_v150/docs/cis_v150_4_7.md @@ -0,0 +1,82 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + {($.eventSource = kms.amazonaws.com) && (($.eventName=DisableKey)||($.eventName=ScheduleKeyDeletion))} + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.7-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_8.md b/cis_v150/docs/cis_v150_4_8.md new file mode 100644 index 00000000..9383664d --- /dev/null +++ b/cis_v150/docs/cis_v150_4_8.md @@ -0,0 +1,82 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + { ($.eventSource = s3.amazonaws.com) && (($.eventName = PutBucketAcl) || ($.eventName = PutBucketPolicy) || ($.eventName = PutBucketCors) || ($.eventName = PutBucketLifecycle) || ($.eventName = PutBucketReplication) || ($.eventName = DeleteBucketPolicy) || ($.eventName = DeleteBucketCors) || ($.eventName = DeleteBucketLifecycle) || ($.eventName = DeleteBucketReplication)) } + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.8-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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. + +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_v150/docs/cis_v150_4_9.md b/cis_v150/docs/cis_v150_4_9.md new file mode 100644 index 00000000..c01cc94a --- /dev/null +++ b/cis_v150/docs/cis_v150_4_9.md @@ -0,0 +1,83 @@ +## 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 + +The steps to remediate this issue include setting up an Amazon SNS topic, a metric filter, and an alarm for the metric filter. + +### From Console + +**To create SNS topic** + +1. Open the Amazon SNS console at [SNS](https://console.aws.amazon.com/sns/v3/home). +2. Create an Amazon SNS topic that receives all CIS alarms. Create at least one subscriber to the topic. You can follow steps [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) +3. Set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in CIS 3.1 โ€“ Ensure CloudTrail is enabled in all Regions. +4. Make a note of the associated log group name. + +**To create a metric filter and alarm** + +1. Open the CloudWatch console at [CloudWatch](https://console.aws.amazon.com/cloudwatch/). +2. In the navigation pane, choose **Log groups**. +3. Select the check box for the log group that you made a note of in the previous step (4). +4. From **Actions**, choose **Create Metric Filter**. +5. Under Define pattern, do the following: + - Copy the following pattern and then paste it into the Filter Pattern field. + ``` + { ($.eventSource = config.amazonaws.com) && (($.eventName=StopConfigurationRecorder)||($.eventName=DeleteDeliveryChannel) ||($.eventName=PutDeliveryChannel)||($.eventName=PutConfigurationRecorder))} + ``` + - Choose **Next**. +6. Under **Assign metric**, do the following: + - In Filter name, enter a name for your metric filter. + - For Metric namespace, enter `CISBenchmark`. You can use the same namespace for all of your CIS log metric filters. + - For Metric name, enter a name for the metric. + - The name of the metric is required to create the alarm. + - For Metric value, enter 1. + - Choose **Next**. +7. Under **Review and create**, review the details and choose **Create metric filter**. +8. Choose the **Metric filters** tab, select the metric filter that you just created. +9. To choose the metric filter, select the `check box` at the upper right. +10. Choose **Create Alarm**. +11. Follow the steps provided in [Create an alarm](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) +12. Under Configure actions, do the following: + - Under **Alarm state trigger**, choose In alarm. + - Under Select an SNS topic, choose Select an existing SNS topic. + - For Send a notification to, enter the name of the SNS topic that you created in the previous procedure. + - Choose **Next**. +13. Under Add name and description, enter a Name and Description for the alarm. For example, CIS4.9-[SmallDescription]. Then choose **Next**. +14. Under **Preview and create**, review the alarm configuration. Choose **Create alarm**. + +### From Command Line + +Perform the following to setup the metric filter, alarm, SNS topic, and subscription + +1. Create a metric filter based on filter pattern provided and CloudWatch log group. + +```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 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. + +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 --evaluationperiods 1 --namespace 'CISBenchmark' --alarm-actions +``` diff --git a/cis_v150/docs/cis_v150_5.md b/cis_v150/docs/cis_v150_5.md new file mode 100644 index 00000000..5c0cf133 --- /dev/null +++ b/cis_v150/docs/cis_v150_5.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring security-related aspects of AWS Virtual Private Cloud (VPC). diff --git a/cis_v150/docs/cis_v150_5_1.md b/cis_v150/docs/cis_v150_5_1.md new file mode 100644 index 00000000..1a6e3a97 --- /dev/null +++ b/cis_v150/docs/cis_v150_5_1.md @@ -0,0 +1,21 @@ +## Description + +The Network Access Control List (NACL) function provide stateless filtering of ingress and egress network traffic to AWS resources. It is recommended that no NACL allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 +and RDP to port 3389. + +Public access to remote server administration ports, such as 22 and 3389, increases resource attack surface and unnecessarily raises the risk of resource compromise. + +## Remediation + +### From Console + +1. Login VPC Console at [VPC](https://console.aws.amazon.com/vpc/home) +2. In the left pane, click **Network ACLs** +3. For each network ACL to remediate, perform the following: +4. Select the respective network ACL +5. Choose the **Inbound Rules** tab and click **Edit Inbound rules** +6. Check remote server access port entries. **Note** A Port value of ALL or a port range such as 0-1024 are inclusive of port 22, 3389, and other remote server administration ports. +7. Either + - A) Update the `source` field to a range other than 0.0.0.0/0 or + - B) Click **Remove** the offending inbound rule +8. Click **Save changes** diff --git a/cis_v150/docs/cis_v150_5_2.md b/cis_v150/docs/cis_v150_5_2.md new file mode 100644 index 00000000..6cf43dbc --- /dev/null +++ b/cis_v150/docs/cis_v150_5_2.md @@ -0,0 +1,20 @@ +## Description + +Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389. + +Public access to remote server administration ports, such as 22 and 3389, increases resource attack surface and unnecessarily raises the risk of resource compromise. + +## Remediation + +### From Console + +1. Login VPC Console at [VPC](https://console.aws.amazon.com/vpc/home) +2. In the left pane, click **Security Groups** +3. For each security group to remediate, perform the following: +4. Select the respective security group +5. Choose the **Inbound Rules** tab and click **Edit Inbound rules** +6. Identify the rules to be edited or removed bas on the remote server access port entries. **Note** A Port value of ALL or a port range such as 0-1024 are inclusive of port 22, 3389, and other remote server administration ports. +7. Either + - A) Update the `source` field to a range other than 0.0.0.0/0 or + - B) Click **Remove** the offending inbound rule +8. Click **Save changes** diff --git a/cis_v150/docs/cis_v150_5_3.md b/cis_v150/docs/cis_v150_5_3.md new file mode 100644 index 00000000..65655ddd --- /dev/null +++ b/cis_v150/docs/cis_v150_5_3.md @@ -0,0 +1,19 @@ +## Description + +Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389. + +Public access to remote server administration ports, such as 22 and 3389, increases resource attack surface and unnecessarily raises the risk of resource compromise. + +## Remediation + +Perform the following to implement the prescribed state: + +1. Login to the AWS Management Console at 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. Click the **Edit inbound rules** button +7. Identify the rules to be edited or removed +8. Either A) update the `source` field to a range other than ::/0, or, B) Click **Delete** to remove the offending inbound rule +9. Click **Save rules** diff --git a/cis_v150/docs/cis_v150_5_4.md b/cis_v150/docs/cis_v150_5_4.md new file mode 100644 index 00000000..e3700cf8 --- /dev/null +++ b/cis_v150/docs/cis_v150_5_4.md @@ -0,0 +1,26 @@ +## 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. + +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. + +### From Console + +1. Login to the AWS [VPC 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. For each default security group, choose the `Inbound rules` tab and delete all inbound rules. +7. For each default security group, choose the `Outbound rules` tab and delete all outbound rules. +8. Create a set of least-privilege security groups for the resources. See [here](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups) for more details. diff --git a/cis_v150/docs/cis_v150_5_5.md b/cis_v150/docs/cis_v150_5_5.md new file mode 100644 index 00000000..e3773ccf --- /dev/null +++ b/cis_v150/docs/cis_v150_5_5.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. + +### From Command Line + +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-cidrblock +``` + +2. Create a new compliant route: + +```bash +aws ec2 create-route --route-table-id --destination-cidrblock --vpc-peering-connection-id +``` diff --git a/cis_v150/section_1.sp b/cis_v150/section_1.sp new file mode 100644 index 00000000..c5ebabbe --- /dev/null +++ b/cis_v150/section_1.sp @@ -0,0 +1,331 @@ +locals { + cis_v150_1_common_tags = merge(local.cis_v150_common_tags, { + cis_section_id = "1" + }) +} + +benchmark "cis_v150_1" { + title = "1 Identity and Access Management" + documentation = file("./cis_v150/docs/cis_v150_1.md") + children = [ + control.cis_v150_1_1, + control.cis_v150_1_2, + control.cis_v150_1_3, + control.cis_v150_1_4, + control.cis_v150_1_5, + control.cis_v150_1_6, + control.cis_v150_1_7, + control.cis_v150_1_8, + control.cis_v150_1_9, + control.cis_v150_1_10, + control.cis_v150_1_11, + control.cis_v150_1_12, + control.cis_v150_1_13, + control.cis_v150_1_14, + control.cis_v150_1_15, + control.cis_v150_1_16, + control.cis_v150_1_17, + control.cis_v150_1_18, + control.cis_v150_1_19, + control.cis_v150_1_20, + control.cis_v150_1_21 + ] + + tags = merge(local.cis_v150_1_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v150_1_1" { + title = "1.1 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." + sql = query.manual_control.sql + documentation = file("./cis_v150/docs/cis_v150_1_1.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.1" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_2" { + title = "1.2 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." + sql = query.manual_control.sql + documentation = file("./cis_v150/docs/cis_v150_1_2.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.2" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_3" { + title = "1.3 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." + sql = query.manual_control.sql + documentation = file("./cis_v150/docs/cis_v150_1_3.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.3" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_4" { + title = "1.4 Ensure no 'root' user account access key exists" + description = "The 'root' user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the 'root' user account be removed." + sql = query.iam_root_user_no_access_keys.sql + documentation = file("./cis_v150/docs/cis_v150_1_4.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.4" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_5" { + title = "1.5 Ensure MFA is enabled for the 'root' user account" + description = "The 'root' user account is the most privileged user in an AWS account. Multi-factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device." + sql = query.iam_root_user_mfa_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_1_5.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.5" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_6" { + title = "1.6 Ensure hardware MFA is enabled for the 'root' user account" + description = "The 'root' user account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their user name and password as well as for an authentication code from their AWS MFA device. For Level 2, it is recommended that the root user account be protected with a hardware MFA." + sql = query.iam_root_user_hardware_mfa_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_1_6.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.6" + cis_level = "2" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_7" { + title = "1.7 Eliminate use of the 'root' user for administrative and daily tasks" + description = "With the creation of an AWS account, a 'root user' is created that cannot be disabled or deleted. That user has unrestricted access to and control over all resources in the AWS account. It is highly recommended that the use of this account be avoided for everyday tasks." + sql = query.iam_root_last_used.sql + documentation = file("./cis_v150/docs/cis_v150_1_7.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.7" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_8" { + title = "1.8 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." + sql = query.iam_account_password_policy_min_length_14.sql + documentation = file("./cis_v150/docs/cis_v150_1_8.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.8" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_9" { + title = "1.9 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." + sql = query.iam_account_password_policy_reuse_24.sql + documentation = file("./cis_v150/docs/cis_v150_1_9.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.9" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_10" { + title = "1.10 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 authentication assurance beyond traditional credentials. With MFA enabled, when a user signs in to the AWS Console, they will be prompted for their user name and password as well as for an authentication code from their physical or virtual MFA token. It is recommended that MFA be enabled for all accounts that have a console password." + sql = query.iam_user_console_access_mfa_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_1_10.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.10" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_11" { + title = "1.11 Do not setup access keys during initial user setup for all IAM users that have a console password" + description = "AWS console defaults to no check boxes selected when creating a new IAM user. When creating the IAM User credentials you have to determine what type of access they require." + sql = query.iam_user_access_keys_and_password_at_setup.sql + documentation = file("./cis_v150/docs/cis_v150_1_11.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.11" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_12" { + title = "1.12 Ensure credentials unused for 45 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 45 or greater days be deactivated or removed." + sql = query.iam_user_unused_credentials_45.sql + documentation = file("./cis_v150/docs/cis_v150_1_12.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.12" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_13" { + title = "1.13 Ensure there is only one active access key available for any single IAM user" + description = "Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK)." + sql = query.iam_user_one_active_key.sql + documentation = file("./cis_v150/docs/cis_v150_1_13.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.13" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_14" { + title = "1.14 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." + sql = query.iam_user_access_key_age_90.sql + documentation = file("./cis_v150/docs/cis_v150_1_14.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.14" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_15" { + title = "1.15 Ensure IAM Users Receive Permissions Only Through Groups" + description = "IAM users are granted access to services, functions, and data through IAM policies. There are three ways to define policies for a user: 1) Edit the user policy directly, aka an inline, or user, policy; 2) attach a policy directly to a user; 3) add the user to an IAM group that has an attached policy. Only the third implementation is recommended." + sql = query.iam_user_no_inline_attached_policies.sql + documentation = file("./cis_v150/docs/cis_v150_1_15.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.15" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_16" { + title = "1.16 Ensure IAM policies that allow full \"*:*\" administrative privileges are not attached" + 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." + sql = query.iam_policy_all_attached_no_star_star.sql + documentation = file("./cis_v150/docs/cis_v150_1_16.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.16" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_17" { + title = "1.17 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." + sql = query.iam_support_role.sql + documentation = file("./cis_v150/docs/cis_v150_1_17.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.17" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_18" { + title = "1.18 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." + sql = query.manual_control.sql + documentation = file("./cis_v150/docs/cis_v150_1_18.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.18" + cis_level = "2" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_19" { + title = "1.19 Ensure that all the expired SSL/TLS certificates stored in AWS IAM are removed" + description = "To enable HTTPS connections to your website or application in AWS, you need an SSL/TLS server certificate. You can use ACM or IAM to store and deploy server certificates. Use IAM as a certificate manager only when you must support HTTPS connections in a region that is not supported by ACM. IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage. IAM supports deploying server certificates in all regions, but you must obtain your certificate from an external provider for use with AWS. You cannot upload an ACM certificate to IAM. Additionally, you cannot manage your certificates from the IAM Console." + sql = query.iam_server_certificate_not_expired.sql + documentation = file("./cis_v150/docs/cis_v150_1_19.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.19" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_20" { + title = "1.20 Ensure that IAM Access analyzer is enabled for all regions" + description = "Enable IAM Access analyzer for IAM policies about all resources in each region. IAM Access Analyzer is a technology introduced at AWS reinvent 2019. After the Analyzer is enabled in IAM, scan results are displayed on the console showing the accessible resources. Scans show resources that other accounts and federated users can access, such as KMS keys and IAM roles. So the results allow you to determine if an unintended user is allowed, making it easier for administrators to monitor least privileges access. Access Analyzer analyzes only policies that are applied to resources in the same AWS Region." + sql = query.iam_access_analyzer_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_1_20.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.20" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v150_1_21" { + title = "1.21 Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments" + description = "In multi-account environments, IAM user centralization facilitates greater user control. User access beyond the initial account is then provide via role assumption. Centralization of users can be accomplished through federation with an external identity provider or through the use of AWS Organizations." + sql = query.manual_control.sql + documentation = file("./cis_v150/docs/cis_v150_1_21.md") + + tags = merge(local.cis_v150_1_common_tags, { + cis_item_id = "1.21" + cis_level = "2" + cis_type = "manual" + service = "AWS/IAM" + }) +} diff --git a/cis_v150/section_2.sp b/cis_v150/section_2.sp new file mode 100644 index 00000000..84b39349 --- /dev/null +++ b/cis_v150/section_2.sp @@ -0,0 +1,233 @@ +locals { + cis_v150_2_common_tags = merge(local.cis_v150_common_tags, { + cis_section_id = "2" + }) +} + +locals { + cis_v150_2_1_common_tags = merge(local.cis_v150_2_common_tags, { + cis_section_id = "2.1" + }) + cis_v150_2_2_common_tags = merge(local.cis_v150_2_common_tags, { + cis_section_id = "2.2" + }) + cis_v150_2_3_common_tags = merge(local.cis_v150_2_common_tags, { + cis_section_id = "2.3" + }) + cis_v150_2_4_common_tags = merge(local.cis_v150_2_common_tags, { + cis_section_id = "2.4" + }) +} + +benchmark "cis_v150_2" { + title = "2 Storage" + documentation = file("./cis_v150/docs/cis_v150_2.md") + children = [ + benchmark.cis_v150_2_1, + benchmark.cis_v150_2_2, + benchmark.cis_v150_2_3, + benchmark.cis_v150_2_4 + ] + + tags = merge(local.cis_v150_2_common_tags, { + type = "Benchmark" + }) +} + +benchmark "cis_v150_2_1" { + title = "2.1 Simple Storage Service (S3)" + documentation = file("./cis_v150/docs/cis_v150_2_1.md") + children = [ + control.cis_v150_2_1_1, + control.cis_v150_2_1_2, + control.cis_v150_2_1_3, + control.cis_v150_2_1_4, + control.cis_v150_2_1_5 + ] + + tags = merge(local.cis_v150_2_1_common_tags, { + service = "AWS/S3" + type = "Benchmark" + }) +} + +control "cis_v150_2_1_1" { + title = "2.1.1 Ensure all S3 buckets employ encryption-at-rest" + description = "Amazon S3 provides a variety of no, or low, cost encryption options to protect data at rest." + documentation = file("./cis_v150/docs/cis_v150_2_1_1.md") + sql = query.s3_bucket_default_encryption_enabled.sql + + tags = merge(local.cis_v150_2_1_common_tags, { + cis_item_id = "2.1.1" + cis_level = "2" + cis_type = "automated" + service = "AWS/S3" + }) +} + +control "cis_v150_2_1_2" { + title = "2.1.2 Ensure S3 Bucket Policy is set to deny HTTP requests" + description = "At the Amazon S3 bucket level, you can configure permissions through a bucket policy making the objects accessible only through HTTPS." + documentation = file("./cis_v150/docs/cis_v150_2_1_2.md") + sql = query.s3_bucket_enforces_ssl.sql + + tags = merge(local.cis_v150_2_1_common_tags, { + cis_item_id = "2.1.2" + cis_level = "2" + cis_type = "automated" + service = "AWS/S3" + }) +} + +control "cis_v150_2_1_3" { + title = "2.1.3 Ensure MFA Delete is enabled on S3 buckets" + description = "Once MFA Delete is enabled on your sensitive and classified S3 bucket it requires the user to have two forms of authentication." + documentation = file("./cis_v150/docs/cis_v150_2_1_3.md") + sql = query.s3_bucket_mfa_delete_enabled.sql + + tags = merge(local.cis_v150_2_1_common_tags, { + cis_item_id = "2.1.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/S3" + }) +} + +control "cis_v150_2_1_4" { + title = "2.1.4 Ensure all data in Amazon S3 has been discovered, classified and secured when required" + description = "Amazon S3 buckets can contain sensitive data, that for security purposes should be discovered, monitored, classified and protected. Macie along with other 3rd party tools can automatically provide an inventory of Amazon S3 buckets." + documentation = file("./cis_v150/docs/cis_v150_2_1_4.md") + sql = query.manual_control.sql + + tags = merge(local.cis_v150_2_1_common_tags, { + cis_item_id = "2.1.4" + cis_level = "2" + cis_type = "manual" + service = "AWS/S3" + }) +} + +control "cis_v150_2_1_5" { + title = "2.1.5 Ensure that S3 Buckets are configured with 'Block public access (bucket settings)'" + description = "Amazon S3 provides Block public access (bucket settings) and Block public access (account settings) to help you manage public access to Amazon S3 resources. By default, S3 buckets and objects are created with public access disabled. However, an IAM principle with sufficient S3 permissions can enable public access at the bucket and/or object level. While enabled, Block public access (bucket settings) prevents an individual bucket, and its contained objects, from becoming publicly accessible. Similarly, Block public access (account settings) prevents all buckets, and contained objects, from becoming publicly accessible across the entire account." + documentation = file("./cis_v150/docs/cis_v150_2_1_5.md") + sql = query.s3_public_access_block_bucket_account.sql + + tags = merge(local.cis_v150_2_1_common_tags, { + cis_item_id = "2.1.5" + cis_level = "1" + cis_type = "automated" + service = "AWS/S3" + }) +} + +benchmark "cis_v150_2_2" { + title = "2.2 Elastic Compute Cloud (EC2)" + documentation = file("./cis_v150/docs/cis_v150_2_2.md") + children = [ + control.cis_v150_2_2_1 + ] + + tags = merge(local.cis_v150_2_2_common_tags, { + service = "AWS/EBS" + type = "Benchmark" + }) +} + +control "cis_v150_2_2_1" { + title = "2.2.1 Ensure EBS Volume Encryption is Enabled in all Regions" + description = "Elastic Compute Cloud (EC2) supports encryption at rest when using the Elastic Block Store (EBS) service. While disabled by default, forcing encryption at EBS volume creation is supported." + documentation = file("./cis_v150/docs/cis_v150_2_2_1.md") + sql = query.ebs_volume_encryption_at_rest_enabled.sql + + tags = merge(local.cis_v150_2_2_common_tags, { + cis_item_id = "2.2.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/EBS" + }) +} + +benchmark "cis_v150_2_3" { + title = "2.3 Relational Database Service (RDS)" + documentation = file("./cis_v150/docs/cis_v150_2_3.md") + children = [ + control.cis_v150_2_3_1, + control.cis_v150_2_3_2, + control.cis_v150_2_3_3 + ] + + tags = merge(local.cis_v150_2_3_common_tags, { + service = "AWS/RDS" + type = "Benchmark" + }) +} + +control "cis_v150_2_3_1" { + title = "2.3.1 Ensure that encryption is enabled for RDS Instances" + description = "Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. After your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance." + documentation = file("./cis_v150/docs/cis_v150_2_3_1.md") + sql = query.rds_db_instance_encryption_at_rest_enabled.sql + + tags = merge(local.cis_v150_2_3_common_tags, { + cis_item_id = "2.3.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/RDS" + }) +} + +control "cis_v150_2_3_2" { + title = "2.3.2 Ensure Auto Minor Version Upgrade feature is Enabled for RDS Instances" + description = "Ensure that RDS database instances have the Auto Minor Version Upgrade flag enabled in order to receive automatically minor engine upgrades during the specified maintenance window. So, RDS instances can get the new features, bug fixes, and security patches for their database engines." + documentation = file("./cis_v150/docs/cis_v150_2_3_2.md") + sql = query.rds_db_instance_automatic_minor_version_upgrade_enabled.sql + + tags = merge(local.cis_v150_2_3_common_tags, { + cis_item_id = "2.3.2" + cis_level = "1" + cis_type = "automated" + service = "AWS/RDS" + }) +} + +control "cis_v150_2_3_3" { + title = "2.3.3 Ensure that public access is not given to RDS Instance" + description = "Ensure and verify that RDS database instances provisioned in your AWS account do restrict unauthorized access in order to minimize security risks. To restrict access to any publicly accessible RDS database instance, you must disable the database Publicly Accessible flag and update the VPC security group associated with the instance." + documentation = file("./cis_v150/docs/cis_v150_2_3_3.md") + sql = query.rds_db_instance_prohibit_public_access.sql + + tags = merge(local.cis_v150_2_3_common_tags, { + cis_item_id = "2.3.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/RDS" + }) +} + +benchmark "cis_v150_2_4" { + title = "2.4 Elastic File System (EFS)" + documentation = file("./cis_v150/docs/cis_v150_2_4.md") + children = [ + control.cis_v150_2_4_1 + ] + + tags = merge(local.cis_v150_2_4_common_tags, { + service = "AWS/EFS" + type = "Benchmark" + }) +} + +control "cis_v150_2_4_1" { + title = "2.4.1 Ensure that encryption is enabled for EFS file systems" + description = "EFS data should be encrypted at rest using AWS KMS (Key Management Service)." + documentation = file("./cis_v150/docs/cis_v150_2_4_1.md") + sql = query.efs_file_system_encrypt_data_at_rest.sql + + tags = merge(local.cis_v150_2_4_common_tags, { + cis_item_id = "2.4.1" + cis_level = "1" + cis_type = "manual" + service = "AWS/EFS" + }) +} diff --git a/cis_v150/section_3.sp b/cis_v150/section_3.sp new file mode 100644 index 00000000..668b1f3c --- /dev/null +++ b/cis_v150/section_3.sp @@ -0,0 +1,181 @@ +locals { + cis_v150_3_common_tags = merge(local.cis_v150_common_tags, { + cis_section_id = "3" + }) +} + +benchmark "cis_v150_3" { + title = "3 Logging" + documentation = file("./cis_v150/docs/cis_v150_3.md") + children = [ + control.cis_v150_3_1, + control.cis_v150_3_2, + control.cis_v150_3_3, + control.cis_v150_3_4, + control.cis_v150_3_5, + control.cis_v150_3_6, + control.cis_v150_3_7, + control.cis_v150_3_8, + control.cis_v150_3_9, + control.cis_v150_3_10, + control.cis_v150_3_11 + ] + + tags = merge(local.cis_v150_3_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v150_3_1" { + title = "3.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)." + sql = query.cloudtrail_multi_region_read_write_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_3_1.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v150_3_2" { + title = "3.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." + sql = query.cloudtrail_trail_validation_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_3_2.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.2" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v150_3_3" { + title = "3.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 prevent public access to the CloudTrail logs." + sql = query.cloudtrail_bucket_not_public.sql + documentation = file("./cis_v150/docs/cis_v150_3_3.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v150_3_4" { + title = "3.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." + sql = query.cloudtrail_trail_integrated_with_logs.sql + documentation = file("./cis_v150/docs/cis_v150_3_4.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.4" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v150_3_5" { + title = "3.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 AWS Config be enabled in all regions." + sql = query.config_enabled_all_regions.sql + documentation = file("./cis_v150/docs/cis_v150_3_5.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.5" + cis_level = "2" + cis_type = "automated" + service = "AWS/Config" + }) +} + +control "cis_v150_3_6" { + title = "3.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." + sql = query.cloudtrail_s3_logging_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_3_6.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.6" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v150_3_7" { + title = "3.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." + sql = query.cloudtrail_trail_logs_encrypted_with_kms_cmk.sql + documentation = file("./cis_v150/docs/cis_v150_3_7.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.7" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v150_3_8" { + title = "3.8 Ensure rotation for customer created symmetric 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 for symmetric keys. Key rotation can not be enabled for any asymmetric CMK." + sql = query.kms_cmk_rotation_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_3_8.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.8" + cis_level = "2" + cis_type = "automated" + service = "AWS/KMS" + }) +} + +control "cis_v150_3_9" { + title = "3.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." + sql = query.vpc_flow_logs_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_3_9.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.9" + cis_level = "2" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v150_3_10" { + title = "3.10 Ensure that Object-level logging for write events is enabled for S3 bucket" + description = "S3 object-level API operations such as GetObject, DeleteObject, and PutObject are called data events. By default, CloudTrail trails don't log data events and so it is recommended to enable Object-level logging for S3 buckets." + sql = query.cloudtrail_s3_object_write_events_audit_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_3_10.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.10" + cis_level = "2" + cis_type = "automated" + service = "AWS/S3" + }) +} + +control "cis_v150_3_11" { + title = "3.11 Ensure that Object-level logging for read events is enabled for S3 bucket" + description = "S3 object-level API operations such as GetObject, DeleteObject, and PutObject are called data events. By default, CloudTrail trails don't log data events and so it is recommended to enable Object-level logging for S3 buckets." + sql = query.cloudtrail_s3_object_read_events_audit_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_3_11.md") + + tags = merge(local.cis_v150_3_common_tags, { + cis_item_id = "3.11" + cis_level = "2" + cis_type = "automated" + service = "AWS/S3" + }) +} diff --git a/cis_v150/section_4.sp b/cis_v150/section_4.sp new file mode 100644 index 00000000..04d2d07a --- /dev/null +++ b/cis_v150/section_4.sp @@ -0,0 +1,257 @@ +locals { + cis_v150_4_common_tags = merge(local.cis_v150_common_tags, { + cis_section_id = "4" + }) +} + +benchmark "cis_v150_4" { + title = "4 Monitoring" + documentation = file("./cis_v150/docs/cis_v150_4.md") + children = [ + control.cis_v150_4_1, + control.cis_v150_4_2, + control.cis_v150_4_3, + control.cis_v150_4_4, + control.cis_v150_4_5, + control.cis_v150_4_6, + control.cis_v150_4_7, + control.cis_v150_4_8, + control.cis_v150_4_9, + control.cis_v150_4_10, + control.cis_v150_4_11, + control.cis_v150_4_12, + control.cis_v150_4_13, + control.cis_v150_4_14, + control.cis_v150_4_15, + control.cis_v150_4_16 + ] + + tags = merge(local.cis_v150_4_common_tags, { + type = "Benchmark" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_1" { + title = "4.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." + sql = query.log_metric_filter_unauthorized_api.sql + documentation = file("./cis_v150/docs/cis_v150_4_1.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_2" { + title = "4.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)." + sql = query.log_metric_filter_console_login_mfa.sql + documentation = file("./cis_v150/docs/cis_v150_4_2.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.2" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_3" { + title = "4.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." + sql = query.log_metric_filter_root_login.sql + documentation = file("./cis_v150/docs/cis_v150_4_3.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_4" { + title = "4.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." + sql = query.log_metric_filter_iam_policy.sql + documentation = file("./cis_v150/docs/cis_v150_4_4.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.4" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_5" { + title = "4.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." + sql = query.log_metric_filter_cloudtrail_configuration.sql + documentation = file("./cis_v150/docs/cis_v150_4_5.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.5" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_6" { + title = "4.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." + sql = query.log_metric_filter_console_authentication_failure.sql + documentation = file("./cis_v150/docs/cis_v150_4_6.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.6" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_7" { + title = "4.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." + sql = query.log_metric_filter_disable_or_delete_cmk.sql + documentation = file("./cis_v150/docs/cis_v150_4_7.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.7" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_8" { + title = "4.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." + sql = query.log_metric_filter_bucket_policy.sql + documentation = file("./cis_v150/docs/cis_v150_4_8.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.8" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_9" { + title = "4.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." + sql = query.log_metric_filter_config_configuration.sql + documentation = file("./cis_v150/docs/cis_v150_4_9.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.9" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_10" { + title = "4.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 for detecting changes to Security Groups." + sql = query.log_metric_filter_security_group.sql + documentation = file("./cis_v150/docs/cis_v150_4_10.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.10" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_11" { + title = "4.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." + sql = query.log_metric_filter_network_acl.sql + documentation = file("./cis_v150/docs/cis_v150_4_11.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.11" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_12" { + title = "4.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." + sql = query.log_metric_filter_network_gateway.sql + documentation = file("./cis_v150/docs/cis_v150_4_12.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.12" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_13" { + title = "4.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." + sql = query.log_metric_filter_route_table.sql + documentation = file("./cis_v150/docs/cis_v150_4_13.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.13" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_14" { + title = "4.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." + sql = query.log_metric_filter_vpc.sql + documentation = file("./cis_v150/docs/cis_v150_4_14.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.14" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_15" { + title = "4.15 Ensure a log metric filter and alarm exists for AWS Organizations 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 AWS Organizations changes made in the master AWS Account." + sql = query.log_metric_filter_organization.sql + documentation = file("./cis_v150/docs/cis_v150_4_15.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.15" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudWatch" + }) +} + +control "cis_v150_4_16" { + title = "4.16 Ensure AWS Security Hub is enabled" + description = "Security Hub collects security data from across AWS accounts, services, and supported third-party partner products and helps you analyze your security trends and identify the highest priority security issues. When you enable Security Hub, it begins to consume, aggregate, organize, and prioritize findings from AWS services that you have enabled, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie. You can also enable integrations with AWS partner security products." + sql = query.securityhub_enabled.sql + documentation = file("./cis_v150/docs/cis_v150_4_16.md") + + tags = merge(local.cis_v150_4_common_tags, { + cis_item_id = "4.16" + cis_level = "2" + cis_type = "automated" + service = "AWS/SecurityHub" + }) +} diff --git a/cis_v150/section_5.sp b/cis_v150/section_5.sp new file mode 100644 index 00000000..e99eb73d --- /dev/null +++ b/cis_v150/section_5.sp @@ -0,0 +1,92 @@ +locals { + cis_v150_5_common_tags = merge(local.cis_v150_common_tags, { + cis_section_id = "5" + }) +} + +benchmark "cis_v150_5" { + title = "5 Networking" + documentation = file("./cis_v150/docs/cis_v150_5.md") + children = [ + control.cis_v150_5_1, + control.cis_v150_5_2, + control.cis_v150_5_3, + control.cis_v150_5_4, + control.cis_v150_5_5 + ] + + tags = merge(local.cis_v150_5_common_tags, { + service = "AWS/VPC" + type = "Benchmark" + }) +} + +control "cis_v150_5_1" { + title = "5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports" + description = "The Network Access Control List (NACL) function provide stateless filtering of ingress and egress network traffic to AWS resources. It is recommended that no NACL allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389." + sql = query.vpc_network_acl_remote_administration.sql + documentation = file("./cis_v150/docs/cis_v150_5_1.md") + + tags = merge(local.cis_v150_5_common_tags, { + cis_item_id = "5.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v150_5_2" { + title = "5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports" + description = "Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389." + sql = query.vpc_security_group_remote_administration_ipv4.sql + documentation = file("./cis_v150/docs/cis_v150_5_2.md") + + tags = merge(local.cis_v150_5_common_tags, { + cis_item_id = "5.2" + cis_level = "1" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v150_5_3" { + title = "5.3 Ensure no security groups allow ingress from ::/0 to remote server administration ports" + description = "Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389." + sql = query.vpc_security_group_remote_administration_ipv6.sql + documentation = file("./cis_v150/docs/cis_v150_5_3.md") + + tags = merge(local.cis_v150_5_common_tags, { + cis_item_id = "5.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v150_5_4" { + title = "5.4 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." + sql = query.vpc_default_security_group_restricts_all_traffic.sql + documentation = file("./cis_v150/docs/cis_v150_5_4.md") + + tags = merge(local.cis_v150_5_common_tags, { + cis_item_id = "5.4" + cis_level = "2" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v150_5_5" { + title = "5.5 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." + sql = query.manual_control.sql + documentation = file("./cis_v150/docs/cis_v150_5_5.md") + + tags = merge(local.cis_v150_5_common_tags, { + cis_item_id = "5.5" + cis_level = "2" + cis_type = "manual" + service = "AWS/VPC" + }) +} diff --git a/docs/index.md b/docs/index.md index e40788b7..86029b11 100644 --- a/docs/index.md +++ b/docs/index.md @@ -110,13 +110,13 @@ steampipe check all Run a single benchmark: ```sh -steampipe check benchmark.cis_v140 +steampipe check benchmark.cis_v150 ``` Run a specific control: ```sh -steampipe check control.cis_v140_2_1_1 +steampipe check control.cis_v150_2_1_1 ``` Different output formats are also available, for more information please see diff --git a/query/iam/iam_user_one_active_key.sql b/query/iam/iam_user_one_active_key.sql index ac4641bd..db759710 100644 --- a/query/iam/iam_user_one_active_key.sql +++ b/query/iam/iam_user_one_active_key.sql @@ -10,7 +10,7 @@ select -- Additional Dimensions u.account_id from aws_iam_user as u -left join aws_iam_access_key as k on u.name = k.user_name and u.account_id = u.account_id +left join aws_iam_access_key as k on u.name = k.user_name and u.account_id = k.account_id where k.status = 'Active' or k.status is null group by diff --git a/query/vpc/vpc_security_group_remote_administration_ipv4.sql b/query/vpc/vpc_security_group_remote_administration_ipv4.sql new file mode 100644 index 00000000..508d2336 --- /dev/null +++ b/query/vpc/vpc_security_group_remote_administration_ipv4.sql @@ -0,0 +1,44 @@ +with bad_rules as ( + select + group_id, + count(*) as num_bad_rules + from + aws_vpc_security_group_rule + where + type = 'ingress' + and ( + cidr_ipv4 = '0.0.0.0/0' + ) + and ( + ( ip_protocol = '-1' -- all traffic + and from_port is null + ) + or ( + from_port >= 22 + and to_port <= 22 + ) + or ( + from_port >= 3389 + and to_port <= 3389 + ) + ) + group by + group_id +) +select + -- Required Columns + arn as resource, + case + when bad_rules.group_id is null then 'ok' + else 'alarm' + end as status, + case + when bad_rules.group_id is null then sg.group_id || ' does not allow ingress to port 22 or 3389 from 0.0.0.0/0.' + else sg.group_id || ' contains ' || bad_rules.num_bad_rules || ' rule(s) that allow ingress to port 22 or 3389 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 bad_rules on bad_rules.group_id = sg.group_id diff --git a/query/vpc/vpc_security_group_remote_administration_ipv6.sql b/query/vpc/vpc_security_group_remote_administration_ipv6.sql new file mode 100644 index 00000000..5f776f81 --- /dev/null +++ b/query/vpc/vpc_security_group_remote_administration_ipv6.sql @@ -0,0 +1,44 @@ +with bad_rules as ( + select + group_id, + count(*) as num_bad_rules + from + aws_vpc_security_group_rule + where + type = 'ingress' + and ( + cidr_ipv6 = '::/0' + ) + and ( + ( ip_protocol = '-1' -- all traffic + and from_port is null + ) + or ( + from_port >= 22 + and to_port <= 22 + ) + or ( + from_port >= 3389 + and to_port <= 3389 + ) + ) + group by + group_id +) +select + -- Required Columns + arn as resource, + case + when bad_rules.group_id is null then 'ok' + else 'alarm' + end as status, + case + when bad_rules.group_id is null then sg.group_id || ' does not allow ingress to port 22 or 3389 from ::/0.' + else sg.group_id || ' contains ' || bad_rules.num_bad_rules || ' rule(s) that allow ingress to port 22 or 3389 from ::/0.' + end as reason, + -- Additional Dimensions + sg.region, + sg.account_id +from + aws_vpc_security_group as sg + left join bad_rules on bad_rules.group_id = sg.group_id