AWS Security is very complicated... or very simple - it's all how you architect it!

Written by Kara Nottingham and Manuel Vogel.

This blog post is part of a series about the AWS Well-Architected Framework; what it is, why it makes sense to do it, and how we at kreuzwerker do it. In this entry, we will focus on the Security Pillar - how to make security your second nature.

What it is - a quick recap

Using the collective knowledge and experience of their architects and clients, AWS is continuously working on a Well-Architected Framework, which consists of key concepts, design principles and best practices on how to architect and run workloads in the AWS Cloud. AWS developed Well-Architected Framework in order to understand what makes some customers succeed in the cloud while others fail. They also wanted to identify common problems, decisional and architectural patterns as well as anti-patterns. In other words, what is well-architected and what is not, and to make this knowledge available to all, regardless of whether someone is only just considering migrating to the cloud, or are already running thousands of workloads there.

Well-Architected Framework is built on six pillars

1. operational excellence 👨🏽‍💻
2. security 🔒
3. reliability 💪🏾
4. performance efficiency 🚀
5. cost optimization 💵
6. sustainability 🌳

The AWS Well-Architected Review process provides a consistent approach for customers and partners to evaluate architectures and implement scalable designs.

It's important to note that the Well-Architected Review is not an audit. It's nothing to be afraid of; there are no penalty points for not getting things right the first time. Well-Architected Review is a way of working together on how to improve your architecture. The process leads through several foundational questions and checks. It has been derived from years of experience that have been gained from working with the AWS cloud regarding security, cost efficiency, and performance. Hence, it provides good advice on improvements. It helps you to build secure, high-performing, resilient, and efficient infrastructure for your applications and workloads.

The hard facts about AWS Well-Architected reviews in 2022 are:

• it consists of 58 questions in total across all pillars
• it takes around 4-6 hours for one workload (without tool support)
• the goal is to remediate 45% of the high-risk findings with a minimum of 20 questions answered.

We describe the process from our perspective in more detail here.

How we do it at kreuzwerker

Why should you do it with us?

As a Well-Architected partner, we do at least 20 well-architected reviews per year and have built overall deep architectural expertise for every pillar and hands-on experience.

How do we perform such a review?

For us, it's an interactive process: we inspect and adapt every time we do it by requesting feedback from our clients and doing a short internal retrospective. As of now, we perform it as follows:

• We do it in 2 blocks from 09:00-12:00 and 13:00-15:00 with a lunch break. However, we can continually adapt if we are faster, e.g., we shift the gap, and we are also flexible whether doing it remotely or at your office.
• We do it in an interactive, story-telling mode. This means: you talk, we listen, and then dig deeper into specific areas while being able to cover multiple questions.
• Our process is supported by tools (more in the other part of the blog post series 🥳)

We do not just handle the questioning but give guidance to answering them. We can tell you how and why there could be improvements to be made. Alright, enough for the introduction. Let's jump right into it.

Security Pillar

In a nutshell

The need for security doesn't need defining - we all want our data and services to be complete, available and confidential when needed, and we want our clients and employees to use them as intended. Things get a bit murky when we think about how to achieve it.

In the AWS Cloud, we should start with defining the lines of responsibility between you - the Cloud Service Consumer (CSC), and AWS - the Cloud Service Provider (CSP).

AWS is responsible for "Security of the Cloud" - the facilities, networking, hardware and software that runs the AWS Cloud Services. AWS is always responsible for the physical and environmental security of their data center and what's in it, as well as the virtualization layer that provides the logical segmentation and isolation of services. To break it down a bit further: AWS will ensure that their infrastructure is protected from bad actors (and from squirrels, too!), fires and floods, or from regular "wear-and-tear" of physical components. AWS will also ensure that their infrastructure is up to date, patched and configured, and that their employees are trained and knowledgeable in security.

This is to assure that many cloud consumers can run their cloud services on the same physical hosts and send their data through the same physical networking cables - and be safe in the knowledge that their workloads are secure and entirely separated from those of other consumers. Inheriting those controls allows them to focus solely on their part of shared responsibility, and in many cases, can help CSCs achieve compliance with various cybersecurity frameworks.

Diagram shows The Shared Responsibility Model, source: Amazon Web Services

