The Problem with Zero Trust Network Access is Trusting the Service Provider

Last Updated on June 7, 2024

Zero trust network access (ZTNA) is the foundation of a zero-trust security architecture and an increasingly popular VPN alternative to support remote/hybrid work models. ZTNA gives remote users secure access to sensitive corporate applications and data on a least-privilege, need-to-know basis driven by fine-grained policies and access controls.

But can you still call it “zero trust” when the client organization has to trust the service provider, which may have access to its data?

This article overviews the trust issues inherent in most SaaS business models—including many ZTNA solutions—and how a different approach could improve security and privacy.

What is ZTNA?

A rapidly growing remote workforce has exposed the security and scalability shortfalls of traditional VPN/firewall configurations and led to the rise of ZTNA solutions. ZTNA eliminates trust assumptions in several ways:

• ZTNA separates network access from application access. Instead of authenticating with the network and automatically being granted access to many applications, application access is highly specific based on authentication and authorization, aka micro segmentation.
• ZTNA reduces the attack surface that VPNs create. Hackers can potentially penetrate a VPN by stealing or brute-forcing the credentials, then move laterally across the network. ZTNA authenticates at the application level only when the user, identity, device, and location all align, blocking lateral movement.
• ZTNA enables only outbound connections and never exposes IP addresses on the public internet, making the network and applications invisible to attackers.

How do most ZTNA solutions work?

Most third-party ZTNA solutions are SaaS offerings. The service provider manages the control plane and associated infrastructure on behalf of customers. Through client-based software or equivalent technology, customers funnel their network traffic to the service provider’s data centers, trusting them with privacy and security.

The result is akin to a traditional network architecture, where data traverses a gateway that now resides in the cloud instead of the network edge. The advantage for customers is convenience and ease of management. The downside is giving control of their data to the SaaS provider.

A common rejoinder is that SaaS providers have better security than their customers. But they are also a high-profile target for sophisticated cybercriminals, who potentially can access multiple organizations’ data by infiltrating a single environment.

As a result, this “ZTNA as a service” approach may not meet the security and privacy needs of government and regulated entities. It can also be a pitfall for other businesses.

Is true ZTNA possible if you leverage SaaS?

The hallmark of zero trust is to eliminate assumptions when it comes to network access. But SaaS relationships give the service provider significant control over customer deployments, with attendant operational/functional dependencies. If the service provider is breached, for example, your data may be breached. If the service provider’s infrastructure goes down, you will probably lose access to your applications and data for an indeterminant time period.

According to William Eshagh, co-founder and CEO at Bowtie, most SaaS relationships represent a “Faustian bargain” that trade security for convenience. Against the benefits of SaaS are potentially significant costs that are conventionally overlooked:

• SaaS customers give up autonomy—control over their information assets. When customer data and processes reside on vendor systems, freedom to move those assets may be limited, creating vendor lock-in.
• Despite SLAs, availability of information assets may also be at risk, with data integrity and restoration time being open questions outside the customer’s influence. Atlassian’s two-week outage in 2022 is a memorable example.
• Loss of data privacy is among the most concerning issues with SaaS. When customer data resides on vendor systems and is accessible to vendors, unforeseen manipulation of that data for the vendor’s benefit can and does result.
• SaaS relationships tend to place responsibility for security on the vendor, hampering customers’ ability to address risk or impact incident response. Even Microsoft’s cloud has been hacked, compromising email accounts of major customers like the US Department of State.

Are these tradeoffs inevitable with SaaS? One alternative is “local-first software,” a model that allows customers to retain control of their data and improves security and privacy, while still enabling the convenience and rapid time to value of SaaS.

Bowtie is one ZTNA provider that embraces the local-first software design philosophy, giving customers complete control over their deployments with no operational dependencies regarding their network operations. No customer data is routed through Bowtie servers. Access control, availability, and encryption remain under customer control.

While it is not the easiest technological path, a local-first approach is possible for SaaS providers. The question is, will customers demand it?

What’s next?

For more guidance on this topic, listen to Episode 138 of The Virtual CISO Podcast with guest William Eshagh, co-founder and CEO at Bowtie.