CIS for Amazon Web Services

Center for Internet Security

The Center for Internet Security (CIS) provides best practices and security standards for the internet. The CIS for Amazon Web Services (AWS) is a detailed benchmark that provides industry standard guidance on cloud security in the AWS cloud. CIS Benchmarks are a global standard and recognized best practices for securing IT systems and data against the most pervasive attacks. Comprehensive security guidelines from CIS are widely accepted by governments, businesses, various industries, as well as universities and research facilities.

Green Marimba provides AWS Security Assessments and AWS cloud migrations that follow these strict security protocols.

Below we provide a summary of the critical AWS cloud security standards, as laid out by CIS. These requirements are divided into two sections – Scored and Not Scored. A scoring status indicates whether compliance with the given recommendation impacts your benchmark score.

Scored – Failure to comply with a Scored recommendation will decrease the final benchmark score, while compliance will increase the final score.
Not Scored – Failure to comply with Not Scored recommendations will neither decrease nor increase the final benchmark score.

Green Marimba will review all requirements below as part of our comprehensive AWS security assessment, as CIS has determined that these are all valuable to overall cloud security.

CIS Standard 1: Identity and Access Management for the Cloud

CIS for Amazon Web Services via IAM

Identity and Access Management (IAM) is the first security protocol. With IAM, you can manage your AWS users and groups, allowing you to securely control access to AWS services and resources by using permissions to allow and deny user permissions.

Here CIS outlines recommendations for configuring identity and access management related options. Secure passwords are one of the easiest, yet most important factors to securing AWS accounts, so those figure widely here.

Password policies are used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are complex, using a mix of different length requirements and character sets.
Setting a password complexity policy increases account resiliency against brute force login attempts.

The included CIS requirements under Identity and Access Management (IAM) are:

1.1 Avoid the use of the root account

The “root” account is the primary and most privileged AWS account. The root account should only be used for administrative activities and not internet browsing, email, or other non administrative activities.
Using a dedicated or secondary account (with fewer privileges) for access management will reduce the risk of accidental changes and unintended disclosure of highly privileged credentials.

1.2 Ensure multi-factor authentication is enabled for all IAM users that have a console password

Multi-factor authentication (MFA) is a secure authentication method that requires users to verify their identity by entering two or more items (or factors) to log in. Possible factors include a code generated by an authentication app, a hardware security key, or even a biometric scan such as a fingerprint.

With MFA enabled an extra layer of protection on top of a username and password are added. When a user signs in to an AWS website, they will need to enter their username and password as well as an authentication code from their AWS MFA device.

1.3 Ensure credentials unused for 90 days or greater are disabled

If AWS credentials have not been used in 90 days, it is highly recommended to delete or deactivate them.
Removing or disabling unused credentials will reduce the probability of unauthorized access.

1.4 Ensure access keys are rotated every 90 days or less

It is recommended that all access keys be regularly rotated. Access keys consist of an access key ID and secret access key that are required 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.
Access keys should be rotated to ensure that data cannot be accessed with an old key which might have been lost or compromised.

1.5 Ensure IAM password policy requires at least one uppercase letter

It is a CIS recommendation that the password policy require at least one uppercase letter. This helps ensure a complex password that cannot be easily replicated.

1.6 Ensure IAM password policy require at least one lowercase letter

It is a CIS recommendation that the password policy require at least one lowercase letter.

1.7 Ensure IAM password policy require at least one symbol

It is recommended that the password policy require at least one symbol.

1.8 Ensure IAM password policy require at least one number

It is recommended that the password policy require at least one number.

1.9 Ensure IAM password policy requires minimum length of 14 or greater

CIS recommends that the password policy require a minimum password length of 14 characters.

1.10 Ensure IAM password policy prevents password reuse

CIS recommends that the password policy prevent the reuse of passwords.

1.11 Ensure IAM password policy expires passwords within 90 days or less

It is recommended that the password policy expire passwords after 90 days or less.
Requiring regular password changes help security in a variety of scenarios, including common cloud security threats and user error.

1.12 Ensure no root account access key exists

It is recommended that all access keys associated with the root account be removed.
Removing access keys associated with the root account limits the means by which the account can be compromised and, removing the root access keys will encourage the use of role based accounts that are least privileged as in 1.1 above.

1.13 Ensure MFA is enabled for the root account

Since the root account is the most privileged user in an AWS account, adding MFA provides 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.
Having MFA enabled will increase security for console access because it requires the user to have the device to produce a time-sensitive key.

1.14 Ensure hardware MFA is enabled for the root account

For Level 2, it is recommended that the root account be protected with a hardware MFA.
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 mobile smartphone on which a virtual MFA resides.

Note: Using hardware MFA for many, many AWS accounts may create a logistical device management issue. If this is the case, consider implementing this Level 2 recommendation selectively to the highest security AWS accounts and the Level 1 recommendation applied to the remaining
accounts.

1.15 Ensure security questions are registered in the AWS account

It is recommended that security questions be established to allow account owners to establish security questions that can be used to authenticate individuals calling for support.

1.16 Ensure IAM policies are attached only to groups or roles

It is recommended that IAM policies be applied directly to groups and roles but not users. By default, IAM users, groups, and roles have no access to AWS resources. IAM policies are the means by which privileges are granted to users, groups, or roles.
Assigning privileges at the role or group level will reduce the complexity of managing privileges and access levels as the number of users increases, and reduces the likelihood of inadvertently receiving or retaining excessive privileges.

1.17 Maintain current contact details

