ZTNA – what is it and how does it work?

Legacy SSL-VPN, is it still a valid option?

If you’re an old-school IT professional, you’ve probably set up countless SSL VPN connections to connect remote users to the workplace in a secure manner.  Over the last year or so, you’ve also probably heard rumors, or learned that many firewall vendors are starting to move away from SSL VPN offerings due to the concerns about security vulnerabilities along with sometimes complicated setups and deployment configurations.   Some vendors like Fortinet are leading the charge to push customers towards more modern-day technologies and have even started to remove SSL VPN capabilities from newer firmware releases of certain firewall models because of this, while other vendors like Palo Alto and Sonicwall have continued to support SSL VPN, at least for now.  While there’s still a use case for legacy SSL VPN deployments in some situations, technologies have drastically changed and improved over the years, which has led to a couple of different remote access alternatives that are strongly worth considering to enhance and improve your organization’s overall security posture.

Alternatives to SSL-VPN?

Most vendors seem to agree that IPSec VPN is a much better alternative to SSL VPN for establishing connections for remote users in the workplace.  IPSec encryption is stronger because it provides that encryption at layer 3 of the OSI model (Network Layer), while SSL VPN encrypts specific data at Layer 7 (the Application Layer).  As a result, IPSec is often a much hardier solution for encrypting your sensitive data, less susceptible to man in the middle attacks, and doesn’t really add much complication to the setup or deployment process to get it installed on end-user devices, laptops, etc.  If your organization needs a quick and easy alternative to SSL VPN, considering looking at IPSec, especially because your current firewall manufacturer likely supports IPSec at no additional cost.

Another even better alternative that is quickly gaining a lot of traction in the IT industry is using ZTNA which stands for Zero Trust Network Access.  ZTNA is a security framework that has a ton of different features and security improvements overall but the idea behind ZTNA is never trust anything and always verify everything.  A concept that security experts will certainly favor to make sure that only authorized individuals can gain access to specific destinations and resources which provides you with considerably more oversight and granular control. 

Image: What is Zero Trust Network Access (ZTNA)?

To better conceptualize the real-world difference between SSL VPN and ZTNA, from a usage standpoint, think of how remote users are often setup with SSL VPN.  Remote users are typically configured in a way that, once they open up their VPN client software and enter in their credentials to properly authenticate.  Once authenticated, they are allowed access to the entire corporate network while working remotely, just as if they were on onsite and plugged in via a physical Ethernet connection or Secured wireless connection.  And every single morning, when they open up their laptop to begin their regular workday, they have to reestablish that SSL VPN connection using their VPN client software connect to the corporate firewall.  If they close their laptop for lunch and come back later, they will once again have to manually authenticate and reestablish that SSL VPN back to the office all over again.  In contrast, when ZTNA is deployed, there are several substantial key differences. 

• First, rather than allowing that particular user/device access to the entire network, ZTNA provides access to specific applications or specific data sets that you as the administrator configure (preferably based on Principal of Least Privilege access level assignment if you’re doing things by the book and best practices!).  If you want your remote users to -only- have access to a single Microsoft RDS server, or a specific internal web server, or limit their access to only the Microsoft SQL server that is needed for their front-end application, or perhaps they need access to a combination of various destinations based on their job role, all of these things are easily possible using ZTNA deployments by use of implementing fine grained access policies (ZTNA) versus providing them access to the entire network (SSL VPN).  This kind of least privilege access helps to substantially reduce the overall attack surface and security risk within your environment for all remote users as well because ZTNA establishes a secure tunnel between that client device and the application or destinate resource they need to access.    
• Second, all IT professionals and IT administrators want remote access to be easily deployed and be easy to use for end user who, let’s be honest, may not be the most tech-savvy people out there.  Remember the earlier mention how every single morning, with SSL VPN, remote users have to reestablish their VPN connection back to the office in order to start their day?   With ZTNA, users will no longer have to manually authenticate using their VPN client software because ZTNA continuously validates user/device credentials in the background instead of just during that first initial connection.  An end user’s experience each morning is just opening up their RDP session and connecting into their RDS server, or firing up the front-end application that connects to the back-end Microsoft SQL server in the corporate Datacenter, without the fuss and complication of VPN client software.   

It’s truly a win-win scenario when you can have your end users working remotely and actually streamline their remote access process and offer all of that while actually improving overall security and reducing the overall attack surface for the entire organization.   Another benefit about ZTNA deployments is that they are pretty straight forward and don’t require a huge learning curve for the IT administrator to figure out either.  Consider as an example, the ZTNA solution from Fortinet, which only requires the necessary FortiEMS/ZTNA licensing that is currently offered in two different ways, either a) Cloud hosted FortiEMS server, or b) Local hosted FortiEMS server, whichever fits your infrastructure model best.  Once you have your FortiEMS server deployed, then it’s just a matter of configuring your FortiClient.exe so it can be deployed to and installed on your remote user laptops.  Seems simple?  That’s because it is.   

If you haven’t yet started to look into ZTNA as an alternative to replace your aging SSL VPN solution, perhaps now is the time to start inquiring and looking at your options. Your organization’s Chief Security Officer will thank you for helping to improve network integrity and minimize cybersecurity attack risks, and your end-users will thank you for making remote access from home easier and more streamlined overall.

Additional resources

https://www.fortinet.com/resources/cyberglossary/what-is-ztna),