CSO Perspectives is a weekly column and podcast where Rick Howard discusses the ideas, strategies and technologies that senior cybersecurity executives wrestle with on a daily basis.
SD-WAN: What’s the big deal for security leadership?
I have to be honest. I never understood the excitement around software-defined networking in a wide area network, or “SD-WAN,” for short. It wasn’t until I went back and looked at the history of enterprise connectivity architecture that I began to understand its significance. Likewise it wasn’t until I viewed SD-WAN technology through the same lens of DevOps and DevSecOps that it became obvious to me something like SD-WAN was the logical next step. But if you wanted to secure it, you’d need to jump through a lot of network configuration hoops and take on even more technical debt in the process. The truth is that to really get the benefits that SD-WAN promises in a secure manner that doesn’t break your technical debt bank, you really need to couple it to a secure access service edge (SASE) deployment. But I’m way ahead of myself here. Let’s start with some enterprise connectivity history.
Enterprise connectivity: a timeline.
1970s and 1980s: X.25
X.25 networks provided connection-oriented services over phone or leased lines and were popular for remote mainframe terminal access.
1980s: DS0/T1/T3 Lines
To connect local area networks (LANs) that were not in the same location, network managers used point-to-point leased lines using remote bridges at each end. Later, they would swap the bridges for routers. Connection speeds varied:
- DS0: 56 thousand bps
- T1: 1.5 millions bps
- T3: 45 million bps
1990s: Shared Frame Relay and IPSec
Network managers used Frame Relay services that ran between 64 thousand bps to 1.5 million bps, depending on the congestion of the shared line. They could use IPSec VPNs over Frame Relay lines to encrypt site-to-site connections.
2000s
The improved Multiprotocol Label Switching (MPLS) overlay technique becomes the successor to Frame Relay.
Carriers deployed the last mile to home users and small business with broadband. It allowed the signal in one line to be split between telephone and internet. It provided relatively cheap internet access to home and business users but with lesser quality compared to MPLS.
The Transition to SD-WAN.
MPLS networks are essentially dedicated circuits. They’re reliable and provide high quality. They’re also expensive because you’re paying for dedicated lines and proprietary equipment on each end. They made sense in the early 2000s because we all needed to connect our office buildings to our remote data centers to get access to our email servers, database servers, and file servers. By 2020, however, the entire IT community had been in the process of moving those very same services to the cloud, either through SaaS services like Gmail and Office 365 or through virtual services that we run ourselves in one or more of the big cloud providers.
At some point on this journey, it no longer makes sense to maintain expensive MPLS circuits when all we really need is to provide each remote site access to the internet at cheaper broadband prices. But the problem with broadband connections is that, even though they are cheaper by far compared to MPLS circuits, they’re in no way as reliable. They’re not dedicated for one thing, and the available bandwidth goes up and goes down depending on internet congestion. If you’re running an application that has to be reliable, running it through a single broadband connection may not be the best solution. For example, stock traders may not find this solution acceptable if their competitive edge depends on their knowing something sooner than somebody else. This is where SD-WAN comes in.
SD-WAN is a software control layer that sits atop your collection of WAN connections. Since most organizations will not eliminate MPLS connections completely for lots of reasons, the idea is to reduce the set as much as possible and supplement with cheaper but less reliable broadband connections. The SD-WAN layer allows network managers to prioritize certain traffic over others, let’s say the stock trader’s network traffic over the cafeteria’s web menu traffic, and allows the system to dynamically choose which internet connection is the fastest out of all the internet connections in the system. Network managers can buy hardware from SD-WAN vendors and run their software, deploy 1u computers-off-the-shelf and run open source SD-WAN software, or anything in between. Since the key component is the software, SD-WAN implementations are a perfect fit for DevOps and DevSecOps shops.
Furthermore, big content providers like Amazon, Microsoft, and Google have already established peering relationships with local internet service providers around the world. It’s quite possible that network managers could install multiple broadband connections from their SD-WAN environments straight into the content provider networks they regularly use.
If network managers get the mix of MPLS circuits, broadband internet connections, and links to content providers right, a deployed SD-WAN system could provide significant savings to their network management budget. It would also give them more control and flexibility over how they direct network traffic flows then they’ve ever had before. You can see why they’re so excited about it. That’s the good news.
The bad news is that with the SD-WAN control plane dynamically redirecting network traffic all over the place, ensuring that all such traffic goes through a standard security stack somewhere in the pipeline could obviate all the cost savings. If security managers have to replicate the security stack at every internet exit point, and assume the burden of those devices’ care and feeding in a 24/7 environment, all the money saved in the SD-WAN deployment will be paid to the security vendors in the stack and the employees you will need to run the system. It’s the reason some of the big security platform vendors like Palo Alto Networks, Fortinet, and Check Point have gobbled up a bunch of SD-WAN vendors. They see an opportunity in the merger of the security platform with SD-WAN functionality.
That might indeed be the solution that wins here. A security platform that executes all of your zero trust policies, automatically updates its own prevention controls across the intrusion kill chain for all known adversary playbooks, and handles all of your SD-WAN configuration needs is a powerful network and security apparatus. They’re expensive for sure, but by absorbing the functionality of homegrown SD-WAN networking gear and proprietary software into the security platform, the reduction in complexity the network manager gains might be worth it. That said, an even less complex solution would be to embrace SASE.
I’ve discussed SASE architecture before. It’s the perfect solution for small and mid-sized businesses today that don’t have the resources to manage complex network and security deployments. I believe it will be the model in, say, five years, that even large organizations will use to some extent. The genius of the secure access service edge is that it flips the best practise of security deployments on its head by adopting the shared responsibility model of the cloud. Instead of the network and security managers running the deployment and day-to-day operations of the security stack and the SD-WAN within their organization, they pay a cloud provider to do it. The first hop out of every LAN, and even every personal device of an employee sitting at Starbucks, is not to the internet but to the SASE vendor’s cloud network. The SASE vendor runs those connections through the security stack and SD-WAN layer. The SASE vendor manages all the complexity, and the customer gets the benefit. The SASE vendor keeps all of the hardware and software up to date and running while the customer manages the policy.
SD-WAN technology is a network manager’s dream. Security managers looking to protect those new architectures might have some issues though. They can look to the security platforms of the big vendors for help here because they’re all in the process of adding SD-WAN capability to their already powerful security platforms. To reduce the complexity even more though, the network defender community in general should be leaning toward the SASE model. For the first time in my career, the benefits of moving to a cloud provider—a SASE cloud provider—is to provide better security, and that is a very good thing indeed.
Notes.
“A Brief History of the Enterprise WAN: How little has changed in the last 15 years,” by Andy Gottlieb, Network World, 6 April 2012.
“Broadband history,” by Dani Warner, USwitch, 19 July 2018.
“Cybersecurity Innovation Starts Here,” Lee Klarich, Palo Alto Networks, 13 November 2019.
"MEF White Paper MEF 3.0 SD-WAN Services,” MEF, November 2019.
“MEF 3.0 SD-WAN Services & Certifications – Frequently Asked Questions,” by MEF.
“SD-WAN drives managed network services trends for 2020,” by Tom Nolle, CIMI Corporation, TechTarget, December 2019.
"SD-WAN Explained: The Ultimate Guide to SD-WAN Architecture,” by TechTarget.
“SD-WAN (Software-defined WAN),” TechTarget.
“SD-WAN vs. MPLS vs. Public Internet,” by Idan Hershkovich, CATO Networks, 28 February 2018.
“SD-WAN security explained,” by Ericka Chickowski, AT&T Business, 25 June 2020.
“SD-WAN - What it means for enterprise networking, security, cloud computing,” by Michael Cooney, Network World, 9 October 2019.
“The 6 Biggest SASE Buys of 2020 (So Far)” by Tobias Mann, SDxCentral, 26 August 2020.
“The Secret to SASE is the Right SD-WAN,” by Network World from IDG, 2020.
“What is MPLS: What you need to know about multi-protocol label switching,” by Neal Weinberg and Johna Till Johnson, Network World, 16 March 2016.
“What is SD-WAN and why do you need it? Quick Explainer Video,” by Drew Schulke, Dell, 18 October 2019.
“Why SD-WAN is the next breed of WAN optimization,” by Sean Michael Kerner, TechTarget.
“X.25 – What is X.25 Networks?” by Dinesh Thakur, Computer Notes.
“Your security stack is moving: SASE is coming,” by Rick Howard, CSO Perspectives, The CyberWire, 5 April 2020.