In Cloud We Trust? Not So Much – Implementing an Enterprise Zero Trust Model
If you’re following all the infosec trends as of late, you’ve no doubt heard the phrase ‘zero trust’ bandied about nearly every week for the past few years, usually with glowing promises from vendors that their particular solution provides massive gains in security and lowers risk. This interest has grown beyond the normal marketing hype cycle, as COVID has forced more organizations to adopt at least a hybrid cloud model to deal with the growth in BYOD, WFH, and insider threat.
What Do We Mean When We Talk About Zero Trust?
So, what is zero trust, and what might a native cloud implementation of zero trust look like?
First, it’s good to start with the basics. Zero Trust Architecture (ZTA) is a design philosophy where everything is presumed insecure (and potentially malicious). Accordingly, anything touching or accessing the network must first be validated. That means each application, endpoint, or component is treated as an untrusted microservice. It’s a big shift from the secured perimeter model, which assumes that things outside the network are the main threats and prioritizes strong access controls, the use of VPNs and firewalls to harden network defenses.
A ZTA approach encompasses everything from identity and access management, credentialing, endpoints, device management, data security, and operational processes, such as context-aware policies. One central aspect to ZTA is that access is granted via a decisioning and enforcement process known as Policy Decision Point (PDP), which consists of two subprocesses: a Policy Engine (PE) and Policy Administrator (PA). The PA is responsible for establishing or ending communication between a subject and a given resource, while the PE handles the ultimate decisioning on whether or not to grant access. A separate process, known as the Policy Enforcement Point (PEP) communicates with the PA to apply a confidence rating based on a number of factors, including location, time of day, and previous access attempts. That confidence rating in turn, defines the level of trust (“implicit trust zone”) given to a subject. The PDP/PEP applies a set of controls so that all traffic beyond the PEP has a common level of trust.
The National Institute for Standards and Technology published an excellent guidance document on setting up ZTA for enterprise environments that is definitely worth a read. The NIST ZTA document helpfully analogizes the PDP/PEP process to passenger screening at an airport:
The “implicit trust zone” represents an area where all the entities are trusted to at least the level of the last PDP/PEP gateway. For example, consider the passenger screening model in an airport. All passengers pass through the airport security checkpoint (PDP/PEP) to access the boarding gates. The passengers, airport employees, aircraft crew, etc., mill about in the terminal area, and all the individuals are considered trusted. In this model, the implicit trust zone is the boarding area.
Image from NIST SP 800-207
That said, moving to a zero trust approach is not without risk or tradeoffs. The most distinct threat to ZTA environments is of course, compromise to the decision or enforcement processes. Misconfiguration of the PE rules, or a compromised PA could either allow unauthorized access, or deny legitimate access requests via DoS attacks or network disruption. Similarly, a ZTA environment is not wholly immune to phishing, insider threat, or other account compromises. Finally, undertaking a radical redshift in IT architecture often incurs significant resources and costs.
Implementing Zero Trust Natively in Cloud Environments
All of the major providers offer at least some degree of zero trust implementation. Usually, its applicable not only within the cloud environment, but to other systems and services as well.
AWS: As noted in their guidance documentation, AWS offers numerous tools and strategies as part of the AWS Well-Architected Framework. Using native tools like Amazon’s Elastic Load Balancing (ELB)/Application Load Balancer (ALB), DNS domain management through Amazon Route 53, encryption via AWS Key Management Service (AWS KMS), and edge security and caching through Amazon CloudFront, allows customers to create an effective Zero Trust implementation and adhere to AWS’ five pillars:
- Security
- Operational Excellence
- Performance Efficiency
- Cost Optimization
- Reliability
Here’s a visual example of their AWS Well-Architected Framework as applied to a web hosting provider:
Additional guidance can be found here and here.
GCP: The GCP-native solution for ZTA is based on Google’s well-known BeyondCorp offering. BeyondCorp builds directly on Google’s own in-house zero trust network model, along with industry best practices. BeyondCorp is based on three principles:
- Connecting from a particular network must not determine which services you can access
- Access to services is granted based on what we know about you and your device
- All access to services must be authenticated, authorized, and encrypted
For its decisioning, BeyondCorp relies heavily on ‘context-aware access’ — an approach that uses device, access and other rules and conditions to grant access on a user or device level.
Here’s a view of Google’s Context-Aware approach:
Additional guidance can be found here.
Azure: Finally, Microsoft’s offering relies heavily on app detection and control through its Microsoft Cloud App Security solution. While there’s a good deal of monitoring and identification (including ‘Shadow IT’ application detection), and more granular app control, the Azure solution seems less developed compared to those offered by GCP or AWS.
Additional guidance can be found here.