AWS have released their own security maturity model, which contains a lot of detail on their take as to how to secure your AWS estate. Does it stack up against what we’re seeing in real-world attacks, or the approaches being suggested by the rest of the AWS security community? Unfortunately, I’m not convinced, and I’ll lay out why below.
Table of Contents
- Update: 2022-05-29
- What is a Security Maturity Model?
- A Summary of the AWS Security Maturity Model
- How Should You Use a Maturity Model?
- Where Does it Shine, and Where Does it Fall Short?
- What Are the Other Options?
- Where Should AWS Take This?
Update: 2022-05-29
I passed this onto Dario Goldfarb, the solutions architect driving the maturity model, and we’ve since had a productive, frank and open discussion about much of the content here. It’s become apparent that at least some of my disagreements reflect that I’m used to working in more mature markets, with organizations who have access to AWS specialists even if not dedicated security teams. This maturity model, especially the quick wins, reflects quick wins that are frequently effective in smaller organizations in less mature markets.
Dario’s been kind enough to quickly update the model in light of some of the feedback here, in particular making mention of third party options to reduce the apparent AWS bias around things like WAF and Security Hub (mentioning alternatives like Cloud Custodian and a few of the commercial options). I’ve included some clarifications throughout this post (you’ll notice struck through text and “UPDATE:” markers as you read). I look forward to working more with him on the team on this going forward.
I also think it’s important to call out that at least some of my criticisms here are the result of AWS’ institutional fear of accidentally scaring customers with the realities of security in the cloud, and the kind of attacks that are regularly perpetrated in the wild. That inherently limits what can be presented and discussed in content with AWS branding on it. One can’t blame the authors of the model for corporate policy, though.
What is a Security Maturity Model?
The core goal of security work should be to ensure organizational resilience against expected attacks, as appropriate for risk appetite and budget. One of the more common ways to approach this is to define a desired end state, benchmark the organization against it, then define several phases of work with measurable deliverables or improvements to iterate over. There’s a few popular ones for cybersecurity in general:
A lot of these, especially those driven by government organizations, can be unwieldy, complex and difficult to directly translate to real action. The UK National Cyber Security Center (which informs most aspects of UK government cybersecurity practices, with a strong influence on the private sector) withdrew its support for the maturity model it previously published. The industry as a whole is also questioning whether maturity models, in their usual format, are even a good idea. It’s well worth reading over that post to understand the limitations of maturity models. That said, the overall approach has been found to be valuable by many organizations, and they’re certainly a lot easier to work with when they’re more targeted and prescriptive as AWS have done here.
A Summary of the AWS Security Maturity Model
The AWS Security Maturity Model is a newly released set of guidance and documentation from AWS, intended to help an organization assess their security maturity, shape their cloud security strategy, and to prioritise future work accordingly. It’s based on AWS’ idea of how to secure workloads deployed on their systems, and makes extensive use of their services to achieve what they consider to be a strong security posture. It cross references numerous other sources, including the AWS Well Architected Framework Security Pillar, their security documentation, and a number of previously published whitepapers.
When it comes to security maturity models, the devil is usually in the details. It’s all about what and how to prioritise with the limited budgets and effort available to your average organization. In AWS’ case, they’ve made their prioritization decisions based on what they deem to be the quickest wins with the biggest benefits, outlined by their model here.
AWS breaks down their maturity model into four phases, as show in the table below. I’ve lifted it wholesale from their documentation here: https://maturitymodel.security.aws.dev/en/model/. I’ve included it here for ease of reference, and maintained the original links to their documentation to allow you to dive directly into specific pieces.
How Should You Use a Maturity Model?
Security maturity models like this are generally intended as a starting point, a framework to build on. It’s important that whatever maturity model you take, you tailor it to your organization’s situation and needs. In practice, a good, actionable maturity model will be tweaked by an organization before it’s applied by three things:
- Real world threat intelligence to inform what you’re defending against
- Any regulatory requirements (GDPR, PCI DSS, SOC2, HIPAA, etc)
- An organization’s budget and risk appetite
I’m no expert on the compliance or risk side, but I’ve several years of experience breaking into and defending cloud environments at the technical level. As such, what I’m saying will be largely coloured by the idea of building technical resilience against real world attacks, rather than accounting for compliance requirements. To support that, I’ll also be using Rami McCarthy’s database of AWS customer security incidents and other assorted cloud breach data. Looking at his dataset and the associated presentation, you’ll see several themes here, and these tally with my experience:
- Public S3 buckets and leaked credentials are so common that he’s not bothered tracking all these incidents
- Stealing valid credentials is the most common way attackers gain access
- Exploiting applications, especially Server-Side Request Forgery (SSRF) to steal credentials from the EC2 instance metadata service, is also common initial access vector
- Many breaches are exacerbated by poorly configured IAM permissions
- Most publicly known breaches are relatively low sophistication.
This slide on initial access on public breaches from Rami’s accompanying talk also presents a pretty clear picture on initial access mechanisms:
This is also borne out by the results of the latest Verizon Data Breach Investigations Report, which shows credentials are clearly top of the list of initial access vectors.
Between all of that, we’ve got a pretty clear idea of the things that matter when it comes to preventing a breach. Other key priorities for early stages of a security program should be:
- An asset inventory, so we know what we’re defending
- Recovery - verified backups, a way to recreate infrastructure, and a basic disaster recovery plan
- Some basic scanning for:
- Simple misconfigurations - Prowler and ScoutSuite are popular options for this
- Secrets in places they shouldn’t be, like git repositories - TruffleHog is my usual favourite here
Where Does it Shine, and Where Does it Fall Short?
There are several areas where I think AWS have done really well with the model:
- They’re calling out a lot of great continuous improvement practices - Threat modeling, security champions in dev teams, involving security teams in the development work, sharing security work across teams and so on. These reduce the cost of cloud security and increase organizational velocity.
- There’s a clear focus on automation - Automated remediation of misconfigurations, automating response playbooks, pipelines for building and deploying security critical components. Automation is absolutely critical to scaling cloud security in larger organizations.
- They’re highlighting a lot of things that would prevent many breaches I see - S3 public access, several different components around IAM and least privilege, avoiding secrets in your code. At least some of this is reflective of real world threat intelligence.
- Backups as a foundational capability - Incredibly important, but uninteresting and often not as much of a priority as they should be.
- It’s well sourced - lots of good links out to other content, both from AWS and other organisations such as NIST and CIS.
That said, there are several key areas where I think this model has missed the mark, and we’ll break them down one by one. Before I do though, I want to make two things clear:
- This is not intended as a critique of the experience or capabilities of the individuals who have worked hard to produce this - it’s clear a lot of hard work has gone into this maturity model, and I view it as an institutional issue on AWS’ part that this was released in an official capacity without broader support and review.
- I have my own biases that inform my critique here. I’m by no means perfect, and I come from a background that will shape my take here:
- I’m an offensive security specialist - I spend my time trying to break into AWS estates, and so I focus on prioritising effort and controls that stop, spot, or support response to the kinds of breaches I see achieved on a weekly basis.
- I have little experience with the governance, risk and compliance side of security, which means I’ll inevitably downplay some components and controls that matter more in that space.
- I’m used to working with forward-thinking, and often large, organizations - my recommendations will bias towards well-funded security teams with strong AWS specialists.
Many “Quick Wins” Don’t Move the Needle
It’s always tempting in security to focus on quick wins - things you can do that look like they’re going to jump your security posture ahead. Given what was established in What Matters in a Security Model? above, how do the list of quick wins affect the core themes from publicly available breach data? Only five of the fifteen quick wins prevent or reduce the damage presented by those breach scenarios and key themes:
| Quick Wins | Useful For: | But… |
|---|---|---|
| Multi-Factor Authentication | Preventing abuse of valid credentials | UPDATE: Clarified in the model now, and I agree with the recommendations now made. |
| Avoid using Root and audit it | Preventing abuse of valid credentials | UPDATE: Clarified in the model to recommend IAM users as a temporary solution to avoid root account usage, which makes sense until an SSO is in place. |
| Access and role analysis with IAM Access Analyzer | Reduce IAM misconfigurations | Without an accurate inventory, it’s difficult to contexualise and action any findings. UPDATE: It’ll catch the absolute worst of external access violations, like externally granted admin access. Likely still a quick win for low maturity environments. |
| AWS WAF with managed rules | Application/IMDS exploitation* | A WAF is also only useful if the app was insecure in the first place and the payload is basic enough to be signatured. UPDATE: The WAF comparison is out of date, and the maturity model now makes reference to third party options. This might be a useful option if you’re not confident in the security posture of your applications. |
| Amazon S3 Block Public Access | Prevent public S3 buckets | Nothing - this is a quick and very big win |
In my opinion, the point of investing in quick wins in security is usually to buy time to address the deeper issues - if the quick wins don’t support that, then they’re a time sink, however quick they are.
I think it’s important to be clear here - some of the other quick wins are still very important, and I wouldn’t want to claim otherwise. Enabling CloudTrail & GuardDuty is one of the first things I usually do. That said, turning on Macie, Security Hub and Trusted Advisor straight out the gate doesn’t always necessarily get you very much that matters. Running Prowler will get you further, faster in my experience, if you’ve got the know-how to use it, interpret and action the results.
One big thing is missing off the list of quick wins, too - enforcing IMDSv2 on EC2 instances. This complicates a common attack vector and presents very little risk of breaking things in an environment using reasonably modern version of the AWS SDKs. It’s also a much more effective control than a WAF against SSRF attacks, which have proven to be the most prolific cloud native application attack vector. UPDATE: In some environments this may break things. If you have legacy code using SDKs that pre-date IMDSv2’s release, or anything that for some reason implements custom interactions with the IMDS rather than using the SDKs, tread lightly and verify changes before deploying to production. I still believe this is a really critical thing to do, though, and it’s always one of the first things I look for.
Doing Security Work with AWS Products, vs Doing Security Well
AWS is in the business of making money, and anything they publish is going to push their offering ahead of anyone else’s. That’s fair enough, and entirely understandable, but there’s a point where that becomes a problem. Like many other security workshops and publications I’ve seen from AWS, the maturity model feels like it focuses on doing security work with AWS offerings, not doing good security. This doesn’t really line up with their frequent proclamation that “security is job zero”. It also excludes or downplays a range of other things that are important for a strong cloud security posture where they don’t fit neatly into an AWS-built box. Two that immediately spring to mind are:
- A proper asset list, which is a core requirement for any effective security posture. You can’t secure what you don’t know you have.
- CI/CD pipelines for infrastructure deployment, to avoid developers needing privileged access to production all the time
There’s also a push towards AWS technologies like Control Tower, SSO, Shield Advanced and WAF that the community have identified significant limitations with. Control Tower is incredibly opinionated as to how things work, has limited flexibility, and can’t be retrofitted into existing organizations. With AWS SSO, it’s useful as a glue layer between AWS and an existing identity provider, but due to API limitations it’s not fit for purpose as a standalone SSO. In the case of WAF, it’s significantly less capable than most competitors, and Shield Advanced is overkill for the vast majority of organizations and very expensive.
In my opinion, the framework would be better served by being constructed around the practices, controls and strategies that are essential for a strong security posture, talking about the types of services and products that might help in each case, and then weaving any available AWS services in around that where it makes sense to.
Over-emphasising Encryption and DLP
This is another institutional bias in AWS that I take exception to - an over-emphasis on encryption. I’ve yet to see a single breach where custom KMS configurations would have been the best option to prevent it. That applies to red teams and penetration testing too. In every case, it would either have been a worse investment than other controls, or would not have helped at all. I subscribe to the Chris Farris school of thought on cloud encryption. You absolutely should turn on the default encryption everywhere, to be clear - there’s no reason not to and it helps to appease the auditors. Put anything KMS-related beyond that to the bottom of the priority list. UPDATE: Dario pointed out that, especially from a compliance perspective, there are benefits to having separate KMS keys for encrypting data at different sensitivity levels. I’m still unconvinced that custom KMS keys, key policies etc are a good investment in most cases, but they’re probably worth a closer look if you’re particularly concerned about insider threat or attacks from organizations with state-level capabilities.
DLP is likewise not a control I’d ever advise an organization to prioritise, not least because it’s a questionably effective last-ditch effort that only affects the very end of an intrusion. Macie also only covers S3 buckets, and not RDS, DynamoDB, RedShift, EFS, EBS or a host of other places people store data. The “quick win” listed for Macie is just for public S3 bucket discovery. but that’s something that Access Analyzer for S3 can do without needing to go near Macie. UPDATE: This can present a useful overview of external access that’s been granted, in a way that’s easier to work with than Access Analyzer. This might be a useful first step if you’re expecting that a lot of third party access has granted across your estate.
Deprioritising Infrastructure as Code
UPDATE: The model has been updated to include a recommendation to get this done sooner rather than later. I still believe that this ought to be seen as a foundational capability, but recognize that for many less mature and well resourced organizations it may be a step too far.
Infrastructure as code is a critical, foundational cornerstone of good cloud security, in my opinion. I’ve seen so many issues and incidents being the result of resources someone spun up and forgot, or where someone misclicked while configuring it through the console. Even from an operational standpoint, “ClickOps” has very few advantages and many disadvantages compared to infrastructure as code. Infrastructure as code brings a lot of benefits, including:
- Easy environment replication (for disaster recovery, testing, security assessments etc)
- Infrastructure versioning (easy rollback of failed changes)
- Being able to apply source code security processes and principles (code reviews, merge approval processes, static code analysis…)
It’s hard and expensive to retrofit infrastructure as code into mature environments. In theory you can claw it back using tools like Ian McKay’s fantastic former2, but it’s an uphill battle nonetheless. Which leads me neatly into…
Some Things are Best Done Early
A lot of what’s listed in the framework pay big dividends if designed in early on in an organization’s cloud security journey, but are hard to retrofit later on, or become a major source of security technical debt. The big ones that strike me include:
- A solid multi-account structure, including appropriate service control policies
- Infrastructure as Code
- Implementing federated access via an SSO platform
- Tagging strategies
- IAM least privilege policy enforcement
- Threat modeling programmes
I feel like the framework would benefit from highlighting where the capabilities being discussed are worth investing in early on, because if it’s successful, this will be something referred to by many AWS clients at all stages of their cloud journey.
Organizations Don’t Need Internal Red Teams
This one’s a more minor nitpick but I’ll throw it in anyway because it’s a real pet peeve of mine, as someone who does a lot of work in the detection space. Having people with offensive security knowledge and experience in a security organization is absolutely a positive thing. For larger organizations, an internal security assessment or penetration testing team might make sense as an extension of that. Both of these things are a very far cry from a proper red team.
That said, Red teams are the absolute last and final thing an organization should invest in. Most organizations will never get to the point where a red team will provide significant value, and I don’t believe they have a place in most maturity models and similar frameworks. Red teaming engagements focus on exercising an organisation’s entire security lifecycle, from prevention through detection, response and recovery. They are a validation exercise to prove all the other security work has gone right, and all other security work should be undertaken first. To understand the value and pitfalls here, I’d recommend reading Red Team, by Micah Zenko. It does a fantastic job outlining all the reasons red teaming fails in many organizations, whether cybersecurity red teaming or otherwise.
I’m also quick to note that there’s a nice list of attack simulation tools included in this section, and I feel privileged to have my work, Leonidas, listed there. That said, running a bunch of attack simulation tools does not a red team make, and including it here as part of what’s being called a red team muddies what are already some rather murky waters in the industry at present.
What Are the Other Options?
Scott Piper’s AWS Security Maturity Roadmap has been the gold standard for AWS for several years now. It’s something I regularly point clients to, and something I use to inform my own engineering on AWS too. I’d also like to highlight the more cloud-agnostic work that Marco Lancini’s been doing in this space with his Cloud Security Roadmap and Template, too, which is a lot more comprehensive but less prescriptive. For organizations who have the security know-how and resources to make good use of them, I believe either of these would be a better option than this framework in its present state. For organizations without the security resources available, some of the quick wins in particular serve as a good starting point for improving their security posture.
Where Should AWS Take This?
To my mind, there’s quite a lot of smaller things to tweak here, but the way to really take this forward is for AWS to do two things:
- Lend some real institutional support to the initiative - so far it’s been driven by an enterprising team of solutions architects, but I think it’d benefit from input from many of the security-focused engineering teams. I also suspect broader support would also have caught some of what I’ve called about above, though it would also likely have aggravated the aforementioned institutional biases.
- Collaborate closely with independent AWS security specialists - I’m not by any means saying they should have come asking me for my advice (I’m sure there’ll be plenty of holes to pick in what I’ve said here!). That said, reaching out to key members of the independent side of the AWS security community for their input early on would likely have helped shape this into something the whole community could have gotten behind. The fact that it was a surprise to most of the major players when it dropped suggested that this step has not been taken to date.
UPDATE: Dario clarified that this model was previously worked through with a wide number of users in the Latin American AWS community, but has only just been translated into English. This would explain why none of the usual suspects in the English-speaking AWS security world had heard anything about it prior to now.