Basing network security on IP addressing: Would it be worth it?

Why is it that over 90% of enterprises tell me that they expect to spend more on security over the next three years, and almost 60% say they expect to spend less on networking? We obviously think that network technology is getting more efficient, more competitive. Why isn’t that the case for security? The short answer is that enterprises have been chasing acronyms and not solutions.

Acronym-chasing comes about because by nature, security is hard to plan for. The average network expert finds out there’s an issue because some higher-up reads or hears about a breach. Maybe they do a quick search, and they find out that what they really need is SASE. Or maybe they need SSE, which we’re told is SASE without SD-WAN. In any event, what happens is that there’s pressure to add this new thing on, and that creates another layer of protection…maybe.  Complication and cost? Surely.

Chasing acronyms is bad, but there may be a lesson in the latest security equation: SSE equals SASE minus SD-WAN, right? Well, maybe the minus-SD-WAN piece is where we’re going wrong, because a lot of our security cost and complexity problems could be solved by letting the network play a role in its own protection, and we actually know how to do that. In fact, it leverages networking’s fundamental property: addressing.

You can’t have connections if you can’t address the things being connected. The power to address is the power to hack. All of networking is about addressing, and it shouldn’t be a surprise that addressing could play a major role in security. Tools like IPvirtual private networks, private IP addresses, and (yes) virtual networks and software-defined WANs are widely available but not always effectively used.

VPNs can reduce risk of intrusions

Let’s start with VPNs. The number of enterprises who don’t use IP VPNs in some form is statistically insignificant. An IP VPN is a form of what used to be called a closed user group, a community range of addresses that can freely communicate but are isolated from the internet unless their addresses are explicitly exposed.  However, all VPN users can reach other VPN users, where private IP addresses can isolate one set of users/applications from others, even within a company.

VPNs actually provide pretty good protection against outside intrusion, but they have one problem—the small sites. MPLS VPNs are expensive and not always available in remote locations. Those sites often have to use the internet, and that can mean exposing applications, which means increasing the risk of hacking.  SD-WAN, by adding any site with internet access to the corporate VPN, reduces that risk.

Or rather it reduces that particular risk. But hacking in from the outside isn’t the only risk. These days, most security problems come from malware planted on a computer inside the company. There, from a place that’s already on whatever VPN the company might use, the malware is free to work its evil will. One thing that can help is private IP addresses.

We use private IP addresses literally every moment of every day, because virtually all home networking and a lot of branch-office networking are based on them. There are a series of IPv4 and IPv6 addresses set aside for use within private subnetworks, like your home. Within the private subnet, these addresses work like any IP address, but they can’t be routed on the internet. That means that something with a private IP address can’t be reached outside the subnet, even by someone on the company VPN.

Private IP addresses are widely used in container networking. Using them breaks up a data center into application-specific pieces, and application components that aren’t supposed to be accessed except by other components are protected. What is accessible is explicitly under your control because you have to expose a component to the internet or your VPN in order to make it available. If enterprises build their resource pools using private IP addresses, all the “interior” components of the application are pulled off the attack surface, and security can focus on those components that are exposed for use. It’s a great security strategy, but still not perfect. Fortunately, there’s one final tool that a network can exploit, and it’s one we’ve already mentioned. 

Decades ago, a startup called Ipsilon developed a model of an IP network where edge devices identified persistent flows and mapped them to virtual circuits. The idea, which was designed to promote the use of ATM (remember that?) in IP networks, didn’t catch on directly, but it was one of the forces that gave rise to MPLS.  We can exploit that concept of persistent flows to add a final dimension to network-based security.

SD-WAN and virtual networks can offer network security

In IP network terms, a persistent flow is a session, an end-to-end relationship between two entities that lasts for a period of time. Most of our applications communicate via sessions, and it’s possible to identify sessions by looking at the packet headers. The nice thing about that is that if you know what a session is, you know there’s an application running. If you know who’s running it, or trying to, and who’s allowed to run it, you can permit the good and block the bad. Some of the SD-WAN and virtual-network products and services out there are session-aware, and this can add a critical set of new network security capabilities. The SSE products now emerging can also sometimes add session awareness, but as another of those pesky security layers, not as part of the network itself.

If you’re a hacker planting malware to worm into things, a data center or set of cloud applications that can freely talk to each other is a nice breeding ground. If there are limits on who is allowed to talk with a particularly critical application, then a hacker would have to do more than plant malware, they’d have to plant it in a system that had the right to communicate with their target. It’s hard to even know what systems that might be, so security is improved. It’s improved even more if the network journals any attempts to access something that the user doesn’t have a right to use.

The strategy has issues, of course. For it to work, enterprises have to take the time to maintain accurate policies on who is allowed to connect with what. Is that more effort than managing a lot of security layers? More than dealing with a security breach that could have been prevented? Think about it.