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\u2019t that the case for security? The short answer is that enterprises have been chasing acronyms and not solutions.\nAcronym-chasing comes about because by nature, security is hard to plan for. The average network expert finds out there\u2019s 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\u2019re told is SASE without SD-WAN. In any event, what happens is that there\u2019s pressure to add this new thing on, and that creates another layer of protection...maybe.\u00a0 Complication and cost? Surely.\n\nChasing 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\u2019re 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\u2019s fundamental property: addressing.\nYou can\u2019t have connections if you can\u2019t address the things being connected. The power to address is the power to hack. All of networking is about addressing, and it shouldn\u2019t 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.\nVPNs can reduce risk of intrusions\nLet\u2019s start with VPNs. The number of enterprises who don\u2019t 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.\u00a0 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.\nVPNs actually provide pretty good protection against outside intrusion, but they have one problem\u2014the 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.\u00a0 SD-WAN, by adding any site with internet access to the corporate VPN, reduces that risk.\nOr rather it reduces that particular risk. But hacking in from the outside isn\u2019t the only risk. These days, most security problems come from malware planted on a computer inside the company. There, from a place that\u2019s 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.\nWe 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\u2019t be routed on the internet. That means that something with a private IP address can\u2019t be reached outside the subnet, even by someone on the company VPN.\nPrivate IP addresses are widely used in container networking. Using them breaks up a data center into application-specific pieces, and application components that aren\u2019t 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 \u201cinterior\u201d components of the application are pulled off the attack surface, and security can focus on those components that are exposed for use. It\u2019s a great security strategy, but still not perfect. Fortunately, there\u2019s one final tool that a network can exploit, and it\u2019s one we\u2019ve already mentioned.\u00a0\nDecades 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\u2019t catch on directly, but it was one of the forces that gave rise to MPLS.\u00a0 We can exploit that concept of persistent flows to add a final dimension to network-based security.\nSD-WAN and virtual networks can offer network security\nIn 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\u2019s 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\u2019s an application running. If you know who\u2019s running it, or trying to, and who\u2019s 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.\n\nIf you\u2019re 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\u2019d have to plant it in a system that had the right to communicate with their target. It\u2019s hard to even know what systems that might be, so security is improved. It\u2019s improved even more if the network journals any attempts to access something that the user doesn\u2019t have a right to use.\nThe 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.