So that's the AWS part? As the Cloud Service Consumer, you are responsible for the "Security in the Cloud" - which means everything else. Starting with your AWS account itself and down to every single resource you create - it is your responsibility to make sure it's secure. At the same time - let's not forget availability! Security and availability are natural "frenemies" - we could easily "secure" our systems from malicious outsiders by simply unplugging the network cable - but that would mean rendering them unavailable for legitimate users. So how do we go about it? Yes, you guessed it - with the help of the AWS Well-Architected Framework Security Pillar.

Design principles

Implement a Strong Identity Foundation

Start with identifying identities that will access your resources, both human (users, developers, partners) and machine (virtual machines, functions, applications).

In many cases it makes sense to use a centralized identity provider to simplify access management. You can use AWS Single Sign-On, connect to an external identity provider or if you already have it implemented - utilize your Microsoft Active Directory.

Once you know who is going to be accessing your resources, ensure proper authentication - the logging in process - to make use of password policies and wherever possible, enforce the use of multifactor authentication (MFA).

Proceed by asking who and how should access your data and services, identify roles and responsibilities and group them together. For example, by making use of AWS IAM Groups and Policies you can create a group of users who are your Administrators and then add another layer of security by only allowing them to perform actions if they connect from a particular set of IP addresses - your office or your VPN ranges. (This is just a small example - AWS IAM Policies offer incredible levels of granularity!)

Remember the least privilege principle - the minimum permissions required to perform the function. Even if a bit inconvenient for them, if a legitimate user lacks the privileges to do their job, they will come and tell you. It's better this way around than over-provisioning and hearing later that an intern accidentally deleted your production database.

Enable Traceability

Monitor, log and audit what's happening in your environment. It will allow you to spot issues and continually improve your security posture, reducing the risk to your business. Or - in the worst case scenario - it will help answer "who did what, when and why?" so that when something bad happens, you will be able to tell if it was a genuine mistake or malicious attack - and perform appropriate corrective actions.

Implement detective controls that will notify and inform you about unexpected occurrences in your environment. AWS detective controls can learn about your environment and detect any deviations from regular patterns.

At kreuzwerker, we are passionate advocates of AWS security and detective controls and we love sharing our knowledge about how you can utilize:

• AWS Security Hub - to centrally view and manage your security and compliance posture
• Amazon GuardDuty - to monitor and detect threats
• Amazon Inspector - to improve security and compliance posture of your applications running on virtual machines
• AWS CloudTrail - to audit all event happening in your AWS environment
• AWS Config - to build your resources and configuration inventory and ensure compliance
• VPC Flow Logs - to help you understand your network security and flows by analysing traffic

and many more! - reach out to us about our Security Workshop to learn more!

Apply Security at All Layers

Assume your infrastructure is always under attack. That's not paranoia. These days that's common sense. Even if you're not being specifically targeted, rest assured that someone somewhere out there is launching a "spray-and-pray" attack - checking millions of targets for an easy way in to do mischief. Applying security at all layers will give you extra protection if one of the layers is breached.

In practice this means you need to know your infrastructure. Keep up to date diagrams of your assets and topologies - and implement trust boundaries, segmentation, configuration, policy enforcement points etc. that will protect your systems from unauthorized and unintentional access.

For network protection, clearly define and separate publicly facing services from internal services. Your public access points are some of your most vulnerable spots - make sure to properly secure all paths and routes in. AWS offers many forward facing services to offer you additional protection, amongst them Amazon Route53 (it's not just to host your domain names, it's a lot more!), Amazon CloudFront, Elastic Load Balancers, AWS WAF and AWS Shield. Virtual Private Networks (VPCs) within AWS can also be protected using a combination of solutions such as network access control lists (NACL), security groups, routing tables, NAT gateways or Egress-Only gateways for IPv6 networks.

For compute protection, firstly make sure you inherit protection by deploying your resources to networks that are already secured with aforementioned protections, and use access control policies. Then you can leverage a plethora of AWS solutions that will help you secure your workloads: AWS Systems Manager allows you to securely log into console or execute one off commands and scripts on your VMs without needing outside SSH access or bastion hosts. It can also help with security patching. Once you decide on a workload, it's a good idea to reduce attack surface by removing all unnecessary programs, scripts and drivers that may come pre-installed with the operating systems. You can then save those configurations as your own AMIs (or use Trusted AMIs from AWS and AWS Partners) and use policies that you can restrict so that your developers only use pre-approved AMIs.

