Instructions

Template Revised Jan 4, 2025.

Global Search and Replace these persona and teams and parameters to apply to your organization. Then delete what you don’t want.

COMPANY - The name of your company
SECURITY_TEAM - The name of your security team, InfoSec, ISO, Security, whatever
CENTRAL_CLOUD_TEAM - If you have a centralized cloud engineering, center-of-excellence, governance, team, that’s this placeholder. If you don’t have that, I’m sorry.
NETWORK_TEAM - In larger orgs, there is probably a team than manages the networks, VPNs, fiber lines, etc. They care about overlapping IPs and segmentation. This is that group.
LOG_RETENTION_IN_DAYS - Placeholder for how long you want to keep your logs.

INTRODUCTION

This document defines the minimum security requirements for the configuration of AWS accounts and services. As part of COMPANY’s obligations under the Shared Responsibility Model, COMPANY is responsible for protecting the confidentiality, integrity, and availability of its applications and data in AWS.

The use of cloud services - defined as all external cloud services including document storage, Software as a Service, Platform as a Service, and Infrastructure as a Service - must comply with other existing COMPANY Security Policies.

Scope & Applicability

This Baseline applies to all AWS Accounts belonging to COMPANY or any COMPANY Affiliate. Compliance to this baseline is mandatory for all account owners.

COMPANY’s applications running in AWS may have additional regulatory or legal requirements (PCI, GDPR, SOX, etc) that require stronger controls than standard applications. If an AWS account contains any of these sensitive applications, the stronger controls apply to all cloud resources in that account.

Terms

Regulated Application - Any application that is subject to PCI, COPPA, GDPR, CPPA, etc., is considered a Regulated Application.
Regulated Data - Any data that is subject to PCI, COPPA, GDPR, CPPA, etc., is considered Regulated Data.
Regulated Account - Any AWS Account that contains a Regulated Application or stores Regulated Data is considered a Regulated Account, and all resources in the account must adhere to the controls specified for Regulated Accounts.
Must - As defined by RFC 2119 and adopted by COMPANY, means that the statement is a mandatory requirement of this baseline.
Should - As defined by RFC 2119 and adopted by COMPANY, means that there may exist valid reasons in particular circumstances to ignore a particular statement, but the full implications shall be understood and carefully weighed before choosing a different course.

Responsible Parties

SECURITY_TEAM
SECURITY_TEAM has a mission to create a secure and resilient cybersecurity program that enables BLAH BLAH BLAH

CENTRAL_CLOUD_TEAM
CENTRAL_CLOUD_TEAM has responsibility for overall cloud governance and the creation and management of cloud accounts. No AWS Account should be created outside of the CENTRAL_CLOUD_TEAM standard process, and CENTRAL_CLOUD_TEAM should have administrative access to all AWS accounts as part of its cloud governance function. If the cloud governance function for a COMPANY Affiliate is not provided by CENTRAL_CLOUD_TEAM, SECURITY_TEAM will designate another group or team to fulfill the responsibilities of CENTRAL_CLOUD_TEAM for the Affiliate.

NETWORK_TEAM
The NETWORK_TEAM managed the COMPANY network, and is responsible for all IP Address assignments.

Account Owner
The Account Owner will consist of an Executive Owner (VP or higher) and a Technical Contact. Both must be employees of COMPANY, Inc. or an Affiliate. The Executive Owner is accountable to security, finance, and cloud governance for all activities in the account. The Technical Contact is the primary point of contact for issues related to security, finance and governance for the AWS Account.

Exceptions to this Baseline

INSERT your company’s risk acceptance or policy exception process here.

REQUIREMENTS

Account Management
1. Asset Management
  1. All AWS Accounts must be in COMPANY’s Asset Inventory or CMDB.
  2. The CMDB record for an account must contain the Executive Owner and Technical Contact
  3. The CMDB record for an account must link to the applications running in the account.
  4. The CMDB record must contain an emergency escalation path for the account and application owners.
  5. All Accounts should have Primary and Alternate Contacts (Security, Billing, and Operations) set.
