Follow Mark on LinkedIn Follow @marknca on Twitter Follow marknca on GitHub Follow marknca on YouTube

imgs/hero.jpg

Security Best Practices the AWS Well Architected Way

7 minute read |An icon depicting a retail tag with a heart for 'favourite'AWSAWS re:InventCloudSecurity

Watch on-demand

This talk (SEC314) is now available to watch on-demand.

Abstract

As you continually evolve your use of AWS products and services, it’s important to consider ways to improve your security posture and take advantage of new security services and features. This session shares architectural patterns for meeting common challenges, service quotas, and tips and tricks for continually evaluating your architecture against best practices.

Automation and tools are featured throughout, and there will be code giveaways! Be prepared for a technically deep session on AWS security.

Speaker

Ben Potter is the lead for the security pillar of the AWS Well-Architected Framework.

My Breakdown

Having taught the Well-Architected Framework to thousands of builders and security being my general focus, I’m a bit opinionated on this topic. That said, Ben literally leads the work around this pillar. This should be a great talk…just keep in mind it’s only 30 minutes.

I’ve provided some more detailed thoughts on session SEC314 below. I also live tweeted the talk when I watched it through if you just want the quick hits.

Click on the slides for larger versions

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

Why the framework? Because you want to build better!

...and these reasons too.

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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" 😉

Slide from presentation, described in the next grid item

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)

Slide from presentation, described in the next grid item

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
Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

This is going to be interesting...

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

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item