gruntwork-io · eak12913 · Jan 14, 2022 · Jan 11, 2022 · Jan 11, 2022 · Jan 12, 2022
diff --git a/_docs-sources/guides/build-it-yourself/1-overview.md b/_docs-sources/guides/build-it-yourself/1-overview.md
diff --git a/...es/build-it-yourself/2-landing-zone/0-intro/0-what-youll-learn-in-this-guide.md b/...es/build-it-yourself/2-landing-zone/0-intro/0-what-youll-learn-in-this-guide.md
diff --git a/_docs-sources/guides/build-it-yourself/2-landing-zone/0-intro/_category_.json b/_docs-sources/guides/build-it-yourself/2-landing-zone/0-intro/_category_.json
diff --git a/...uides/build-it-yourself/3-pipelines/0-intro/2-what-this-guide-will-not-cover.md b/...uides/build-it-yourself/3-pipelines/0-intro/2-what-this-guide-will-not-cover.md
diff --git a/_docs-sources/guides/build-it-yourself/3-pipelines/0-intro/_category_.json b/_docs-sources/guides/build-it-yourself/3-pipelines/0-intro/_category_.json
diff --git a/_docs-sources/guides/build-it-yourself/4-vpc/0-intro/_category_.json b/_docs-sources/guides/build-it-yourself/4-vpc/0-intro/_category_.json
diff --git a/_docs-sources/guides/build-it-yourself/5-kubernetes-cluster/0-intro/_category_.json b/_docs-sources/guides/build-it-yourself/5-kubernetes-cluster/0-intro/_category_.json
diff --git a/...elf/6-achieve-compliance/0-intro/1-what-is-the-cis-aws-foundations-benchmark.md b/...elf/6-achieve-compliance/0-intro/1-what-is-the-cis-aws-foundations-benchmark.md
diff --git a/_docs-sources/guides/build-it-yourself/6-achieve-compliance/0-intro/_category_.json b/_docs-sources/guides/build-it-yourself/6-achieve-compliance/0-intro/_category_.json
diff --git a/...iance/3-deployment-walkthrough/2-prepare-your-infrastructure-live-repository.md b/...iance/3-deployment-walkthrough/2-prepare-your-infrastructure-live-repository.md
diff --git a/...self/6-achieve-compliance/_category_.json → ...urself/achieve-compliance/_category_.json b/...self/6-achieve-compliance/_category_.json → ...urself/achieve-compliance/_category_.json
diff --git a/...ding-zone/1-core-concepts/_category_.json → ...-compliance/core-concepts/_category_.json b/...ding-zone/1-core-concepts/_category_.json → ...-compliance/core-concepts/_category_.json
diff --git a/...eve-compliance/1-core-concepts/0-intro.md → ...achieve-compliance/core-concepts/intro.md b/...eve-compliance/1-core-concepts/0-intro.md → ...achieve-compliance/core-concepts/intro.md
@@ -5,6 +5,12 @@ sidebar_label: Intro
 
 # CIS Compliance Core Concepts
 
