Part 6 – Security Pillar Intro
We’re onto Part 6 or our deep-dive into the AWS Well-Architected Framework. In this post, we will be taking a look at the AWS Security Pillar.
If you haven’t checked out the earlier 5 parts to this series, pause here and check those out. For this article, we’re going to assume that you’ve read the previous posts and are up to speed on the framework itself and all the guiding general design principles.
If you did you miss our earlier editions? Why not sign up for our newsletter? This way, you won’t miss out again on future parts of this series and future Cloud and DevOps topics!
Similar to our other posts, we’re going to break down this pillar overview into a few parts to put some structure around all this information:
- AWS Security Pillar Overview
- The Pillar Design Principles
- The Shared Responsibility of Security in AWS
- Best Practice Areas
AWS Well-Architected Security Pillar Overview
With the Security Pillar from AWS, we’re provided an in-depth, best-practice guidance paper for architecting secure workloads on AWS that can provide significant improvements to your security and risk management postures.
Security needs to be an integral component of all architecture decisions as opposed to an independent feature that you simply add to your system. By integrating security throughout your workload design phases, you’ll create a system that is more secure by implementing security in layers.
The AWS Well-Architected Security principles complement the other five AWS Well-Architected principles, adding security considerations to architecture design and deployment. Following the security best practices provided in this pillar will help ensure the safety and security of your data, as well as the integrity, availability, and durability of your services.
Like all AWS Well-Architected Pillars, the Security Pillar consists of general design principles, along with a number of best practice areas.
Let’s take a look at these, starting with the Security Pillar general design principles.
Understanding AWS Well-Architected Security Pillar
Security Pillar General Design Principles
- Implement a Strong Identity Foundation
- Enable Traceability
- Apply Security at All Layers
- Automate Security Best Practices
- Protect Data in Transit and at Rest
- Keep People Away From Data
- Prepare for Security Events
Let’s dive into each one top put some more context to these design principles and help us understand what they’re all about.
Implement a Strong Identity Foundation
Implement the principle of least privilege in your AWS access management and at all times enforce separation of duties. This design principle recommends that we centralize identity management, eliminate long-lived and hard-coded credentials and rotate them regularly.
Enable Traceability
Log and metric collection should be integrated with systems to allow for real-time monitoring and to help with automated investigation and remediation actions.
Apply Security at All Layers
This design principle guides us to take an onion approach to applying security to our cloud workloads. Having a multi-layered, defence-in-depth approach can offer better security overall, rather than focus on a single aspect of your overall design.
Automate Security Best Practices
This principle suggest using software-based security solutions to quickly and securely adapt your workloads to changes in demand. Having security automations in place while your infrastructure scales can help improve the overall cost-efficiency of your workload. AWS also suggests here that as we design our secure architectures, we don’t forget about implementation controls when creating our infrastructure-as-code (IaC) and other infrastructure templates. Implementing security best practices into you infrastructure templates or modules can help with security automation, auditing and governance areas as well, and help implement a secure-by-default menu of cloud resources your organization can use where security best practices are baked in.
Protect Data in Transit and at Rest
Here, AWS recommends that we review our cloud workload data involved. Both data at rest, that will be stored on EBS volumes, EFS, databases like RDS, DynamoDB, Auroroa, and Redshift, then also how this data is sent over networks to your various workload components and end users. We should be classifying this data into appropriate sensitivity levels. then based on that sensitivity level, use encryption and the necessary access controls to keep that data safe. Organizations often have a variety of company data policies, governance, and compliance aspects to consider with how their data is stored, transmitted and secured that should also be taken into account.
Keep People Away From Data
Keeping people away from your data can be one of the best methods of keeping your data secure. Human error can lead to all kinds of mishandling of sensitive information. Limiting the need for people to access the data directly can help ensure your data is safe, stored where you intended it to be stored, and keep your company compliant across its data governance policies.
Prepare for Security Events
Similar to the famous quote by AWS CTO, Werner Vogels…
“Everything fails, all the time.”
in today’s modern world, security events happen all the time as well. This security pillar design principle states that we should be prepared for these security events rather than scrambling to figure things out for the first time during a critical security incident.
We should have all our security incident management processes and policies in place and ensure these are tested. Similar to other AWS pillar guidance around running game day events to simulate failures, we should be running mock security incident response events to test your policies, procedures and investigation tools and methods. Rehearsing these events will help refine your existing policies and procedures and speed up the detection, response, and remediation of live security events when then occur. And they will. Be prepared.
Security in AWS is a Shared Responsibility
Core to this security pillar is understanding the AWS shared responsibility model when it comes to securing your cloud workloads running on AWS. Understanding what AWS is responsible for and what you are responsible for securing is a critical first step.
If you’re not familiar with the AWS Shared Responsibility Model, please take some time to understand this well.
For more information on the AWS Shared Responsibility Model, check out the AWS documentation here.
For organizations looking to migrate to the cloud from traditional on-premises data centers, the AWS shared responsibility model should be a welcomed sight. The operational and OpEx cost overhead with “simply” securing the physical aspects of datacenter are put on AWS’ shoulders, leaving you to focus more on your business and products that add real value to your company, rather than doing the heavy lifting and costly security and operations of physical datacenter locations.
Security Pillar Best Practice Areas
The AWS Well-Architected Security Pillar contains 6 best practice areas to consider when reviewing security aspects of your cloud workloads.
The AWS Well-Architected Security Pillar contains 6 best practice areas to consider when reviewing security aspects of your cloud workloads.
- Security
- Identity and Access Management
- Detection
- Infrastructure Protection
- Data Protection
- Incident Response
As part of this series, we’ll be diving into each of these AWS security best practice areas in a future article, looking at each best practice area in depth and putting some additional context to the AWS information to help you on your way to securing your cloud workloads.
Don’t miss out on the upcoming parts of this series and other Cloud and DevOps by signing up for our newsletter below!
Need Help Today?
The Autimo team can help you navigate the complex cloud security landscape and help build automation and baked-in security into your engineering platforms, leaving your business to focus on delivering value to your customers through your products and solutions.
AWS Secure Environment Accelerator (ASEA)
The Autimo team has specialized implementation experience with the AWS Secure Environment Accelerator, that helps Canadian and Global AWS customers with NIST 800-53 and Canadian Centre for Cyber Security’s ITSG-33 specifications around network design and segmentation, data security, centralized identity and access management (IAM), logging and auditing, and more.
The reference ASEA AWS landing zone can be a complex implementation. The Autimo team can help understand your organization’s unique requirements and help navigate the design and implementation details based on your unique business, security, and compliance requirements.
Security by Design
Learn how Autimo helped Hero Group implement a turnkey development platform focused on security and productivity through infrastructure automation through Terraform infrastructure-as-code (IaC)
“Without Autimo’s help there is no way we’d have
been able to hit the level of productivity we have seen. To be able to
forget about the infrastructure and just get on with writing code has
been transformative for our team.”
Markus Westerholz
CTO, Hero Innovation Group
