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.

More from Zero Trust

Overheard at RSA Conference 2024: Top trends cybersecurity experts are talking about

4 min read - At a brunch roundtable, one of the many informal events held during the RSA Conference 2024 (RSAC), the conversation turned to the most popular trends and themes at this year’s events. There was no disagreement in what people presenting sessions or companies on the Expo show floor were talking about: RSAC 2024 is all about artificial intelligence (or as one CISO said, “It’s not RSAC; it’s RSAI”). The chatter around AI shouldn’t have been a surprise to anyone who attended…

Does your security program suffer from piecemeal detection and response?

4 min read - Piecemeal Detection and Response (PDR) can manifest in various ways. The most common symptoms of PDR include: Multiple security information and event management (SIEM) tools (e.g., one on-premise and one in the cloud) Spending too much time or energy on integrating detection systems An underperforming security orchestration, automation and response (SOAR) system Only capable of taking automated responses on the endpoint Anomaly detection in silos (e.g., network separate from identity) If any of these symptoms resonate with your organization, it's…

Zero trust data security: It’s time to make the shift

4 min read - How do you secure something that no longer exists? With the rapid expansion of hybrid-remote work, IoT, APIs and applications, any notion of a network perimeter has effectively been eliminated. Plus, any risk inherent to your tech stack components becomes your risk whether you like it or not. Organizations of all sizes are increasingly vulnerable to breaches as their attack surfaces continue to grow and become more difficult — if not impossible — to define. Add geopolitical and economic instability…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today