And always remember to secure access to your S3 buckets! When in doubt - use IAM Access Analyzer to find out your buckets access patterns.

Automate Security Best Practices

Your architecture will grow and change in response to your business needs, so make sure your security keeps up!

In AWS, your best friend is AWS Config - you can use a sets of AWS defined or custom rules to ensure your resources comply with best practices. Depending on your setting, AWS Config can inform you about non-compliance event and do nothing, but also with the help of Lambda Function it can automatically remediate non-compliant resources. AWS Security Hub can continuously monitor your security posture and send findings to Amazon EventBridge (CloudWatch Events) for remediation.

And last but not least - AWS CloudFormation can help your security automation in various ways. Storing Infrastructure as code makes for easy auditing and change management, and in the event of an incident, can help you quickly redeploy your infrastructure and resume operations, reducing downtime and loss of business.

Protect Data in Transit and at Rest

Most importantly - know your data. To avoid compliance and legal headaches, as well as increased cost - only store data that you must store, and only as long as it's necessary.

Implement data classification procedures and techniques to separate data based on sensitivity, workload, compliance, retention. AWS Macie can help to automatically discover, classify and protect sensitive data stored in AWS. S3 lifecycle policies and Object Lock can automate retention and compliance. Developing tagging schema will help with categorizing, managing and accessing your S3 data. Use tokenization and encryption to protect sensitive data.

Data at rest is precisely what it sounds like - static data persisted to storage. Other than securing access to your data with proper controls we have already mentioned, it may be necessary to encrypt it as well. You can choose to encrypt it before committing it to storage (Client Side Encryption) or you can let AWS help you, using S3 bucket encryption, AWS Key Management System (KMS) or if you're operating in a heavily regulated environment - CloudHSM.

Data in transit moves from one location to another - often via insecure public networks. To ensure it's not compromised, it must be encrypted. Encrypt your traffic with SSL/TLS and let AWS Certificate Manager reduce the burden of managing, purchasing, issuing and deploying your public and private certificates.

Keep People Away from Data

While we spend a lot of time thinking about the "stranger danger", many security breaches do not originate as malicious actions, but a simple human error from well intentioned, loyal employee who just pressed the wrong button. By automating your processes you reduce the risk that comes from human interaction.

Prepare for Security Events

Even with the best security practices in place, incidents will happen, so plan ahead. Think about all the bad things that can happen and how you will respond. Put all those actions into Response Plan. Make sure everyone knows their role during the security events - where to find the documentation, who needs to be notified, what actions need to be taken and in what order; which resources need to be cordoned and what impact it will have on your production environment. Those are not the questions that you want people asking in the chaos of an ongoing security event. Plan, educate, simulate, learn, document findings, develop runbooks - and repeat.

Use AWS Fault Injection Simulator to create disruptive events in controlled environments and create remediation actions in case of a real security event.

Conclusion

So now that we have talked about security designs and solutions, you may be curious about how we do security at kreuzwerker?

Firstly, we make sure everybody is on board. The very last thing we want is to have a brilliant security plan that nobody knows, understands or cares about. This is the most important part - our security practice must help us do our business, not hinder us. We take time to explain to all our colleagues (not only those directly involved with IT practice) how our security practices help protect us, until we all understand and agree on the importance of adhering to them.

Then we continually re-evaluate our policies. We grow. As a business, and as individuals, and as times and circumstances change, new threats emerge and our security must keep up! Security is not a goal. It's a process, and we always treat it as such.

We also know that people make mistakes, and that people tend to hide their mistakes if they fear punishment. We cultivate a blameless environment and we encourage colleagues to come forward if they made a mistake, so that we can all learn from it and correct it. Honesty is in our DNA because there is no security without trust!

Lastly, we never stop learning and sharing what we learn. We inform each other about new technologies, threats, incidents. We discuss them internally and where appropriate, we notify our clients. If we spot a bug in somebody else's code, we make sure to let them know. And likewise - we welcome improvements to our solutions. We think security is everybody's responsibility and we do our bit.