SD-WAN security benefits go beyond the obvious

Some companies say they allocate more money to network security than they do to their networks overall. Even for those that don't hit that level of investment, most earmark a pretty respectable piece of their networking budget to security. So when someone claims a hot new technology like software-defined WAN could totally change the way we think about security, it's going to get attention. But is the spotlight warranted? Can network operators capitalize on SD-WAN security benefits?

SD-WAN is best known as a way to exploit internet connectivity to extend the corporate VPN to sites too small to afford MPLS VPNs or where MPLS VPNs are simply not available. SD-WAN can also connect cloud applications and components to the VPN without requiring the VPN owner to pay special connection fees to a cloud provider.

But you don't hear much about SD-WAN and security because security isn't the primary feature driving most implementations. Most SD-WAN vendors offer support for prevailing IP security standards while others have partnered with security vendors to integrate some proprietary features. Still, there are some additional SD-WAN security benefits important to know.

Permissive connectivity and what an overlay can do

An IP network, including both the internet and corporate VPNs, is based on a permissive connectivity model. Each user and resource on these networks is presumed to be connectable, which certainly makes it easier to set up networks, but this connectivity lies at the heart of problems people face when securing their networks. The truth is that even on a corporate VPN, well over 95% of all possible connections should be forbidden. Security products and practices are profiting by taking back the access that IP usually provides by default.

SD-WAN is an overlay network technology. Although specific details differ by vendor and product, an SD-WAN provides a second network that logically rides on top of IP with its own mechanism for routing packets to make connections among users and resources. In the vast majority of the more than two dozen SD-WAN products and services commercially available, this second level of routing does exactly what IP routing does -- creates the same permissive connectivity.

But it wouldn't have to. In theory, SD-WAN routing could be made explicit, meaning only the connectivity that was actually authorized would be permitted. Think of it as meaning that unless the combination of source and destination address is in a forwarding table, nothing gets forwarded. If you know a destination address but your own address isn't linked with it, you can't exchange traffic at all. That destination would look like the proverbial "bit bucket" where poorly addressed packets go.

Chronicling invalid connection attempts

Another feature of SD-WAN could have its own impact on security. Since the SD-WAN knows what's authorized in terms of connectivity, it also knows when someone tries an unauthorized connection. By journaling invalid connection attempts, an SD-WAN with explicit forwarding can warn administrators that either somebody is trying to access something without permission or that malware has been introduced and is using the system as a proxy for evil deeds. This kind of journaling could even detect and prevent denial-of-service attacks.

In a CIMI survey, one respondent suggested explicit forwarding and journaling of invalid connection attempts would, in combination, address over 90% of all the security issues the organization faced and reduce network security costs by over 75%. Since it would be possible to make an SD-WAN deployment overlay every IP network -- even the MPLS VPNs -- an SD-WAN could provide uniform protection for a company.

Why aren't SD-WAN security benefits more widely known?

Given the possible benefits, why haven't SD-WAN's security capabilities taken off? Moreover, why haven't service providers talked up SD-WAN security? The first reason is most SD-WAN implementations can't do what we've described here. In fact, only about 10% can, which means that service providers that made SD-WAN decisions without looking at the technique's unique security features probably didn't get a product that supports those features.

The second reason is that explicit forwarding requires forwarding policies, and it takes time and effort to provide them. It's obviously critical to define what connections should be permitted, lest you allow something that shouldn't be or prohibit valid connections. Also, just how users would prepare for, then adopt, explicit connection policies isn't widely known or even discussed. SD-WAN sellers -- including network operators -- aren't eager to get into the education business.

As cloud-native applications develop and go into production, SD-WAN will be able to connect and secure them through all their scaling and redeployment.

The third reason is SD-WAN explicit forwarding isn't the total answer to security. Malware infecting a system authorized to connect to a resource could still cause harm or steal information if it could get past application or database safeguards. Thus, access security on applications and information resources is often still required. A disgruntled or careless employee with authorized connectivity could do the same thing. This is why SD-WAN can reduce, but not eliminate, additional spending on security.

The last reason and perhaps the best is the fact that SD-WAN is promoted as an MPLS VPN replacement creates operator concerns that getting on the SD-WAN bandwagon for any reason will put VPN revenues at risk.

But, over time, the impact of these negative forces will decline. Competition inevitably levels the feature playing field in any product space and so eventually SD-WAN vendors will widely support explicit connectivity and journaling. Tools to help buyers set their forwarding policies will emerge and mature, and security vendors will begin to offer on-top-of-SD-WAN tools to supplement explicit-connection security.

Operators, finally, will recognize that a competitive SD-WAN service steals all their VPN revenue, while one of their own steals only the net of VPN-to-SD-WAN pricing. Some of that loss can be offset by incremental security revenue, too.

It's also true that a powerful positive driver fueling the rollout of these SD-WAN security benefits is coming from the cloud. As cloud-native applications develop and go into production, SD-WAN will be able to connect and secure them through all their scaling and redeployment. Network operators that offer cloud services, or even use them internally for things like network functions virtualization, will need SD-WAN's explicit connection control and security for themselves and their customers -- and they'll get it.