Zero Trust VPN

PDS partner and security expert John Parker has been putting these new tools—currently regarded as falling somewhere between legacy VPN and full-blown SASE—through their paces and has come to the conclusion that we may be on the verge of seeing broad adoption of these products as a game-changing approach to not only VPN, but possibly to securing an organization's network from possible internal mischief as well.

Author's Note:

Organizations are accustomed to possessing a VPN solution through having acquired one of many firewall solutions on the market. A VPN (Virtual Private Network) is traditionally a native component of the firewall, and the features that come with it—those related to compliance, posture, URL protection, etc.—are generally determined by which firewall solution they purchase. This is the general concept of what a VPN solution is, and may vary to some extent based on whether an organization relies on a legacy or "next gen" firewall.

More recently we've seen adoption by some organizations of SASE (Secure Access Service Edge) solutions, which incorporate VPN, and simplify networking and security management by aggregating monitoring, management and control into a single gateway, or a "single pane of glass", so to speak. SASE generally gives organizations more granularity of control, and it can also make life simpler.

These two technologies—the corporate firewall and SASE—represent two ends of a spectrum, one which to a large extent reflects the ongoing migration of practically all corporate computing from on-prem to the cloud.

But while SASE may be superior in many ways, it's not without its drawbacks when seen through the eyes of some customers. For one, SASE isn't cheap, and, depending on exactly where a customer is coming from, it may be seen as resource-intensive in a management sense. Despite the single pane of glass, deploying and managing SASE may require a level of effort, attention and expertise that don't necessarily justify the perceived return on investment.

And yet these same customers saying "no" to the cost of SASE also tend to be unhappy with their legacy VPN solutions. The VPN is doing what it was designed to do, perhaps, but it's not doing everything they need, the story often goes. Historically, to their point, VPNs are, well, wide open. With a VPN, organizations are basically extending their network out to their employees, and based on my career experience, firewall rules tend to be quite non-restrictive. This creates intolerable risk, many say, but it seems that for them the risk is less intolerable than the price of SASE.

So what's a customer to do? And how does a professional services provider like Prescriptive help guide them toward a middle ground that truly solves their needs? Thankfully, we've seen a rise of new solutions that do just this. They're not full-on SASE, and they're not legacy VPN. So what are they?

Turns out, describing the differences has its challenges, but let's start with the basics. The first thing I want to point out is that legacy VPN is a service. It's always open and exposed to the internet. If I'm running it over SSL, using port 443, that means my firewall has a public IP with an open port 443. Anybody can hit it at any time, and they're generally able to hammer on it as long as they like trying different combinations of URLs and credentials attempting to breach it. An organization may decide to block an IP address in response, but this can turn into little more than a game of cat and mouse. This has always been a concern with a legacy approach to VPN, and, believe it or not, this doesn't necessarily go away with SASE, either, where VPN is still a service. Sure, SASE is more secure, in part because it's not hosted on prem, and not eating up bandwidth while would be intruders hammer on it. But its authentication mechanism still carries risk.

This may be why this new VPN alternative is really taking hold, with a refreshingly novel approach.

No More Holes in the Firewall

A traditional VPN relies on the firewall as the connection point to a network. To reach resources inside the network, the firewall has to provide for a "hole" through which a client can pass. In essence, the network is extended to the user. With these newer, alternative solutions, a connector sits inside the firewall, and the firewall allows for an outbound connection to a relay which sits, you guessed it, outside the firewall. External clients needing to connect with internal network resources, then, communicate with the relay, which in turn brokers communication between the client and the connector. Instead of having to poke a hole in the firewall for an authenticated client to pass through, we now allow communication with the internal connector only through the relay. The relay itself houses the mechanism controlling how the relay can be used, and by whom, and the biggest immediate benefit is the elimination of the holes in the firewall.

Only Trusted Endpoints

To dive a little further into what's going on behind the scenes of the client-relay communication, we'll find a familiar authentication mechanism, involving elements of username and password, SAML (Security Assertion Markup Language), and/or SSO (Single Sign-On). This part hasn't changed. But layered within a cloud relay are aspects of trusted endpoint and posture, which may require, for example, not only that a client successfully authenticate, but that the client device—before even being provided access to the connector—be recognized as trusted, or having been authorized to access the connector. In addition, the relay may check for requirements such as whether the client is, for example, running an up-to-date version of Windows or Mac OS or updated virus protection. While all of these protections may have been possible, they've required other back end components to do so, involving greater expense and complexity. Now these capabilities are rolled into a single, focused offering.

Explicit Enablement

And here things get even more interesting. With traditional VPN, once a client reaches, say, a given server within the firewall, there may be no deterrence to prevent that user from pivoting to other resources through other ports. Remember, with a traditional VPN we're extending the network to the user. Firewall rules can prevent this, but they often don't. On the other hand, a relay controller can easily be configured to restrict communication to, for example, a single port. A client's activity is strictly limited to what the relay explicitly permits.

Additional, Secondary Security Measures

Other capabilities provided by alternative VPN include limiting activity to certain time windows, or forcing re-authentication every so often during a session, or maybe even, for example, requiring a different method of MFA (multifactor authentication) than the one used for the first authentication. Any combination of these will enhance an organization's security posture beyond what's possible—or practical, at least—with a traditional firewall.

The Cost-Benefit Assessment

If I'm a customer, I'm asking myself this: Does this solution make financial sense when my VPN is, essentially, a free resource, already bundled with my firewall? If my only solution to a more secure environment in the face of a growing remote workforce is SASE, I can tell you that in many cases customers are going to stick with their legacy VPN. But these new solutions, offered by hardware vendors like Twingate, cost only a small fraction of the cost of a full-blown SASE solution, and at the same time require less in terms of management resources.

Envisioning Broader Application, and the Advent of "SASE Light"

And now to what I've been exploring here in the Prescriptive lab, and am incredibly excited to talk about. What if this new mechanism—involving relay and connector—were applied to users not only outside the firewall, but also inside the firewall? Why should an organization loosen its security posture for internal users—assuming those users require the same resources whether inside or outside of the network—just because they happen to be inside the office? My early impressions are that the applications for what I'm calling "Zero Trust VPN" are a whole lot broader than I originally thought.

Changing the Relationship Between Customer and Service Provider

A more specific realization for me has been how Prescriptive can leverage Zero Trust VPN in our work with customers, using it to limit our own access to customer networks. This not only gives our customers more control of their network—and more peace of mind as it relates to how they dole out access to third parties—but it also significantly lessens the likelihood that, should malicious actors ever successfully breach Prescriptive's own defenses, our customers' resources are put in more danger.

Wrapping This Up

As I've said on so many occasions when introducing customers to new technologies, virtually all of these capabilities were available on the market before these new solutions came along. The breakthrough is often not so much about what a technology can do, however, but in how much easier it becomes for the customer to leverage it. And this is absolutely true for the Zero Trust VPN I'm describing here. These solutions can literally be deployed, configured, and made available to users in less than an hour from start to finish.

If you'd like to learn more about the new Zero Trust VPN and about the specific products we've been testing, please send us a note or give us a call. I'd love to personally walk you through how it might be applied in your own organization.