The shift to Zero-Trust Network Architecture is recent — but not the ideas behind it.

As an old timer who’s been in the Remote Access (RA) space since the mid-’90s, I see the current wave of evolution in SASE/SDP/ZTA more of a devolution. It takes us back to providing RA as a service (RaaS), replacing dedicated i386 appliances with virtual images akin to the early days of micro services on Unix. For example, this is how Aventail, a pioneer in RaaS, launched — as a service; the appliance came some years later.

When the RaaS (again, service is right there in the name) revolution first hit — way before the SSL VPN reboot — I was building huge NT 3.51 clusters with a spaghetti of US Robotics Courier modems hanging out the back. This service was offered to customers as the Common Office environment bundle and built on the premise that we could not trust incoming user traffic.

Over the proceeding 25+ years, much has changed. But the core principle of distrust remains. One of my favorite vintage marketing tag lines simplifies this message of zero trust to “Detect – Protect – Connect.”

With the 2000s came the SSL VPN revolution, which at its heart messaged “VPN is dead” and “clientless remote access rules.” We’re seeing this again today with SASE/SDP messaging, but what does it really mean?

It comes down to crypto, packet encapsulation and routing — aka “when do I route direct,” “when do I proxy” and “when do I backhaul tunnel.” These are all questions of trust. There is no one-size-fits-all answer to this; thus, to build a highly resilient and scalable service, you must do all three and often together within a single session using JIT logic.

Injecting a bit of humor, let’s look at this piece of Aventail marketing I pulled from the web. (The internet forgets nothing!)

FYI: Aventail lives on today — it is the SSL VPN startup company SonicWall purchased in 2007, which has evolved into today’s SonicWall SMA 1000 series.

With no change to the core of the slide, just updating the terminology buzzwords to current standard, we can see ZTA ideals have been around for a lot longer than you may think.

So why, then, if solution architects like me have been singing the praises of a Zero Trust Architecture (ZTA) approach for 20 years, has there been such a slow adoption? Well, unpicking a flat network is hard work, and often in a large enterprise, you just don’t know who needs access to exactly which apps and data. However, you have to start somewhere — and with many years of experience, we’ve learned a thing or two about the best way to peel that particular onion.

COVID has changed this landscape, and today I see what was considered a “good enough” remote access implementation no longer cutting it. RA overhaul projects are again in the CIO’s Top 3, the common driver being ZTA to support the home worker revolution. So the chickens have finally come home to roost, and my years of banging the drum of inverted networks and shrunken perimeters becoming the mainstay have paid off.

A final thought: A modern RAS needs more than just a complex ACL table to be a robust, reliable ZTA service. The ACE (Access Control Engine) at the core of the SonicWall SMA 1000 may be what your security team is pushing for, but as a CIO, that alone will not help you appease the business or provide a highly reliable, most critical service.

Business continuity thinking has replaced disaster recovery thinking to achieve service uptimes of nearly 100%. This needs consideration for parallel live infra demarcations with a roll forward N+1 strategy, SPOG central configuration change scheduling, mix-mode physical and virtual termination nodes salt-and-peppered between private and public datacenters, redundant app-data paths … which all come from experience.