Over the last few years many organizations have already introduced a zero trust network access (ZTNA) solution, and are seeing the benefits from it. But many others have been put off by the work needed to transition to a zero trust-based access model and the associated technical integration work. In this blog I will unpack the aspects to consider and share some insight into how organisations can begin their move to ZTNA now, transitioning fully over time, by debunking some of the common myths I hear about.
Many of the common issues with a virtual private network (VPN) are well understood, whether it’s security concerns regarding encryption and authentication, the original premise of a VPN no longer being suitable for the hybrid way we work today, and of course the security implications of allowing incoming connections to a location.
ZTNA looks to solve each of these issues, using a cloud layer to broker connections between users and applications, yet, reliable and fast connectivity to applications remains a problem for organisations. A recent Cisco report claims 51% of organisations they surveyed have had problems connecting workers to company resources over the past 18 months.
Connecting people to applications should not be a hard task and the five myths below are the most common reasons I hear as to why organisations have not adopted a ZTNA approach yet.
Myth 1: I don’t have the insight I need to create a zero trust-based policy
This myth can be broken down into two components, either you don’t have the insight into the application landscape or you don’t have the insight into user groups and access permission.
Both can be dealt with through a well thought out migration and pre-planning to identify your top use cases and most valuable data. This can be aided by partnering with other initiatives including cloud migration projects. The issue of application discovery can also be aided by discovery tools built into ZTNA and security service edge (SSE) solutions.
Finally, the organisation will always undertake a staged migration of users when implementing ZTNA, allowing them to build up the correct access policies over time. Start with the high risk apps and users for quick wins, build a zero trust-based policy for access to high risk apps and migrate services over time, building up a comprehensive zero trust policy to underpin ZTNA-based access.
Myth 2 – Implementing zero trust and ZTNA sounds like a major undertaking
One can understand why this myth exists, but it’s important to remember that zero trust and ZTNA are not the same thing—there is an easy way to decouple the two. Zero trust is a way of thinking and can be translated to a security strategy—one that allows you to systematically remove implicit trust. ZTNA is the mechanism and technology to implement zero trust for remote access to applications. That said, ZTNA is a great first project to start your zero trust journey, one that many companies take and one that does not require a large resource outlay to introduce.
Myth 3: ZTNA will add yet another client to my endpoint
It is true that many ZTNA solutions do have an endpoint client to manage connections, as well as running posture checks and providing integration with authentication providers. ZTNA can also be provided via clientless browser-based connections, but while this solves the “We are not putting another agent on the endpoint” issue, it doesn’t allow for many of the benefits of deploying a client. The Netskope approach is unique in the market, providing a single agent for all aspects of secure access service edge (SASE). One that not only provides remote access, but also steers web and cloud app traffic, inspects content, facilitates endpoint DLP, and provides end user coaching and feedback.
This is one reason why organisations should always consider their long term plans for SASE. If ZTNA is the first step on their SASE journey, they should make sure that the platform they choose provides all the capabilities they will need for a unified SASE offering in the future.
Myth 4: ZTNA is just a VPN replacement
While ZTNA replaces many of the use cases handled by a VPN today, for many organisations their initial ZTNA project is driven by the need to provide contractor and third-party access to internal applications.
These access initiatives are often completely separate initiatives from providing remote access to employees, and they offer the perfect first use cases for ZTNA, where the same level of implicit trust can’t be applied to the device or user connecting to the application or network.
Another common use case for ZTNA is to support mergers and acquisitions, allowing very fast provisioning and scalability not afforded by traditional VPNs, especially in a more hybrid world where most VPN concentrators are running at near capacity.
Myth 5: VPN and ZTNA can’t run side by side
For my final myth I would like to address a common discussion point. Many organisations need to keep a limited VPN capability running for legacy applications, and therefore believe they might as well keep the VPN for all users.
This thinking fails to take into account one of the core reasons for deploying ZTNA, providing granular policy control, including content aware policies for application access. ZTNA solutions reduce risk, not only of direct unauthorised access or risky actions, but also lateral movement.
Many organisations run VPN and ZTNA side-by-side, making changes to the VPN access and routing policies once ZTNA has been deployed, to reduce the risk associated with VPN compromise. Over time as organisations complete their digital transformation projects, phasing out legacy apps and VoiP solutions, they can decommission their VPN entirely.
Running VPN and ZTNA at the same time also helps highlight a solution to some of the most common issues with VPN today related to performance, network/connectivity issues, and the cost of hairpinning traffic through a data centre. Migrating traffic off of a VPN and on to ZTNA and a wider SASE or SSE platform solves both of these issues, ultimately reducing overall costs.
For more information on a number of the points covered in this blog, read our Practical Guide to ZTNA.
