Banner Image: map pin to symbolize roadmap

Enhance Cloud Security with the AWS Security Maturity Roadmap &

Whether your cloud presence is big or small, cloud security is a key concern. Threats - internal and external - aren’t diminishing, so security remains a key foundational element of a successful and reliable cloud environment. Security is a key focus for us here at

Scott Piper of Summit Route recently released his annual AWS Security Maturity Roadmap. The roadmap highlights a series of actionable steps an organization can take to enhance security of their AWS cloud environment.

As I reviewed the Roadmap, there were several recommended actions that jumped out at me as ones you could easily accomplish with Here’s a look at Scott’s 10 stages of security maturity:  I’ve highlighted some checklist items within each stage and how you might achieve a highly secure cloud environment by using to execute security protocols and check these items off your list!

Stage 1: Inventory

  • Identify all AWS accounts in the company and their points of contact.
  • Integrate AWS accounts into AWS Organizations.
  • Create budget alarms. gives you an inventory of all accounts in your cloud environment. You can view them as a list or as a visual hierarchy in our Organizational Chart. leverages AWS Organizations to help establish new accounts, deploy service control policies (SCPs), and quickly bring your entire cloud footprint into the management structure. Using’s account creation functionality, it’s very easy to ensure the accounts are mapped back to their point of contact. You can also use this functionality as a way to trace back the initial request for a new account using our self-service approval workflows.

At, we have budget alarms but we think it’s important to go beyond an alarm. While we can inform you of an alert threshold, our budget enforcements take it one step further! These enforcements allow you to set configurable “actions” on an account (or many accounts) when a specific threshold is reached. Example actions include turning off your ec2 instances on the weekend, preventing a user from creating new resources, or even breaking down cloud resources in development or sandbox environments to stop cloud spend.

Stage 2: Backups

  • Create regular backups. cloud rules provide a proactive approach to backups, and backups can be executed in multiple ways with Cloud rules are collections of cloud-specific resources that can be applied to cloud accounts in a managed way. A cloud rule can deploy CloudFormation templates to enable S3, RDS, and/or EBS backup policies in each account. From a monitoring perspective, will keep a watchful eye on your accounts using our continuous compliance feature to verify and validate that backup policies are in place and in use across your environment.

There are benefits to taking a holistic approach to cloud governance and assessing the impact of your actions and choices across cloud access, cost, and security. Our savings opportunities feature ensures that your backups don’t sit in your accounts indefinitely and add unnecessary costs to your cloud bill. Savings opportunity checks will identify these snapshots and backups that should be aged out to less expensive storage options or deleted altogether.

Want to learn more about integrating your backup and recovery approach with your cloud governance approach? Join our upcoming webinar with N2WS.

Stage 3: Visibility and Initial Remediation

  • Turn on CloudTrail, GuardDuty, and Access Analyzer for all accounts to send their logs and alerts to the Security account.
  • Create an IAM role in every account that grants view access into the account from the Security account.
  • Run a one-time scanning tool to identify tactical remediations.
  • Turn on S3 Public Block Access.

Similar to the backup policies,’s cloud rules can be used to configure any service in AWS. The particular services called out here come out of the box as part of our managed reference library of policies, configurations, and infrastructure jumpstarts. For example, our CIS 1.2 Cloud Rule Jumpstart includes “CIS 1.2.0 Logging”, which ensures CloudTrail is enabled in all regions and configures logging to a private S3 bucket.

Creating an IAM role in every account is quick and easy using cloud access roles (CARs). The CAR can be placed at any level in the Organizational Chart hierarchy to be inherited by all accounts below. With just one CAR, you now have an IAM role in every account that select users can access to AssumeRole into that respective account. A perfect use case for this is when your organization has a requirement for your security team to access any account in the organization. Piece of cake! Make a CAR at the top-level organizational unit and never think about it again -- your security team can control access to that CAR via an Active Directory group and ensure full chain of custody is achieved.

As mentioned earlier, our continuous compliance feature will continually scan for and enable auto-remediation of findings such as identifying publicly accessible S3 buckets and blocking their public access.

Stage 4: Detection

  • Send alerts to a ticketing system.
  • Enable investigations to logs.
  • Perform regular scanning of the accounts for security issues. can interface with external ticketing systems in a number of ways. You can leverage native functionality from the underlying engine of our continuous compliance feature -- Cloud Custodian. We have customers who leverage the webhook functionality of a compliance check to not just post a finding to, but also to reach out to an external ITSM system like ServiceNow or JIRA to create a SecOps ticket to investigate, and if necessary, remediate the finding.

With so many intersections into traditional SecOps processes, there are a number of other integration opportunities. You can send findings into SIEM tools like Splunk, synchronize findings with AWS Security Hub, and even use an out-of-the-box cloud rule to handle Incident Response. This cloud rule strips out access to the account, takes automated backups of instances and databases, and preserves logs for your security team to roll up their sleeves and get into the weeds of the incident.

