CIS AWS Foundations Benchmark
The Center for Internet Security (CIS) AWS Foundations Benchmark serves as a set of security configuration best practices for AWS. Stax endeavours to meet version 5.0.0 of this framework.
Stax will automatically configure a number of settings for your AWS accounts to meet these best practices. There are also a number of settings that you must opt-in to due to the increased costs or additional information required.
Recommendations
The following are the CIS version 5.0.0 recommendations and how they are addressed by Stax.
Covered by Stax Default configuration
| CIS 5.0.0 Ref | Description | Stax Considerations |
|---|---|---|
| 1.1 | Maintain current contact details | AWS Accounts created through Stax will follow your configured email address format. |
| 1.3 | Ensure no 'root' user account access key exists | |
| 1.4 | Ensure MFA is enabled for the 'root' user account | |
| 1.5 | Ensure hardware MFA is enabled for the 'root' user account | |
| 1.6 | Eliminate use of the 'root' user for administrative and daily tasks | Stax will automatically enable and configure Centralize root access for member accounts, this will prevent the automatic creation of root user credentials when a new AWS Account is created. Whilst Stax provides a secure default it is important to ensure that these root credentials are not enabled at a later date. |
| 1.7 | Ensure IAM password policy requires minimum length of 14 or greater | |
| 1.8 | Ensure IAM password policy prevents password reuse | As part of AWS Account Assurance Stax will set these IAM requirements for each AWS Accounts. |
| 1.11 | Ensure credentials unused for 45 days or more are disabled | Stax will deploy and manage an AWS Config Conformance pack to automatically disable these unused credentials. |
| 1.16 | Ensure a support role has been created to manage incidents with AWS Support | The stax-aws-support role is provisioned. |
| 1.19 | Ensure that IAM External Access Analyzer is enabled for all regions | Stax will configure an analyzer with a zone of trust for the entire AWS Organization. This is centralized into the Security AWS Account. |
| 1.20 | Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments | Stax provides each tenant with their own identity service which is configured as an identity provider for each AWS Account. This allows for AWS Access using role assumption. |
| 3.1 | Ensure CloudTrail is enabled in all regions | |
| 3.2 | Ensure CloudTrail log file validation is enabled | Stax will create and configure a multi-region Organization Trail. This will be automatically applied to all AWS Accounts in the AWS Orgranization. All logs are centralized into the cloudtrail CloudWatch Log Group in the management AWS Account. |
| 3.3 | Ensure AWS Config is enabled in all regions | Stax will configure this for all AWS Accounts. |
| 3.4 | Ensure that server access logging is enabled on the CloudTrail S3 bucket | |
| 3.5 | Ensure CloudTrail logs are encrypted at rest using KMS CMKs | All CloudTrail logs are written to an S3 Bucket within the logging AWS Account. |
| 4.1 | Ensure unauthorized API calls are monitored | See Note 1 |
| 4.2 | Ensure management console sign-in without MFA is monitored | See Note 1 |
| 4.3 | Ensure usage of the 'root' account is monitored | See Note 1 |
| 4.4 | Ensure IAM policy changes are monitored | See Note 1 |
| 4.5 | Ensure CloudTrail configuration changes are monitored | See Note 1 |
| 4.6 | Ensure AWS Management Console authentication failures are monitored | See Note 1 |
| 4.7 | Ensure disabling or scheduled deletion of customer created CMKs is monitored | See Note 1 |
| 4.8 | Ensure S3 bucket policy changes are monitored | See Note 1 |
| 4.9 | Ensure AWS Config configuration changes are monitored | See Note 1 |
| 4.10 | Ensure security group changes are monitored | See Note 1 |
| 4.11 | Ensure Network Access Control List (NACL) changes are monitored | See Note 1 |
| 4.12 | Ensure changes to network gateways are monitored | See Note 1 |
| 4.13 | Ensure route table changes are monitored | See Note 1 |
| 4.14 | Ensure VPC changes are monitored | See Note 1 |
| 4.15 | Ensure AWS Organizations changes are monitored | See Note 1 |
Note 1: Stax will create a number of filters and alarms based on the CIS recommendations above. Each of these will be filtering the Organization CloudTrail logs for events and centralizing any alarms to the SNS Topic stax-cis-benchmark in the security AWS account. It is recommended to subscribe your tooling or configure Amazon Q Developer to notify you of new messages published to this SNS Topic.
Requires opt-in configuration
| CIS 5.0.0 Ref | Description | Stax Considerations |
|---|---|---|
| 1.2 | Ensure security contact information is registered | Using the AWS Account Foundation service, Stax allows you to configure the Alternate Contact information to be applied to every AWS Account in your AWS Organization. This contact information will be applied to all new and existing accounts. |
| 1.9 | Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password | |
| 1.10 | Do not create access keys during initial setup for IAM users with a console password | |
| 1.12 | Ensure there is only one active access key for any single IAM user | |
| 1.13 | Ensure access keys are rotated every 90 days or less | |
| 1.14 | Ensure IAM users receive permissions only through groups | Stax discourages the use of IAM users as part of best practices. You can use Configurable Guardrails to Block the creation of any IAM users. |
| 2.1.4 | Ensure that S3 is configured with 'Block Public Access' enabled | Using the AWS Account Foundation service, Stax allows you to enable this option for all existing and new AWS Accounts. Additionally Configurable Guardrails can be enabled to prevent this option from being modified. |
| 4.16 | Ensure AWS Security Hub is enabled | Stax provides Security Hub as a seperate Foundation service that you can enable and configure. This will delegate the service to the security AWS Account and use central configuration to manage the entire AWS Organization. |
| 5.1.1 | Ensure EBS volume encryption is enabled in all regions | |
| 5.7 | Ensure that the EC2 Metadata Service only allows IMDSv2 | Using the AWS Account Foundation service, Stax allows you to enable this option for all existing and new AWS Accounts. Additionally Configurable Guardrails can be enabled to prevent this option from being modified. |
Customer shared responsibility
Recommendations below are complied with by Stax, but can be violated by customer configurations, so are considered "shared" responsibilities that must be addressed by both parties as shared responsibilities.
| CIS 5.0.0 Ref | Description |
|---|---|
| 1.15 | Ensure IAM policies that allow full ":" administrative privileges are not attached |
| 1.17 | Ensure IAM instance roles are used for AWS resource access from instances |
| 1.18 | Ensure that all expired SSL/TLS certificates stored in AWS IAM are removed |
| 1.21 | Ensure access to AWSCloudShellFullAccess is restricted |
| 2.1.1 | Ensure S3 Bucket Policy is set to deny HTTP requests |
| 2.1.2 | Ensure MFA Delete is enabled on S3 buckets |
| 2.1.3 | Ensure all data in Amazon S3 has been discovered, classified, and secured when necessary |
| 2.2.1 | Ensure that encryption-at-rest is enabled for RDS instances |
| 2.2.2 | Ensure the Auto Minor Version Upgrade feature is enabled for RDS instances |
| 2.2.3 | Ensure that RDS instances are not publicly accessible |
| 2.2.4 | Ensure Multi-AZ deployments are used for enhanced availability in Amazon RDS |
| 2.3.1 | Ensure that encryption is enabled for EFS file systems |
| 3.6 | Ensure rotation for customer-created symmetric CMKs is enabled |
| 3.7 | Ensure VPC flow logging is enabled in all VPCs |
| 3.8 | Ensure that object-level logging for write events is enabled for S3 buckets |
| 3.9 | Ensure that object-level logging for read events is enabled for S3 buckets |
| 5.1.2 | Ensure CIFS access is restricted to trusted networks to prevent unauthorized access |
| 5.2 | Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports |
| 5.3 | Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports |
| 5.4 | Ensure no security groups allow ingress from ::/0 to remote server administration ports |
| 5.5 | Ensure the default security group of every VPC restricts all traffic |
| 5.6 | Ensure routing tables for VPC peering are "least access" |