Spent some time lately thinking about the approaches to corporate client VPNs, during a time of a pandemic, which has changed how a number of companies are operating. Namely, organizations are relying on their ability to remotely enable their workforce. To do this efficiently, there are modern strategies and tactics built into products engineers and management should be familiar with in order to achieve the best end user experience, and most efficient use of remote access to the company's information assets. Turns out, good end user experiences will also create both network performance increases, and potential cost savings.
Chris
VPNs as an Enabler
Virtual Private Networks, or VPNs, by their nature, are designed to protect network traffic from a network or individual machine, to another remote machine, or network. VPNs have been around for a long time, supporting and securing corporate network communications from laptops, desktops, and remote offices back to the main office or data center.
In the case of a client VPN, you're connecting your desktop/laptop to the corporate network, so you and your machine can work just like it did in the office.
Yes, desktops can VPN too, especially in the days of 100% WFH because of Covid quarantining and "safe distancing". Companies are just as likely to ship a desktop to a person's home to establish a home office when people are WFH.
So let's walk through the progression of remote access solutions, and what's possible today, selective split tunneling.
Remote Access Solution #1: Decentralized Broad Internet Access Creates Problems
Back in the day...companies didn't have high bandwidth connections, to the home office, or to the Internet. Given that, Network Admins wanted to only Corporate traffic to come back to Corporate networks, allowing users to use the local Internet connections for general Internet access. This is called "split tunneling" because you're splitting the VPN tunnel to allow network traffic outside the VPN, to access local or Internet resources. This saved on Corporate expenses around Internet bandwidth, and other overhead in managing people's Internet traffic.
There are potential problems with deciding routing for Internet traffic at the client level. Say you only route "company" traffic back to the company over a VPN. Or, in the case of a remote office, say you access the Internet using the local office connection, and you only route "corporate" traffic back to the "home office". Something like this:
The problem with this configuration is primarily that there may not be the same Internet controls, like URL filtering or other network security monitoring controls in place in each remote office, or on each client, to protect the company's assets from compromise.
Short-sighted companies without cybersecurity guidance frequently chose this configuration to save on costs and "create network efficiencies".
Companies with information security expertise would tend to gravitate to solution #2...
Remote Access Solution #2: Centralizing Network Security Monitoring is Popular
This is the model we've been using since 1995, at least. Here's a basic example of what a traditional corporate VPN looks like because of the aforementioned issues with decentralized Internet access.
In this example, the VPN Gateway is typically at your Corporate HQ/Data Center, and you get access to both local resources and the Internet, including all your SaaS providers like Office365, or Service Now, or Zoom, or WebEx, etc.
The advantage to this is primarily network controls and visibility, since all traffic from the client comes back to the centrally managed, on-premise corporate information security controls. This includes things like
- Network traffic monitoring through IDS/IPS
- Basic firewalling, blocking general network access to both local networks and the Internet, since you won't know whether or not the laptop is in a hostile airport or hotel network or an unmaintained home network.
- Category-based and specific URL blocking/permissions/reporting
- "next gen" firewall application security capabilities, monitoring application layer traffic
- network monitoring for data loss prevention (DLP) capabilities
Remote Access Solution #3: Selective Split Tunneling
As corporate software solutions have evolved to more Software-as-a-Service (SaaS) models, more of what we use in the day-to-day has moved to web-based, Internet-based service and software portals, companies have been moving to add more Internet bandwidth, adding SAML-based authentication, and providing more scrutiny and assessment of SaaS providers who provide business essential services.
Cyber-mature organizations will see a new way forward, to move beyond the Standard Corporate VPN, to enable both efficient use of network and Internet traffic, as well as maintaining expected and required cybersecurity controls.
This is still called VPN Split Tunneling, but is more appropriately called, Selective Split Tunneling. Here's what this looks like, from a Cisco WebEx perspective:
And, from a SaaS industry perspective, *ALL* of the high bandwidth SaaS application providers are going to recommend split tunneling Corporate VPNs for their services. I've seen this from Zoom and O365, as well. Here's the O365 guidance.
The controversy; dogma, NIST and current realities
If anyone has a rub with this design, its typically because dogma would have you believe split tunneling is risky behavior. May older information security frameworks, based on a compliance regimen, still prescribe that spilt-tunneling opens organizations up to additional risk. Traditional guidance on this topic is probably 10-15 years old.
"Thou shalt not split tunnel VPNs!"
That guidance was fine when VPNs only had two settings: no split tunneling, and only split the tunnel for specific networks you want to run through the VPN. But times have changed.
Modern problems require modern solutions
These days VPN capabilities are more robust and more capable, allowing for split tunneling for Zoom or Office 365, or other SaaS solutions. Companies should do this *if, and only if* a company is assessing their SaaS solutions for cybersecurity controls prior to their use. "Trust but Verify".
Allowing SaaS traffic to operate outside of the Corporate VPN should only minimally increase risk. The top SaaS solutions should care about and are taking actions to protect their traffic (Zoom was challenged on this point for a while in 2020, though, to be transparent). As a part of your own Vendor Risk Assessment, you should validate that a vendor is encrypting traffic between your clients and the SaaS provider.
But, but, but, you can't see or stop "bad" traffic!
Sure, you may not have network monitoring. You have to check your assumptions and ask yourself if you really have that visibility today. Do you intercept SSL? Would you intercept Zoom calls? Would you intercept WebEx? My bet is no.
Conclusion
I'd argue there's less reason, and little risk, to push full SSL-enabled web traffic through a VPN to partner organizations where the controls have been evaluated and understood, with contracts to enforce them. Yes, partner compromises happen (ahem Target), so it's highly dependent on the situation, but it seems like we should be taking a risk-based approach and not be just repeating dated dogma.
What points did I skip over, or miss? Or do you interpret differently? Comment below. Let me know what you think.
Chris
More info:
