How to achieve compliance with the CIS AWS Foundations Benchmark

Number of recommendations: 22

The recommendations in this section involve the use of identity, accounts, authentication, and authorization. On AWS, most identity and access control related concerns are managed using the eponymous IAM service. Hence, most (but not all) of the recommendations in this section discuss particular IAM configurations, such as the configuration of the password policy, the use of various groups and roles, and the configuration of multi-factor authentication (MFA) devices.

Number of recommendations: 3

This section was added in the version 1.3.0 and involves the use of storage capabilities of AWS. The relevant services for this section are S3 and EC2. The recommendations in this section pertain to in-transit and at-rest encryption.

Number of recommendations: 11

AWS has a variety of logging, monitoring, and auditing features, and the Benchmark has recommendations for several of them:

AWS has several other logging related features that are not covered directly by the Benchmark. For example, the primary log ingestion and query service, Amazon CloudWatch Logs, is integrated with many other AWS services. The Benchmark does not contain any recommendations specifically for CloudWatch Logs, though many recommendations do make mention of it.

Number of recommendations: 15

Monitoring is an overloaded term in the industry. In the context of the AWS Foundations Benchmark, the monitoring section is exclusively about monitoring for specific API calls using the CloudTrail service paired with CloudWatch Logs filter metrics. Each recommendation in this section spells out a specific filter and an associated alarm.

Number of recommendations: 4

The Benchmark is uncomfortably light on networking, considering its central role in the security of any distributed system. The recommendations merely limit traffic from the zero network (0.0.0.0/0) and suggest limiting routing for VPC peering connections based on the principle of least-privilege.

One of main areas of concern in the IAM section relates to authentication. The Benchmark has recommendations for IAM users and the root user account, password policy, and multi-factor authentication. There is more than one way to authenticate to AWS, and the method you choose determines how to implement these recommendations in your code.

Recommendation 1.16 states that no IAM policies with full administrator privileges be assigned. However, some administrator access is needed to maintain the account on an ongoing basis, and use of the root account is also prohibited. What to do?

One approach is to create an IAM policy with full permissions to IAM and nothing else. Attach the policy to a group, and give access only to trusted users. This allows effective administrator access without an explicit administrator policy. For example, you could use the following Terraform code to create such a policy:

You can then attach that policy to a group:

In this example, any IAM user that is a member of the iam-admins group will have has permissions to access all functionality in the IAM service, make them an effective administrator of the account.

Recommendation 1.10, which requires all IAM users to have MFA enabled, seems straightforward on the surface, but in AWS, there’s no way to explicitly require MFA for log in. Instead, you can make sure that all groups and roles have a conditional IAM policy attached that explicitly denies all actions unless MFA is enabled. This way, whenever a user logs in without MFA, all services will show a permission denied error if the user didn’t use MFA.

The AWS documentation has an example of this policy. Create the policy with Terraform, and attach it to every group you create - including the iam-admins and support groups we created above. Here’s an example:

We’ve created an IAM policy that denies all access accept the necessary permissions to set up an MFA device, then we attached the policy to the support group. If a user that is a member of the support group logs in without MFA, they won’t have access to any services, even if the support group or the user had other policies attached. They will have enough permissions to set up an MFA device, and after doing so, they can log in and will have any permissions granted to them by other IAM policies.

Attach a policy like this one to every group in your account.

The IAM password policy is perhaps the most straightforward and explicit set of recommendations (1.8-1.9 and 1.12) in the entire Benchmark. You can invoke the Terraform aws_iam_account_password_policy resource to implement the recommended policy.

For example:

The CIS AWS v1.3 recommendations require that all expired SSL/TLS certificates stored in AWS IAM are automatically removed (see 1.19). Unfortunately removing expired certificates via AWS Management Console is not currently supported so we must remove then using the AWS API. To view the current certificates stored in IAM, use the AWS CLI and execute the list-server-certificates command:

The command output should return an array that contains all of the SSL/TLS certificates currently stored in IAM and their metadata:

