On Zero Trust and BeyondCorp

This month I was at Black Hat and there was a new buzzword being tossed around by security vendors in the business hall:

Zero Trust.

I always like to see what exciting new concepts the security industry tries to productize and incorporate into their product demos to convince budget decision makers to buy them, so I approached a vendor that had a sign about “Zero Trust in the Enterprise“. I chatted with a technical salesperson who said something along the lines of:

Our product has Zero Trust incorporated into it. Using xxxx, you can ensure that your network is monitored continuously and secure.

Unnamed technical salesperson at unnamed security vendor

What does that even mean? Mind you, this was a network security solution, which left me quite puzzled at first. Sure, we can apply it to a network, but Zero Trust is all about strong identity context behind every action. The concept of zero trust is tied to identity, and not the network itself.

Origins

Back in 2010, researchers at Forrester Research published the report “No More Chewy Centers: Introducing The Zero Trust Model Of Information Security” – and hence the term ‘Zero Trust’ was born. Zero Trust (ZT) is a design principle that was popularized by Google’s BeyondCorp architecture in 2014. Like most design principles, it is not something that one can achieve or implement simply by slapping on an expensive product from a security vendor. (Not even the best and latest “NeXt GenErAtiOn FiReWaLL”)

Before Zero Trust

In the yesteryears of security, network security was partly achieved through network segregation – dividing a large network up into logical administrative units – and enforcing access policies between those units.

The main network segregation was that of the perimeter – the boundary between what is internal and external. For many enterprises, that simply meant the private address space was internal and trusted, and everything else was external. Placed in between were firewalls, network segmentation measures (typically via VLANs+ACLs) and VPNs.

For years, enterprises have been using VLANs+ACLs and/or internal firewalls as a way to segment networks. It is still an effective approach to controlling ingress/egress traffic flow, but these traditional methods have some major drawbacks, biggest of them being the operational nightmare of managing the VLANs and ACLs: every single internal networking appliance (switch, router, wireless AP) has to know which VLANs exist, which switch access ports should be tagged with which VLANs, which ACLs apply… The decentralized nature of this method makes it very difficult to effect a single change on the network in a consistent manner, causing configuration drift.

In addition to the manageability issue, there are many other drawbacks to the secure perimeter approach, especially in modern enterprise environments. The operating assumption is that the perimeter is impenetrable – that is never true. Also, trusting everything on the internal network is not a good idea. Insider threats are devastating. It also begets the question – where is the perimeter? The advent of cloud computing has blurred the line between what is internal and external. Should there be multiple perimeters? (and the answer is NOT using a site-to-site VPN and merging everything into one large internal network)

It’s not that the secure perimeter model is obsolete – many enterprises still use a secure perimeter as part of their security policy. After all, building a fortress has its marked benefits. However, operating solely on the secure perimeter model and having a single trust boundary – internal vs. external – is insufficient, for the following reasons (in summary):

• Trust is based on device network properties.
• Insider threats are not considered.
• The perimeter is never completely impenetrable in practice.
• Traditional segmentation methods (e.g. VLANs) is an operational nightmare without the help of configuration management tooling, especially in heterogeneous networks.
• Defining the network perimeter is difficult in modern enterprise environments.

So what is Zero Trust?

Instead of trusting everything whatever is behind the network perimeter, the Zero Trust model assumes that the network is breached and that every request is treated as if it originated from the external network (that is, untrusted). It is designed to limit lateral movement of threat actors across internal network resources.

The core motto of Zero Trust is “never trust, always verify“, which is rooted in the following principles:

1. Always assume that the network is breached.
2. Therefore, trust nothing implicitly.
3. Ensure that all network entities and traffic are authenticated and authorized. This includes all devices, users and traffic.
4. Therefore, trust is centered around device identity, user identity and access context.
5. Trust has to be continually re-established (always verify!)
6. Hence, the access policy has to adapt to the ever-changing trust relationships, which has to be aggregated from multiple sources.

A common misconception is that Zero Trust eliminates the network perimeter – this is false. It strengthens the perimeter’s internal defenses so that all zones are equally trusted (or un-trusted).

Implementing Zero Trust

The old playbook of network segmentation is not entirely tossed away when it comes to adopting Zero Trust. In fact, Zero Trust informs network segmentation, drawing focus to the “what” (what is being segmented away), “why” and “how” (how the segmentation is enforced). There many methods to establish zero trust in a network. It can be distilled down to a few high-level steps that must be achieved:

