Chapter 10. The Adversarial View

Most formal proposals in the technology industry include a section commonly known as “security considerations.” In fact, the IETF mandates a security consideration section for all submitted RFCs.

This section is crucial for many reasons. First, it clearly communicates potential pitfalls, dangers, and caveats. This is extraordinarily important during the implementation and deployment phases, as it will help to ensure that the operator arrives at a design which retains the security properties that the system was originally designed for.

Second, it demonstrates that the authors have put good thought into the ways in which the system can be attacked. It is far too easy to design a seemingly secure system which harbors a major vulnerability just under the surface. And finally, it sets the stage for discussion on how to best approach and manage the security risks presented. As a result, including a security considerations section is generally considered best practice. Some might even view the work as deceptive without such a section, since it might indicate that the authors are trying to push a known-weak technology.

Even the strongest proposals will have some security considerations. For instance, the latest RFC for the TLS protocol has 12 pages worth. It is important to understand that a system is not inherently insecure simply because there are security considerations associated with it; rather, it should be a sign that the system as a whole is more secure.

In this chapter, we will discuss the potential pitfalls, dangers, and attack vectors associated with the zero trust model. If you were trying to penetrate a zero trust network, how might you do it?

Identity Theft

Practically all of the decisions and operations performed within a zero trust network are made on the basis of authenticated identity. In Chapter 6, we discussed the difference between informal and authoritative identity, such as the difference between your “human” identity and your government identity. Computer systems implement authoritative identity similar to the way governments do—and similar to the way your government identity can be stolen, so can your identity within a computer system.

If your identity is stolen or compromised, it might be possible for an attacker to masquerade their way through the zero trust authentication and authorization checks. This is, of course, extremely undesirable. Since identity in a computer system is typically tied to some sort of “secret” which is used to prove said identity, it is extraordinarily important to protect those secrets as well as we can.

These secrets can be protected in different ways, based on the type of component the identity belongs to. Careful consideration should go into choosing which methods to use for which components. We spoke about different ways to approach this problem in previous chapters.

Since a zero trust network authenticates both the device and the user/application, it is necessary for an attacker to steal at least two identities in order to gain access to resources within it, raising the bar when compared to traditional approaches in use today. These concerns can be additionally mitigated through the use of trust engine behavioral analysis.

While securing identity is a widespread industry concern, and is not specific to zero trust, its importance is large enough to justify calling it out as something which should be carefully handled, despite the fact that the zero trust model works to naturally mitigate this threat.

Distributed Denial of Service

A zero trust network is primarily concerned with authentication, authorization, and confidentiality, generally affected by tightly controlling access to all network resources. While the architecture strives to authenticate and authorize just about everything on the network, it does not provide good mitigation against denial-of-service (DoS) attacks on its own. Distributed DoS (DDoS) attacks that are volumetric in nature can be particularly troublesome.

Just about any system which can receive packets is vulnerable to volumetric DDoS, even those employing the zero trust architecture. Some implementations “darken” internet-facing endpoints through the use of pre-authentication protocols. We spoke a little about these in “Bootstrapping Trust: The First Packet”, the basic premise being to hide those endpoints behind a deny-all rule, adding narrow exceptions based only on signaling. While this method goes a long way in helping to keep the endpoint addresses obscured, it does not fundamentally mitigate DDoS attacks.

Zero trust networks, by nature, retain a great deal of information about what to expect on the network. This information can be used to calculate policy for more traditional traffic filtering defenses far upstream. For instance, perhaps only a few systems in the network actually communicate with the internet. In this case, we can use the policy to calculate coarse enforcement rules from the perspective of an upstream device, applying very broad enforcement with few exceptions. The advantages of this approach over the typical approach are two-fold:

  • The configuration is fully automated.
  • The traffic filtering mechanisms can remain stateless.

The second advantage is quite a large one, since it obviates the need for expensive hardware and complicated state replication schemes. In this way, these filtering devices act more like scrubbers than firewalls. Of course, this only makes sense if you operate a large network. If you have a few racks in a colocation facility, or are cloud native, you might prefer to leverage an online DDoS-prevention service.

