From 6a4114ea7c3bf23a3fdf7ee172da1eafc146538d Mon Sep 17 00:00:00 2001 From: Ana Krivokapic Date: Thu, 1 Apr 2021 16:30:02 +0200 Subject: [PATCH 1/2] Improve CIS upgrade guide - Reword sentences to make recommendation removals clearer - Fix broken GH links by pointing to specific git tags instead of master --- .../2021-01-06-how-to-update-to-cis-13.adoc | 25 +++++++++++-------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/_posts/2021-01-06-how-to-update-to-cis-13.adoc b/_posts/2021-01-06-how-to-update-to-cis-13.adoc index 0c0d780b2..1f6b77cc4 100644 --- a/_posts/2021-01-06-how-to-update-to-cis-13.adoc +++ b/_posts/2021-01-06-how-to-update-to-cis-13.adoc @@ -51,13 +51,16 @@ This guide consists of two main sections: Version 1.3.0 of the CIS AWS Foundations Benchmark was released in September of 2020. You can refer to the https://www.cisecurity.org/benchmark/amazon_web_services/[CIS website] where you can download the latest version of the -Benchmark (as well as all the previous versions). The latest version introduces several new recommendations. This guide -will walk you through implementing these using Gruntwork's Infrastructure as Code Library +Benchmark (as well as all the previous versions). The latest version introduces several new recommendations, and also +removes several recommendations. This guide will walk you through implementing these using Gruntwork's Infrastructure as Code Library so that your infrastructure is fully compliant with version 1.3.0 of the framework. -==== New recommendations -These are the new recommendations introduced in version 1.3.0 of the Benchmark. You can think of these as a "diff" -between versions 1.2.0 and 1.3.0: +==== Changes in recommendations +Changes in recommendations (both additions and removals) are listed below. You can think of these as a "diff" +between versions 1.2.0 and 1.3.0. + +===== New recommendations +These are the new recommendations introduced in version 1.3.0 of the Benchmark: - 1.19: Ensure that all the expired SSL/TLS certificates stored in AWS IAM are removed - 1.20: Ensure that S3 Buckets are configured with 'Block public access (bucket settings)' @@ -70,16 +73,16 @@ between versions 1.2.0 and 1.3.0: - 4.15: Ensure a log metric filter and alarm exists for AWS Organizations changes - 5.1: Ensure no network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports -==== Deleted recommendations +===== Deleted recommendations Version 1.3.0 removed some recommendations, but they only affect the IAM password policy: - 1.5: Ensure IAM password policy requires at least one uppercase letter -- 1.6: Ensure IAM password policy require at least one lowercase letter +- 1.6: Ensure IAM password policy require at least one lowercase letter - 1.7: Ensure IAM password policy require at least one symbol - 1.8: Ensure IAM password policy require at least one number ==== New Gruntwork modules vs. existing modules -To achieve compliance with the newly added 10 recommendations listed above, we created four new modules in the +To achieve compliance with the new version of the Framework, we created four new modules in the Gruntwork's Infrastructure as Code Library, and updated a bunch of existing modules. Namely: recommendations 1.19, 1.21, 2.2.1 and 5.1 required creating new modules; the rest of the recommendations were achieved by updating existing modules. @@ -175,7 +178,7 @@ on the AWS website for detailed instructions. The new CIS AWS v1.3 recommendations require that all expired SSL/TLS certificates stored in AWS IAM are automatically removed. 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. To help you -achieve this recommendation, check out the https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/master/examples/cleanup-expired-certs/terraform[example] of the ready-made `cleanup-expired-certs` module. +achieve this recommendation, check out the https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/v0.10.0/examples/cleanup-expired-certs/terraform[example] of the ready-made `cleanup-expired-certs` module. For the code examples of deploying this module, see the link:https://gruntwork.io/guides/compliance/how-to-achieve-cis-benchmark-compliance/#cleanup_expired_certs_deployment[relevant section] @@ -205,7 +208,7 @@ of our "How to achieve compliance with the CIS AWS Foundations Benchmark" guide. EC2 supports encryption at rest when using the Elastic Block Store (EBS) service. While disabled by default, forcing encryption when creating EBS volumes is supported. Encrypting data at rest reduces the likelihood that it is unintentionally exposed and can nullify the impact of disclosure if the encryption remains unbroken. Recommendation 2.2.1 specifies a manual process to encrypt EBS volumes using the AWS Console; however, Gruntwork has developed -a module that configures volume encryption by default in all enabled regions. Check out the https://github.com/gruntwork-io/terraform-aws-security/tree/master/modules/ebs-encryption-multi-region[ebs-encryption-multi-region] to +a module that configures volume encryption by default in all enabled regions. Check out the https://github.com/gruntwork-io/terraform-aws-security/tree/v0.10.0/modules/ebs-encryption-multi-region[ebs-encryption-multi-region] to configure AWS EBS encryption in all allowed regions of an AWS Account. For the code examples of deploying this module, see the @@ -214,7 +217,7 @@ of our "How to achieve compliance with the CIS AWS Foundations Benchmark" guide. ==== 4. Deploy the vpc-app-network-acl and vpc-mgmt-network-acl modules (recommendation 5.1) -To help us achieve CIS 1.3 compliance, we've also created the `vpc-app-network-acl` module in our https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/master/modules/vpc-app-network-acls[dedicated CIS service catalog]. This module is designed to follow CIS 1.3 recommendations - restrict access by default, but only allow explicitly listed SSH and RDP connections and hosts. To be compliant, you'll need to deploy the new module. For more details, please refer to the https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/blob/master/modules/vpc-app-network-acls/README.md[dedicated module README] and https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/master/examples/vpc-network-acls[the relevant example]. +To help us achieve CIS 1.3 compliance, we've also created the `vpc-app-network-acl` module in our https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/v0.10.0/modules/vpc-app-network-acls[dedicated CIS service catalog]. This module is designed to follow CIS 1.3 recommendations - restrict access by default, but only allow explicitly listed SSH and RDP connections and hosts. To be compliant, you'll need to deploy the new module. For more details, please refer to the https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/blob/v0.10.0/modules/vpc-app-network-acls/README.md[dedicated module README] and https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/v0.10.0/examples/vpc-network-acls[the relevant example]. If you are already using the `vpc-app-network-acl` or `vpc-mgmt-network-acl` modules, you need to update the source URL from the https://github.com/gruntwork-io/terraform-aws-vpc[`terraform-aws-vpc` module] (previously known From 975ed9f822ff74c1a4b8eeeb29af87f5590aee5b Mon Sep 17 00:00:00 2001 From: Ana Krivokapic Date: Thu, 1 Apr 2021 16:35:48 +0200 Subject: [PATCH 2/2] Fix link --- _posts/2021-01-06-how-to-update-to-cis-13.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2021-01-06-how-to-update-to-cis-13.adoc b/_posts/2021-01-06-how-to-update-to-cis-13.adoc index 1f6b77cc4..7b9bb8db5 100644 --- a/_posts/2021-01-06-how-to-update-to-cis-13.adoc +++ b/_posts/2021-01-06-how-to-update-to-cis-13.adoc @@ -208,7 +208,7 @@ of our "How to achieve compliance with the CIS AWS Foundations Benchmark" guide. EC2 supports encryption at rest when using the Elastic Block Store (EBS) service. While disabled by default, forcing encryption when creating EBS volumes is supported. Encrypting data at rest reduces the likelihood that it is unintentionally exposed and can nullify the impact of disclosure if the encryption remains unbroken. Recommendation 2.2.1 specifies a manual process to encrypt EBS volumes using the AWS Console; however, Gruntwork has developed -a module that configures volume encryption by default in all enabled regions. Check out the https://github.com/gruntwork-io/terraform-aws-security/tree/v0.10.0/modules/ebs-encryption-multi-region[ebs-encryption-multi-region] to +a module that configures volume encryption by default in all enabled regions. Check out the https://github.com/gruntwork-io/terraform-aws-security/tree/master/modules/ebs-encryption-multi-region[ebs-encryption-multi-region] to configure AWS EBS encryption in all allowed regions of an AWS Account. For the code examples of deploying this module, see the