Reinventing the VPN — Q&A With New Edge CEO David Goldschlag
New Edge has a unique approach for secure remote access which brings traditional VPN concepts into the modern “cloud first” era. As an investor and user of the solution, I recently was able to ask New Edge CEO and cofounder, David Goldschlag, a variety of questions about VPNs and New Edge’s unique approach.
What was so wrong or frustrating for VPN customers that led you to start New Edge?
It’s so interesting — the benefit that IT got from VPN has basically flipped over the past two decades of use. At first, the primary purpose of the VPN was the tunnel itself — help remote users get access to enterprise applications by giving their devices an IP address on the enterprise network and access to behind the firewall enterprise applications. The secondary purpose was user authentication and later device posture checking (compliance). But as security concerns grew, that secondary purpose became the primary value. And as enterprise IT went Hybrid, and enterprise applications moved from the datacenter to SaaS and the Public Cloud (AWS, Azure, GCP), the point-to-point tunnel became an obstacle — but enterprises still needed VPN-like authorization policies enforced for all these distributed apps.
And they needed this without tunneling through their own data center?
Yes, without tunneling through the corporate data center on the way to public cloud and SaaS. For a while, enterprises thought that tunneling through the enterprise network was the way to enforce authentication and compliance and doing so made enterprises more comfortable with use of Public Cloud and SaaS. But then we started to see cloud-first businesses that rented colo spaces just to house the VPN or an F5 box. Of course this sounds ridiculous and IT shops that do it, know it, but they also know that a VPN’s auth and compliance provides critical security value.
A colo for VPN or F5 sounds like a cloud-only solution for a smaller enterprise. But what about larger enterprises?
Larger enterprises have been building out enterprise-run access services for a long time. They would buy several VPN appliances for each geographic datacenter, and staff a team to operate the service, and charge their business units to use the service. So at New Edge, we decided to build access-as-service for Hybrid IT, and just like Akamai can build a better content delivery network than any enterprise can, New Edge can offer better point-to-multipoint connectivity at a lower cost than any single enterprise can do on its own. So New Edge’s access-as-a-service solves the secure access problem for large and small enterprises, whether they are Hybrid IT, Cloud-First, or Cloud-Only.
How does New Edge solve these problems?
New Edge offers a cloud service that does two things. First is a centralized authorization Policy — defining what enterprise applications are made available (published), which user groups can connect to which applications, and what device compliance level is required to access applications with different levels of data sensitivity. The second aspect of the cloud service is a distributed set of something we call an Application Router. Devices connect to the nearest Application Router, and connect to enterprise applications through that Application Router. A critical advantage of this architecture is transparent and secure access to enterprise applications across multiple locations, without going through a corporate data center, and without switching between different point-to-point VPN connections.
How is the Application Router different from a proxy?
A proxy sits in the middle of HTTP traffic, terminates connections from a device, and creates a new connection to a web service. So proxies work for browser apps and they typically “see” the application data. The New Edge Application Router is different. For one, it’s application agnostic, and can support any application as long as it’s fundamentally TCP or UDP based. And it can support users using both browser and thick apps on the device. The Application Router works by terminating two inbound tunnels, one from the device to the Application Router, and the other from each enterprise network to the Application Router. Application data flows through these inbound tunnels, and the Application Router is responsible for passing data between these tunnels, after authorizing that the user and device are permitted to access the application. This is called “authorize before connect” and is a very powerful security paradigm: the enterprise network only sees traffic from trusted users using trusted devices.
A key capability of New Edge is service publishing. I really like this because you can “hide” applications behind the New Edge service and not have open ports directly on the internet.
That’s exactly right. Because of “authorize before connect,” New Edge’s service publishing makes specified enterprise applications available only through the New Edge Application Router. And only authorized users/devices can connect to the New Edge Service and only to the applications to which they are authorized. And the tunnel from each enterprise physical or virtual data center is outbound to the Application Router, so datacenter firewall rules with respect to remote access are very simple — no inbound connections allowed.
Another key capability of New Edge is the ability to assign specific applications to specific users. How does this work, and how does it compare to traditional access control based VPNs with IP address rules.
New Edge operates on the principle of least privilege. Users who need access to certain applications should get access to those applications and not to others, and certainly not broad access to the enterprise network. New Edge never gives a device an enterprise IP address. Instead, New Edge, by policy, knows which enterprise applications a user/device is authorized to access, and they are specified as a set of hostname:port pairs. And only connections from the device to these allowed hostname:port pairs are tunneled to the Application Router and stitched onto the enterprise network. And hostnames are more manageable than IP addresses, and are mostly static (eg, they equate with applications), while IP addresses are dynamic, which makes VPN IP-based ACLs complicated and hard to maintain.
New Edge recently came out of “stealth” mode and your first use case centered around securing access to Amazon Wed Services. What is your approach here and why AWS first?
In addition to security, New Edge is focused on easy. Easy for the end-user and easy for IT. We want secure access to be easy to deploy and easy to use.
So for deployment, we’re distributing all of our endpoint software on the various app stores, including Windows, Mac, and iOS, and making end-user enrollment self-service. And just as importantly, we’re making enterprise provisioning self-service. This is especially important in the new DevOps centric IT models. DevOps can deploy New Edge end-to-end easily, like an application, without any specialized networking or security expertise. Even device certificates are delivered from a New Edge PKI that is self-contained and operates as a black box.
And our AWS Marketplace AMI makes VPC deployment easy. You just start up a server in your VPC with our New Edge publisher AMI, and give the publisher a name provided by the New Edge policy service. The Publisher then makes an outbound connection to the Application Router, and it’s all configured. No network configuration and no firewall rule changes.
You can deploy secure-access end-to-end in 30 minutes. Try doing that with a VPN or a Proxy. By focusing on AWS first, we can help large and small enterprises secure access to their applications in their AWS VPCs. In addition to custom web apps, we’re seeing lots of need to access Jira and Confluence (the “Atlassian stack”), as well as Linux secure shell and Windows remote desktop use cases. As we add support for VMware and Azure and GCP over the next few months, we’ll support more Hybrid IT and Cloud-first use cases.
Where can readers go to learn more about proof of concepts and other use cases?
Originally published at https://www.linkedin.com on August 29, 2017.