Enterprise cybersecurity technology research that connects the dots.
Bringing Zero Trust to Secure Remote Access
Demand for secure remote access has skyrocketed during the pandemic. Here Omdia profiles more secure alternatives to virtual private network (VPN) technology.
The coronavirus pandemic has put secure remote access technology in the spotlight as never before. In 2020, the WFH acronym was seared into the consciousness of countless organizations, as their office staff was forced to decamp suddenly and, often for extended periods, to work from home offices (i.e. back bedrooms, living rooms or kitchens) around the world.
Of course, the trend for knowledge workers to "work from anywhere" had begun long before that: 2005 is generally agreed to be the year in which the number of laptops sold surpassed that of desktops for the first time as the primary form factor for personal computing. Indeed, since the turn of the millennium, technology to enable the so-called “road warrior” has been a staple of hardware and software vendors, as well as providers of various types of connectivity and security services.
However, it was COVID-19 that drove literally millions of office workers to work from home in successive waves of regional and national lockdowns across the globe, enshrining WFH as a "new normal," potentially even for the long term.
In turn, this has caused corporate tech teams to rethink the underlying systems they rely on to deliver secure remote access.
VPNs are the big beast in secure remote access
For the time being, the bulk of these secure connections are provided by virtual private network (VPN) technology and services, which already constituted a market estimated at $25bn in 2019, though numbers vary, depending on whether you consider only customer-provisioned VPNs or also those delivered by service providers. Either way, it will of course have seen a huge increase in demand last year. However, as secure remote access has become an almost universal requirement and corporate application infrastructures migrate increasingly to the cloud, newer approaches that are both more secure and more efficient have emerged.
Omdia refers to these approaches with the umbrella term of Zero Trust Access (ZTA) technologies. Another well-known research firm uses the term Zero Trust Network Access (ZTNA), and while our illustrious competitor is usually quite accurate when baptizing most new and emerging areas of technology, Omdia believes ZTNA is inaccurate: ZTA is about granting access to applications, regardless of the network over which the data will travel, so the ‘N’ is, in Omdia’s opinion, superfluous.
The reason for the Zero Trust epithet here is that these new approaches embody that philosophical stance to security, in that they grant specific access rights, i.e. the minimal ones required for a user to perform a specific task, rather than blanket access to an organization’s entire infrastructure, as typically happens with VPNs.
ZTA also avoids the architectural constraint of customer-provisioned VPNs, in that it does not require traffic from end user devices to traverse a concentrator in a company’s data center, even when that user is accessing a cloud-based application (a shortcoming often referred to as “tromboning” or “hairpinning”).
Software-Defined Perimeter (SDP)
Broadly speaking, ZTA platforms fall into one of two groups, with a fundamental architectural difference between the two.
First are those that adopt the Software-Defined Perimeter (SDP) architecture, the technical specification which hails from the Cloud Security Alliance (CSA). SDP inserts a controller into the control path between the end users and the applications they wish to access, but not in the data path. The controller receives a request for access and, if accepted, notifies an SDP gateway sitting in the data plane, in front of the application that it should set up encrypted tunnels to both the end user’s device and the application. It then goes into pass-through mode, such that there should be no latency added to the communication.
Identity-Aware Proxy (IAP)
The second group is called Identity-Aware Proxy (IAP) platforms. With IAP, the proxy sits in both the control and the data paths, where it brokers the access requests, then sets up the encrypted tunnels between end user and application.
Figure 2: The IAP Architecture
By inserting an extra “bump in the wire” into the data plane, this approach has the potential to add latency. For this reason, most of the vendors and providers offering IAP operate their own networks, which enables them to mitigate latency and other performance considerations with techniques such as optimal path selection. Examples of IAP providers are:
Akamai
Cloudflare
Perimeter81
PortSys
Proofpoint
Zscaler
PortSys is the exception here, in that it adopts an IAP architecture but does not operate its own network, leaving its customers free to deploy its Total Access Control product on whichever network infrastructure they prefer. The vendor says it architected its platform to avoid adding latency, partly by removing the overhead of many of its competitors’ products.
If there are any challenges with latency, customers can address it by adding memory or CPU cores to TAC for an individual instance, or by expanding an array – or arrays – to build out the capability and throughput to whatever level the organization needs, without incurring any additional licensing costs for TAC.
By contrast, SDP is usually offered as software for a company to deploy and operate, i.e. there is no obligation for it to be a service. SDP vendors include:
AppGate
Opswat
Safe-T
Okta, Pulse Secure (now part of Ivanti) and Verizon also use an SDP architecture, but offer it only as a service.
When considering a ZTA solution, enterprises should be aware of this distinction between IAP and SDP. If an organization prefer to operate its own infrastructure and has the wherewithal to do so, SDP is worth considering.
If, on the other hand, an enterprise is more inclined toward employing a service for remote connectivity, IAP would seem the logical way to go. That of course means traffic will be traversing the IAP provider’s network rather than one of its own choosing, so it becomes necessary to think about service level agreements on connections, in the same way it would with a managed WAN or internet provider.
And of course, remember the exceptions: providers including Okta, Pulse and Verizon offer SDP-as-a-service, while PortSys offers IAP as software for the customer to deploy wherever it likes.
About the Author
You May Also Like