Security Best Practices the AWS Well Architected Way
7 minute read | Last updated 4-Dec-2020 |AWS, AWS re:Invent, Cloud, Security
This talk (SEC314) is now available to watch on-demand.
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.
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
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.
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.
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.
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.
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.