The short of it is, DDoS is still a problem in the zero trust world, and while we might have a few new clever ways to address it, it will still require special attention.

Endpoint Enumeration

The zero trust model lends itself naturally to perimeterless networks, since a perimeter makes much less sense when the internal network is untrusted. The peer-to-peer nature of perimeterless networks make them generally easier to maintain than perimeter networks, which frequently include network gateways and tunnels like VPNs which pose scaling, performance, and availability challenges.

As a result of this architecture, it is possible for an adversary to build a system diagram by observing which systems talk to which endpoints. This is in contrast to architectures which leverage network gateways like VPNs, since an adversary observing VPN traffic can’t see conversations with endpoints beyond the VPN gateway. It should be noted that this advantage is lost as soon as the traffic crosses the gateway—a classic property of the perimeter model.

It is here that we make a distinction between privacy and confidentiality. The zero trust model guarantees network confidentiality, but not privacy. That is, ongoing conversations can be observed and asserted to exist; however, the contents of the conversation are protected. Systems that provide network privacy attempt to obscure the fact that the conversation happened at all. Tor is a popular example of a system which provides network privacy. This is a wholly different problem space and is considered out of scope for the zero trust model.

If a limited form of privacy over public networks is desired, tunneling traffic through site-to-site tunnels is still an option in zero trust networks. This deployment will make it more difficult to see which individual hosts are communicating on either side of the tunnel. We should be clear that this additional privacy protection should not be considered critical in the network’s security. In fact, in some ways it undermines the zero trust model itself, as hiding information in one part of the network and not another suggests that one is more trusted than the other.

Untrusted Computing Platform

We covered this in Chapter 5, but it’s important to reiterate that zero trust networks require the underlying computing platform to be a trustworthy system. There’s a distinction to be made here between the computing platform itself (think cloud hardware, virtual machine hypervisor) being trusted and the “device” being trusted. Oftentimes these two systems are conflated, but the attacks against each are subtly different due to their differing privilege levels.

Totally defending against untrustworthy computing platforms is practically impossible. Consider a system which used hardware that purposefully generated weak random numbers (which encryption systems depend on). Defending against that type of attacker would first involve detecting the problem, though this alone might be impossible if the attacker hides their capability most of the time.

Despite our inability to guard against a truly malicious computer platform, zero trust systems can still guard against simpler attacks against the platform. Encrypting persistent data and swapped-out memory pages will mitigate simpler attacks by malicious peers on the computing platform. It will also remove some small amount of trust in the platform’s operators and therefore is recommended.

Physical Coercion

Zero trust networks effectively mitigate many threats in the virtual world, but threats in the real world are another beast entirely. Valid users and devices can be effectively coerced to aid an attacker to gain access to a system that they shouldn’t have access to. Border crossing can often be a place where government entities have substantial power over an individual who just wants to get to their destination. And someone with a blunt instrument can force even the most honest individuals to aid them (as demonstrated in Figure 10-1).

