Security Best Practices the AWS Well Architected Way

I'm generally not a fan of teaching any pillar in isolation and try my best to steer people away from looking at them individually. That said, it's also a good way to ease specific teams into the framework's way of thinking

Why the framework? Because you want to build better!

...and these reasons too.

Ben points out the use of multiple accounts as a nice boundary. Believe it or not, this can actually make permissions management easier and data flows cleaner.

This is an old whitepaper from AWS on the topic but the principles still hold up. Though this paper from the cost optimization explains some of the non-security benefits too.

Thankfully, there a host of new-ish services like AWS Control Tower and AWS Organizations that help manage the logistics associated with multiple accounts

In addition to using multiple accounts, setting up guardrails is a very important step to take.

Here, Ben provides an example where he's created an IAM policy that denies anyone in the account the ability to create access keys or users. This type of guardrail will funnel access and account creation to a small number of places which is exactly what you want.

You don't want any user to be able to create more access key or even other user accounts.

This is where I remind you that this was a 30 minute talk.

Ben reminds everyone that you should use a threat model to help you identify and prioritize risks.

There's a lot of complexity and nuance to this topic but at it's highest level, you need to be pragmatic about the threats your build faces. Not everyone needs to defend against high powered nation states.

Regardless of your risk appetite, you should keep an eye on security threats and recommendations that impact your builds. AWS has a number of services that can help with this, like Amazon GuardDuty and Amazon Inspector.

Moving to identify now, a centralized approach is best here. Thankfully between Amazon Cognito and AWS Single Sign-On there are some very easy to use, scalable options.

MFA is a must.

Here again there is a lot of built-in support, including the newly announced support for WebAuthn via AWS Single Sign-On

Granting permissions goes well beyond least privilege but that's definitely where things start.

AWS Resource Access Manager can help you share resources securely and IAM Access Analyzer can help with scope

Here's a great example of a least privilege policy using a condition. In this case "aws:CalledVia" ensures that access to this bucket is only granted when requested by Amazon Athena

Detection is something you have to prepare for ahead of time. Configuring service and application logging is key.

Notice that the slide says analyze logs, findings and metrics centrally. Not store them.

Don't violate the local & simple principle from the Unicorn Project, please & thank you.

I left this slide in because the architecture does show a centralized logging bucket.

I get the logic behind it and I'm not flat out against it but I have major concerns here. The biggest? Security doesn't need an isolated copy of the data. What security—and the other teams involved in the workload—need is access to comprehensive metrics.

Analyzing only security data leads to short sighted conclusions and contains an implicit bias skewing analyst conclusions.

If all you have is a hammer 🔨...

The AWS Security Hub team released a new set of security checks called AWS Foundational Security Best Practices. These checks implement a standard set of 31 security controls for your AWS accounts based things that the AWS security teams have run into time and time again.

These checks are simple reminders to help make sure you've closed off some easily overlooked issues. The good news is that it only takes a few minutes to turn these on if you don't have then enabled already

Again, I've got to bring up the fact that this was only a 30 minute session. I know Ben has more to add on this topic: events.

Basically everything in David Yanacek's fantastic talk, "Monitoring Production Services at Amazon" applies to the security domain as well.

Events that aren't actionable are just noise

Conformance packs are sets of rules for AWS Config (which are themselves AWS Lambda functions triggered by the service). These are easy to use governance checks that may highlight issues with your builds.

If you haven't spotted the pattern yet, Ben's talk is highlighting a ton of resources that AWS has provided to help you fulfill your part of the shared responsibility model. This is on top of all of the stuff behind the scenes that is helping to secure your builds

Typically "infrastructure" means "network" and that's the context in which it's presented here.

This is a slightly update standard model that creates zones within your VPC to provide a place to implement a control as traffic moves between zones.

The good news is that it's easy to build this out in AWS in a very cloud native way...now that AWS Network Firewall has been launched. That was the missing piece (not displayed here due to timing) alongside AWS Transit Gateway.

The key takeaway is "don't let things connect to the internet unless it's absolutely necessary...for real-sy" 😉

This 👆 layered approach will reduce your overall attack surface...basically don't have pointy bits sticking out for cybercriminals to see.

On top of that, use something like Amazon Inspector to help with vulnerability management. Of course, don't just accept updates from anywhere, make sure they are what you think they are (that's the "validate software integrity" piece)

The title says it all, "Keep people away from data."

I really appreciated that the first point made on this slide was, "don't store or collect it unless you have to." There's definitely a continuing trend of keeping too much data around. That's raises both security and privacy issues.

Data protection deserves a talk on it's own but these highlights do it justice;

• Don't store it if you don't have to. Don't grant access unless it's needed
• If you do store it, encrypt, mask, or tokenize it...again reducing the blast radius of leaks
• Make sure access to data is via tools
• Keep a high level of rigor for the operations and control of your data systems

The key to data protection is mapping out where it's gathering, processed, and stored. If you don't know that, none of the other controls matter a damn

Ben recommends enabling default encryption. Given that's typically $0.00 and comes with no performance hit that's solid advice. Just be aware of the threat model for this. You're usually preventing a physical intrusion...not super common in the cloud

This is going to be interesting...

What do you cover for four minutes of a thirty minute talk aimed at a general audience?

Solid first step: plan ahead. You do not want to be responding to an incident by the seat of your pants...trust me on this one.

GameDays are a great way to practice what you've laid out in your response plan...and not just for security.

Ben rightfully points out that one key preparation is granting access to responders. You don't want to be messing with permissions during an incident...that way madness lies.

The team has published a sample playbook in the AWS Well-Architected Lab

This comes in the form of a Jupyter notebook that contains the configurations, credentials, and code required to respond to basic incidents.

I really like this approach. It provides the code to discovery some key issues and to remediate them. It's "incident response as code" and can be versioned and tracked as such.

Ben closes out this great talk with some handy resources;

• The AWS Well-Architected Framework
• The AWS Well-Architected Tool
• AWS Well-Architected Labs
• AWS Solutions Library