+The [CIS Benchmarks](https://www.cisecurity.org/resources/?type=benchmark) are objective, consensus-driven
+configuration guidelines developed by security experts to help organizations improve their security posture.
+The AWS Foundations Benchmark is a set of configuration best practices for hardening AWS accounts to establish
+a secure foundation for running workloads on AWS. It also provides ongoing monitoring to ensure that the
+account remains secure.
+
 The CIS AWS Foundations Benchmark is organized into the following sections:
 
 - Identity and Access Management
@@ -42,8 +48,3 @@ Organizations seeking to implement a comprehensive security program or framework
 progress and prioritize security efforts. The Foundations Benchmark is just one of several guidelines that can help
 reach the bar set by the CIS Controls. Refer to the Benchmark document directly to view how the recommendations map to
 controls.
-
-
-<!-- ##DOCS-SOURCER-START
-{"sourcePlugin":"Local File Copier","hash":"56c0543c5fd2cf410b922c940c4a414a"}
-##DOCS-SOURCER-END -->
diff --git a/...ore-concepts/1-recommendation-sections.md → .../core-concepts/recommendation-sections.md b/...ore-concepts/1-recommendation-sections.md → .../core-concepts/recommendation-sections.md
diff --git a/.../3-deployment-walkthrough/_category_.json → ...ce/deployment-walkthrough/_category_.json b/.../3-deployment-walkthrough/_category_.json → ...ce/deployment-walkthrough/_category_.json
diff --git a/...create-an-iam-user-in-the-root-account.md → ...create-an-iam-user-in-the-root-account.md b/...create-an-iam-user-in-the-root-account.md → ...create-an-iam-user-in-the-root-account.md
diff --git a/...-walkthrough/3-create-the-root-account.md → ...nt-walkthrough/create-the-root-account.md b/...-walkthrough/3-create-the-root-account.md → ...nt-walkthrough/create-the-root-account.md
diff --git a/...ent-walkthrough/9-create-vpc-flow-logs.md → ...yment-walkthrough/create-vpc-flow-logs.md b/...ent-walkthrough/9-create-vpc-flow-logs.md → ...yment-walkthrough/create-vpc-flow-logs.md
@@ -85,7 +85,7 @@ all regions in an account, saving you the hassle of creating flow logs in each d
 The Monitoring section of the Benchmark centers on a collection of
 [CloudWatch Logs Metric
 Filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html). Gruntwork has simplified this section to a single module: the
-[`cloudwatch-logs-metric -filters` wrapper module](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/blob/master/modules/cloudwatch-logs-metric-filters/README.adoc). It will create and configure all the CloudWatch Logs metric filters necessary for
+[`cloudwatch-logs-metric -filters` wrapper module](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/blob/master/modules/observability/cloudwatch-logs-metric-filters/README.adoc). It will create and configure all the CloudWatch Logs metric filters necessary for
 compliance with the Benchmark. Note that when you deploy the CIS account baseline modules, the CloudWatch Logs metric
 filters will be created and configured automatically, so that you don’t have to do anything special to enable the metric filters on the
 deployed CloudTrail configuration.
@@ -147,7 +147,7 @@ inputs = {
 }
 ```
 
-Refer to the [terraform-aws-cis-service-catalog](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/master/examples/for-learning-and-testing/networking/vpc/terraform)
+Refer to the [terraform-aws-cis-service-catalog](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/master/examples/for-learning-and-testing/networking/vpc/)
 repo for a more comprehensive example.
 
 Finally, run the [`cloud-nuke defaults-aws`](https://github.com/gruntwork-io/cloud-nuke) command to remove all

diff --git a/...loy-landing-zone-solution/_category_.json → ...loy-landing-zone-solution/_category_.json b/...loy-landing-zone-solution/_category_.json → ...loy-landing-zone-solution/_category_.json
diff --git a/...y-account-baseline-app-to-logs-account.md → ...y-account-baseline-app-to-logs-account.md b/...y-account-baseline-app-to-logs-account.md → ...y-account-baseline-app-to-logs-account.md
diff --git a/...t-baseline-app-to-other-child-accounts.md → ...t-baseline-app-to-other-child-accounts.md b/...t-baseline-app-to-other-child-accounts.md → ...t-baseline-app-to-other-child-accounts.md
@@ -275,7 +275,7 @@ On some operating systems, such as MacOS, you may also need to increase your ope
 1. Use your IAM user’s user name and password (decrypted using keybase) to log into the web console of the security
    account (remember to use the IAM user sign-in URL for the security account).
 
-2. Follow the steps in [Lock down the root account IAM users](../6-lock-down-the-root-account-iam-users.md) to lock down your IAM user in the security account. This includes
+2. Follow the steps in [Lock down the root account IAM users](../lock-down-the-root-account-iam-users.md) to lock down your IAM user in the security account. This includes
    configuring an MFA device for your IAM user.
 
 3. After configuring an MFA device, log out, and then log back into the security account again, this time providing your

diff --git a/...-account-baseline-root-to-root-account.md → ...-account-baseline-root-to-root-account.md b/...-account-baseline-root-to-root-account.md → ...-account-baseline-root-to-root-account.md
@@ -581,6 +581,6 @@ Use this process to reset the password for the root user of each child account y
 
 ## Lock down the root user in the child accounts
 
-Once you’re able to access the root user of each child account, you should follow the steps in [Lock down the root user](../4-lock-down-the-root-user.md)
+Once you’re able to access the root user of each child account, you should follow the steps in [Lock down the root user](../lock-down-the-root-user.md)
 for each of those child accounts—including enabling MFA and deleting the root user’s access keys—and (almost) never use
 those root users again.
diff --git a/...-baseline-security-to-security-account.md → ...-baseline-security-to-security-account.md b/...-baseline-security-to-security-account.md → ...-baseline-security-to-security-account.md
diff --git a/...ion/8-enable-key-rotation-for-kms-keys.md → ...ution/enable-key-rotation-for-kms-keys.md b/...ion/8-enable-key-rotation-for-kms-keys.md → ...ution/enable-key-rotation-for-kms-keys.md
diff --git a/...liance-by-following-iam-best-practices.md → ...liance-by-following-iam-best-practices.md b/...liance-by-following-iam-best-practices.md → ...liance-by-following-iam-best-practices.md
diff --git a/...ce-by-following-logging-best-practices.md → ...ce-by-following-logging-best-practices.md b/...ce-by-following-logging-best-practices.md → ...ce-by-following-logging-best-practices.md
diff --git a/...ce-by-following-storage-best-practices.md → ...ce-by-following-storage-best-practices.md b/...ce-by-following-storage-best-practices.md → ...ce-by-following-storage-best-practices.md
diff --git a/...tion/4-use-iam-roles-for-ec2-instances.md → ...lution/use-iam-roles-for-ec2-instances.md b/...tion/4-use-iam-roles-for-ec2-instances.md → ...lution/use-iam-roles-for-ec2-instances.md
diff --git a/...ment-walkthrough/7-deployment-approach.md → ...oyment-walkthrough/deployment-approach.md b/...ment-walkthrough/7-deployment-approach.md → ...oyment-walkthrough/deployment-approach.md
@@ -1,7 +1,7 @@
 # Deployment approach
 
 Before we dive into the code and deployment for each resource, let’s take a step back and understand how the code is structured.
-Most of the features explained in the [Production-grade design](../2-production-grade-design/0-intro.md) section will be deployed using the Landing Zone solution, and some more standalone modules like the VPC module.
+Most of the features explained in the [Production-grade design](../production-grade-design/intro.md) section will be deployed using the Landing Zone solution, and some more standalone modules like the VPC module.
 
 The Landing Zone will be deployed in three steps - the `account-baseline-root` to set up your organization-wide configurations, create the necessary child AWS accounts, set up the CloudTrail and AWS Config buckets. Next, we’ll need to apply the `account-baseline-app` against the created logs account, adding more settings that will be used for aggregation of logs and metrics from the whole organization. Then the `account-baseline-security` will be applied, and that’s responsible to set up your IAM roles and groups that would allow you to access the rest of the accounts within your organization. And finally, the `account-baseline-app` will be applied to an AWS account with the purpose of hosting an application.
 

diff --git a/...6-lock-down-the-root-account-iam-users.md → ...h/lock-down-the-root-account-iam-users.md b/...6-lock-down-the-root-account-iam-users.md → ...h/lock-down-the-root-account-iam-users.md
diff --git a/...-walkthrough/4-lock-down-the-root-user.md → ...nt-walkthrough/lock-down-the-root-user.md b/...-walkthrough/4-lock-down-the-root-user.md → ...nt-walkthrough/lock-down-the-root-user.md
diff --git a/...eployment-walkthrough/0-pre-requisites.md → .../deployment-walkthrough/pre-requisites.md b/...eployment-walkthrough/0-pre-requisites.md → .../deployment-walkthrough/pre-requisites.md
@@ -4,7 +4,7 @@ pagination_label: Deployment Walkthrough
 
 # Pre-requisites
 
-The [Production-grade Design](../2-production-grade-design/0-intro.md) section describes in detail the Terraform resources to use and the approach to take for
+The [Production-grade Design](../production-grade-design/intro.md) section describes in detail the Terraform resources to use and the approach to take for
 each recommendation, but we've already done that grunt work! This section documents how to achieve compliance using the Infrastructure as Code modules from Gruntwork.
 
 This walkthrough has the following pre-requisites:

diff --git a/...ompliance/deployment-walkthrough/prepare-your-infrastructure-live-repository.md b/...ompliance/deployment-walkthrough/prepare-your-infrastructure-live-repository.md
@@ -0,0 +1,8 @@
+---
+sidebar_label: Prepare your infrastructure-live repository
+---
+
+# Prepare your `infrastructure-live` repository
+
+We’ve previously described exactly how to prepare your repository in the
+[Gruntwork Landing Zone guide](../../landing-zone/deployment-walkthrough/prepare-your-infrastructure-live-repository.md). Follow the steps in that section to get your `infrastructure-live` repository set up for the next steps.
diff --git a/...t-walkthrough/1-the-gruntwork-solution.md → ...ent-walkthrough/the-gruntwork-solution.md b/...t-walkthrough/1-the-gruntwork-solution.md → ...ent-walkthrough/the-gruntwork-solution.md
@@ -22,7 +22,7 @@ Gruntwork’s [infrastructure as code repositories](https://gruntwork.io/repos).
 ## Standalone Compliance modules
 
 The standalone compliance modules complement the modules available in the IaC Library. They have the CIS compliance requirements built right in and may combine multiple modules including Core modules for a
-specific use case. For example, the [`cleanup-expired-certs` standalone module](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/master/modules/cleanup-expired-certs) deploys a Lambda function that runs regularly and automatically removes all expired SSL/TLS certificates stored in AWS IAM in compliance with recommendation 1.19 of the CIS AWS Foundations Benchmark. These modules are in the [`terraform-aws-cis-service-catalog`
+specific use case. For example, the [`cleanup-expired-certs` standalone module](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/tree/master/modules/security/cleanup-expired-certs) deploys a Lambda function that runs regularly and automatically removes all expired SSL/TLS certificates stored in AWS IAM in compliance with recommendation 1.19 of the CIS AWS Foundations Benchmark. These modules are in the [`terraform-aws-cis-service-catalog`
 repository](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog) (accessible to Gruntwork Compliance subscribers).
 
 ## Compliance wrapper modules

diff --git a/...intro/0-what-youll-learn-in-this-guide.md → ...d-it-yourself/achieve-compliance/index.md b/...intro/0-what-youll-learn-in-this-guide.md → ...d-it-yourself/achieve-compliance/index.md
@@ -24,8 +24,8 @@ compliant state over time because all of the infrastructure is defined as code.
 
 Previously, we supported versions 1.3.0 and 1.2.0 of the Benchmark. If you are looking to upgrade from an older version please follow these in order:
 
-- To upgrade from v1.2.0 to v1.3.0, please follow [this upgrade guide](../../../stay-up-to-date/1-cis/1-how-to-update-to-cis-13/0-intro.md);
-- To upgrade from v1.3.0 to v1.4.0, please follow [this upgrade guide](../../../stay-up-to-date/1-cis/0-how-to-update-to-cis-14/0-intro.md).
+- To upgrade from v1.2.0 to v1.3.0, please follow [this upgrade guide](/docs/guides/stay-up-to-date/cis/cis-1.3.0).
+- To upgrade from v1.3.0 to v1.4.0, please follow [this upgrade guide](/docs/guides/stay-up-to-date/cis/cis-1.4.0).
 
 ![CIS Benchmark Architecture](/img/guides/build-it-yourself/achieve-compliance/cis-account-architecture.png)
 

diff --git a/...self/6-achieve-compliance/4-next-steps.md → ...yourself/achieve-compliance/next-steps.md b/...self/6-achieve-compliance/4-next-steps.md → ...yourself/achieve-compliance/next-steps.md
diff --git a/...2-production-grade-design/_category_.json → ...e/production-grade-design/_category_.json b/...2-production-grade-design/_category_.json → ...e/production-grade-design/_category_.json