2. Organizations
  AWS Organizations provides an additional layer of protection that is managed outside of the specific protected AWS account. It will prevent specific actions (outlined below) from happening if an account compromise occurs.
  1. All Organizational Management (Payer) Accounts must enable Full Organizations.
  2. All Member accounts must accept the Organization Invite.
  3. All AWS Accounts must be part of an approved COMPANY AWS Organization.
  4. AWS Service Control Policies must be applied to all accounts to:
    - Protect against modification to CloudTrail
    - Prevent an account from leaving the organization
    - Prevent an account enabling or opting in to new AWS Regions
    - Prevent the use of the root user
  5. Enabling new regions requires the approval of SECURITY_TEAM (so monitoring can be established) and CENTRAL_CLOUD_TEAM.
  6. Each AWS Organization must have a Delegated Admin Account for the purposes of running security tooling that supports AWS Organizations. This Delegated Admin Account will be owned by SECURITY_TEAM.
  7. AWS Organization Management accounts must not run production workloads
  8. All AWS Accounts must enable Enterprise Support
  9. AWS Resource Control Policies must be applied to all AWS Accounts to:
    1. Prevent ransom attacks leveraging kms:DeleteCustomKeyStore and kms:DeleteImportedKeyMaterial
  10. AWS Declarative Policies must be applied to all AWS Accounts to enforce:
    1. EBS Snapshot Block Public Access (snapshot_block_public_access)
    2. AMI Block Public Access (image_block_public_access)
    3. IMDSv2 Enforcement (instance_metadata_defaults)
3. Root User
  1. The root email address for an account must be a distribution list, and cannot be an employee’s direct email. In addition to account owners CENTRAL_CLOUD_TEAM must be a member of the distribution list. The root email distribution lists must be monitored for security alerts sent by Amazon.
  2. The Organizational Management account root password & MFA token must be controlled by CENTRAL_CLOUD_TEAM.
  3. The Organizational Management account root password and MFA must not be stored in the same password or secrets repository.
  4. Root API Keys must not exist.
  5. Root User must not be used for day to day activities.
  6. All accounts, other than the Organizational Management account, must leverage Centralized Root Management.
  7. Only the CENTRAL_CLOUD_TEAM should have permissions to sts:AssumeRoot. This should be enforced with a permission boundary on all principals in the payer account.
4. CloudTrail
  1. All AWS Organizations must have an organizational-level CloudTrail configured for management & read events in all AWS regions with Integrity Validation enabled.
  2. All CloudTrail events must be written to a SECURITY_TEAM approved central S3 Bucket with MFA delete or other suitable control to prevent an account admin from deleting CloudTrail events.
  3. All CloudTrail events must be fed to the SECURITY_TEAM SIEM.
  4. CloudTrail S3 Object level logging must be enabled for all buckets in any account that processes Regulated Data.
  5. Organizational Member Accounts should have access to the CloudTrail events generated by that account in the SECURITY_TEAM approved central S3 Bucket.
5. Security Tooling
  1. GuardDuty must be deployed in all enabled regions via Delegated Admin account. All GuardDuty findings will be sent to SECURITY_TEAM, however account owners may subscribe to GuardDuty findings from their own accounts.
  2. IAM Access Analyzer must be enabled via Delegated Admin account.
  3. The Security Contact must be set for all accounts. The following contact information should be set:
    
    Full Name: COMPANY SECURITY_TEAM
    Title: Security Operations
    Email Address: cloudsecurity@COMPANY.com
    Phone Number: CHANGE_ME
  4. The SECURITY_TEAM Audit Role must be deployed in all accounts
  5. The SECURITY_TEAM Incident Response Role must be deployed in all accounts
6. Tagging
  1. All AWS resources should be tagged according to CENTRAL_CLOUD_TEAM standards.
  2. At minimum an owner/contact tag must be applied to all resources for SECURITY_TEAM Incident Response escalation. To facilitate automation, owner/contact value must be in the form of an email address.
IAM
1. Employee & Contractor Access
  1. AWS Identity Center must be used for all human access to AWS console and APIs.
  2. The COMPANY Single Sign On solution must be used as the identity provider for AWS Identity Center.
  3. Access for Employee & Contractors must adhere to the principle of least privilege and be commensurate with job-function.
  4. Access to AWS must follow a formal approval process.
  5. Other Single Sign On and Identity Providers must be reviewed and approved by SECURITY_TEAM to ensure appropriate password complexity, MFA, logging, and lock-out controls are enabled.
