Universal ZTNA Provides a Frictionless Access Experience For All

In 2009, a member of the Chinese Politburo decided to learn what the internet had collected about himself. He searched for his own name on Google and, well, became exceedingly angry as he perused the results. Revenge was the only response.

Shortly thereafter, a Chinese advanced persistent threat (APT) known as Elderwood Group compromised Google’s corporate network. The group absconded with a tranche of intellectual property and attempted to access email accounts of human rights activists. State security agents investigated the bank account of one target. As a result, Google changed its stance regarding google.cn—it would stop censoring search results; if an uncensored engine were found to violate the law, it would depart the country altogether. Visitors to Google’s headquarters in Beijing placed flowers on the sign, which were declared an “illegal flower tribute” and petulantly removed.

I should note that Google wasn’t the only victim. In an effort dubbed Operation Aurora, the attackers targeted at least 20 other large companies by exploiting vulnerabilities in Internet Explorer (sigh) and a version control system called Perforce. The primary goal was to access and modify source code repositories at various technology and defense firms. Shockingly, no one had ever thought to secure these wide-open containers of valuable intellectual property! Compromised systems made outbound TLS connections to command and control (C&C) servers in Illinois, Texas, and Taiwan using stolen virtual machines from Rackspace customers. They explored connected networks to find repositories and other vulnerable systems.

From 2014 to 2018, Google rebuilt its access architecture to thwart such attacks in the future. It moved all people to an unprivileged network, even for those inside Google offices. They are, essentially, “outside” the corpnet and receive only internet connections. All access—whether from there or from some other network—flows through an identity-aware access proxy. No classical network perimeter exists. Google concluded that corporate networks are no less dangerous than the public internet and that it’s disingenuous to maintain some kind of fiction that they ever were.

Formally documented and implemented as BeyondCorp, access depends solely on user credentials and device status (BeyondCorp allows only managed devices and requires 802.1X and PKI). It harmonizes the way people connect to applications and data regardless of where they are and what networks they’re using—no more distinction between local access and remote access.

ZTNA announces its appearance

One year later in 2019, when Gartner published its first “Market Guide for Zero Trust Network Access” (I was the lead author as a Gartner analyst then), it identified two styles:

• Endpoint-initiated mirrored an older specification for software-defined perimeters and was envisioned for local access only; it returned a list of allowed applications after a person authenticated.
• ZTNA service-initiated followed some of the BeyondCorp design in which users and devices were considered remote, even if in the same building. It dropped the requirements for managed devices, 802.1X, and PKI. It added a twist: inside-out connections.

Several cloud-based startups adopted the service-initiated model because it was more amenable to remote access. A connector starts an outbound session to the broker in the provider’s cloud—thus “inside-out.” The broker shields applications from internet discovery and constrains lateral movement.

However, vendors contemplated only remote access scenarios. It appeared that the BeyondCorp lesson was forgotten.

ZTNA becomes universal

Recently, some vendors—Netskope included—have added local on-premises brokers to their ZTNA services. This has acquired the moniker “universal ZTNA” and interestingly aligns it more closely with the BeyondCorp philosophy. We can observe that Google built an access architecture that smells a lot like ZTNA—before ZTNA was a thing.

Let’s review ZTNA using Netskope terms. In your data center or IaaS cloud, a publisher configured there establishes a long-lived outbound session to the publisher gateway portion of the private access broker in our cloud. When a remote person wants to access a published resource, they connect as usual to it, which actually begins with a session to the client gateway portion of the private access broker. We stitch these sessions together and activity transpires. We now call this remote ZTNA, because people are remote from the application.

For local access, local ZTNA places a broker in the same network as the resources people wish to interact with. In most cases, people will be in the same physical location as a data center. Publishers establish sessions with the local broker, and when a person connects to a resource the traffic flows through the local broker, not the one in our cloud.

Why a local broker? Recall the hairpinning problem: forcing remote people through an on-premises data center to access internet resources is a performance drag. Similarly, reverse-hairpinning is a problem: forcing local people through a cloud-based broker to access local resources is also a performance drag. Local traffic should remain local.

Universal ZTNA combines remote ZTNA plus local ZTNA and represents the best of BeyondCorp. It:

• Harmonizes the access experience, so people don’t need to ponder what’s the correct way to access applications. Our goal is always to help people strike the right balance between staying secure and getting work done. If we expect them to use multiple remote access methods that all differ from local access, they might very well increase risk by inventing insecure workarounds. We shouldn’t expect our people to tinker with the infrastructure to do their jobs. Universal ZTNA removes all friction related to access and provides a single, consistent, and secure method that works no matter where people or applications reside.

• Eliminates privileged networks, which are in reality no safer than the internet. Traditional access methods into privileged networks continue to present risk to those networks, whether via compromised hosts (ransomware) or by compromised individuals (privilege escalation). I’d argue that universal ZTNA removes the requirement to maintain privileged networks because IP-based routing goes away. (U)ZTNA connects people to data, not devices to networks. [Note: in this blog post, I write “(U)ZTNA” to indicate that an associated observation applies to both “regular” ZTNA and universal ZTNA.] Before the person-side of the inside-out connection is stitched to the publisher-side, the person must successfully authenticate to a company’s enterprise directory. This authenticate-then-connect paradigm is the safe alternative to the connect-then-authenticate standard that has been broken ever since its inception in the 1970s, in which nothing can stop determined adversaries from hurling all kinds of malicious traffic at innocent listening sockets behind holes in firewalls.

• Removes traditional VPNs, a persistently and painfully vulnerable entry point. VPNs are 1990s technology originally designed for small sets of people who would remotely manage routers. They simply can’t scale to the requirements of large hybrid workforces with diverse roles on assorted devices in various states. (U)ZTNA provides precision access, access that can adapt to roles, devices, and states. Note also that (U)ZTNA eliminates the worst kind of privileged server: a VPN concentrator, which attempts (increasingly unsuccessfully) to bridge between the internet and a privileged network by relying on an innocent listening socket exposed to the vagaries of the insecure internet.

• Reduces the need for NAC, because it focuses on application-level access rather than network-level access. IP-based routing between people’s devices and their destinations no longer occurs, and no paths to switch ports or other aspects of the network infrastructure exist. Simply being in a network no longer confers advantage if you can’t randomly interact with whatever’s there. Furthermore, many NAC projects fail because hardware becomes outdated, downtime can’t be tolerated, policies proliferate wildly, and the many moving parts don’t always mesh well. NAC still evinces an implicit trust model (go anywhere after joining the network), which is the opposite of common modern security projects oriented around zero trust strategies.

• Offers optimized location-based access, with no slow hairpins or other impediments that might force people to find insecure workarounds. Harmonized access stops people from working around poor security. Optimized access stops people from working around poor performance. When people can access what they need right now, without tinkering or resorting to hacks or even thinking about what to do based on where they are, they remain maximally productive and in good spirits (and keep the help desk phone lines open).

In essence, universal ZTNA sheds all the distinctions between local and remote. It’s just access now—tailored, consistent, fast, and secure. Reimagine your access architecture now with universal ZTNA from Netskope. Thanks for reading.

Mark Fabbi (another ex-Gartner analyst and now Netskope CXO advisor) and I recorded a webinar in which we further explore the benefits of universal ZTNA. Watch it now.