As an advocate and veteran practitioner of zero trust, I was intrigued by a recent article decrying its "vulnerability.” In fact, seeing zero trust and vulnerability in the same headline had me wondering if I overlooked some glaring flaw in past deployments. Perhaps a new exploitation technique that reliably breaches the security framework had been discovered. Were my previous positive experiences with zero trust a statistical anomaly? I had to find out.
Understanding zero trust identity
Reading the article, the first thing that jumped out at me was this statement:
“Identity and access management (IAM) undoubtedly play a fundamental role in Zero Trust. Unfortunately, constant verification of users' identities proves ineffective in cases of stolen identity.”
This claim relies on a couple of big assumptions. First, it alludes to identity being a simple pass/fail check that returns an immutable result. Presumably, the article implies, once you pass the identity check, that’s it. You now have the keys to the kingdom. Apparently every other iteration of the “constant verification” process will determine your identity has been deemed good, forever. Does this describe the state of modern enterprises? It sounds like a bygone era, back when dinosaurs on Windows Vista taped passwords to their monitors with their tiny T-Rex hands.
Consider the widespread adoption of multifactor authentication (MFA). Over 55% of businesses use some form of MFA, which makes stealing identities considerably more difficult. Stealing a username and password is one thing, but swiping a SIM card and intercepting an SMS verification message is no small task. Sure, attackers could try stealing an authenticated session cookie instead, but even then, success would rely upon persistent verification with non-expiring sessions.
Let me get back on track, since MFA is only tangential to zero trust. In fact, MFA is just layering one pass/fail authentication system on top of another. A robust zero trust system should use a far more complex identity verification process. It should look at context as well as credentials. Asking “who is trying to connect” should be the first step of identity verification, not the entire process.
What if, after verifying credentials, IAM asks “does this requestor’s role, location, request timing, and other environmental factors seem suspicious?” Maybe things look okay, maybe not, so let’s dig a little deeper. “What is this requestor trying to access, and is there anything suspicious about that?” The ultimate goal is to create a secure, trusted connection so device security posture, access policies, and behavior patterns should also be analyzed.
Once this context is gathered, do we evaluate the connection request with a pass/fail and throw the gates wide open? No. It’s possible that most of the identity checks went well, but a few suspicious results make granting full access a no-go. In this case, we could ask for further verification, grant restricted access, or launch other processes to evaluate identity further. There is no “steal the identity and have free reign” risk because we’re examining device, location, behavior, role, and other contextual factors.
Basically, a true zero trust environment can’t use a one-step, all-or-nothing identity check. Any model that offers 100% access after clearing a single security hurdle is not in the business of trust, it’s practicing weak verification. That’s full trust with minimal effort, not a zero trust framework.
Understanding zero trust access
My second observation involves a statement appearing a little later in the article. The author states:
“To implement a Zero Trust security strategy effectively, organizations are increasingly turning to network analysis tools, as recently recommended by the analyst firm Forrester ("The Network Analysis and Visibility Landscape, Q1 2023"). According to the Forrester report, security and risk professionals should employ Network Detection and Response (NDR) tools to monitor their networks, search for threats, detect applications and assets, and capture malicious data packets.”
Now I see where this story is headed. The article is assuming a traditional, flat network that hosts users and applications on the same domain. Now, I like NDRs and EDRs and all the other DRs (XDR, CDR) that help strengthen cybersecurity in environments across the globe. Yet, I think they all attempt to improve security processes that are doomed to failure. By this, I mean they try to address endemic security problems by using AI and automation. Unfortunately, new technology doesn’t fix the fundamentally broken architecture of traditional networking.
For example, the best AI-driven, real-time reporting NDR on Earth only monitors your network, not your endpoints, the internet, or the cloud. You can’t possibly create a zero trust environment without securing all of the critical aspects of your enterprise. Likewise, EDR may be deployed on your endpoints, but it’s not securing the cloud, internet, or unmanaged devices. What next? CDR for your cloud? Is running around adding new [insert letter]-DRs every time you find a security problem the path to zero trust?
There is a better, easier, and more efficient way to do this.
The first step is accepting that trying to secure a fundamentally vulnerable network architecture is a fool’s errand. Start thinking of networks as the means for connecting one requester to a single resource. If you can securely create a one-to-one connection between a requester and a resource, fifty years of vulnerable networking architecture become irrelevant.
This same theory applies to applications and resources. No vendor can sell you a solution that evaluates your environment's software, identifies the vulnerabilities, and fixes them. We are all likely using software right now that is fatally flawed, and don’t know it. This is what happened with Log4j, right? Spending your wealth, time, and effort trying to secure decades of buggy software on a fundamentally flawed network is a recipe for failure.
Instead of tackling the macro issue of securing everything, focus on the micro problem of securely connecting one user to one resource. Let’s start that process with a secure connector that receives a request to establish a connection. The connector contacts a policy enforcement node, performing the previously described zero trust identity evaluation. If everything checks out, the connector, acting as a proxy, establishes a secure connection to the resource.
Where is the resource? We don’t know. That is a large part of what makes this system secure. The resource could be in a company data center, the cloud, or on the internet. The connector relays communications to the resource, but the requestor can’t see how.
This means if a bad actor miraculously fools multiple levels of zero trust IAM, they still can’t see the environment. They can talk to a connector that is communicating with one resource, but that’s it. There is no visible network to exploit for lateral movement, there are no servers, web hosts, or firewalls to query. There are no other apps to scan for vulnerabilities. All the business architecture is hidden behind the secure connector, leaving adversaries nothing to work with.
Embracing zero trust principles
Zero trust principles extend beyond “constant verification of users' identities.” While establishing identity is one pillar of zero trust, the principle of least privilege access is equally important. The identity verification standards used by zero trust platforms are considerably more robust than the pass/fail systems of the past and offer significant advancements.
Likewise, the principle of least privilege access is encapsulated by brokering secure, 1-to-1 connections between users and resources. One verified requester has access to one approved thing per connection. Access cannot shrink any further than that.
Ultimately, all CISOs are on the same team, doing their best to stop adversaries from harming people. Anything we do to slow down attackers is helpful and a net positive for the global security posture. That said, I remain a staunch advocate for doing zero trust the right way because nothing really compares to the returns it delivers. It offers benefits beyond vastly improving security, but those topics are probably best saved for another article.
What to read next