Implementing the AWS Foundations CIS Benchmarks will help you improve your cloud security posture in your AWS infrastructure.
What entry points can attackers use to compromise your cloud infrastructure? Do all your users have multi-factor authentication setup? Are they using it? Are you providing more permissions that needed?
Those are some questions this benchmark will help you answer.
Keep reading for an overview on AWS CIS Benchmarks and tips to implement it. Also discover how a security tool can help you automate these benchmarks while continuously checking your cloud security posture.
What are AWS CIS benchmarks?
The AWS Foundations CIS Benchmark is a compliance standard for meeting AWS security controls. The benchmark offers prescriptive instructions for configuring AWS services in accordance with industry best practices delivered by CIS.
Why are AWS CIS benchmarks important?
When you move workloads to AWS, the first problem you encounter is ensuring AWS security across your infrastructure.
Cloud misconfigurations are a constant concern for organizations that operate in AWS. AWS environments are also dynamic, which makes it difficult to detect when assets fall out of compliance. Without a clear mapping of AWS CIS best practices guidelines to this new environment, your teams won’t be able to prove they meet CIS requirements.
Rather than reinventing the wheel, you can follow an AWS CIS standards-based framework that provides security best practices.
AWS CIS benchmarks version 1.3
The Center for Internet Security (CIS) released their latest version of the benchmark, 1.3.0, in September, 2020.
CIS Bechmarks have seven core categories, and “Cloud provider benchmarks” the third in the list. That’s where security configurations for Amazon Web Services (AWS) and other well-known public clouds are addressed.
CIS AWS Foundations Overview
The CIS AWS Foundations Benchmark is composed of five sections with a total of 55 controls known as “recommendations.”
| Controls | Sysdig Support |
| 1. Identity and Access Management | |
| 1.1 Maintain current contact details. (Manual) | |
| 1.2 Ensure security contact information is registered. (Manual) | |
| 1.3 Ensure security questions are registered in the AWS account. (Manual) | |
| 1.4 Ensure no root user account access key exists. (Automated) | ✅ |
| 1.5 Ensure MFA is enabled for the “root user” account. (Automated) | ✅ |
| 1.6 Ensure hardware MFA is enabled for the “root user” account. (Automated) | ✅ |
| 1.7 Eliminate use of the root user for administrative and daily tasks. (Automated) | ✅ |
| 1.8 Ensure IAM password policy requires a minimum length of 14 or greater. (Automated) | ✅ |
| 1.9 Ensure IAM password policy prevents password reuse. (Automated) | ✅ |
| 1.10 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password. (Automated) | |
| 1.11 Do not set up access keys during initial user setup for all IAM users that have a console password (Manual) | ✅ |
| 1.12 Ensure credentials unused for 90 days or greater are disabled. (Automated) | ✅ |
| 1.13 Ensure there is only one active access key available for any single IAM user. (Automated) | ✅ |
| 1.14 Ensure access keys are rotated every 90 days or less. (Automated) | ✅ |
| 1.15 Ensure IAM users receive permissions only through groups. (Automated) | ✅ |
| 1.16 Ensure IAM policies that allow full “*:*” administrative privileges are not attached. (Automated) | ✅ |
| 1.17 Ensure a support role has been created to manage incidents with AWS Support. (Automated) | ✅ |
| 1.18 Ensure IAM instance roles are used for AWS resource access from instances. (Manual) | |
| 1.19 Ensure that all the expired SSL/TLS certificates stored in AWS IAM are removed. (Automated) | ✅ |
| 1.20 Ensure that S3 Buckets are configured with ‘Block public access (bucket settings)’. (Automated) | ✅ |
| 1.21 Ensure that IAM Access analyzer is enabled. (Automated) | |
| 1.22 Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments. (Manual) | |
| 2. Storage | |
| 2.1 Simple Storage Service (S3). Ensure all buckets employ encryption-at-rest and the policy allows HTTPS requests. (Manual) | |
| 2.2 Elastic Compute Cloud (EC2). Ensure EBS volume encryption is enabled. (Manual) | |
| 3. Logging | |
| 3.1 Ensure CloudTrail is enabled in all regions. (Automated) | ✅ |
| 3.2 Ensure CloudTrail log file validation is enabled. (Automated) | ✅ |
| 3.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible. (Automated) | |
| 3.4 Ensure CloudTrail trails are integrated with CloudWatch Logs. (Automated) | ✅ |
| 3.5 Ensure AWS Config is enabled in all regions. (Automated) | ✅ |
| 3.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket. (Automated) | ✅ |
| 3.7 Ensure CloudTrail logs are encrypted at rest using KMS CMKs. (Automated) | ✅ |
| 3.8 Ensure rotation for customer created CMKs is enabled. (Automated) | ✅ |
| 3.9 Ensure VPC flow logging is enabled in all VPCs. (Automated) | ✅ |
| 3.10 Ensure that Object-level logging for write events is enabled for S3 bucket. (Automated) | |
| 3.11 Ensure that Object-level logging for read events is enabled for S3 bucket. (Automated) | |
| 4. Monitoring | |
| 4.1~4.15 Ensure a log metric filter and alarm exist for several events, like unauthorized API calls, usage of the “root” account, or policy changes. (Automated) | |
| 5. Networking | |
| 5.1 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports. (Automated) | |
| 5.2 Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports. (Automated) | ✅ |
| 5.3 Ensure the default security group of every VPC restricts all traffic. (Automated) | ✅ |
| 5.4 Ensure routing tables for VPC peering are “least access”. (Manual) | ✅ |
Identity and Access Management
The first section contains recommendations for configuring IAM-related controls. For example, CIS AWS 1.6 recommends that the root user account be protected with a hardware MFA on Level 2 profiles. 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’re prompted for their username and password, as well as an authentication code from their AWS MFA device.
Another recommendation that we find in this section is CIS 1.20, which requires you to ensure that S3 buckets are not publicly accessible. While enabled, block S3 bucket public access, preventing an individual bucket and its contained objects from becoming publicly accessible. You want to ensure accidental or malicious public exposure of data is contained within the respective bucket(s).
Monitoring
The third section contains recommendations for configuring AWS log metric filters and alarms to monitor services. To comply with CIS AWS 3.2, you need to ensure you have a log metric filter and that an alarm exist for AWS Management Console sign-in without MFA.
Networking
The fifth section contains recommendations for configuring security-related aspects of the default Virtual Private Cloud (VPC). For example, CIS AWS 5.2. Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports.
CSPM for AWS with Sysdig Secure
Sysdig Secure for cloud helps address cloud compliance for AWS and other cloud providers with on-demand assessments and reports.
Here are some of the Sysdig Secure for cloud out-of-the-box policies mapped to AWS CIS benchmarks controls:
Control 1.6: Check if MFA access is turned on for the root account, and also make sure it is associated with a hardware MFA device.
Control 1.20: Check for block public access turned on for S3 buckets.
Control 3.2: Check if you have a log metric filter and alarm configured without MFA.
Control 5.2: Check for security groups allowed to ingress from 0.0.0.0/0 to remote server administration ports.
Sysdig Secure for cloud goes beyond CIS Benchmarks, including runtime detection, image scanning, forensics, and much more.
If you are interested in AWS security, check how Sysdig Secure for cloud unifies threat detection for AWS cloud and containers. Also, we wrote on how an attacker could exploit a vulnerability in one container and perform lateral movement to compromise your whole cloud infrastructure.
Conclusion
Cyber attacks and Cloud misconfigurations are a permanent concern for companies that operate in the cloud, so security is of utmost importance.
When working with cloud providers, like AWS, it’s crucial you do your part and configure finely-tuned access policies that align with the security, governance, and compliance requirements of your organization.
You can use AWS CIS benchmark as a guidance to protect your AWS assets and data.
Or easily track AWS cloud compliance with Sysdig Secure out-of-the-box policies, schedule on-demand assessments for internal and external auditors, and provide real-time insight with interactive dashboards and reports.
With Sysdig Secure for cloud, you can continuously flag cloud misconfigurations before the bad guys get in, and detect suspicious activity like unusual logins from leaked credentials. This all happens in a single console, making it easier to validate your cloud security posture. And it only takes a few minutes to get started!
Start securing your cloud for free with our Sysdig Free Tier!
The Sysdig Secure DevOps Platform provides the visibility you need to confidently run containers, Kubernetes, and cloud. It’s built on an open-source stack with SaaS delivery, and is radically simple to run and scale.
Request a free trial today!