5 Steps to Zero Trust

Interested in Zero Trust—which after ten years of proving itself in diverse organizations has stepped into the spotlight as one of the best ideas in the history of cybersecurity? How do you implement this game-changing approach to mitigating cyber risk?

To get the inclusive, nuanced dive into Zero Trust that only he could provide, we invited John Kindervag, SVP of Cybersecurity Strategy at ON2IT Cybersecurity and the creator of Zero Trust, to join a recent episode of The Virtual CISO Podcast. Hosting the show as usual is John Verry, Pivot Point Security’s CISO and Managing Partner.

John has outlined five steps that are common to all organizations implementing Zero Trust. The approach is fundamentally data-centric. That is, it focuses on defining what data, applications, assets and/or services (DAAS) you most need to protect.

Step 1: Define your protect surface.

“These are real-world things [we’re protecting],” John emphasizes. “I used to say just define your data. But then I realized there were certain times when I couldn’t know that, but I knew the application that was using the data. So, let’s secure the application.

“Things like SCADA systems, IoT devices like MRI machines, wireless morphine infusion pumps… They exchange data, but people think of them as assets. Then there are services like DNS, DHCP, Active Directory… Those are the things we need to protect, and that’s how I tend to talk about it.

“You take a single DAAS element, put it into a single protect surface, and build your Zero Trust network or environment by going through the remaining steps on that single protect surface,” John clarifies.

Step 2: Map the transaction flows.

“I can’t design a network unless I know how it works,” says John. “So, every Zero Trust environment has to be tailor-made for each protect surface. But I can’t know how the protect surface interacts with all these other systems until I map the transaction flows. How does everything work together to define that?”

In other words, understand the system before you start figuring out how you’re going to control the system. Mapping transaction flows is analogous to creating data flow diagrams, if you’re familiar with those. The end result is to validate that what you defined within your protect surface is actually what’s happening.

Step 3: Define your architecture.

The third of the five Zero Trust steps is to architect the environment, whether it’s cloud-based, on-premises, or hybrid. Your transaction flow maps will show you where the controls need to be.

“You just look at [the data flow], and you go, ‘I need a control here because of the way this is going and how I want to write policy because I want to make sure this thing can’t talk to this thing,” John comments. “It shows you where to put the architectural elements. … Whether it’s a next-generation firewall functioning as a segmentation gateway, a container security control, and endpoint control, an SD-WAN control… Whatever the control is and wherever it’s located, you need to understand how it all works as a system before you decide where you’re going to put it.”

John shares an anecdote to illustrate the importance of taking the Zero Trust steps in order: “A lot of times I’m on these calls. They’ll bring a bunch of people, and they’re all trying to position… ‘My product should go here; my product should go there.’ I’ll let that go on for a while, and then I’ll go, ‘Hey, guys, so what are we protecting in this system.’ And they’ll go, ‘Oh, we haven’t thought about that yet.’ That’s probably not going to work. You could probably put all these controls in and it’s not going to get to the outcome that you want because you don’t even know what you’re protecting first.”

Step 4: Create the Zero Trust policy.

In this fourth step, you instantiate your Zero Trust architecture as a policy. “Hopefully up to layer 7,” John warns. “Port and protocol just doesn’t work anymore. … Within the constraints of TCP/IP, you have to go up to layer 7.”

Note that this step is about creating a technical, “where the rubber meets the road” policy that relates to access controls, firewall rules, etc. As opposed to higher-level policies around, for example, management promulgation.

For a policy construct model, John favors the Kipling method: asking who, what, when, where, why, and how. For example, a “who statement” might be “Who should have access to a resource?” These questions relate to authentication and identity. A “what statement” might be, “By what application should they be allowed to access a resource?” “When” rules would relate to contextual identification, and “where” rules to locating a resource.

“All you can do is allow or deny, but you can have massive amounts of data and very complex criteria that you use to determine whether something should be allowed or denied,” John summarizes.

Step 5: Monitor and maintain the Zero Trust environment.

This step is all about verifying that your Zero Trust policy is working the way you intended and correcting any deviations. Elements that come into play here include log management, machine learning, and other ways to make sense of the data your environment is generating.

“We have our own engine; we call it Event Flow,” says John. “It looks at all of the events, all of the data that’s coming into the environments that we’re managing. We take an automated action 99% of the time, and that’s what you’re trying to get to.”

“The idea is that a system under load gets stronger and stronger because it responds to that load,” adds John. “So, Zero Trust is an anti-fragile system.”

“I was looking at some data earlier this week for one of our clients that’s been a client for ten years,” John continues. “We looked at the number of events that we processed over the course of ten years, and then how many interventions we had to do. The more data we had, the more events we looked at, the more we were able to train the system so that we had fewer manual interactions.”

“In our environment, on average in a production system, about one out of every 100,000 events has to be investigated by a human being,” John highlights.

This continuous improvement stems not only from gathering more data to analyze, but also from organizational experience and awareness.

“It’s an absolute combination because the more you learn about it, you might say, ‘Oh, I need to refine my protect surface in this way,’” John offers. “Or, ‘I need to change my policy statement a little bit.’ That’s a continuous feedback loop. It becomes dynamic, and it updates itself over time.”

What’s Next?

If you’re looking into Zero Trust and want a comprehensive overview that covers both technical concepts and business touch points, look no further than this podcast episode with Zero Trust “founding father” John Kindervag.

To hear this episode all the way through, subscribe to The Virtual CISO Podcast on Apple Podcasts, Spotify, or our website.