Zero Trust Concepts and Implementation in AWS

Graham Thompson   ·   Tuesday, May 30th, 2023

Introduction

Zero Trust is a security concept centered on the belief that organizations should not automatically trust anything inside or outside its perimeters and instead must verify anything and everything trying to connect to its systems before granting access.

Implementing Zero Trust in AWS involves multiple strategies, as AWS provides several services that you can leverage to create a Zero Trust environment. If you check out my previous Cloud Native Security blog, you can see that both zero trust and cloud native security share many of the same concepts and principles.

All of the services found below are covered in the CCSK Plus with AWS labs course by the Cloud Security Alliance, delivered by Intrinsec Security.

Here are the first 10 steps to implementing Zero Trust in AWS:

1. Identity and Access Management (IAM):

AWS IAM allows you to manage access to your AWS resources securely. With IAM, you can create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources.

• Create minimum privilege policies: Assign users and roles only the permissions they need to perform their job. This is cybersecurity 101, yet for some reason is bypassed by many because it is seen as “basic” and not “cool”. Know what isn’t cool? Being responsible for leaking millions of client records because you wanted to focus on cool stuff and not the basics.
• Use roles for applications: If an application needs to access AWS resources, create a role for that application. Hard coding credentials in your applications is a one-way ticket to the hall of shame.
• Enable multi-factor authentication (MFA): MFA adds an extra layer of protection on top of the user name and password. It’s very simple. Your Nana is being told she should use MFA to access Facebook. Why should access to the management console not be treated in the same way?

2. Separate AWS Accounts:

Use separate Amazon accounts per workload. This may be overkill if you have a very small AWS footprint, but is very important when you start using AWS at scale. All these accounts can be managed via AWS Organizations.

The benefit of the separate account approach is the default deny nature of AWS (and other IaaS providers). If you create separate accounts for Dev and Prod in support of separation of duties for example, you add Developers IAM accounts to the Dev AWS account and administrators to the Prod AWS account. Sure, it’s easier to throw everything into a single VPC, but having things work versus work securely are two different things, right?

The problem with using multiple VPCs or just a single VPC and adhering to separation of duties is that you then must restrict using conditional statements. This is challenging to say the least. An added headache is the limits you’ll run into using a single AWS account to run everything at scale.

• Design around running workloads in separate AWS accounts.
• Manage multiple accounts using AWS Organizations
• Implement Service Control Policies: Use Service Control Policies to implement guardrails on subaccounts.

3. Security Groups:

Use Security Groups to restrict inbound and outbound network traffic to just the IP ranges or other Security Groups that require access to a workload. This works towards the micro segmentation approach called for with a zero-trust architecture. This is because the security group is applied to the virtual network interface card of the instance.

• Implement firewall services for both inbound and outbound network traffic with Security Groups.

4. Network Access Control List (NACLs):

NACLs provide a rule-based tool for controlling inbound and outbound traffic at the subnet level. NACLs contribute to a defense-in-depth posture required by a zero-trust architecture.

• Use NACLs: Create rules that restrict traffic from certain IP addresses or subnet.

5. AWS Shield and AWS WAF:

AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. AWS WAF is a web application firewall that helps protect your web applications or APIs against common web exploits.

• Use AWS Shield and AWS WAF: Use these services to protect your applications from common web exploits.

6. CloudTrail and CloudWatch:

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. AWS CloudWatch collects monitoring and operational data in the form of logs, metrics, and events. When paired, these two services can enforce a Policy-as-Code (also known as Compliance as Code) approach to event-driven remediation to changes in your environment.

• Enable CloudTrail: Capture all API calls for your account.
• Use CloudWatch: Set alarms and react to changes in your AWS resources.
• Integrate CloudTrail and CloudWatch to create a powerful Event-Driven security environment.

7. AWS Inspector and GuardDuty:

Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. AWS GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts and workloads.

• Use AWS Inspector: Regularly run security assessments for your EC2 instances.
• Enable GuardDuty: Detect and react to any suspicious activity in your account.

8. AWS Config:

AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so you can see how the configurations and relationships change over time.

• Enable AWS Config: Continuously monitor and record your AWS resource configurations and evaluate them against desired configurations.
• Integrate Config and AWS Security Hub to get a single pane of glass view of your security posture.

9. Use AWS Secrets Manager or AWS Systems Manager Parameter Store:

These services help to manage secrets and parameters securely.

• Do not hardcode secrets: Secrets should be pulled from a secured and encrypted service, not hardcoded into the application.
• Implement IAM policies with conditional statements to tightly restrict the secrets available to each application.

10. Incorporate principles of least privilege and segmentation:

This means users and systems should have only the permissions necessary to perform their tasks and nothing more, limiting the potential damage from a compromised account.

Conclusion

Remember, Zero Trust is not a specific technology, but a holistic approach to network security that requires several layers of defenses. AWS provides the tools and services needed to implement a Zero Trust architecture, but it’s up to you to make use of them effectively.