The Expiration attribute contains the expiration date for each SSL/TLS certificate which you can use to determine if it should be removed. To remove the certificate use the delete-server-certificate command, making sure to substitute <CERTIFICATE_NAME> with the ServerCertificateId attribute from the previous command:

To automate this process you might decide to implement a Lambda function that runs on a regular schedule and removes all expired SSL/TLS certificates. Check out the Automatically remove expired SSL/TLS certificates from IAM section of the deployment walkthrough to see how to deploy a ready-made module that can be deployed in each of your AWS accounts.

As of version 1.3.0, the CIS recommendations stipulate that the AWS IAM Access Analyzer service is enabled across all active regions in a given AWS Account or Organization.

To achieve this compliance requirement, enable the IAM Access Analyzer service for every AWS region you have enabled in every one of your AWS accounts. Alternatively, you could make use of the iam-access-analyzer-multi-region module available in the Gruntwork Service Catalog, as described in the Steps to enable IAM Access Analyzer for all enabled AWS regions section of the deployment walkthrough.

Once enabled, it will scan only within the boundaries of the AWS Account or Organization it has access to. Only specific resources are analyzed and included in the results - e.g. S3 buckets, SQS, etc. (For the full list of resources supported, please visit the relevant AWS docs). This lets you identify unintended access to these resources and data by external entities.

The findings from the IAM Access Analyzer can be found in the AWS web console, and can be archived or resolved. Please visit the AWS guidance on how to do so.

A few of the recommendations in the IAM section are not achievable via API and require a one-time manual configuration. Perform the steps in this section manually.

The Benchmark has specific requirements for the CloudTrail configuration, described in recommendations 3.1-4, 3.6-7 and 3.10-11. The CloudTrail must have the following characteristics:

Use the aws_cloudtrail Terraform resource to create the CloudTrail. Include the following settings in the CloudTrail configuration:

You’ll also need the aws_s3_bucket, aws_s3_account_public_access_block resources to create an S3 bucket for the CloudTrail to send its events to and to disable public access to the bucket; you wouldn’t want to expose the CloudTrail data publicly!

Finally, you’ll need the aws_cloudwatch_log_group resource to create a CloudWatch Log group as another location for CloudTrail to send events. Use this ARN for the aws_cloudtrail resource cloud_watch_logs_group_arn parameter when creating the CloudTrail.

Benchmark recommendation 3.5 states that AWS Config be enabled in all regions. This is challenging to implement with Terraform because running a particular configuration in all regions is not a feature that Terraform has natively. Terraform has loops, but they aren’t available for the purpose of repeating a resource in many regions. Unfortunately, at the time of writing, there isn’t a way to complete this recommendation without repetitive code.

To proceed, start by creating a Terraform module that takes the following actions:

When the module is working and sets up AWS Config according to the prescribed configuration, you should invoke it once for each region in the account. One way to do this is to use provider aliases. For example, you could specify one provider for each region, then invoke the module for each provider:

When AWS launches new regions, they are not enabled by default, so you won’t need to add to this list over time.

Alternatively, you could disable the regions you aren’t using and only enable AWS Config for those that you need.

Finally, a simple recommendation! To meet recommendation 3.8, create KMS keys with key rotation enabled. Using Terraform, it looks like this:

Under the Benchmark, all VPCs must have a Flow Log to log network traffic. Use the aws_flow_log Terraform resource, being sure to use log_destination_type=cloud-watch-logs.

Because the recommendation is to attach flow logs to every single VPC, you’ll need to repeat the configuration for all the default VPCs which exist in all regions of the account. You can use the cloud-nuke defaults-aws command to easily remove all the default VPCs (and default security groups) from all regions of an account, making it easier to achieve this recommendation.

Core modules are broadly applicable and can be used with or without compliance requirements. For example, the iam-groups core module creates a best practices set of IAM groups. The groups are configurable according to your needs. You could, for example, choose to create a group with read-only access, another group with full administrator access, and no other groups. All Gruntwork subscribers have access to the core modules, which reside in Gruntwork’s infrastructure as code repositories.

