Pragmatic zero trust

“Zero trust” has been one of the more hyped terms of the last couple of years and there are few signs that it will decline in popularity in the early part of the 2020s. However, as with most buzz terms in IT, there is no consistent view of what “zero trust” means in practice, particularly now that the vendor marketing teams have firmly got the term within their sights and seem intent on labeling everything “zero trust.” This short blog post will cut through the marketing hype and discuss the history, nature, and future of “zero trust.”

You’ll likely have seen articles with headlines such as “identity is the new perimeter,” or “the firewall is dead,” or similar during the evolution of IT towards a more agile, cloud-based delivery model over the last 10–15 years. A lot of this thinking derives from the concepts of zero trust. In reality, zero trust is the latest iteration of an idea that has been around since at least the mid-2000s when the Jericho Forum described the concept of “de-perimiterization.” However, it has taken the wider IT ecosystem the best part of a decade to catch up with the thinking of the Jericho Forum and zero trust has been re-born since Google published their BeyondCorp whitepapers describing how they have adopted a zero-trust approach towards the provisioning of end-user services to their employees. More recently, Google published a whitepaper on BeyondProd, which extends zero-trust principles to the security of cloud-native production services. While the Google whitepapers should be mandatory reading for all security professionals, they are not the only interpretation of zero trust and should not be viewed as being definitive of anything other than Google’s own working implementation of zero-trust principles. The aim of this post is to provide a less-specific introduction to zero-trust principles and the common underlying conceptual architecture.

Zero Trust

So, what does zero trust mean in practice?  The definition I use is:

Every request to access a resource starts from a position of zero trust. Access decisions are then made and enforced based on a set of trust metrics selected by the organization. These trust metrics could relate to the user, their access device, the resource to be accessed, or a combination thereof.

In terms of the overall architecture, the conceptual view is shown in Figure 1.

                       Figure 1: Conceptual Zero Trust Architecture

Figure 1 illustrates a user requesting access to a protected resource with their access being mediated by a trust broker. The real zero-trust magic resides within the trust broker. However, there are a few things to call out in this architecture before we get to the magic:

1. The user could be on the local network or on the internet. It is at the discretion of the implementing organization as to whether network location is viewed as a trust metric. In the Google BeyondCorp approach, the location of the user is irrelevant as both the internet and the local network are viewed as untrusted. Other organizations may choose to take a different approach.
2. The user’s device is shown as a laptop, it could well be a mobile telephone or other smart device. Organizations can choose to apply different trust metrics to different types of devices.
3. The “user” could be a non-human actor, for example another service in the context of microservices-based application infrastructures.
4. The protected resources could be local applications, or cloud-hosted applications, or storage locations, or API endpoints, or just about any kind of resource that an end user may wish to access.
5. The trust broker and the associated enforcement capability could be hosted either on premises or on cloud and either as an integrated broker and access enforcement capability or as separate broker and access enforcement capabilities.

The trust broker is the key element of the zero trust architecture as it bears responsibility for deciding whether the access request is sufficiently trusted so as to be allowed access to the resource. In order to be able to make this decision, a variety of trust metrics must be defined (alongside some trust threshold which the request must successfully pass) while the information required to inform the relevant metrics must also be available to the broker. Let’s examine some potential metrics.

User metrics

Authentication status: Is the user authenticated? If so, how strong is the authentication method used? For example, did the user need to pass multi-factor authentication? Service-to-service requests can also have similar metrics relating to the presented security tokens.

Behavioral status: Is the user acting in accordance with normal working patterns? For example, is the user request coming in during normal working hours? Does the request abide by geographical constraints (for example no simultaneous requests from London and San Francisco)? Is the user making use of their usual access device?

Device metrics

Device identity: Is the device known? Is the device corporately managed? This type of check requires a suitable asset inventory.

Device hygiene: Is the device up to date with security patches? Does the device have anti-malware or EDR controls installed? This type of check may require the installation of agents on the end-user devices.

