Trust but verify: a Russian proverb Ronald Reagan often used to characterize U.S.-Russia relations, especially regarding nuclear weapons. The Internet has made it clear that the “trust” part of the proverb may not work so well. Today, we may have to say, “Never trust; only verify.”
Acknowledging that no entity, especially the kind made of human DNA, is trustworthy, so verification is necessary at all times, John Kindervag originated the concept of “Zero Trust” during his tenure at Gartner, in response the ever-disintegrating network perimeter, and attendant failure of traditional network defenses – firewalls, IPS/IDS, proxies, and similar systems.
The concept of network defense as “crunchy outside, chewy inside” has clearly proven inadequate, and does not reflect the reality of how users consume IT resources today.
Implementing Zero Trust requires a seismic change in thinking and architecture. The era of cloud computing, however, offers a rare chance to implement entirely new models of data processing, and associated security. As you move to the cloud, consider building in security through a Zero Trust model. The old ways don’t work: it’s time for a new approach.
What are the core ideas of Zero Trust? Well, the best source on this is Jon Kindervag, who originated the idea, and evangelizes it energetically. Let’s look at Kindervag’s principles, and see how they align – or clash – with federal guidelines, regulations, and standards.
Identify Your Sensitive Data
You have to know what you’re trying to protect, although identifying sensitive data is often harder than what you might expect.
This aspect of Zero Trust, however, aligns nicely with:
- Phase one (“Identify”) of the NIST Cybersecurity Framework
- OMB M-17-09 (“Management of Federal High Value Assets”)
- DHS’s support of HVA protection (“Securing High Value Assets”)
Map the Data Flows of Your Sensitive Data
Once you get a handle on where the data is stored, you have an even more challenging task: where is it going, and where is it supposed to go? This again is difficult. Once, when mapping data flow between multiple complex systems at a Federal agency, I determined that data was in fact doing a complete circle: literally ending where it started, with little or no modification or update along the way. In federal terms, this aligns with numerous NIST 800-53 controls. (I won’t bore you by listing them all).
Architect Your Network
Kindervag states, “The actual design of a Zero Trust network should be based on how transactions flow across a network and how users and applications access toxic data.” This approach applies equally to on-premise network design and cloud architecture. It’s a relatively new and different approach to network architecture, and it may take time for technical professionals to learn and implement.
Create Your Automated Rule Base
After you identify your data’s home and proper flow, and you have created an appropriate network architecture, enforcement rules will bring the preliminary work to fruition. Kindervag stresses the need for access based on “need to know”1 – a phrase that should resonate with government personnel who work with Secret or Top Secret information.
Continuously Monitor the Ecosystem
In the Zero Trust model, security tools log and inspect all traffic, including traffic “inside” the local network. Remember, you don’t trust anyone in the “Zero Trust” model. The term “Continuous Monitoring” is also the final phase of the venerable NIST Risk Management Framework, although its meaning here is a bit different.