Several of our customers are networking or security teams at companies with the following attributes:
- A growing remote workforce, e.g., 40%+ remote is common
- A mix of managed and unmanaged devices
- Contractors, partners, or third-party services that need access
- The need to secure access to an ever-shifting collection of sensitive data and services, deployed in a mix of on-premises, Infrastructure-as-a-Service (IaaS), and Software-as-a-Service (SaaS) environments.
Why did they need a new solution? Because legacy VPNs and firewalls were built for a different design point that is increasingly obsolete:
- ~10% remote workforce
- All managed devices
- Third-party access not needed/allowed
- Mostly on-premises resources, easily firewalled with static IP addresses and ports
When Jayanth, Tarun, and I co-founded Banyan Security, we anticipated (most of) these changes and built a scalable platform aimed at meeting the secure access needs of modern organizations.
We also recognized early that the sweeping changes we were seeing in organizations would call for re-thinking the whole security stack, not just “remote access”. So, we designed Banyan to be an open platform with API integration points. These enable Banyan to work in conjunction with other best-in-class security solutions such as Endpoint Detection and Response (EDR) like SentinelOne and CrowdStrike, to factor signals from these tools into access decisions and potentially vice versa.
Our early architecture decisions seem to have served our customers well. Our management and control planes continue to provide highly reliable service as we’ve quickly grown. Our Private Edge deployment model is ideal for maximizing performance and privacy by sending data directly to customer-deployed distributed access tiers, while our Global Edge deployment model is a great fit if you need to minimize dependence on your networking teams.
Along the way, though, we’ve learned a whole lot from security and network teams at our customers, and we continue to rapidly evolve our product to better meet your needs. We think that a big advantage of working with a company at our stage is that your voice carries a lot of weight, and we love to build practical solutions aligned with our mission.
Probably the most fundamental thing we’ve learned is that most teams need a much more step-by-step, self-serve Journey to Zero Trust.
From Banyan’s inception, we’ve provided Zero Trust access in a purist sense. We provided policy-controlled access to individual services, and even enabled policy control at the granularity of individual service API endpoint calls.
However, many teams have understandably found it daunting to take a single giant leap to the new Zero Trust model from their existing VPNs and firewalls. And many networking teams simply have an urgent need to replace their painful VPNs.
To better meet these needs, early this year we debuted our Service Tunnel capabilities, a managed Zero Trust VPN service within the Banyan Security Zero Trust Remote Access product offering.
First Step: Service Tunnel
You can start your Zero Trust Journey with Service Tunnel as a direct replacement of a legacy VPN. It’s an easy step for you to take, with big benefits.
Service Tunnel currently uses WireGuard as the encrypted data plane technology. WireGuard’s simple UDP-based protocol, minimal cipher suites, and Linux kernel support allows us to avoid most of the security and performance pitfalls that plague IPsec and TLS-based VPNs.
Service Tunnel relies on Banyan’s control plane for configuration. This approach lets Service Tunnel inherit the capabilities of our earlier Zero Trust access control, i.e., continuous authorization policy enforcement with trust score-based device posture checking. To limit the broad network access of a VPN, you can customize the general Layer-4 rules section in our Banyan policy language.
Finally, Service Tunnel is included with existing deployment models: Private Edge access tiers, and Global Edge with connectors. For Private Edge, each access tier can serve as a WireGuard peer for end-user devices. A Service Tunnel can peer an end-user-device to any number of access tiers simultaneously, allowing selective direct access to addresses within the private networks that are fronted by these access tiers. Administrators can define multiple Service Tunnels to carve out different realms, or to tolerate overlapping IP address ranges in different private networks. The same is true for Global Edge, except here the private network access is managed through connectors instead of access tiers.
Next Step: Publish Services
As you proceed on the Zero Trust Journey, you can start to “publish” individual services. Publishing a service causes the service to be handled by our identity-aware proxy (netagent process). The proxy can carry out policy enforcement at the granularity of individual requests, e.g., each HTTP request. Publishing a service also allows the service to be managed as a named entity, as opposed to a more fragile IP address.
When you publish a service, typically you also want to remove it from the Service Tunnel. By default, this happens automatically. The Service Tunnel’s Domain Name System (DNS) automatically starts resolving the published service’s Fully Qualified Domain Name (FQDN) to the hosting access tier’s site address instead of to the private address in the private network. This way, end-user-devices that are connected to the Service Tunnel automatically get directed to the access tier’s public address when accessing the published service by its domain name, instead of connecting directly to the service’s private network address.
In a near-final state, you can rely on Service Tunnel only for use cases that cannot be proxied (looking at you, Windows file sharing), and manage published services for pure Zero Trust controlled access. DNS requests can all be handled through Service Tunnel without requiring any updates to the public DNS. However, you may need public DNS entries to allow clients that cannot use Banyan’s DNS service, e.g., third-party clients, or SaaS services that need programmatic access to make API calls to a published service.
Deeper Dives
I would be glad to elaborate on the technical details of any of these features or other aspects of Banyan’s platform in future posts. Please let me know any technical topics you’d like me to cover.
We have created an easy-to-deploy Free Team Edition of Banyan so you can get started today.
