How come over 90% of companies tell me 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 believe that network technology is becoming more efficient, more competitive. Why isn’t this the case for security? The short answer is that companies are looking for acronyms, not solutions.
The search for acronyms arises because, by nature, security is difficult to plan. The average network expert finds out there’s a problem because a superior reads or hears about a breach. Maybe they do a quick search and find that what they really need is SASE. Or maybe they need SSE, which we’re told is SASE without SD-WAN. Anyway, what happens is there’s a push to add this new thing, and it creates another layer of protection…maybe. Complication and cost? Surely.
Acronym hunting is bad, but there may be a lesson in the last security equation: SSE equals SASE minus SD-WAN, right? Well, maybe the minus SD-WAN is where we’re wrong, because a lot of our security cost and complexity issues 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 exploits the fundamental property of the network: addressing.
You can’t have connections if you can’t address connected things. The power to address is the power to hack. All networking is about addressing, and it should come as no surprise that addressing can play a major role in security. Tools such as IP Virtual Private Networks, Private IP Addresses, and (yes) Software Defined Virtual Networks and WANs are widely available but not always used effectively.
VPNs can reduce the risk of intrusions
Let’s start with VPNs. The number of companies that do not use IP VPNs in one form or another 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 communicate freely 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 offer pretty good protection against outside intrusions, but they have one problem: small sites. MPLS VPNs are expensive and not always available in remote locations. These sites often have to use the internet, which can mean exposing applications, which increases the risk of hacking. SD-WAN, by adding any site with Internet access to the corporate VPN, reduces this risk.
Or rather it reduces this particular risk. But hacking from outside is not the only risk. Today, most security problems come from malware implanted on a computer inside the company. There, from a location already on any VPN the company might use, the malware is free to exert its ill will. One thing that can help is private IP addresses.
We literally use private IP addresses every moment of every day because virtually all home networks and many branch office networks are based on them. There are a series of IPv4 and IPv6 addresses reserved for use in private subnets, like your home. Within the private subnet, these addresses function like any other IP address, but they cannot be routed over the Internet. This means that something with a private IP address cannot be reached outside the subnet, even by someone on the corporate VPN.
Private IP addresses are widely used in container networks. Their use divides a data center into application-specific parts, and application components that are only meant to be accessible by other components are protected. What is accessible is explicitly under your control because you must expose a component to the internet or your VPN in order to make it available. If companies create their resource pools using private IP addresses, all “inner” application components are removed from the attack surface, and security can focus on components that are exposed to use. It’s a great security strategy, but not yet perfect. Luckily, there is one last tool a network can leverage, and it’s the one we’ve already mentioned.
Decades ago, a startup called Ipsilon developed an IP network model where edge devices identified persistent streams and mapped them to virtual circuits. The idea, which was to promote the use of ATM (remember it?) in IP networks, did not catch on directly, but it was one of the forces that gave birth to the MPLS. We can leverage this concept of persistent streams to add a final dimension to network-based security.
SD-WAN and virtual networks can provide network security
In IP network terms, a persistent stream is a session, an end-to-end relationship between two entities that lasts for a certain amount of time. Most of our applications communicate via sessions, and it is possible to identify sessions by looking at packet headers. The good thing about this is that if you know what a session is, you know an application is running. If you know who is running it, or trying to run it, and who is authorized to do so, you can allow the good and block the bad. Some of the SD-WAN and virtual network products and services are session-aware, which can add a critical set of new network security features. Emerging SSE products can also sometimes add session awareness, but as another one of those pesky security layers, not as part of the network itself.
If you’re a hacker who installs malware to infiltrate things, a data center or set of cloud applications that can communicate freely with each other is a good breeding ground. If there are limits on who is allowed to speak with a particularly critical application, then a hacker should do more than plant malware, they should plant it in a system that has the right to communicate with their target. It is even difficult to know which systems it is, so security is improved. It’s even better if the network logs any attempt to access something the user doesn’t have permission to use.
The strategy has problems, of course. For this to work, companies need to take the time to maintain clear policies on who is allowed to connect with what. Is it more effort than managing a lot of layers of security? More than dealing with a security breach that could have been avoided? Think about it.
Copyright © 2022 IDG Communications, Inc.