The Big Rethink: How Software-Defined Access is Remaking Corporate Network Security
(This article originally appeared in Forbes.)
Psst, CIOs! I'm going to let you in on a not-very-well-kept secret: That spiffy new VPN you just implemented? There's a chance your employees may not exactly love it. That's because VPNs can be slow, inconvenient and may not be as secure as you think.
The times, they are a changin'
Lots of employees today work remotely—from home or coffee places or airplanes. They access corporate resources on tablets and smartphones, many of which they bring to the table themselves. Oh, and did I mention they expect Netflix-fast connectivity? And if you can't meet that network performance expectation, they may go rogue and connect directly.
You've got to keep your workers productive and secure your corporate assets against burgeoning threats. But how can you do both without compromise? You could stack more security appliances at the firewall. But that approach will be complex to manage and expensive to scale. It's also reactive—your network security will be only as good as your last hardware or patch upgrade. And is network security a business you really want to be in?
It’s time for a radical rethink of corporate networking. What if instead of trying to prevent local internet breakouts, you secured them? It'd certainly make users happy. And it’s not a pipe dream—it can actually be done with a security protocol called software-defined access, or SDA.
Why Google decided to change its approach on network security
A quick bit of history: Back in 2011, Google recognized a gap between the way its network security was designed to work and the way its employees preferred to work. Specifically, traditional perimeter-based network security models had limitations:
- Routing traffic through distant firewall gateways slowed performance and impacted user experience.
- Hardware-based security appliances were expensive and not particularly a scalable way to address threats.
- Any breach offered up the entirety of network assets (cross the moat, and you have the run of the entire castle).
Google—in parallel with industry thought leaders—began developing the concept of software-defined access. The idea is straightforward: Let users (wherever they are and from whatever device) connect directly to resources, wherever those resources may be (in the data center, on the internet or in the cloud), thus bypassing the corporate network entirely.
But how do you secure that direct connectivity? Google's approach—its internal non-commercial service is called BeyondCorp—was to establish a cloud-based solution with software-defined security policies assigned to the user.
The end user in the plastic bubble
So what exactly is SDA? SDA is a security model that enables users to connect to resources directly without accessing a corporate network first. Via user- and context-based policy, SDA defines a secure perimeter around each user's traffic—creating a network of one, so to speak. Instead of securing the perimeter around the network, SDA isolates the user and, in turn, limits the scope of a potential breach. SDA can be delivered via in-line software, as a cloud service or, in some cases, on-prem.
Implementing SDA requires a rethink not just of the corporate network, but of trust itself. Trust is no longer a currency to be traded: SDA assumes a default-deny posture with each potential interaction, whether the interaction occurs inside or outside the company. Google BeyondCorp is one flavor of such zero-trust implementations. Forrester created and popularized the zero-trust framework. Gartner took it even further, placing a zero-trust approach on a continuum in its Continuous Adaptive Risk and Trust Assessment (CARTA) model.
Enterprises big and small can realize SDA’s tangible benefits, including distributed-workforce enablement, reduced LAN/WAN costs, facilitated cloud migration and non-standard device access. But SDA shouldn’t be viewed as a panacea. For some enterprises, legacy applications dependent on hub-and-spoke connectivity architectures may complicate SDA adoption. For example, an app with legacy gating (e.g., IP-based identification) may not work in an SDA environment where authentication is tied to the user.
And then there’s security: IT leads looking to SDA should assess their own practices and benchmark legacy-system performance and risk against SDA alternatives.
SDA may not be for everyone, but it can serve as a scalable, secure alternative to VPNs.
- - - - - - - - - - - - - - - - - - - - - - - - -
Patrick Foxhoven is the Zscaler Chief Information Officer and Vice President of Emerging Technologies