In May, The White House released an executive order on improving the nation’s cybersecurity. The order came with various directives for Federal Civilian Executive Branch agencies. Among other efforts, the order focused on the federal government’s advance toward zero trust architecture (ZTA). It framed this journey as one “which shall incorporate, as appropriate, the migration steps that the National Institute of Standards and Technology (NIST) … has outlined in standards and guidance.”

This action item raises an important question. What standards and guidance has NIST outlined in reference to zero trust? Let’s take a look below.

Putting Zero Trust Into Perspective

In its Special Publication (SP) 800-207 ‘Zero Trust Architecture’ published in August 2020, NIST pointed to the reality that many conceptualizations of zero trust position themselves in terms of what to exclude. Many of those take umbrage with perimeter defenses like firewalls in particular. As I’ve written before, zero trust and firewalls can coexist.

But there’s an even larger issue here. In the words of NIST, “most of these definitions continue to define themselves in relation to perimeters in some way (such as microsegmentation or micro-perimeters) … as part of the functional capabilities of a ZTA.” Such definitions frame themselves in terms of perimeter-based models while at the same time attempting to move past them.

Seven Tenets of Zero Trust

NIST sought to define what to include in zero trust, not what to exclude. This led the agency to develop seven tenets of zero trust. They define the first principle this way: “All data sources and computing services are considered resources.”

A network may be composed of multiple classes of devices. A network may also have small footprint devices that send data to aggregators/storage, software as a service (SaaS), systems sending instructions to actuators and other functions. Also, an enterprise may decide to classify personally owned devices as resources if they can access enterprise-owned resources.

Let’s take a moment to unpack this. Elsewhere in SP 800-207, NIST clarified that resources consist of assets, workflows, accounts and services. Network segments aren’t resources, the agency noted, because “the network location is no longer seen as the prime component to the security posture of the resource.” In other words, while network segmentation still serves a role in a network security strategy, the part it plays is a supporting one. An external attacker can infiltrate a network segment by compromising a connected endpoint or authorized account, for instance. With this in mind, assume every potential connection attempt is suspicious unless proven otherwise.

The emphasis of that last sentence falls on the word every. Don’t assume that any network device or asset is automatically secure. You also can’t presume that a device will receive validation every time it submits a connection attempt. Compromises happen. Things change.

Visibility and Insight

This highlights the need for security teams to achieve and maintain visibility over their assets. What if they lack insight into their assets and how they interact? They won’t be able to implement an authentication and access control policy, one of the cornerstones of a zero trust architecture. Towards that end, security teams can extract metadata from network traffic to discover their apps and map their interactions. They can then use that map as a baseline to watch for potentially suspicious activity going forward.

Using network traffic is especially useful for asset mapping. After all, it can detect certain types of resources like legacy systems that other methods might fail to spot. This is important, as organizations’ networks are more complex than ever. After all, we’re fully within the rise of IoT, containers, cloud environments and the like. Anything with a network connection could provide attackers with a way in. Hence the need for an approach that considers all kinds of assets.

The Connection to Hybrid Work

The final sentence of the principle quoted above is particularly instructive for organizations in the age of hybrid work. Prior to 2020, the notion of allowing personal devices to connect to enterprise-owned resources operated in the context of Bring Your Own Device (BYOD) programs. Many organizations created those programs to support the demands of their employees for how they wanted to do their work. In doing so, they also saved money by removing the need for every employee to have a corporate-issued device.

That changed with the events of 2020. The world shifted to remote work, and the hybrid or flex work model followed. These events made personal devices essential for employees to do their work from their home offices. In doing so, they made the work of security teams harder, as traditional security approaches limited how much they could gain visibility over those remote devices — especially when they weren’t located in the same physical place.

That’s not an issue with zero trust. Indeed, zero trust can help because it treats each network connection as a resource to be validated. Every device, account and user is authorized on a case-by-case basis. That gives security teams a means to constantly validate remote connections.

More Zero Trust Principles to Come

This marks the beginning of a series looking at the basic tenets identified by NIST in SP 800-207. Stay tuned for the next blog post.