An AWS account supports a number of contact details. It is important to keep email and phone details current and be mapped to more than one person in your organization. AWS will use this information if activity is judged to be in breach of the AWS Acceptable Use Policy or if a security compromise is observed by the AWS Abuse team.

1.18 Ensure security contact information is registered

Specifying security-specific contact information will help ensure that security advisories sent by AWS reach the team in your organization that is best equipped to respond to them.

1.19 Ensure IAM instance roles are used for AWS resource access from instances

“AWS Access” means accessing the APIs of AWS in order to access AWS resources or manage AWS account resources.

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 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 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.

1.20 Ensure a support role has been created to manage incidents with AWS Support

AWS support 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.

1.21 Do not setup access keys during initial user setup for all IAM users that have a console password

AWS console defaults the checkbox for creating access keys to enabled. This results in many access keys being generated unnecessarily. In addition to unnecessary credentials, it also generates unnecessary management work in auditing and rotating these keys.

Requiring that additional steps be taken by the user after their profile has been created will give a stronger indication of intent that access keys are [a] necessary for their work and [b] once the access key is established on an account that the keys may be in use somewhere in the organization.

1.22 Ensure IAM policies that allow full “:” administrative privileges are not created

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. 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.

CIS Standard 2: AWS Logging

CIS for Amazon Web Services via AWS Logging

Logging is the next important process outlined by the CIS and contains recommendations for configuring AWS’s account logging features.

2.1 Ensure CloudTrail is enabled in all regions

AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files. 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).

2.2 Ensure CloudTrail log file validation is enabled

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.

2.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible

As above, CloudTrail logs a record of every API call made in your AWS account. These logs files 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.

2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs

AWS CloudTrail 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. 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 sensitive account activity.

2.5 Ensure AWS Config is enabled in all regions

AWS Config is a web service that performs configuration management of supported AWS resources within your account and delivers log files. 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.

2.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket

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. Configuring logs to be placed in a separate bucket allows access to log information which can be useful in security and incident response workflows.

2.7 Ensure CloudTrail logs are encrypted at rest using Key Management Service CMKs

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. Configuring CloudTrail to use SSE-KMS provides additional confidentiality controls on log data.

2.8 Ensure rotation for customer created CMKs is enabled

AWS 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. 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.

2.9 Ensure VPC flow logging is enabled in all VPCs

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.
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.

CIS Standard 3: Monitoring on AWS

CIS for Amazon Web Services - Monitoring on AWS

Monitoring your AWS cloud is the next important process outlined by the CIS and contains recommendations for configuring account monitoring.

3.1 Ensure a log metric filter and alarm exist for unauthorized API calls

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 reduce time to detect malicious activity.

3.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA

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).

3.3 Ensure a log metric filter and alarm exist for usage of root account

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, since this is the fully privileged AWS account.

3.4 Ensure a log metric filter and alarm exist for IAM policy changes

It is recommended that a metric filter and alarm be established. Monitoring changes to IAM policies will help ensure authentication and authorization controls remain intact.

3.5 Ensure a log metric filter and alarm exist for CloudTrail configuration changes

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.

3.6 Ensure a log metric filter and alarm exist for AWS Management Console authentication failures

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.

3.7 Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs

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.

3.8 Ensure a log metric filter and alarm exist for S3 bucket policy changes

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.

3.9 Ensure a log metric filter and alarm exist for AWS Config configuration changes

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.

3.10 Ensure a log metric filter and alarm exist for security group changes

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 changes to Security Groups.
Monitoring changes to security groups helps ensure that resources and services are not unintentionally exposed.

3.11 Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)

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.

3.12 Ensure a log metric filter and alarm exist for changes to network gateways

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.

3.13 Ensure a log metric filter and alarm exist for route table changes

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.
Monitoring changes to route tables will help ensure that all VPC traffic flows through an expected path.

3.14 Ensure a log metric filter and alarm exist for VPC changes

A VPC is a secure Virtual Private Cloud hosted within a public cloud.

It is possible to have more than one VPC within an account. It is also possible to create a peer connection between two VPCs, enabling network traffic to route between VPCs.

CIS recommends that a metric filter and alarm be established for changes made to VPCs.

CIS Standard 4: Networking on AWS

Networking

This section contains recommendations for configuring security-related aspects of the default VPC. A VPC is a secure Virtual Private Cloud hosted within a public cloud. With the Amazon VPC, we provision a logically isolated section of the AWS Cloud to launch AWS resources in a predefined virtual network.

4.1 Ensure no security groups allow ingress from 0.0.0.0/0 to port 22

Security groups provide stateful filtering of ingress/egress network traffic to AWS resources.

It is recommended that no security group allows unrestricted ingress access to port 22.
Removing unfettered connectivity to remote console services, such as SSH, reduces a server’s exposure to risk.

4.2 Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389

It is recommended that no security group allows unrestricted ingress access to port 3389.
Removing unfettered connectivity to remote console services, such as RDP, reduces a server’s exposure to risk.

4.3 Ensure the default security group of every VPC restricts all traffic

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. As security groups provide stateful filtering of ingress/egress network traffic to AWS resources, it is recommended that the default security group restrict all traffic.
The default VPC in every region should have its default security group updated to comply. Any newly created VPCs will automatically contain a default security group that will need remediation to comply with this recommendation.
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 reduce the exposure of those resources.

4.4 Ensure routing tables for VPC peering are least access

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.
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.

Don’t go it alone. Let Green Marimba review your cloud architecture to ensure the CIS for Amazon Web Services benchmarks are met.