In this Part 2 of a series examining Zero Trust in more detail, the creator of Zero Trust, John Kindervag, provides an in-depth view of the second and third steps in implementing Zero Trust architecture — mapping transaction flows and defining the architecture. 

Steps two and three of the Zero Trust Model are highly interrelated. Though these are separate functions, in many cases, the steps are executed in tandem. There needs to be an understanding of how the system functions before you can place controls on your unmanageable apps. Then, Zero Trust architecture reveals itself once you recognize how the system works together.

Step two: map your transaction flows 

Typically, we only see the beginning and end of the system transactionally. There are many things in the middle that can impact your Zero Trust deployment, which is why we need to map all of the transaction flows. Cybersecurity is a very complex system. Protect Surfaces are the pinnacle of that system. Protect Surfaces are where much of the transaction processing is done, and most of the important data is stored. In short, it’s where everything ends up.

Getting that transaction to happen is complex and includes many subsystems. We need to map the transaction flows to and from the Protect Surface clearly. This process reveals how components interact with other resources on the network.

Understand how systems work together

It isn’t enough to merely know what needs protecting. A system is a collection of parts that work together as a whole. Understanding how various components interact is crucial to determining where controls are needed and where they should go.

Halford E. Luccock is credited with saying, “No one can whistle a symphony. It takes a whole orchestra to play it.” The challenge is documenting the various musicians and instruments, the DAAS elements, and identifying anything that’s out of tune. The conductor can’t just sit back and enjoy the music without analyzing how all the pieces are working together. To architect a Zero Trust environment properly, you must understand how the system interacts with itself.   

Step 2 is the result of real-world experience. One of the early Zero Trust networks was designed for a restaurant chain Point of Sale (POS) system as part of a PCI compliance initiative. During the implementation, one of the company's employees removed a server “because it was old.” No one had asked if the server was necessary for the POS to function. The server was integral to its operation, and many POS systems at various restaurants went down. Of course, this outage was blamed on “Zero Trust.” But it happened because no one in the organization understood how the system worked together as a system. This is why Step 2, mapping the transaction flows, is hyper-critical to a successful Zero Trust deployment.

Additionally, once you can visualize the transaction flows, the mapping will show you where the controls need to be placed. It’s pretty extraordinary.

Step three: architect a Zero Trust environment

The magic behind the five-step model is that steps one and two inform you on how to design your architecture. Many organizations mistakenly start by creating the architecture first. They then try to figure out how to fit the Protect Surfaces into the design. I have never seen that approach work.

I once had an executive say to me, “IT gave me a nice architecture that has beautiful round holes, but they forgot to ask any questions and didn’t find out that I have square pegs. Now, I spend all my time whittling the pegs to fit into what they gave me.” This is the problem.

What is the Zero Trust architecture? 

Zero Trust architecture is designed from the inside out. It’s fully dependent on your Protect Surfaces. It is the compilation of tools and technologies that’ll be used to build your Zero Trust environment. Those elements could be, at a minimum, appropriately placed segmentation gateways. Endpoint, SaaS, or API controls may also be necessary. Ideally, controls are enforced with a combination of hardware and software capabilities. Because each protect surface is different, the architecture varies from organization to organization and within an organization. 

Once your transaction flows are mapped out, you’ll know what technology to procure. Or, you’ll repurpose and reposition some of your existing tools. Then, you have perfectly sized square holes for your square pegs, and no additional whittling needs to take place.

What is a Zero Trust environment? 

A Zero Trust environment exists when Zero Trust controls and policies are deployed, which we’ll discuss in Part 3. This environment contains all of your Protect Surfaces and can include traditional on-premises networks such as data centers, public clouds, private clouds, on endpoints, or across a software-defined network.

Zero Trust architecture is tailor-made

There isn't a true one-size-fits-all in the world of cybersecurity. You shouldn’t buy a security solution off the rack because, much like a suit, it won’t fit right. When you visit a tailor, the first thing they do is take your measurements and make a pattern, just like the first step in Zero Trust. Next, they pin it up and see if it fits. Then, they refine it based on your needs and size, which is the clothing equivalent of defining your architecture. 

The architectural design can’t be predetermined because it all depends on the work you did in step two. But, it’s best practice to place the controls as close to the Protect Surface as possible.

With a clear understanding of transaction flows and how the system works, you’re creating something purpose-built that protects exactly what you need to protect. It will fit you like a glove (or a well-tailored suit in this example).

Only do things in the benefit of you

When you understand how your systems work, the system tells you where it needs to be protected. We’re looking at unmanageable applications, so there aren’t that many controls needed. 

I’ve seen too many instances where an organization defines themselves according to the vendor they use. Remove “I’m a [insert vendor here] shop” from your vocabulary. You should be saying, “I’m a [insert organization name here] shop” because you’re doing things in your best interest. Only place the controls you’ve identified as necessary, not the ones that Vendor X says you need. 

Ultimately, you should consume technology based upon the needs of the Protect Surface and how it works together in your overall system. Given the diversity of apps that exist in most enterprises, it’s wise to consider not only the apps that support identity and security standards but also those that don’t (nonfederated). These apps often need special consideration when building your Zero Trust architecture, as they lack support for the standards required to integrate with your identity provider. Cerby, whose board I joined in 2022, has a solution for this problem.

​​I joined Cerby because they are the only platform that brings these applications into the Zero Trust world by allowing us to create a Protect Surface around them. By doing so, Cerby is making the unmanageable easily manageable and secure.

Stay tuned for the final parts of John Kindervag's Zero Trust series for Cerby, where he talks about steps four and five in creating a Zero Trust environment‌ — ‌creating policy and monitoring and maintaining the environment.