Figure 10-1. The reality of threats in a system (cartoon by XKCD: https://xkcd.com/538/)

The reality is that defending against these types of compromises is ill-advised. No security professional would ever tell someone in this situation to risk their physical well-being to protect the information that they have access to. Therefore, the best we can work toward as an industry is to keep only the least sensitive data and systems vulnerable to the compromise of a single individual. For higher-value targets, group authorization is an effective mitigation against these threats.

Subtler physical attacks against individuals (say someone is able to insert a USB device into an unguarded laptop) are best mitigated by a consistent process of cycling both devices and credentials. Scanning of unrotated devices can also help to mitigate these types of attacks.

If someone has physical access to your device, they can do a lot of damage. However, that statement should not be license to throw our hands up in the air and not at least try to mitigate these threats, particularly when it comes to securing data used for zero trust authentication/authorization. There are clear steps that can be taken to lessen the impact and duration of compromise even if someone has physical access to a device, and zero trust networks add those steps. You can read more about physical device security in Chapter 5.

Invalidation

Invalidation is a hard problem in computer science. In the context of a zero trust network, invalidation applies chiefly to long-running actions that were previously authorized but are no longer.

The definition of an action is largely dependent on your chosen authorization processes. For instance, if you authorize access on a request-by-request basis, an action would be considered as a single application-level request/operation. If, on the other hand, you authorize network flows (like a TCP session) instead of application requests, an action would be considered to be a single network session.

How quickly and effectively ongoing actions can be invalidated deeply affects security response. It is important to gauge how much risk you’re willing to tolerate in this area as you design your zero trust network, since the answer has the potential to significantly affect how you might approach certain problems. For instance, if a new TCP session is the action being authorized, and some services maintain TCP sessions for multiple days on end, is it acceptable to say that an entity with revoked credentials might retain access for that long? Maybe not.

Luckily, we have some tools in our chest to address this problem. First, and perhaps most obvious, is to perform more granular authorizations on actions that are short-lived. Perhaps this means that the enforcement component authorizes application-level requests instead of new network sessions. While it is still possible to have long-running application requests, they are in practice less frequent than long-running network sessions.

Another approach, though somewhat naive, is to periodically reset network sessions, enforcing a maximum lifetime. When the application/client reconnects, it will be forced back through the authorization process.

The best approach though is to teach the enforcement component to track ongoing actions, and rather than reset them after a period of time, send another authorization request to the policy engine. If the policy engine decides that the action is now unauthorized, the enforcement component can forcibly reset it.

As you can see, these mechanisms still rely on a “pull” model, in which the enforcement component is forced to periodically reauthorize. As a result, sessions can only be invalidated as fast as the longest polling period configured in the enforcement component. While invalidation is best done as a push or event-based model, those approaches come with additional complexities and challenges which perhaps outweigh the benefits. Regardless, it can be seen that the problem is (at the very least) addressable.

Control Plane Security

We discussed many control plane services throughout this book, responsible for things like policy authorization and tracking inventory. Depending on needs, a zero trust control plane can comprise a nontrivial number of services, all of which play a crucial role in ensuring authorization security throughout the network. A natural question follows: how can you protect your zero trust control plane systems, and what happens if one is compromised?

Well, it’s not good, that’s for sure! It is possible to completely undermine the zero trust architecture if a control plane compromise is pervasive enough. As such, it is absolutely critical to ensure the security of these systems. This is not a weakness unique to the zero trust model—it exists even today in perimeter networks. If your perimeter firewall is compromised, what is the impact? Nevertheless, the concern is great enough to warrant a discussion.

Control plane security can begin through traditional means, providing very limited network connectivity and strict access control. Some control plane systems are more sensitive than others. For instance, compromising a data store housing historical access data is strictly less useful to an attacker than compromising the policy engine. In the former, an attacker may be able to artificially raise their level of trust by falsifying access patterns, where the latter leads to a complete compromise of zero trust authorization, allowing the attacker to authorize anything they please.

For the most sensitive systems (i.e., the policy engine), rigorous controls should be applied from the beginning. Requiring group authentication and authorization in order to make changes to these systems is a real option and should be heavily considered. Changes should be infrequent and should generate broadly seen messages or alerts. It should not be possible for a control plane change to go unnoticed.

Another good practice is to keep the control plane systems isolated from an administrative standpoint. Perhaps that means they live in a dedicated cloud provider account or are kept in a part of the datacenter that has more rigorous access control. Doing this allows access to be more carefully audited and minimizes the risk presented to control plane systems by their administrative facilities. Isolating these systems administratively does not mean that they are logically isolated from the rest of the network. Despite administrative isolation, it is important that control plane systems participate in the network just as any other service does. Attempts to isolate them can quickly lead back to a perimeterized design, which can be considered the worst-case scenario for zero trust control plane security.

As the network matures, zero trust enforcement can be slowly applied to the control plane systems themselves. Kind of like rewriting the C compiler in C, backing zero trust enforcement into the control plane ensures that tight security is applied homogeneously throughout the network and that there are no special cases. The propensity to introduce a chicken-and-egg problem should not deter you from this approach. Such problems are manageable and can usually be worked through if sufficient thought is put into them. The alternative (putting control plane systems in a perimeter network) would leave these systems the least protected of all, and is generally unacceptable in the context of a zero trust network.