Generally speaking, Zero Trust is a misnomer. Rather than reducing trust to zero, it simply involves adopting a policy of controlling trust at every trust boundary, rather than letting uncontrolled trust be the primary mode of operation. Even when we get rid of the idea of “reducing” trust, but rather “controlling” it, the word “zero” still needs to avoid being taken literally. In business (and virtually all operational endeavors), we don’t deal with absolutes. We choose the best decision available based on as much quantitative data we can get, but we never have all the information, so often we must make rapid “70% decisions” based on assumptions, rather than delaying until we have 100% of any desired condition, information, resource need, etc.
All said and done, the idea behind ZT is fantastic, the name is terrible, and this contradiction leads to overwhelming misunderstanding about the intended outcome.
Largely, the frustration security professionals have developed with ZT stems from the all-too-common scenario where vendors sell (emphasis on sell, not deliver) “ZT as a Product / Service”, which we all know is a massive undertaking and not possible without also modifying a wide range of tooling across the network to support interruption for this product - usually a technology based on implementing global controls at some OSI layer (I’ve seen 3 and 7) tied into an IAM solution - to enforce the new controls. The top level business leaders who initiate such product purchases fail to understand the extent of the resources required to achieve implementation at scale. The security professionals involved in the under-funded and misguided undertaking of implementing the product (without really achieving ZT) suffer as a result.
Do you disagree with my take? I’m open to discussion.
Reposted from my LinkedIn. Happy to connect & discuss cybersecurity any time.
—-
Comment section is a mess with 90% upvotes and the vocal minority arguing the semantics of “trust”. Deleting my comments. Trying to reconcile with the 10% of people who disagree with you, however tempting it might be, just doesn’t work. We can’t all agree, and that’s ok.
I guess the trust part of name originates from the idea of having trusted and untrusted zones in a network. The firewall blocks untrusted traffic, so any traffic in the internal network is considered trusted.
From that, zero trust is removing the behaviour of trust by default for internal network traffic.
All of the problems you’ve stated (managers making decisions without all the information, underfunded departments, over-zealous vendors) are not problems with the name “Zero Trust” they are problems within the company itself and the nature of vendor-purchaser dynamics.
Blaming a name is silly. Frameworks, services, applications, products, etc. all have mostly non-descriptive names or names that don’t fully encapsulate what they do/are for. You’ll never cover 100% of what something is with a name, people have to do some legwork themselves. Just like literally everything else.
Either way, the name makes sense to me. I’m not trusting X until Y happens. Y can be one of several different things, like coming to a “70% decision”, based on whatever criteria I need to implement. In other words, I don’t trust you (zero trust) until you do Y, which is something that will let me, with some confidence level, trust you to some predetermined extent.
uncontrolled trust be the primary mode of operation
“Uncontrolled trust” is such a weird way of putting it. Trust is an active decision, there is no “uncontrolled”, otherwise it isn’t “trust” anymore.
I don’t think anyone is reading the words zero trust and then spiraling into all the issues you listed. It’s just a classic misunderstanding of the complexities at hand which is exasperated by all the rubbish vendors and other people who also don’t understand say.
I’ve not seen a technology, strategy or framework that isn’t plagued by the issues you listed zero trust has. It’s just the unfortunate reality of the “ecosystems” we have built around technology and humans kinda sucking.
In conclusion I think the words zero trust are about as good as your going to get.
I think I disagree. The idea behind zero trust is a mathematical one — at a decision point, there’s nothing in my trust boundary besides what I’ve verified myself. This is what ZT is conceptually and the name is apt.
The problem which you identify is that implementation of this mathematical model is hard, and ZT has turned into a buzzword such that many “zero trust solutions” have as much to do with ZT as JavaScript has to do with Java.
The name originates from what trust is default, not “how much trust to reduce” (what does that even mean???)
Classic security has a hard network boundary, and those devices inside it are trusted by default.
Then there is the hybrid called “trust but verify”, where you trust the device but verify the user and activity, this was the standard for many years.
“Zero trust” means you DO NOT trust a device or user or application based on the network boundary, or any other condition - you ALWAYS verify, and you CONTINUOUSLY verify.
An ideal zero trust environment does not even have a network boundary at all, every single device and service might as well exist on the public internet for all intents and purposes.
Lastly, Zero Trust can not be solved by any one product, it is a strategy and approach to security - however there ARE product classes like SASE and IDPs thay squarely fit into the Zero Trust space because they are specifically designed to help you implement that kind of approach. So, I think vendors get too much flack over this… there is nothing at all wrong with a cybersecurity vendor claiming their product helps with zero trust. Just like there is nothing wrong with an auto parts supplier claiming they enable making cars, even if they don’t build the whole thing. They are still essential.
It is called Zero Trust, because that is your ultimate starting point and then verify, identify and authenticate connection.
Zero Trust describes a problem where you automatically trust a connection, when it has a certain condition. For example: “if it is internal company network it is absolutely ok to use fileshare without authentication, because it is internal” NO it is not, because you cant be 100% sure if the network isn’t already compromised. So you set it back all to zero trust - and the solutions are as described above: verify, identify, authenticate.
I always view Zerotrust like a diet. It’s not just a single meal (or set and forget action) but instead a company is signing up for an ongoing life style.
There are a lot of different ZT approaches (like diets) where each vendor claims their approach to ZT is the right one. Most vendors just took an older solution that was not meant to enable ZT principals and tried to put a ZT label on it. A lot of vendors claim their single solution will provide a full ZT outcome.
Honestly, ZT is an eco system solution where trust is not granted directly by having access to the system or app. You want to treat all access levels in the same basis: trust is not default but instead assessed at the time of access (each time) based upon variables of risk: device, user role/rights and app type.
I would disagree. Zero trust means exactly what it says, you don’t trust anything automatically. NIST 800-207 - Every device, connection or login is verified and re-verified. A zero trust architecture assumes attackers are on the inside and seeks to stop or limit any lateral movement. People love to cite the old school castle, moat and draw bridge approach to IT security, what they forget to mention is that there were always guards at every hallway entrance and guards at every door of important people. There were guards in the tower and guards walking around the court yard. Zero trust would check and verify not only at the entrance, but also at every hallway and door and wouldn’t just let people roam around willy nilly. Now make that whole castle invisible to the world. That’s zero trust in a nutshell.
Ok, you are just frankly wrong about your premise, therefore your entire post is incorrect.
From the mouth of the guy who coined the idea: the concept of zero trust, which is framed around the principle that no network user, packet, interface, or device—whether internal or external to the network—should be trusted. Some people mistakenly think zero trust is about making a system trusted, but it really involves eliminating the concept of trust from cybersecurity strategy. By doing this, every user, packet, network interface, and device is granted the same default trust level: zero.
It sounds like you’re trying hard to sell ZT to executives, because the verbiage is boiler-plate “I’m presenting to upper-management”.
High level topic with awkward dives into the technical, and still not hitting the mark. Adding numbers and man-splaining “the way things ought to be” makes me dislike the writeup even more.
You have a good point, people’s perception of ZT isn’t great. The comments pointing out “zero trust = don’t trust anything until validated” better explain the concept. No need to make a LinkedIn post and gather metrics from Reddit.
For almost 10 years I’ve been preaching “secure authentication boundary” and folks are finally getting to it the past few years. Exciting stuff. As soon as I saw everything shifting to XaaS I was like “well, boundaries are fluid now” and seeing CASB and the other offerings to help with this dynamic trust boundary is lovely.