Eliminate Risky Attack Surfaces

Many moons ago, when the world wide web was young and the nerd in me was strong, I remember building a PC and setting it up as a web server. In those exciting, pioneering days, it was quite something to be able to have my very own IP address on the internet and serve my own web pages directly from my Apache server to the world. Great fun.

I also remember looking at the server logs in horror as I scrolled through pages upon pages of failed login, and presumably hacking, attempts. I’d buttoned things up pretty nicely from a security standpoint, but even so, it would only have taken a vulnerability in an unpatched piece of software for a breach to occur, and from there, all bets would have been off.

Even today, many internet service providers will let you provision your own server, should you feel brave enough. Of course, the stakes were not high for me at home, but knowing what we know now about the growth of ransomware attacks and how AI is facilitating them, no organization would dare do such a thing in 2024.

Back then, I’d created an obvious and open attack surface. Tools were (and still are) readily available to scan IP address ranges on any network and identify open ports. In my case, ports 22, 80 and 443 were open to serve web pages and enable me to administer my server remotely. Every open port is a potential conduit into the heart of the hosting device, and so these should be eliminated where possible.

Open ports, VPNs, and business

Since online remote working became a real possibility in the early 2000s, organizations have tried to protect themselves and their employees by adopting VPN technology to encrypt traffic between a remote device and a VPN concentrator at the head office, allowing employees access to services like email, file and print servers. Even when these services became cloud-based solutions like Gmail and DropBox, many organizations pulled that traffic across a VPN to apply IT access policies. Not only did this often lead to an inefficient path from a remote worker to their applications, it also presented a serious security risk.

As the performance and dependability of the internet grew, we also saw the advent of site-to-site VPNs, which made for an attractive alternative to far more expensive circuit-based connections that had been so prevalent such as MPLS. A vast number of organizations continue to rely on a virtual wide area network (WAN) built on top of VPNs. Unfortunately, as the old saying goes, there’s no such thing as a free lunch.

Every VPN client or site using the internet as its backbone needs an IP address to connect to, an open port to connect through, and, well, you can see where this is going. Not every VPN solution has an active flaw, just as—luckily—my Apache server didn’t at the time I was running it. That said, software is fallible, and history has demonstrated this fact in numerous instances in which vulnerabilities are discovered and exploited in VPN products. Just last month, a fatal flaw was discovered in Ivanti’s VPN services, leaving thousands of users and organizations open to attack. Hackers are scouring day and night for vulnerabilities like these to exploit—and AI is only making their lives easier.

“without proper configuration, patch management, and hardening, VPNs are vulnerable to attack” from Securing IPsec Virtual Private Networks by the National Security Agency (NSA)

Zscaler is different

The Zscaler Zero Trust Exchange™ works in a fundamentally different way—no VPN is required to securely connect. Instead, connections via the internet (or even from within a managed network) are policed on multiple levels. An agent on your device creates a TLS tunnel to the Zscaler cloud, which accepts connections only from known tenants (or Zscaler customers). This tunnel is mutually authenticated and encrypted between the agent and the Zscaler cloud. The individual and their device(s) must additionally be identified as part of the process. In short, it’s not possible to simply make a TLS connection to Zscaler.

Once an approved user from a known customer with a recognized device connects to Zscaler, they’re still prevented from moving laterally over the network, as is the case with VPNs. With Zscaler, there is no IP range to which the user has access. Instead, every connection attempt has to be authorized, following the principles of zero trust. A user has access only to the applications for which they’ve been authorized. With this framework, even if an organization were to be successfully attacked,  the blast radius would be limited. The same cannot be said for network-based security.

Here’s the bottom line: VPNs and the firewalls behind them served us well for a long time, but the challenges that come with maintaining a security posture built on these legacy technologies are so great that it’s now a material business risk to use them.  You need only to turn the news on for a few minutes to be reminded of this. Networks were built fundamentally to enable connectivity, and adding security to these networks is an uphill battle of putting the right obstacles in the way of that connectivity. This is why more and more public bodies and private organizations are turning this idea on its head and embracing a zero trust architecture that provides access for only an approved entity, on an approved device, to the applications to which they are entitled.

At Zscaler we have built tools to help you assess the potential risk your own organization faces, some of which are free to access. Test your own defenses by visiting https://www.zscaler.com/tools/security-assessment and when you’re ready to learn more, get in touch!