Edit: This discussion post will be live until end of May, by which time I assume people are okay with a June discussion using the existing rules. As noted, the rules are subject to change based on what makes sense and is in the community's interest.

This post is to discuss the proposed process in which we evaluate ZTA infrastructure or configurations. The goal is to learn from each other.

We're going to discuss the process to make sure it's neutral and conducive to a learning experience before we begin trialing out a discussion. As everything is iterative, we'll probably change the way it's conducted over time. None of the following is currently set in stone and I will take all comments into consideration. This so that everything is written down and documented to prevent confusion in the future.

---

The Process:

The community will probably lean heavily on neutral and authoritative sources of ZTA to evaluate. See our pinned list of zero trust resources.

One thing I particularly like is CISA's ZT Maturity Model's Figure 4 which looks a bit like a rubric:

https://i.imgur.com/bgxJMka.png

If you do not want to have your config/architecture judged by any of these, please state it (and your reasoning why).

Submission Philosophy

You are submitting to understand if the config is in the realm of zero trust, and if yes, how close to zero trust optimal it is. The goal isn't to submit and everyone agrees it's zero trust (though that's possible), but to submit and everyone tell you where it's lacking. That's how it gets better. I think we all agree that far too many cybersec and netsec configurations don't work in the current threat landscape — the rising number of data breaches and hacks only increases every year.

If you are trying to evaluate something that may or may not be for a workplace, please do not get in trouble revealing anything. That being said, zero trust architecture is the exact opposite of security through obscurity — when implemented correctly, it should not matter if hackers know exactly what tools you are using and how they interact (and a fundamental thought process is to assume the hackers already know, so design accordingly). It's worth asking internally that if the infrastructure depends on no external entities understanding how it works, then how safe is it really?

Submission Rules

For a proposed config/architecture to be judged, it should be submitted in a format that makes sense and with stated goals in mind. Part of where communication fails is because people make assumptions, so state as many things as possible.

Here's a starter list of questions I've got, and let's put together our heads to figure out how submitters can give us as much information as possible:

• What are you trying to accomplish with this config?
• How are you managing identity?
• for users and for devices?
• How are you managing devices?
• How will the network be set up?
• How will the applications and workloads be:
• discovered?
• access controlled?
• How will the data be:
• encrypted in use, transit, and at rest?
• tracked and categorized?
• Walk us through how a user gets access to the service and then explain how everything plays together. Ideally, give us a reference diagram. Something like this one https://i.imgur.com/WMSgWpf.png from NIST's General ZTA Reference Architecture will help, but of course replace everything with what's in your proposed config.

List all tools/solutions your config will be using to tackle each of these questions, and ideally explain to us how everything flows.

Rules for Commenters:

Unless the submitter asked to be judged by a completely different set of standards, commenters must stick with asking how something aligns with a pillar of zero trust (Identity, Device, Network, Application & Workload, Data) or CISA’s defined results in the Optimal section.

Commenters may not suggest tools or promote any named solutions, but can suggest looking at a class of tools. This is to prevent vendor spam and overly obvious self-promotion.

Examples:

• Not allowed → I think your authentication step can be better, might I suggest [IdP name here]?
• Allowed → I think your authentication step can be better, might I suggest integrating IdPs?

My thinking is that specifying a class of tools is broad enough to not be overly promoting while being specific enough to be actionable to the users.

---

Finally, everyone is encouraged to do their own research with regards to proposed solutions and feedback because what works for someone else may not work for you.

Unique situations, needs, and environments may require approaches that none of us have ever encountered or considered, but the guiding principles behind what makes something zero trust (aka, enforce authn and authz at every boundary and ideally every request) will probably be your source of truth. It's the "how" you achieve that where we as a community may help each other.