2. IAM Users
  1. IAM Users should be limited only to necessary use-cases like on-prem services communicating with cloud services. These shall be referred to as “Service IAM Users”.
  2. If used for any reason, human access via IAM User usernames should be in the form of their corporate email address
  3. IAM Users must be deprovisioned within 24 hours of an authorized user having been terminated.
  4. All IAM Users with LoginProfile must enable MFA.
  5. Access keys must be rotated every 180 days. Access keys in Regulated Accounts must be rotated every 90 days.
  6. IAM Users LoginProfile or Access Keys inactive for more than 90 days must be disabled by the account owner, and removed after 120 days.
  7. IAM Password Complexity must be enforced with the following AWS Account Password Policy:
```
{
	"PasswordPolicy": {
    	"MinimumPasswordLength": 16,
    	"RequireSymbols": true,
    	"RequireNumbers": true,
    	"RequireUppercaseCharacters": true,
    	"RequireLowercaseCharacters": true,
    	"AllowUsersToChangePassword": true,
    	"ExpirePasswords": true,
    	"MaxPasswordAge": 90,
    	"PasswordReusePrevention": 8,
    	"HardExpiry": false
	}
}
```
3. Service IAM Users
  1. Service IAM Users must not have Login Profile enabled.
  2. Service IAM Users must be tagged with the person or team accountable for access key rotation.
  3. Service IAM Users must be least-privilege, accessing only the specific resources required.
4. Cross-Account Roles Trust
  1. Access to a COMPANY AWS account via the use of IAM Roles granting cross-account trust from a non-COMPANY account must be approved by and registered with the SECURITY_TEAM.
  2. A Resource Control Policy should be applied to all accounts denying cross-account role assumption from outside the Organization, unless the account is approved by and registered with the SECURITY_TEAM.
VPC & Networking
1. VPCs
  1. Application environments (Dev, Test, Prod) should be separated into separate VPCs, or preferably separate accounts.
  2. Where an account is scoped for PCI, separate accounts must be used for production and non-production environments in order to implement separation of duties.
  3. VPCs must be created from patterns approved by SECURITY_TEAM & the NETWORK_TEAM
  4. AWS Default VPCs must be removed
  5. All VPCs must leverage IP Space assigned by NETWORK_TEAM
  6. EC2 Classic must not be used
  7. VPC Flowlogs should be enabled for all Regulated or other high-risk accounts as defined by SECURITY_TEAM. VPC Flowlogs must be sent to an S3 Bucket approved by SECURITY_TEAM.
  8. VPC Endpoints should be created for S3 and DynamoDB.
  9. Elastic Network Interfaces (ENIs) should not bridge VPCs.
2. Network Security Controls
  1. Security Groups must not allow world access (0.0.0.0/0) to management ports such as 22 or 3389
  2. Security Groups must not allow world access to insecure ports (telnet, ftp, database protocols, etc)
  3. Security Groups must not allow world access to all ports (0-65535)
3. VPC Interconnections
  1. All Direct Connects must terminate at an SECURITY_TEAM approved firewall
  2. VPNs to on-prem must terminate at an SECURITY_TEAM approved firewall
  3. All use of Client VPN must have SECURITY_TEAM review for the purposes of user management, authentication, and logging in order to comply with COMPANY VPN Standards.
  4. AWS Client VPN should be integrated with AWS Identity Center.
  5. Any network peering with a non-COMPANY entity must have SECURITY_TEAM and legal approval.
  6. All use of Amazon WorkSpaces Web (formerly WorkLink) must be reviewed by SECURITY_TEAM for data sensitivity purposes.
Workloads
1. EC2
  1. EC2 Instances should be launched from AWS-provided AMIs. Marketplace AMIs should be reviewed by SECURITY_TEAM prior to use.
  2. Secrets must not be stored in EC2 UserData.
  3. EC2 Instances should report into AWS Systems Manager (formerly known as SSM).
  4. EBS Block Public Access must be enabled. EBS Snapshots must never be made public. This will be enforced by an AWS Organizations Declarative Policy.
  5. AMI Block Public Access must be enabled. AMIs must never be made publicly available. This will be enforced by an AWS Organizations Declarative Policy.
  6. All EBS Volumes must be encrypted.
  7. Default Encryption for new EBS Volumes should be enabled using default keys. Where technically feasible, Regulated Account default encryption should use KMS-CMK.
  8. EC2 Instances must leverage the Instance MetaData Service version 2 (IMDSv2) in order to mitigate the risk of credential theft (HttpTokens == required & httpPutResponseHopLimit == 1). This should be enforced by an AWS Organizations Declarative Policy.
  9. EC2 Instance Connect (leveraging EC2 Instance Connect Endpoint) is recommended for remote access to instances in public & private subnets.
  10. EC2 Instances should not have public IP Addresses.
  11. Amazon LightSail should not be used.