The compliance wrapper modules are an extension of the IaC Library. They use the source argument in a Terraform module block to invoke the core module with a configuration that is customized for compliance with the CIS AWS Foundations Benchmark. These modules are in the terraform-aws-cis-service-catalog repository (accessible to Gruntwork Compliance subscribers).

The infrastructure-modules are your organization’s "blueprint" for how to deploy infrastructure. You can use infrastructure-modules to customize the settings according to the needs of your environment. Subscribers can refer to the canonical ACME infrastructure-modules repository for an example of how you might use infrastructure-modules.

If you’re using Terragrunt, the infrastructure-modules are optional; you can call the compliance wrapper modules directly as the source from a Terragrunt configuration. The benefit of this is that you have less code to maintain by depending directly on Gruntwork’s upstream compliance modules.

infrastructure-live uses Terragrunt to make it easier to work with Terraform modules in multiple environments. infrastructure-live is optional - you can use all of the modules with or without Terragrunt.

If you’re not using Terragrunt, you can use infrastructure-modules to call the compliance wrapper modules. Refer to the canonical ACME infrastructure-live repository, and in particular the Infrastructure walkthrough for comprehensive documentation on how infrastructure-live, infrastructure-modules, and the core IaC modules interact.

This modular, decomposed approach allows for maximum code reuse. The core modules can be used with or without compliance, depending on how they are configured. The compliance wrappers are like shadows of the core modules; they pass through most of the variables to the core modules without alteration, but hard code any settings needed for compliance. When you call the compliance modules from your own code in infrastructure-modules, you only need to set up any variables that are custom for your environment. Often times the default settings are good enough.

You can use this approach on AWS account. In many cases, you’ll only need compliance for production accounts, but the same methodology can be applied to pre-production accounts as well.

If you need to brush up on how the IaC Library works, read the How to use the Gruntwork Infrastructure as Code Library guide.

This section demonstrates how to use the CIS compliance password policy wrapper module to create a password policy. Follow this pattern for each of the wrapper modules discussed throughout this walkthrough.

To make sure your S3 buckets are compliant with the benchmark, use the private-s3-bucket module to create and manage all of your S3 buckets. This module blocks public access and enforces encryption by default. Note that all Gruntwork modules that create S3 buckets use this module under the hood.

You can either use the private-s3-bucket module in your own modules, or, if you wish to deploy a standalone S3 bucket, use the s3-bucket service from the Gruntwork Service Catalog.

Use the ebs-encryption-multi-region module to configure AWS EBS encryption in all enabled regions of an AWS Account, as per the Benchmark recommendation.

If you’re using Terragrunt, then you can invoke the standalone module directly by following the pattern outlined in Using the compliance wrapper module with Terragrunt and creating a terragrunt.hcl file with the following contents:

Use the cloudtrail wrapper module to establish a compliant CloudTrail configuration. The wrapper module will configure CloudTrail with all the characteristics required by the Benchmark. Refer to the terraform and terragrunt examples.

Use the aws-config-multi-region module to enable AWS Config in every region of an AWS account, along with a global configuration recorder in one region, as per the Benchmark recommendation.

Use the kms-master-key module to create KMS keys with key rotation enabled by default.

The Benchmark recommends enabling VPC Flow Logs for all VPCs in all regions. You can use the vpc service in the CIS Service Catalog to create your VPCs. This service is configured for CIS compliance, and as such has VPC flow logs enabled. For example, you might create a VPC using the VPC service:

Under the hood, the service will enable VPC flow logs. All that’s remaining is to define the parameters in a variables.tf:

Refer to the VPC example code.

To limit the number of flow logs, you may want to use the cloud-nuke defaults-aws command. It will remove the default VPC from all regions in an account, saving you the hassle of creating flow logs in each default VPC.