One of the big changes in the network selection processes that I’ve been running of late has been the interest in remote access and in particular Zero Trust Network Access (ZTNA). Once a poor step-child to the WAN, remote access has, of course, become the de facto approach for how many of us work every day. So let’s talk about what you should be considering when evaluating the remote access and ZTNA capabilities as part of a broader SASE and SD-WAN selection process.
The ZTNA Challenge
If you’re anything like the companies I advise, you’ve seen your network perimeter obliterated by users working from anywhere, and data and applications moving to the cloud. The notion that there’s a “secure here” and “insecure there,” which typified classical network design, is long gone. Today, security and management controls need to travel with your users and data, no matter where they are.
However, legacy network access relies to a degree on trust. Yes, we authenticate users with a password and multi-factor authentication (MFA), but once users were on the network they could still ping, and hence attack, network resources. Malware on one machine could also potentially spread laterally between locations. Of course, this is a simplification. Measures can be engineered to restrict remote user access.
ZTNA: Not Just Remote Access
ZTNA removes the element of trust, presenting users with only those resources — applications and data resources — authorized for access. ZTNA is based on the approach of always verifying and never trusting. To do this, users of a ZTNA platform connect to an entity — a controller or connector — for authentication and policy enforcement. The ZTNA platform assesses the user’s identity and real-time context — the location, device, and time of day — to provide dynamic and granular access policies. Once authorized, users can only access specific applications and resources, such as through an application portal, not the complete network. A detailed description of ZTNA can be seen here. You can also read the NIST paper, “Implementing A Zero Trust Architecture.”
ZTNA is commonly thought of as a remote access solution but it’s much broader, applying to all forms of access in and outside of the office. For SD-WAN solutions, ZTNA then is something new on two accounts. As I’ve noted before, security and remote access are not inherent to SD-WAN. SD-WAN was a solution for the high cost of MPLS and network uptime, a site-to-site connectivity problem not a secure or remote access problem. There are no remote access clients, for example, that come as part of SD-WAN. There’s no notion of identity in an SD-WAN that’s so critical to ZTNA. All of which will require SD-WAN vendors to partner with third-parties, like zScaler, if they’re too offer a ZTNA approach with their SD-WAN offering. Even then this will only provide ZTNA as it relates to remote access NOT as it relates to site-to-site access.
SASE: A Natural Fit For ZTNA
By contrast, secure access service edge (SASE) solutions are highly synergistic with ZTNA. SASE solutions converge security and networking with ZTNA being but one of the security components. They already include SD-WAN and remote access capabilities and are identity-aware — the raw ingredients for ZTNA.
SASE also fills holes that ZTNA alone lacks. While ZTNA describes how to deliver secure access it doesn’t necessarily mean that the platform can enforce policy on all network- or Internet-based resources. SASE includes both firewall and CASB capabilities. ZTNA talks about access but may not include the technologies to monitor for malware and online threats. Those capabilities are part of SASE.
ZTNA solutions may also face performance problems. In the extreme case, if policy inspection occurs in one location, remote and local users can find their traffic being backhauled to that inspectdion point, adding latency to their sessions. Global traffic still needs to traverse the Internet with all of the latency and unpredictability that’s implied. SASE architectures address both of those issues.
What To Consider When Considering ZTNA?
When looking at ZTNA capabilities in your SASE or SD-WAN solution, we recommend validating that ZTNA is offered in the first place and the extent of those ZTNA capabilities. Are they offered for remote and local users? At a minimum, ZTNA should limit access down to the specific resource, ideally by presenting your users with a robust application portal.
Also consider the architecture. Which approach to ZTNA is the vendor taking? There are two approaches — endpoint-initiated ZTNA and service-initiated ZTNA. Where are the authentication points situated in relationship to your organization’s need. What other security and networking capabilities are built into the platform and work with ZTNA?
ZTNA will be critical as companies look to provide agile, secure access everywhere. The differences in architectures can make a significant difference depending on the size and type of your organization. If you need help sorting through your ZTNA options, give me a call.
