Implementing Zero Trust

The previous entry on the topic of Zero Trust networks presented the concept and why it’s preferable to more traditional enterprise network security models. In short, corporate firewalls lead to implicit trust under the assumption that an actor within the firewall must be friendly.

This isn’t always the case, however, and a nefarious party that manages to penetrate a corporate network can take advantage of the lower security bar common behind firewalls and VPNs. Zero Trust networks, on the contrary, dispense with the false promise of a secure perimeter and require that all parties mutually identify themselves and communicate over encrypted connections.

This article will discuss how to implement the necessary Zero Trust infrastructure, with a follow-up post covering migrating to Zero Trust. For purposes of this conversation, we’ll use the following terms:

• Client – the device initiating a request
• Service – the application responding to a request
• User – the human using the client, where applicable

Within a Zero Trust framework, each of these must be identified and known to the others for a given request to succeed.

Client

Ensuring that requests are sourced from a known secure device provides additional security beyond simply identifying the user of the device. Ascertaining that a device is “locked down”, however, requires infrastructure and automation. Since all client devices must be known to the target service, a list of valid devices must be maintained somewhere. In Zero Trust, this list is kept in a database referred to as a Device Inventory Service. Devices registered with this service continually identify themselves and relevant characteristics, such as whether their antivirus software is up to date and whether their local file storage is encrypted. The results of this instrumentation are stored in the inventory and used to determine whether the device qualifies for access and at what level. Implied by the fact that this device is known to the enterprise is the requirement that it run software to enforce these policies. This software falls under the category of Mobile Device Management (MDM) and is typically installed prior to the first-time issuing of the device to the user.

Given what is known about the user and their client device, a determination must be made concerning what authorization the user/device should be granted. This is the responsibility of the Trust Inferer, an infrastructure system that owns and applies the rules that govern access rights. The result of a given evaluation should determine a tier of access. For instance, a device in good standing with recent OS patches may be given a higher tier of access than one that is lagging. Since the client device is an enterprise-managed device, security audits can continuously update the Device Inventory Service so that the Trust Inferer can make informed access decisions with respect to the device.

Service

At the core of any complex application are the services that persist data, run business logic, and/or propagate messages. Often each of these components is developed, deployed, and scaled independently of the others, particularly in modern microservice architectures. Even an enterprise of modest size typically has constellations of services, databases, and messaging systems communicating over the network. In Zero Trust, each of these must be independently secured.

In a Zero Trust architecture, the Access Proxy (AP) helps address the security requirement. The AP sits between clients and services in the network and ensures that only known and approved users and devices can access a given service. Preconfigured Access Control List (ACL) rules for each service are applied against every service request and the AP determines whether each should be forwarded by the proxy to the backing service.

Since the AP is also liable to serve as a load balancer, it is a natural place to do SSL/TLS termination to handle HTTPS for web-tier services. In this fashion, the backing service can focus on providing business value while offloading certificate handling and authentication/authorization to the upstream proxy. The AP can pass custom metadata to the backing service, which can use to gracefully degrade access or implement more granular controls than those provided by the ACLs. Graceful degradation is a hallmark of well-implemented Zero Trust as it maintains a high-security stance while reducing the risk that a user will be entirely cut off from necessary access.

User

Having positively identified both the client device and the service it targets, identifying the user completes the triumvirate of certainty that Zero Trust demands. Of course, system-to-system requests that don’t involve a human user don’t apply to this requirement or section.

Human users typically identify themselves with a username or email address and password. Whether using a thick client application on their device or a browser, the use of passwords is well established in practice. Weak passwords, cross-site password reuse, and other such insecure practices lead to security breaches. This has led to the increased usage of multi-factor authentication (MFA), in which a physical device is used in tandem with a password to ensure a person is who they say they are. These devices can take the form of hardware security tokens, such as YubiKeys or smart cards, or mobile devices, using an app or SMS text messages.

Once a password of sufficient security is established and used in tandem with MFA, it is often a priority to provide a unified experience across applications within an organization. This is supported via Single Sign-On (SSO), in which a user’s credentials provide access to multiple systems. When an external identity provider is used for this authentication, it is referred to as federated identity. Users are likely familiar with this when, for instance, their Google, Apple, or Facebook login provides access to another site or service.

Maintaining individual access rights for each user in an organization would be prohibitively expensive. Therefore, role-based access controls are widely used to allow users who share a classification to have equivalent access, always with an eye toward the Principle of Least Privilege. The combination of individual and group authentication and authorization comprises Identity Access Management (IAM).

Well-considered roles and structured processes around group management are fundamental to securely implementing Zero Trust.

Network Considerations

Prior to implementing authentication and other Zero Trust security infrastructure, some attention should be given to the network itself. In cloud computing, software-defined networks are called Virtual Private Clouds (VPCs) that comprise related resources that share an IP address pool. Instances within one VPC cannot contact instances in another without specific network handling to allow and route such communication. Careful application of permissions should forbid unapproved communication even to peers within the VPC. The security boundaries provided by VPCs encourage a practice called micro-segmentation, in which collections of services are isolated from others, and approved communication between clients and services must be explicitly permitted. In this fashion, even if a VPC is compromised, the blast radius of possible damage is kept to a minimum. Unlike in traditional networking, a nefarious actor will not have trusted access to other network members.

Conclusion

Implementing a robust Zero Trust framework requires a complete rethinking of network security. Responsibility for ensuring there are no breaches shifts from a hands-off “castle-and-moat” system in which trust is assumed within the perimeter to a model in which every user, device, and service must prove its identity and trustworthiness through providing credentials and telemetry data that are regularly collected and kept up to date. This requires a significant initial investment in infrastructure and automation but pays off in ease of access and a higher degree of security.