Intro to Zero Trust

This is the first in a planned series of articles about the concept of zero trust. It is a big subject; today, we will start small, and focus on getting the most basic understanding of just what zero trust is and what it means for an organization.

The first thing to do is talk about what isn’t changing when we move to zero trust. The logical model has always been to place a checkpoint between where you are and where you want to go. All information security can be viewed in this light: account credentials imply a system to verify a digital identity, access controls verify requests for resources, and the firewall acts as a literal checkpoint at the perimeter of the system. Zero trust alters nothing in that conceptual framework. Instead, the changes lie in where the checkpoints are placed in relation to resources.

In the past, there was an assumption that network boundaries meant that external connections had to be viewed with suspicion, but that internal connections were right and natural and above reproach. That understanding is being proven wrong more and more each day. BYOD has complicated the degree of control administrators have over their internal environments. Remote work means that components of the environment are distributed geographically, and administrators have lost control over physical settings. Attackers have always had some amount of ability to penetrate network defenses, and as numbers and complexity grows, the chance that someone will gain access to the network approaches certainty.

Zero trust is a network and system administration philosophy where the designers and administrators assume that the boundary of an organization’s network cannot be considered secure. NIST defines it as “a collection of concepts and ideas… [that enforces] accurate, least privilege per-request access decisions… in the face of a network viewed as compromised” (Rose et al., 2020). At first glance, we’re still trying to restrict access to only those authorized. The change is implied in the phrase “per-request access decisions”.

In terms of those checkpoints we mentioned, with zero trust, the fences surround the smallest territory possible — ideally, one resource per fence. That way, each time some subject of the system attempts to access an object, that specific request must be verified before access is granted.

Instead of continuing to talk in terms of checkpoints and fences, let’s move to some basic guidelines that NIST provides for zero trust architectures. These seven tenets form the core for how an organization can begin to think about how zero trust might work in their environment.

1. All data sources and computing services are considered resources.

This one seems trivial, and in one sense it is: all of an organization’s information systems are of course resources for their use. But thinking this way and acting this way are two very different ideas. It is easy for a system administrator to see a database server as an information resource, but how often do we think of a particular network segment that way? From a zero trust perspective, both are resources, and access to either requires the same kind of scrutiny.

2. All communication is secured regardless of network location.

This tenet starts to reveal where the conceptual changes begin. We are all familiar with the idea of using a VPN to gain access to an internal network. In zero trust, however, all of the machines on the internal network must also request and be granted access, if they want to communicate at all. I don’t mean that each of them has to have its own VPN; I’m not recommending any specific products or technologies here. I just mean that being on the internal network shouldn’t automatically grant any sort of trust.

3. Access to individual enterprise resources is granted on a per session basis.

This idea deserves a little unpacking. With the previous tenet, we said we wouldn’t trust an access request just because it came from the internal network. We also shouldn’t trust a user or system just because a previous request was granted, whether that request was for this resource or some other.

4. Access to resources is determined by dynamic policy — including the observable state of client identity, application service, and the requesting asset — and may include other behavioral and environmental attributes.

Usernames and passwords are fine for authenticating a digital identity in simple circumstances, but they are not the only way that a subject could be authenticated. This tenet suggests that an organization should consider all of the different authentication and access control scenarios available to them, and select the appropriate ones for the different types of assets and access requests that they encounter.

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.

If the idea is zero trust, then any asset might be compromised at any time. The only way to be confident of an asset’s status is to investigate that status, regularly or constantly.

6. All resource authentications and authorizations are dynamic and strictly enforced before access is allowed.

This tenet is similar to the idea of not trusting an access request just because it came from the internal network, or it was granted yesterday, but goes a little farther: even if an access request was granted a minute ago, if something about the situation changes, then it should be possible to sever that request if necessary.

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

This one boils down to “don’t get comfortable.” No situation is static indefinitely. The information that we collect to make authorization and access control decisions can be logged to provide better insight into the functioning of our systems; that insight might be invaluable when the next attack comes.

In later articles of the series, we will look at the ways that these tenets affect design decisions that administrators and security professionals face in today’s threat environment.

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture (Special Publication No. 800–207; Computer Security). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207