CHAPTER 1

Zero Trust Fundamentals

In a time where network surveillance is ubiquitous, we find ourselves having a hard

time knowing who to trust. Can we trust that our internet traffic will be safe from
eavesdropping? Certainly not! What about that provider you leased your fiber from?
Or that contracted technician who was in your datacenter yesterday working on the
cabling?
Whistleblowers like Edward Snowden and Mark Klein have revealed the tenacity of
government-backed spy rings. The world was shocked at the revelation that they had
managed to get inside the datacenters of large organizations. But why? Isn’t it exactly
what you would do in their position? Especially if you knew that traffic there would
not be encrypted?
The assumption that systems and traffic within a datacenter can be trusted is flawed.
Modern networks and usage patterns no longer echo those that made perimeter
defense make sense many years ago. As a result, moving freely within a “secure” infra‐
structure is frequently trivial once a single host or link there has been compromised.
Zero trust aims to solve the inherent problems in placing our trust in the network.
Instead, it is possible to secure network communication and access so effectively that
physical security of the transport layer can be reasonably disregarded. It goes without
saying that this is a lofty goal. The good news is that we’ve got pretty good crypto
these days, and given the right automation systems, this vision is actually attainable.

What Is a Zero Trust Network?

A zero trust network is built upon five fundamental assertions:

• The network is always assumed to be hostile.

• External and internal threats exist on the network at all times.

1
 • Network locality is not sufficient for deciding trust in a network.
• Every device, user, and network flow is authenticated and authorized.
• Policies must be dynamic and calculated from as many sources of data as
possible.
Traditional network security architecture breaks different networks (or pieces of a
single network) into zones, contained by one or more firewalls. Each zone is granted
some level of trust, which determines the network resources it is permitted to reach.
This model provides very strong defense-in-depth. For example, resources deemed
more risky, such as web servers that face the public internet, are placed in an exclu‐
sion zone (often termed a “DMZ”), where traffic can be tightly monitored and con‐
trolled. Such an approach gives rise to an architecture that is similar to some you
might have seen before, such as the one shown in Figure 1-1.

Figure 1-1. Traditional network security architecture

The zero trust model turns this diagram inside out. Placing stopgaps in the network
is a solid step forward from the designs of yesteryear, but it is significantly lacking in
the modern cyberattack landscape. There are many disadvantages:

• Lack of intra-zone traffic inspection

• Lack of flexibility in host placement (both physical and logical)
• Single points of failure

2 | Chapter 1: Zero Trust Fundamentals

It should be noted that, should network locality requirements be removed, the need
for VPNs is also removed. A VPN (or virtual private network) allows a user to
authenticate in order to receive an IP address on a remote network. The traffic is then
tunneled from the device to the remote network, where it is decapsulated and routed.
It’s the greatest backdoor that no one ever suspected.
If we instead declare that network location has no value, VPN is suddenly rendered
obsolete, along with several other modern network constructs. Of course, this man‐
date necessitates pushing enforcement as far toward the network edge as possible, but
at the same time relieves the core from such responsibility. Additionally, stateful fire‐
walls exist in all major operating systems, and advances in switching and routing have
opened an opportunity to install advanced capabilities at the edge. All of these gains
come together to form one conclusion: the time is right for a paradigm shift.
By leveraging distributed policy enforcement and applying zero trust principles, we
can produce a design similar to the one shown in Figure 1-2.

Figure 1-2. Zero trust architecture

Introducing the Zero Trust Control Plane

The supporting system is known as the control plane, while most everything else is
referred to as the data plane, which the control plane coordinates and configures.

What Is a Zero Trust Network? | 3

Requests for access to protected resources are first made through the control plane,
where both the device and user must be authenticated and authorized. Fine-grained
policy can be applied at this layer, perhaps based on role in the organization, time of
day, or type of device. Access to more secure resources can additionally mandate
stronger authentication.
Once the control plane has decided that the request will be allowed, it dynamically
configures the data plane to accept traffic from that client (and that client only). In
addition, it can coordinate the details of an encrypted tunnel between the requestor
and the resource. This can include temporary one-time-use credentials, keys, and
ephemeral port numbers.
While some compromises can be made on the strength of these measures, the basic
idea is that an authoritative source, or trusted third party, is granted the ability to
authenticate, authorize, and coordinate access in real time, based on a variety of
inputs.

Evolution of the Perimeter Model

The traditional architecture described in this book is often referred to as the perime‐
ter model, after the castle-wall approach used in physical security. This approach pro‐
tects sensitive items by building lines of defenses that an intruder must penetrate
before gaining access. Unfortunately, this approach is fundamentally flawed in the
context of computer networks and no longer suffices. In order to fully understand the
failure, it is useful to recall how the current model was arrived at.

Managing the Global IP Address Space

The journey that led to the perimeter model began with address assignment. Net‐
works were being connected at an ever-increasing rate during the days of the early
internet. If it wasn’t being connected to the internet (remember the internet wasn’t
ubiquitous at the time), it was being connected to another business unit, another
company, or perhaps a research network. Of course, IP addresses must be unique in
any given IP network, and if the network operators were unlucky enough to have
overlapping ranges, they would have a lot of work to do in changing them all. If the
network you are connecting to happens to be the internet, then your addresses must
be globally unique. So clearly some coordination is required here.
The Internet Assigned Numbers Authority (IANA), formally established in 1998, is
the body that today provides that coordination. Prior to the establishment of the
IANA, this responsibility was handled by Jon Postel, who created the internet map
shown in Figure 1-3. He was the authoritative source for IP address ownership
records, and if you wanted to guarantee that your IP addresses were globally unique,
you would register with him. At this time, everybody was encouraged to register for

4 | Chapter 1: Zero Trust Fundamentals

IP address space, even if the network being registered was not going to be connected
to the internet. The assumption was that even if a network was not connected now, it
would probably be connected to another network at some point.

Figure 1-3. A map of the early internet created by Jon Postel, dated February 1982

Evolution of the Perimeter Model | 5