2. Containers
  1. Containers must leverage AWS Secrets Manager or another SECURITY_TEAM-approved secrets store in order to securely retrieve and manage secrets.
  2. Elastic Container Registries (ECR) must not be made public.
  3. Container/Container Orchestration control planes must restrict access to COMPANY owned IP space or approved management systems.
  4. EKS Clusters must not have public endpoints.
  5. Containers should use immutable tags.
3. Load Balancers
  1. Load Balancers should be configured to redirect all HTTP requests to HTTPS
  2. SSL Certs tied to ALB/ELB services should be stored in AWS ACM
  3. ELBSecurityPolicy-FS-2019-08 should be used unless ELBSecurityPolicy-TLS-1- 2-Ext-2018-06 is needed for client compatibility.
  4. Load balancers should enable logging.
4. Logging
  1. EC2 Instances must export default system logs (ie /var/log/messages, /var/log/secure) to an external logging system. If one is not available they should log to CloudWatch Logs
  2. Application Logs should be exported to a logging system not on the EC2 Instance.
  3. CloudWatch Log retention must not be set to less than 90 days, unless the logs are exported to another storage location.
5. Cloud Workload Asset LifeCycle
  1. Instances should live no more than XX Days
  2. AMIs should be rebuilt every 90 days
  3. Containers should run for no longer than X days
S3
1. S3 Buckets must enable default encryption, Default Encryption with KMS-CMK is required for all buckets in Regulated Accounts.
2. S3 Buckets should disable ACLs. A Resource Control Policy should be applied to all accounts to prevent the creation of S3 Buckets that support ACLs.
3. Unless they must be publicly readable, S3 Buckets must enable block public access with the following settings:
```
	{
	"BlockPublicAcls": true,
	"IgnorePublicAcls": true,
	"BlockPublicPolicy": true,
	"RestrictPublicBuckets": true // <unless cross account access is required>
	}
```
4. All AWS Accounts that process Regulated Data must enable Block Public Access at the AWS account level.
5. S3 Buckets must not be publicly listable
6. S3 Buckets must not be publicly writable
7. S3 Buckets that are publicly readable must be reviewed by SECURITY_TEAM
8. S3 Buckets that are publicly readable must enable S3 Data Events in CloudTrail, or with approval of SECURITY_TEAM, S3 Access Logging.
9. S3 Buckets should use CloudFront rather than Static Website Hosting.
10. S3 Buckets fronted by Cloudfront should leverage Origin Access Identity.
11. S3 Data Events in CloudTrail must be enabled for all buckets in Regulated Accounts.
12. S3 buckets containing Regulated Data should have a bucket policy that conditionally grants access based on a VPC Endpoint
13. Public S3 Bucket Security Requirements
  S3 buckets that allow read access anonymously or from all AWS Customers is a valid use of S3. All such Public S3 Buckets must adhere to the following requirements:
  1. Public Buckets must have a data-classification tag with a value of “public”.
  2. All Public S3 Buckets must be disclosed and approved as part of the Security Architecture Review Process
  3. S3 Bucket Policies & ACLs must not allow world write or full control for “Everyone” or “All AWS Users” to modify the Objects or Buckets.
  4. S3 Access Logging should be enabled for all public buckets.
WAF & Shield
1. AWS Web Application Firewall (WAF)
  1. All publicly exposed ALB, API Gateway and CloudFront Distributions must have a SECURITY_TEAM approved WAF attached.
  2. Working with the account owners, SECURITY_TEAM will define the required rule sets for each WAF.
  3. SECURITY_TEAM must have cross account permissions to programmatically manage specific allow and block lists on every AWS WAF
  4. All AWS WAF deployments must enable logging. WAF Logs must be written to S3 and Bucket Replication configured to copy into the SECURITY_TEAM Logging account
