This is the third annual release of my “AWS Security Maturity Roadmap” to give companies a series or actionable steps to improve the security of their AWS environments. Each year I update this with the latest features of AWS, along with improvements based on my discussions with clients, other consultants, and more who have gone through some of these activities or encountered challenges, or have mentioned new ideas. This includes companies of all sizes, risk tolerances, and integration (from lift and shift to completely serverless).

Changes include:

• Added that your root email addresses should be under your company domain and on email distribution lists as I’ve found many accounts during assessments that were associated with old aol.com emails and other personal accounts. This is how AWS communicates with you and is an important part of account recovery.
• Added opting out of the AI services from sending your data outside of the regions you put it in.
• Added budget alarms to Stage 1. Although less likely to provide as much value for larger enterprises, these are very important for individuals and small businesses. Also mentioned Cost Anomaly Detection and Budget Actions.
• Mentioned that you should consider using GuardDuty’s S3 monitoring, which for monitoring, is as an alternative to Macie.
• Mentioned the use of CloudFormation StackSets with Organizations which is an Organization feature that deploys a CloudFormation StackSet whenever a new account is created to ensure it is initialized with your baseline.
• Discussed using a ticketing system for alerts, as I’ve found the ways in which companies receive alerts to vary in maturity which impacts their ability to properly monitor and respond to incidents.
• Discussed turning on more log sources, such as VPC DNS queries, VPC Flow Logs, S3 access logs, etc. and linked to a post by Matt Fuller for a list of log sources on AWS: How to Enable Logging on Every AWS Service in Existence (Circa 2021).
• Mentioned that IAM user access keys, when required, should ideally be put in a single account and assume roles into other accounts as it makes detection of compromise easier.
• Mentioned that Access Advisor now shows the use of s3:ListAllMyBuckets, so you should use that to remove that specific privilege when not needed.
• Discussed the need to plan how accounts will be connected, as the security boundaries of separate accounts can become blurred due to trust relationships of resource policies, network connections, and other mechanisms.
• Expanded on the discussion of using SCPs to mention how exceptions can be made for specific roles, and SCPs can vary between accounts. Therefore, you can initialize an account by configuring it’s network configuration in advance and restricting changes via SCPs, such that a dev account may be restricted from making any resources public. Also listed possible SCPs to deploy, which are described in my post AWS SCP Best Practices.
• Mentioned former2 for helping transition to IaC (Infrastructure as Code).
• Mentioned that IaC scanning tools can be used, referencing Christophe’s post Shifting Cloud Security Left — Scanning Infrastructure as Code for Security Issues.
• Removed mention of Tag Policies as this service is limited in various ways that make it not worth bothering with.
• Merged “Stage 8: Enhance detection” and “Stage 9: Auto-remediation and privilege refinement” into one stage. Mostly because I wanted this to be 10 stages. :)
• Mentioned Client Side Monitoring as part of the least privilege improvements, and linked to the cloudonaut article Record AWS API calls to improve IAM Policies.
• Mentioned the AWS Network Firewall as a solution for monitoring and protecting your networks.
• Mentioned the use of microservices to access resources instead of direct access so that better monitoring, restrictions, and rate limiting can be performed.