A Review of the AWS Security Model

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.

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:

• The NIST Cybersecurity Framework (CSF)
• The Cybersecurity Maturity Model Certification

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.

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 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.
Access and role analysis with IAM Access Analyzer	Reduce IAM misconfigurations	Without an accurate inventory, it’s difficult to contextualise and action any findings.
AWS WAF with managed rules	Application/IMDS exploitation	A WAF is 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.
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.

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.

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”.

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

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.

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.

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. 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.

Organizations Don’t Need Internal Red Teams

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.

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.
• Collaborate closely with independent AWS security specialists - 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.

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.