Applying zero trust to reinforce cloud security architecture

If you work in any form of information technology, you will have been bombarded with products that claim to deliver zero trust, with most zero trust vendors providing tools and capabilities that help secure end-user compute environments.

What you may not be aware of is how to employ zero trust philosophy when developing your cloud security architecture. This short post is designed to widen the understanding of what the zero trust philosophy is—and what it is not—by demonstrating how it can be used to build out a cloud security architecture as part of a modern cloud-native application deployment.

Given that you do not manage or configure the underlying platform in a cloud environment, you have two broad choices to make when deploying applications on the public cloud. The first is to implicitly trust the vendor as part of the shared responsibility model. The second—and my preferred—approach is to treat the cloud platform as an untrusted entity and build out the cloud security architecture based on zero trust philosophies.

The foundations of effective zero trust

Before we get started on what that cloud security architecture might look like, we need a common understanding of the core tenants of zero trust. These can be summarized as not trusting anything and explicitly authorizing each and every connection. While NIST defines seven tenants, I prefer to simplify and group them into the following six principles:

1. Require explicit authorization for all communications, system, and data access requests for users, services, and devices. Never assume trust based on location or device attributes.
2. Use a dynamic access policy using contextual information such as (but not limited to): the end-user device type, health of the device, data sensitivity, the individual, the location, and the current threat environment when authorizing access.
3. Verify trust of both sender and receiver; ideally use the Mutual TLS (mTLS) protocol or other approaches.
4. Encrypt all data (at rest and in transit).
5. Segment and control network access.
6. Continuously monitor the integrity and security posture of all connected resources with telemetry to identify indicators of compromise.

In effect, zero trust introduces an identity-based access model in addition to the traditional network-centric security model. Note that no single component, function, or product can implement zero trust. Rather, they must be combined to collectively achieve zero trusts goals and outcomes. Please do remember that in addition to the above zero trust principles, you should not forget other established security architecture principles and approaches, including, but not limited to:

• Defining reusable patterns.
• Defense in depth.
• Minimizing attack surface area.
• Following the principle of least privilege.
• Deploying segmentation to reduce blast radius damage.
• Designing for failure.
• Testing prior to deployment.
• Assuming a breach, i.e., an attacker is already on your network.

Read more: Three transformative ways zero trust will benefit your enterprise

How does this work with my cloud security architecture?

So now you have a set of principles. How do you use those to build out a robust and resilient cloud security architecture for a modern application? I have used an AWS example in the figure below; you will find that Google and Azure have similar capabilities.

In this example, Amazon Cognito and AWS Single Sign-On powered by AWS-IAM services enable authorization and authentication of all operations. In some cases, there will be a need for static secrets, perhaps to link to the orchestration or repository tooling. These can be secured in a Secrets Manager, called on by application invocation and rotated frequently, following the dynamic access policy principle.

Any data transmission is achieved using the mTLS protocol which itself will require certificates issued by Certificate Manager. Any service connection must have a short time to live of the order 5-30 minutes. This ensures all resource-to-resource access is authorized and authenticated and any certificate compromise has limited impact.

The three-tier application is segmented north-south and east-west using security groups and ACLs. In addition, external Platform-as-a-Service (PaaS) services such as S3 and Aurora are presented over private network endpoints to reduce the attack surface and ensure segmentation. Data is encrypted at rest using AWS CMK service with customer provided and managed key material.

Finally, the last zero trust principle of monitoring everything is achieved using GuardDuty and CloudWatch with rules written to adjust access on receipt of high threat determination.

As I have shown, this deployment model treats the AWS platform as untrusted and—using the six principles—builds out an effective and resilient cloud security architecture.

In summary, zero trust philosophies give form to function

By creating a set of architectural principles derived from the zero trust philosophy and applying them to the simple three-tier web application, we have demonstrated how to use a zero trust philosophy to create a robust and secure service running on an untrusted platform. You can apply this same technique to any system or service development to embed security into your digital transformation agenda, be it at the initial concept stage or during system hardening and or threat modeling.

For more reading and a view on how to scale this model out to complex microservices architectures using a service mesh, see the newly released NIST Special publication: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments

Read more: Data-Directed Security: How zero trust fits into enterprise data security