Five Steps of the Zero Trust Program
CMF: Thank you for establishing background and context Mr. Mitcham. Mr. Kindervag, what is the crux of the Zero Trust program, the crux of the construct that makes it go?
JK: Well, the crux is to figure out that you can’t protect anything until you understand what you can protect. That’s called a protect surface. I’m on these calls all the time, where everybody is positioning their product. I’ll finally at some point say, ‘What are we trying to protect?’ and then they go, ‘Oh, I haven’t thought about that.’ If I know what to protect, then I can know how to build it. And so, I built a simple five step methodology. I use it every day.
‘The crux is to figure out that you can’t protect anything until you understand what you can protect.’ – John Kindervag
The first step is to find the protect surface, what are you going to protect— that’s called a data element. ‘DAAS’ is easy to remember, the acronym that stands for data, applications, assets or services. Next, you’ll see this represented in the DISA guidance. You take a single data element, you put it into a single protect surface, and then you architect everything around it. We’ve defined the protect surface as a high value asset, say, the OPM data that was stolen.
Okay, now the second step is to understand the transaction flows. How does the system work together? We can’t protect the system until we understand how it works.
The third thing we do is we architect the controls for the protect surface. Too often we start with the architecture before we know what needs protection. Every zero-trust environment needs to be tailor made for the protect surface, so I can’t tell you what controls you need, until I know what I’m protecting.
The fourth step is writing policy. That’s called the Kipling method. And I can use that ‘who, what, when, where, why, and how’ methodology to define a protect surface.
Who should be accessing a resource, this is a layer seven instantiation of say, source IP. And this is where we do all the identity stuff, what, by what application? Should I be allowed to access the resource, because in almost all cases, resources, or app access for your applications, so I can define that all the way up at layer seven instead of just at port and protocol. The third step is who, what, when we need more time delineated rules? We don’t do that very often. But a lot of rules should be turned off if nobody’s using them, you know, consistently.
Where is that located? This again, is you know, because we have certain rules that say, you can go to the cloud, but only in this geographic area, we need to understand that.
Why is data for classification, reading the metadata from the classification? I have written about how we can reinvent that. But, if we do that, we can then bring in that metadata to help inform policy.