To learn about how we got to Zero Trust Network Access (ZTNA), we need to look at the evolution of remote access.

Remote Access Enterprise VPNs (Virtual Private Networks) have evolved quite a bit over the years. They first became important when employees were being issued laptops and could do some work from home. Those VPNs were based on IKE/IPSec and the connections were terminated on concentrators, a special device that only did tunnel termination and encryption/decryption. That functionality slowly made its way to edge security devices, aka the edge firewall. The edge firewall had two functions: protect the internal network and provide remote access. Most did one thing well. Most were still configured and managed as firewalls, in active/active or active/passive pairs. This was never ideal, but it was what IT had at the time.

In 2013, the Cloud Security Alliance (CSA) began working on the Software-Defined Perimeter (SDP) specification. SDP is composed on three components: a controller, a gateway, and a client. VPN users were used to using a client. The concept of a controller and gateway meant that the control plane and data plane were now separate. This helped performance and delivered modest improvement on the admin and end user experience side, however, SDP fell short in other areas such as device security thus the SDP trend didn’t last long.

ZTNA learned many lessons from VPN and SDP, while improving scale and performance, easing deployment obstacles, increasing security, and improving the admin and end user experience.

What else to keep in mind when thinking about the evolution?

  • VPN is how things are remotely accessed today
  • Existing 3rd party software integrations can be carried over today using API-based methods
  • Existing authentication functionality in Identity as a Service (IDaaS) can be carried over using industry-standard methods such as Security Assertion Markup Language (SAML) version 2.0 and OpenID Connect (OIDC)
  • Existing business processes can be simplified with easier-to-use remote access software solutions such as ZTNA
  • VPNs have lots of deployment challenges that ZTNA solves

Deploying a VPN wasn’t easy, but IT has had to live with it. Here’s a quick summary of how IT bought and deployed.

To buy:

  1. Need to design/architect full global deployments along with planning for high availability
  2. Need to understand licensing, including what happens in failover scenarios
  3. Know the number of users

To deploy:

  1. Ship/rack/stack/power physical appliances
  2. Make sure firewall rules are all configured (including a few open ports)
  3. Configure DNS and possibly load-balancing rules for each appliance
  4. Make sure all appliances have backend access for authentication/resources
  5. Configure user directory
  6. Add resources
  7. Create policies

With VPN, if you need to add just one new location, think adding an offshore development team or a M&A scenario, you basically need to do everything above again for the new appliance(s) along with updating all the clients to make sure they are aware of the new appliances.

For Banyan’s ZTNA, you just need to the know the number of users to make a purchase. In terms of deployment, only three steps (5-7, above) are needed.

Further considerations for migration from legacy VPNs:

  • Deployment options and ease for ZTNA
  • Improved end user experience
  • “Working” vs. safe, secure, easy, etc.
    • Lots of organizations stop paying support and stop updating their legacy VPN software
    • Common Vulnerabilities and Exposures (CVEs) are abundant in VPNs. In 2019, there were over 17,000 CVEs with 4.3K+ being High Risk.
  • “Good enough” VPNs are a compromise
    • Poor end user experience
    • Complicated configuration
    • Limited monitoring
    • Poor performance/scale
    • This has led to different solutions from different vendors across the organization
  • Misconfiguration is possible, so it happens
    • Access beats out security when it comes to business continuity
  • All remote access security is circumvented once on-premises
    • For example, for remote access there is token-based MFA and a device posture check, but on-premises username/password and you’re on

While you’re on, check out why Banyan Security’s ZTNA solves all these problems for you.

Finally, stay tuned. A blog comparing ZTNA with Remote Desktop and Virtual Desktop Infrastructure (VDI) including offerings from Citrix and VMware is in the works.





author avatar
Ashur Kanoon