2. Shield
  NOTE: Shield Advanced is an expensive service ($36k/yr with a one year commitment). Do NOT Adopt this Policy Statement without proper review and diligence on the efficacy of the service for your specific threat model.
  1. All public endpoints should have Shield Advanced enabled. SECURITY_TEAM must have the proper permissions to subscribe to Shield Advanced and set SRT escalation to Security Operations in case of a DDOS attack.
Managed Databases
AWS Managed Databases consists of RDS, Aurora, Amazon DocumentDB, Amazon Quantum Ledger, AWS Managed Blockchain, Amazon Neptune, and Amazon Timestream.
1. Managed Databases must use KMS Encryption (AWS managed keys).
2. AWS RDS, Amazon Redshift, and Amazon DocumentDB Databases must not have public IP addresses.
3. Auto Minor Version Upgrade should be enabled on RDS databases.
4. Where available, all managed databases must use TLS Encryption for accessing the database.
5. RDS Logs should be collected and retained for no less than 90 days.
6. Managed Databases must have volume encryption enabled.
7. Database Snapshots must never be made public.
Lambda & API Gateway
1. Lambda Functions must not be publicly invocable.
2. Lambda Layers must not be shared publicly.
3. Lambda Functions must not use End-of-life Lambda runtimes.
4. Lambda Functions must leverage AWS Secrets Manager or another SECURITY_TEAM approved secrets store in order to securely retrieve and manage secrets.
5. When using Lambda Containers, the container image must be sourced from a COMPANY owned Elastic Container Registry.
6. All API Gateways must enable access logging.
7. API Gateways should implement proper authentication (API Keys, Cognito, Lambda Authorizer) depending on the use-case.
AWS Backup
1. AWS Backups Vaults should be created in every region in use.
2. SECURITY_TEAM AWS Backups Plans should be created in every region in use.
Other Services
1. General Encryption Statement
  1. Any AWS Services that stores sensitive data must enable the AWS provided KMS Encryption. If an AWS Service does not support KMS for data-at rest encryption, please engage SECURITY_TEAM for provisional approval.
  2. Where technically feasible, Regulated Accounts should use KMS-CMK with least-privilege key policies
2. Resource Policies
  Many AWS Services support Resource Policies - IAM policies that are attached to specific resources and define specific principals that may access the resource. If used improperly, Resource Policies can make resources publicly accessible or accessible outside COMPANY.
  1. AWS Resource that supports Resource Policies must not permit access to “Principal: *”. This signifies all AWS Customers or unauthenticated (anonymous) access.
  2. AWS Resource Policies should not trust AWS accounts not owned by COMPANY, unless a legal agreement is in place between COMPANY and the account owner.
3. OpenSearch
  1. AWS Managed OpenSearch must require IAM Authentication to access OpenSearch, they cannot be internet exposed with no authentication.
  2. OpenSearch must enforce encryption-at-rest and in transit.
4. AWS Simple Email Service (SES)
  1. SES must use Email Address Identities for verification of Identities allowed to send email.
  2. SES should not allow arbitrary sending from COMPANY’s primary email domains without explicit permission from SECURITY_TEAM.
  3. SES should be denied by SCP in all accounts where it is not needed.
5. Route53
  1. Any domain registered by an Account or Application Owner in AWS’s Route53 Domains registrar service will be reviewed by COMPANY Legal. COMPANY Legal may instruct the Account Owner to modify registration information or transfer the domain into the possession of the COMPANY Legal.
  2. In AWS accounts subject to PCI-DSS, internal RFC-1918 addresses are not permitted in public HostedZones
  3. Route53 resource records must be deleted when the resource they point to is deleted.
6. Workspaces
  1. AWS Workspaces should leverage IP Access Control to limit direct access from the internet.
  2. AWS Workspaces should enable volume encryption.
  3. AWS Workspaces must leverage COMPANY Active Directory for authentication.
7. KMS
  1. ~~KMS Key Rotation must be enabled~~ (Don’t do this unless you have a specific verified regulatory requirement. It’s expensive and provides minimal security value. )
  2. AWS KMS Key Policies should not Deny kms:describe* actions.
  3. A Resource Control Policy should be applied to all AWS accounts to limit KMS Key access to the AWS Organization.
  4. A Resource Control Policy must be applied to all Regulated AWS accounts to limit KMS Key access to the AWS Organization.
