If VPN is the answer, perhaps you should be asking a different question
- 21 August, 2019 13:20
With mobile working gaining popularity, organisations have had to figure out how to provide secure remote access to centralised IT infrastructures. In many cases, this has been achieved through the use of virtual private networks (VPNs).
While they look good on paper, VPNs might not be the solution that CIOs and IT departments believe them to be. Users often find them slow and inconvenient—and they’re not as secure as you think.
This creates an IT conundrum. A way must be found to keep staff productive while securing corporate assets against cyberthreats. But how can this be achieved without compromise?
One option is to stack more security appliances at the firewall. However, this approach will be complex to manage and expensive to scale. It's also a reactive approach as network security will only be as good as the last hardware or patch upgrade.
Rethinking the challenge
Instead of placing all the mobile security eggs in the VPN basket, it’s time for a radical rethink of corporate networking. Instead of trying to prevent local internet breakouts, what if you simply secured them? This approach would certainly improve the experience for users, and probably their productivity as well.
Secure local breakouts can be achieved by using a security approach called software-defined access (SDA). The development of this technology can be traced back to work undertaken by Google in 2011. Back then, the company recognised 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 were becoming limited.
The reasons were clear. Routing traffic through distant firewall gateways slowed performance and impacted user experience. At the same time, hardware-based security appliances were expensive and not a particularly scalable way to address threats. Also, any breach offered up the entirety of network assets because when you cross the moat, you have the run of the entire castle.
Google, in conjunction with other technology firms, began developing the concept of SDA. The idea is straightforward: you let users connect directly to resources from wherever they are and wherever those resources may be (in the data centre, on the internet, or in the cloud), thus bypassing the corporate network entirely.
The question then becomes, how do you secure this 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 each user.
In simple terms, SDA is a security model that enables users to connect to resources directly without first accessing a corporate network. With user and context-based policies, SDA defines a secure perimeter around each user's traffic, effectively creating a network of one.
Rather than 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 even on-premises.
Implementing SDA requires a rethink—not just of the corporate network, but of trust itself. Trust is no longer a currency to be traded, and SDA assumes a default-deny posture with each potential interaction, whether the interaction occurs inside or outside the company.
Google BeyondCorp is one flavour of such zero-trust implementations. Forrester created and popularised the zero-trust framework and Gartner took it even further, placing a zero-trust approach on a continuum in its Continuous Adaptive Risk and Trust Assessment (CARTA) model.
Thanks to these developments, organisations large and small can realise SDA’s tangible benefits. These include distributed-workforce enablement, reduced LAN/WAN costs, facilitated cloud migration and non-standard device access.
However, it’s important not to view SDA as the answer for everything. Within some organisations, legacy applications that are dependent on hub-and-spoke connectivity architectures may complicate SDA adoption.
There is also the question of effective security. When IT teams are assessing the suitability of SDA, they need to examine their own practices and benchmark legacy-system performance and risk against SDA alternatives.
Clearly, SDA may not be the answer for all organisations. However, with correct planning, deployment, and security, it can become a welcome alternative to VPNs.