1. Identifying information assets. This could be data such as Personal Health Information (PHI) or mission-critical applications and services (DNS, Active Directory/LDAP, RADIUS). This helps in understanding what to protect.
2. Identifying network flows concerning the information assets. This helps to establish context for how information flows within the network and how different network entities interact with one another.
3. Using the flows identified to develop a network architecture that is capable of facilitating Zero Trust. As we will see in the next section, building out a Zero Trust architecture requires some infrastructure heavylifting.
4. Developing a context-aware policy to facilitate access control to the critical information assets. Methods such 5W1H (Who, What, When, Where, Why, How) helps in developing the context for every flow between resources. This context-aware policy helps serve as a baseline that is limited to contextual actions that are known and allowed in the network.
5. Re-configuring and monitoring the network. Armed with the inventory of critical information assets and network flows, the next step would be to determine what to monitor. Network telemetry can then be analyzed in order to develop a better context-aware policy, and can also be used as part of an adaptive policy that responds to changing risks.

Bear in mind that there is no “correct” Zero Trust architecture. Again, Zero Trust is a design principle. Every organization has different needs and circumstances – every Zero Trust architecture and the resultant infrastructure is bespoke to the organization.

That being said, the folks have at Google have included a reference architecture in the BeyondCorp papers. It is an ideal, but in reality most implementations will have to make exceptions as appropriate for their environment.)

The overall architecture diagram of BeyondCorp presents many intertwining components:

The concrete transition steps toward a Zero Trust network look different for every organization. For most organizations operating solely on traditional perimeter-based network security, it might look something like this:

1. The first step would be to identify all endpoints in the network and store it all in an inventory.
   • This could be performed through user enrollment, or via some discovery process (i.e. using tools at your disposal – jamf, SCCM, or a perimeter access gateway). Whichever method you use, you will want to compile your sources in a manner that gives the best consistency and non-redundancy.
   • In addition to looking for managed devices on the network, you want to lookout for non-enrolled/disallowed devices such as personal mobile phones (i.e. obtaining switchport information from all the access switches, performing an address space scan).
   • Once you have an inventory, it will be much easier to ensure that endpoints are in a trusted and known state (that there is no configuration drift).
   • The inventory should have user information binded to each endpoint. Threat actors often use stolen organization credentials to login on a compromised endpoint, so you want to know which users in your directory are expected to be originating from which endpoints.
   • It will also help to re-evaluate your trusted computing base/critical infrastructure to determine which endpoints require the highest levels of security.
2. Setup a PKI (if you haven’t already!) so that you can sign and issue endpoint certificates. Certificates should be issued to every managed device and every user so that it can be uniquely identified as part of the organization. This also helps in uniquely identifying every device and its outbound connections – for example, if you see the same client certificate authenticating from two geographically different IP addresses within a short period of time, this might indicate that the machine is compromised and you can dynamically degrade the trust level appropriately.
3. Setup monitoring (if you haven’t already!) at appropriate points in the network. This helps in tagging the inventory with the types of traffic that is to be expected, and the connections that are typical between endpoints.
4. Develop a network policy and a policy enforcement framework. Regardless of whether your policy evaluation and enforcement is in-house or via some vendor software package, you need to develop a set of requirements for every endpoint in your inventory. This a multipart process and it involves all the network stakeholders in your organization. It helps to classify the inventory into different functional segments and then applying the same policy to the entire segment. You will also need to develop the different trust tiers in your policy (i.e. shutting an endpoint out completely, denying access to certain applications, etc.)
5. Monitor policy evaluation and policy enforcement. Initially, you will want policy enforcement to be permissive so that you can audit for any legitimate accesses that would otherwise be erroneously blocked. Over a period of time (depending on the size of your organization) you will want to progressively ramp up the strictness of the policy enforcement when you are more confident of the network policy. This also gives time for your security team to develop an iterative process to update the endpoint inventory is as updated as possible.

Once again, there is no “correct” Zero Trust architecture – different organizations will implement it differently. What matters is tailoring an infrastructure and a process that will help smoothly transition your organization’s security posture to a more secure state. As Zero Trust gains traction, expect to see maturity models (e.g. Capability Maturity Model Integration or CMMI) for Zero Trust to pop up, which helps organizations evaluate the maturity and completeness of vision of their execution.

Update: Microsoft has released a Zero Trust Maturity Model paper.