There's no zero trust if you trust the network...

Zero trust network access (ZTNA) should have transformed cybersecurity. Dozens, perhaps hundreds of vendors describe their solutions as “zero trust” – a term meaning that anyone or anything trying to gain access to a system is hostile unless proved otherwise. The unabated rise in the number and severity of security exploits shows that zero trust is not just another hype wave, but a lie, writes Galeal Zino, founder, NetFoundry.

ZTNA 1.0 lies

ZTNA is red hot. Everyone is doing it to improve their security.

That’s the first lie. 

ZTNA 1.0 services were adopted for convenience, not security. COVID-19 sent us all home. Accessing our business apps from home via corporate VPN ranged from painful to broken. IT was flooded with complaints and realized that the user experience via cloud ZTNA services was better than corporate VPN, and that the security story was good enough. 

The pandemic drove an uptake in ZTNA 1.0 services. You know what else has spiked? Breaches. Both ZTNA 1.0 adoption and breaches have hockey stick growth – up and to the right – massive surges in both. If ZTNA helps with security, then why are breaches exponentially increasing as ZTNA adoption increases? 

This is the second lie of ZTNA 1.0. It helps with the visible part of the iceberg, but attackers simply dive underwater to attack the greater exposed surface area.

Deny all inbound

Although ZTNA doesn’t trust the WAN, it does trust the Internet! Why? Because sessions that originate from outside our WAN, including many APIs, remote management, third party access, IoT, B2B and service provider connections, are not fully authorized until after they are already inside the enterprise. We are forced to ‘trust’ the Internet – open inbound ports on our firewalls – and then our app server, web server or API server does the final authorization inside our DMZ. This is the rest of the iceberg. 

Ask your firewall administrators, DevOps or NetOps teams how painful it is for them to manage their inbound firewall rules or access control lists (ACLs) – the rules which determine which network sessions to trust. There are thousands of these rules, multiplied by how many sites you have. If zero trust 1.0 wasn’t a lie, then there would be one rule: deny all inbound. 

What’s wrong with trusting the networks?

Let’s accept that sessions need to originate from external networks and that the pain felt by security and operations teams is worth it. Our alphabet soup of “day two” security solutions – WAF, IPS, IDS, API security et al – should identify the threat and terminate the session. Yes, they should. And they do. Most of the time. 

The problem is that the alphabet soup is trying to filter the entire Internet. Even if it filters out 99.9% of the threats, zero days, authorization bugs, configuration issues and business logic gaps enable clever attacks to get through.

There is good news. When ZTNA moves from lies to reality in 2024, then these day two security solutions will work better and be far simpler. Instead of filtering the entire Internet, they will filter sessions which have already been identified, authenticated and authorized. In that model, techniques like AI/ML based anomaly detection become really useful. It still won’t be perfect, but even avoiding a single breach, one period of downtime for your customers or one exposure of customer information is important.

One open port is too many

The source of truth is the firewall. If the inbound rule is deny-all inbound, then the firewall is not trusting the networks. Anything else – even one single open port to one single IP address – is a hole. Attackers are pretty good at exploiting holes, as we have seen. Firewalls are also good – if we can stop poking holes in them.

In order to get to deny-all inbound nirvana, we need to identify, authenticate and authorize all sessions, not just the ZTNA 1.0 sessions of our internal users accessing their apps. Every externally originated session must also be secured.

In other words, we need to stop external sessions before they reach the network, our firewalls and our DMZ. That means the policy enforcement point (PEP) has to move to the origination of the session – and only strongly authorized sessions can proceed.

ZTNA currently assumes that the network or the DMZ will do the identification, authentication and authorization..That’s like only asking people for ID when they get to the airport gate or checking tickets for a football game when people are already in the stadium. But it’s what we do every day with our open inbound firewall ports. 

The enforcement point in ZTNA 2.0 will no longer be the network but software. 

This is the only mechanism that can extend to apps, APIs and devices we don’t control. The software needs to be able to go anywhere, including:

1. Inside the actual application or API. Let’s say a third-party needs access to one of your apps or APIs. Zero trust 2.0 software simply adds the zero trust parts into your app – a few more lines of code. 
2. Inside software already being used to support the solution. This is most commonly a browser, proxy or reverse proxy. Sometimes it is agents or collectors being used by MSPs, MSSPs, SIEM or APN providers. Zero trust 2.0 software adds a few lines of code to that software, and sometimes provides the entire function (e.g. a zero trust enabled, globally distributed, reverse proxy service).
3. As an application-specific smart agent. VPNs often don’t work for this use case because they are too broad. Absent the horror of split tunnel VPNs, the VPN will backhaul all the traffic to one location. An app-specific smart agent is the opposite. It only does the zero trust 2.0 goodness for the specific apps which the policy dictates. In a third-party contractor example, access to the apps she needs at Acme company is provided by the app-specific smart agent. But when she goes to Netflix, or serves some other business, then those apps follow her company’s policies.

In all these options, the software results in the PEP moving to the origination of the data session – it won’t get to your network unless it is strongly identified, authenticated and authorized.

To move beyond the tip of the iceberg model of zero trust, we need a solution that  

• Changes the model from implied trust to explicit authorization. For every use case. 
• Changes the model from infrastructure-dependent and bespoke to open source based and software-defined. Consistent across any network, edge or cloud.
• Changes the model to meet and exceed the strongest security guidelines including: CISA (Zero Trust 2.0 - May 2023); NIST (SP 800-207); and the U.S. Government (Cybersecurity Strategy – March 2023). For all use cases.

Four fundamentals enable this model:

1. Identity based networking. Strong identities apply to every workload,and enable centralized management and end-to-end visibility. Identities are independent of IPs, network providers, infrastructure and public DNS. 
2. Strong authentication and authorization of every session before it is given any network access, based on the strong identities. The auth(n) and auth(r) are independent of different administrative domains, enabling operators to easily enforce explicit, contextual trust decisions.
3. Microsegmentation, mTLS and encryption for every session. Microsegmentation helps quarantine breaches and prevent data exfiltration. Encryption helps secure critical data, even in the face of an attack. Mutual TLS (mTLS) verifies both the ‘client’ and ‘server’ sides of each connection.
4. Not reachable. No open inbound ports – no access from underlay networks.

Follow The Stack on LinkedIn