SD-WAN: What’s the big deal for security leadership?
Rick Howard: Hey, everyone. Welcome back to "CSO Perspectives." We are just starting season 3, and I'm very much looking forward to what we're going to discover together. I picked four topics for this season that, typically, network defenders talk about on the fringe - SD-WANs, containers versus lambda functions, SOAR and orchestration.
Rick Howard: Now, you can see high-level conversations going on about these topics, but I wanted to dive into some detail about what they actually mean to the network defender community. And truthfully, I picked them because my knowledge of them was only just skin-deep. I wanted to invite the CyberWire's pool of subject matter experts to the Hash Table and see if they were as confused as I was about some of these ideas.
Rick Howard: So let's begin with SD-WANs, or software-defined networking in a wide area network. I have to be honest; I never understood the excitement around this subject. It wasn't until I went back and looked at the history of enterprise connectivity architecture that I began to understand the significance of it. It wasn't until I viewed SD-WAN technology through the same lens of DevOps and DevSecOps that it became obvious to me that something like SD-WAN was the logical next step for the network defender community.
Rick Howard: But if we're going to secure it, we would 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 SASE deployment, or secure access service edge deployment. But I'm way ahead of myself here. I think we need to start at the beginning.
Rick Howard: My name is Rick Howard. You are listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. On this show, I'm talking about why network defenders of all stripes should be paying attention to SD-WAN technology now, before it sneaks up on them in the future and bites them on the backside.
Rick Howard: In 1969, UCLA and the Stanford Research Institute established the first internet connection. As Andrew Blum would say in one of my favorite internet history books called "Tubes," the internet took its first breath that day. I love that line.
Rick Howard: Here is Blum reading from his book about that moment when the internet was born. He is talking about Leonard Kleinrock, one of the founding internet fathers, and the connection machine that he helped build and install called the IMP, or interface message processor, at Stanford University.
(SOUNDBITE OF ARCHIVED RECORDING)
Andrew Blum: (Reading) He pulled out the original log recording the moment when UCLA's IMP first connected with IMP No. 2 installed at Stanford Research Institute late on the Wednesday evening of October 29, 1969. The notebook was tan, with IMP Log written in sloppy marker on its cover. You can see it on Kleinrock's website, of course.
Andrew Blum: That's the most precious document on the internet, he said. There was someone putting together these archives now, and they shoot me every time I touch this. They're the ones who gave me this box.
Andrew Blum: He opened it up and began to read the entries. SRI called. Tried debug test, but it didn't work. Dan (ph) pushed some buttons.
Andrew Blum: The important one is here, October 29. I shouldn't be touching these pages, but I can't resist. There it is, in blue ballpoint pen, the words running over two lines and besides, the time code 22:30 was written. Talked to SRI host to host. It is the sole documentary evidence of the ARPANET's first successful transmission between sites, the moment of the internet's first breath.
Rick Howard: In the late 1970s, back when I was just a wee lad going to college, the internet still wasn't really a thing yet - at least not for us common folk. But if you wanted to connect two mainframes together across long distances not on the same network, the X.25 protocol was the way to go.
Rick Howard: It was and is complex but offered the first usable packet-switching technique that network operators could use over leased lines. It has since gone out of favor to be replaced by TCP/IP and BGP, but it is still in use today, mostly for ATM machines and in countries where the telecommunications infrastructure is old.
Rick Howard: By the mid-1980s, we were looking for more bandwidth. The telecommunications providers started offering faster connection lines, T1s and T3s, using proprietary bridge equipment at each end that eventually we replaced with routers.
Rick Howard: By the 1990s, network managers could use a shared frame relay service if they couldn't afford their own T1 or T3 lines. They basically shared the pipe with other customers, and they can use IPsec VPNs to encrypt site-to-site connections.
Rick Howard: By the 2000s, the much-improved Multiprotocol Label Switching overlay technique, or MPLS for short, became the successor to frame relay. Also, at the same time, 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.
Rick Howard: MPLS networks are essentially dedicated circuits. They are reliable and provide high quality. They are also expensive because you are 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.
Rick Howard: By 2020, though, the entire IT community has been in the process of moving those very same services to the cloud, either through SaaS services like Gmail or 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 doesn't make 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.
Rick Howard: The problem with broadband connections, though, is that even though they are cheaper by far compared to the MPLS circuits, they are in no way as reliable. They are not dedicated, for one thing, and the available bandwidth goes up and down depending on internet congestion.
Rick Howard: If you use an application that has to be reliable, running it through a single broadband connection may not be the best solution. Like, for example, stock traders may not find the solution acceptable if their competitive edge depends on them knowing something sooner than somebody else. This is where SD-WAN comes in.
Rick Howard: SD-WAN is a software control layer that sits on top of your collection of WAN connections. Let's say you have four MPLS connections at your local headquarters and two broadband connections. SD-WAN is a control layer that lets network managers 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.
Rick Howard: 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 them with cheaper but less reliable broadband connections.
Rick Howard: Network managers can buy hardware from SD-WAN vendors and run their software or deploy 1U computers off the shelf and run open-source SD-WAN software or anything in between.
Rick Howard: Since the key component is the software, SD-WAN implementations are a perfect fit for DevOps and DevSecOps shops. Further, big content providers, like Amazon, Microsoft and Google, have already established peering relationships with local internet service providers around the world. It is quite possible that network managers could install multiple broadband connections from their SD-WAN environments straight into the content providers' networks that they regularly use.
Rick Howard: 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 in their network management budget. It also gives them more control and flexibility over how they direct network traffic flows than they have ever had before. You can see why they are so excited about it. That is the good news.
Rick Howard: The bad news is that with the SD-WAN control plane dynamically redirecting network traffic all over the place, ensuring that all that traffic goes through a standard security stack somewhere in the pipeline could obviate all the cost savings.
Rick Howard: If security managers have to replicate the security stack at every internet exit point and assume the burden of care and feeding of those devices in a 24x7 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 is the reason that 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.
Rick Howard: A security platform that executes all of your zero trust policies and automatically updates its own preventive 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 are 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.
Rick Howard: That said, an even lesser complex solution would be to embrace SASE, or secure access service edge.
Rick Howard: I have discussed the architecture of SASE before in the very first episode of this podcast series - season 1, episode 1. You should go back and check it out.
Rick Howard: But SASE is the perfect solution for small and midsized businesses today who 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.
Rick Howard: The genius of SASE is that it flips the best practice of security deployments on its head by adopting the shared responsibility model of the cloud. Instead of the network managers and security managers running the deployment and day-to-day operations of the security stack and the SD-WAN configuration within their organization, they pay a cloud provider to do it.
Rick Howard: The first hop out of every LAN and even every employee's personal device when they're sitting in 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 through the SD-WAN layer. The SASE vendor manages all of 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.
Rick Howard: SD-WAN technology is a network manager's dream. Security managers, on the other hand, looking to protect those new architectures might have some issues, though.
Rick Howard: They can look to the security platforms of the big vendors, like Palo Alto Networks, Fortinet and Check Point, to help here because many of them are 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 towards the SASE model because for the first time in my career, the benefits of moving to a cloud provider - a SASE cloud provider - in this case is to provide better security, and that is a good thing, indeed.
Rick Howard: And that's a wrap. If you agree or disagree with anything I said, hit me up on LinkedIn or Twitter, and we can continue the conversation there. Next week, I've invited our pool of CyberWire's experts to sit around the Hash Table with me to discuss their deployments of SD-WAN technology. You don't want to miss that.
Rick Howard: The CyberWire's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design and original score. And I am Rick Howard. Thanks for listening.