Device location: Is the device in the expected geographic location? Does available threat intelligence indicate that the device is accessing from a known bad network? Is the device located on a trusted network? NB. As noted earlier, Google does not use the concept of trusted networks in their implementation of BeyondCorp.

Resource metrics

Allow/Block: Does the resource maintain its own access controls? Is the user allowed access? Is the specific resource request allowed (type of access, data affected)?

Micro-segmentation: Does the resource expect to receive requests from the user and/or segment from which the request originates?

Encryption status: Is the link between the user and the resource adequately encrypted?

Resource status: Does the requested resource itself pose a risk to the end user? This is particularly relevant in the cloud context when protecting users from accessing services known to be untrustworthy.

While the trust broker is responsible for assessing whether the request is sufficiently trusted to be allowed to proceed, there is also the need for an enforcement capability such that those requests that do not meet the established trust threshold are denied alongside a variety of supporting information repositories. The enforcement capability can be delivered in a variety of ways depending upon the implementation.

Implementation options

There are now a variety of technology solutions that can be used to deliver zero-trust approaches, but it is important to bear in mind the range of possible trust metrics; the available solutions will typically only deliver a subset of the full spectrum of metrics, i.e. you do not get “zero trust in a box.” Examples of technologies that can form part of zero-trust implementations include:

• Microsoft Azure Active Directory Conditional Access
• Google Identity Aware Proxy
• Cisco Duo Beyond

The technologies above can be used to provide many of the identity, device and (more limited) the resource metrics described above. However, the primary focus tends to be on the user and device elements of the approach.

Hopefully it is clear from the section on metrics that zero-trust approaches do not operate in isolation. Organizations will typically need a wide set of supporting capabilities including:

Identity providers: identity directories, authentication providers, etc.

Asset inventories: device identity, device status

Certificate services: usual certificate authority services for provision of user, device, and service certificates

Threat intelligence: identification of suspicious networks and/or geographic locations, indicators of compromise in relation to requests and/or vulnerable applications

Enforcement capabilities: if moving from a typical legacy perimeterized environment, then there will likely be a requirement for significant network reconfiguration and implementation of enforcement capabilities throughout the technology stack.

Given the complexity of the adoption of zero-trust approaches, why are so many organizations looking at potentially adopting this model? There are a number of reasons, not least of which is user experience. The ability to provide users with access to the services they require without necessarily being connected to the local network (or VPN’d in) is key to supporting cloud-native ways of working. Similarly, the trust-broker approach allows more granular control of access to resources cognizant of the needs of the user, the device they are using to access the resource, and the nature of the resource itself. It allows the appropriate level of control to applied to specific resources rather than the much more blunt access control decision of a user’s device either being on the VPN or not being on the VPN.

Conclusions

It is important to recognize that zero trust does not deliver all the security needs of an organization. When some of the more excitable members of the security community talk about “the death of the firewall,” they are not being completely practical – organizations still need some way of delivering the enforcement elements of zero trust alongside micro-segmentation and blast radius reduction, i.e. a means to prevent lateral movement of an attacker or malware throughout an environment (although those “firewalls” may take the form of cloud-native network security groups or cloud workload protection platforms rather than traditional firewall appliances per se).  Similarly, while “identity is the new perimeter” is a useful battle-cry for identity solution providers, it would probably be more accurate to say that “identity is a new perimeter” rather than the new perimeter.  It is also important to recognize the cultural changes required to implement zero trust approaches; as with many areas relating to cloud-native ways of working, it is often the governance and ownership issues that cause more difficulty than the technology implementation.

Hopefully this short article has helped to illustrate the complexity underlying the simple buzz term that is “zero trust.” Zero trust is here to stay and so it’s important that we all understand what it means in practice.

Lee Newcombe

Expert in Cloud security, Security Architecture

I advise my clients on how to identify and manage cyber risk in an ever-changing and increasingly digital world.
I have assisted central government, a regulatory authority, global insurers, major banks, transport providers, utilities providers, consumer goods producers and others with their adoption of cloud services through provision of pragmatic, forward-looking and practical guidance relating to the organizational, process and technical change needed to securely deliver the benefits offered by the cloud model.