8. CloudFront
  1. All CloudFront Distributions must use TLS1.2 or greater.
  2. All CloudFront Distributions must enable logging.
  3. All CloudFront Distributions must have an SECURITY_TEAM approved WAF applied.
  4. CloudFront VPC Origins should be leveraged and origins should be inside of a VPC where possible.
9. AWS Secrets Manager
  1. In Regulated Accounts, secrets, passwords, and other long-term credentials must be stored in AWS Secrets Manager (not AWS Parameter Store) with least privilege IAM policies.
  2. A Resource Control Policy should be applied to all AWS accounts to limit secret access to the AWS Organization.
  3. A Resource Control Policy must be applied to all Regulated AWS accounts to limit secret access to the AWS Organization.
10. AWS Chatbot
  1. AWS Chatbot should not allow write-access to an AWS account in public slack channels, or channels that have external collaborators.
11. GitHub Actions and other external CI/CD
  1. IAM Users should not be used for external CI/CD systems.
  2. GitHub Actions OIDC Roles must set the token.actions.githubusercontent.com:sub to include both the organization and repository.
12. Generative AI Services
  1. Access to Amazon Q and Amazon Bedrock should be denied by SCP in all accounts where it is not needed.
  2. Amazon Bedrock must enable Model Invocation logging to an S3 Destination. Teams can choose to also log text prompts to CloudWatch Logs as needed.
  3. If Bedrock accepts unfiltered prompts from users, the model invocation logs should be in a bucket with restricted access.
13. AWS Marketplace
  1. The ability to subscribe to Marketplace agreements, subscriptions, and private offers must be limited by SCP to only the CENTRAL_CLOUD_TEAM and COMPANY procurement team, with review from SECURITY_TEAM’s third-party risk management function.

Appendix A - Definitions

Asset: Hardware, Software, Systems, Applications, Data, Content, or other Assets in any form to support COMPANY’s business operations, whether belonging or entrusted to COMPANY, including information about employees, business operations and plans, customers, and business partners.
Cloud Services: Defined as any service made available to users on demand via the internet from a cloud computing provider’s servers as opposed to being provided from a company’s own on-premises servers. Cloud Services include, but not limited to Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).
Customer Details: Customer Details is information which belongs to a customer or consumer that COMPANY collects, processes, stores or transmits in connection with, or generates as a result of, providing products or services to that customer or consumer. Examples include consumer Personal Information, consumer account information, and technical and usage information.
Data Custodian: An individual with operational responsibility for protecting the Confidentiality, Integrity, and Availability of Data according to the requirements and Data Classification established by the Data Owner. For the purposes of this Baseline, the Account Owner is the Data Custodian for all data stored in the cloud account.
Data Owner: An individual, team, or department who has primary responsibility for a set(s) of COMPANY proprietary or Customer Data and is responsible for ensuring process and controls are in place to safeguard appropriate acquisition, use, and distribution.
Information Technology (IT) Asset: Hardware, Software, Systems, Applications, or other Assets in any form to support COMPANY’s business operations, whether belonging or entrusted to COMPANY, including information about employees, business operations and plans, customers, and business partners. For the purposes of AWS, the AWS Account itself an IT Asset, and the AWS resources deployed in that account are also IT Assets.
IT Asset Administrator: An individual who has primary responsibility for the provisioning, deprovisioning, and other responsibilities related to access for an IT Asset. For the purposes of this Baseline, the Account Owner, and CloudEngineering Team are the IT Asset Administrators the cloud account, while the Application Owner is the IT Asset Administrator for resources created in support of their application.
Privileged Access: Any account with elevated privileges. These accounts include but are not limited; to domain/enterprise administrators, account administrators, Database administrators, Network administrators, or local System administrators. Unless the account has tightly scoped IAM permissions, access to the AWS Console or API is considered privileged access.
Resource Policies: Policies that are attached to an AWS resource granting access to the resource. This can include roles and users in the account along with other AWS Accounts.
COMPANY Cloud Accounts: Any AWS Account paid-for and managed by COMPANY, its employees for affiliates.