Stage 5: Secure IAM access

  • Use SSO for access.
  • Remove all IAM users.
  • Remove all unused IAM roles.
  • Reduce the privileges of service roles to necessary services.

Identity and access management is one of the three foundational pillars of a good cloud governance posture - and a core capability of By integrating with your identity provider (IdP) via SAML or LDAP, you can achieve single sign-on (SSO) across your environment in one step! After making a single configuration, you can leverage users’ group membership or roles to properly assign the appropriate cloud access roles to your users, ensuring secure single sign-on and user experience across AWS and Azure (coming soon for Google Cloud!).

Since uses federation into native AWS IAM roles, there is no need for IAM users, alleviating the risks of stale or expired access keys, shared accounts, or new passwords for users to remember. Service roles can be granted specific permissions using cloud access roles for similar role based access, and key rotation can be enforced to mitigate further risks.

Stage 6: Reduce Attack Surface and Mitigate Compromises

  • Apply SCPs.
  • Allow only approved services.
  • Have no publicly facing EC2s or S3 buckets. helps you create, manage, and apply service control policies (SCPs) with ease. By leveraging the organizational hierarchy defined within, your SCPs can be far more granular without limitations such as nested-level limitations. SCPs are attached to a cloud rule, and the cloud rule is applied to any desired OU. The SCPs are then inherited by the accounts below. As cloud rules can be exempted by end users, a simple approval mechanism can be used to tailor policies for a particular account or workload without needing full access to AWS Organizations. The cloud rules can contain SCPs to restrict access to unapproved regions or services to one or all accounts. In addition, can detect drift where you may have had infrastructure deployed in an unapproved region or used an unapproved service before you had a fully governed cloud.

When you need to make a change, you can easily update the SCP in one place within, and will modify it in all of your accounts via your cloud rules. Plus, you'll enjoy greater visibility into which SCPs are applied across your organization.

Regarding publicly facing EC2s or S3s, we have you covered with our continuous compliance feature. You can easily run checks to identify publicly accessible resources and, optionally, take a remediation action to close them. Ideally, your security policy in your cloud rules would prevent this from happening in the first place!

Stage 7: Reproducibility and Ownership

  • Use Infrastructure as Code.
  • Apply tagging strategy. leverages all of your cloud-native infrastructure as code (IaC) languages within cloud rules, including CloudFormation, Azure Resource Manager (ARM) templates, IAM policies, Azure Role Definitions, Service Control Policies, and Azure Policy definitions. To take this even further, these policies can be version controlled and managed under git source control to ensure policies can be managed, rolled back, or updated - even in a highly matrixed organization. By adopting IaC, provisioning new accounts with a fully governed landing zone is easier than ever.

With our proactive and reactive controls in place, enforcing a tagging policy from becomes a breeze. Using IAM/SCP policies to ensure that new resources are tagged is one approach, but leveraging continuous compliance to find and alert on untagged resources, or resources violating the tagging convention is also just a few clicks away.

Stage 8: Enhance Detection and Least Privilege Refinement

  • Implement real-time monitoring.
  • Implement automated remediation.

In addition to our compliance checks, performs real-time monitoring through its microservice architecture design. Our individual services sync to ensure that infrastructure and policy deployed by has not been tampered with. If sees an IAM policy has been modified, we’re going to put it back to the known good state -- yet another watchful eye doing your mundane cloud tasks for you. This prevents any intentional or unintentional changes in the cloud environment.

Stage 9: Secure Network Communications

  • Move all non-public network resources into private subnets and proxy outbound requests so you can filter and block them.

Managing a secure cloud network is one of the most challenging aspects of migrating to the cloud. Fear over one wrong click exposing your company's private information to the internet is what halts most cloud migrations. Using, you can leverage services like AWS Resource Access Manager (RAM) to share out that ready-to-go VPC into the account or just build in policy to configure your VPC, lock down route tables, Internet Gateways, or security group modifications. Once again, you can leave the heavy lifting to our continuous compliance feature to ensure your policy is working as expected -- no custom routes, no security groups, or implement a more tailored policy like “no internet gateways in non-prod accounts”. Additionally, CloudFormation templates attached to cloud rules can even delete default VPCs in accounts to further secure the network.

Stage 10:  Incident Preparation

  • Limit the blast radius of incidents.

How you handle the response and limit the exposure of a security breach is critical. Outside of the controls we’ve gone through above, the Incident Response cloud rule makes this extremely easy.  When applied, this cloud rule will lock down the account(s), restrict all ingress and egress traffic, snapshot databases and instances, and allow your security organization to investigate, respond, and recover with minimal impact. Once the incident has been resolved, simply remove the cloud rule and you’re back off to the races!


With Scott’s roadmap and some magic, you can establish state-of-the-art security for your cloud environment without the heavy lift. A final point to note: Scott’s roadmap is solely focused on AWS. is cloud agnostic: all the actions mentioned above are applicable to AWS, Microsoft Azure, and Google Cloud when using

About the author: Rabee is a solutions delivery manager at