For a while now, we’ve spoken about the convergence of SD-WAN and security. Three years ago, the two domains were still very separate. Few, if any, of the SD-WAN evaluations we conducted factored in NGFW and IPS architectures. Today, considering how security will work with SD-WAN has become the norm for my clients, particularly with the widespread adoption of Gartner’s secure access service edge (SASE) architecture. Our WAN RFP template has an extensive security section, contact us for more current information.
Last week, we saw the epitome of security-SD-WAN integration — the inclusion of managed threat detection and response (MDR) into SD-WAN architectures. By building MDR into SD-WAN, the organization managing your SD-WAN architecture also manages your security infrastructure. Open Systems announced that it’ll be adding Microsoft Sentinel to its MDR service by year’s end. We also heard from Cato Networks about the differences between Integrated SIEM versus Inherent MDR.
The Insecurity of SD-WAN Appliances
Ironically, though, it was also last week that we once again heard about SD-WAN and security in a very different vein. Cisco patched a high-severity vulnerability in its SD-WAN software, a vulnerability that local attackers could exploit to inject and execute arbitrary commands with root privileges.
It’s not the first time that we’ve seen security problems with SD-WAN devices. In March, Cisco patched five other SD-WAN vulnerabilities. And in December, Citrix reported a vulnerability that would allow a remote, unauthenticated attacker to perform arbitrary code execution. This vulnerability has been detected in exploits in the wild.
In fact, as far back as 2017, we warned enterprises about the vulnerabilities in SD-WAN appliances. Here’s what we had to say:
The micro-services running in SD-WAN appliances are often sourced from third-parties. They may come from well-known security vendors with well-tested products, but could just as easily be open source components coded together by the vendor. Our findings showed that the latter was common with 80 percent having known Common Vulnerabilities and Exposure (CVEs), some more than a decade old.
Two concrete examples of what this can mean. In one instance, we found if attackers could SSH into a box, and that was certainly possible in some cases, they could create a race condition that rebooted the system. Normally, the IPS of a system should come up before the network, protecting the device. But in some cases, it’s the opposite: the network is first. This gives an attacker a brief window to insert a bug into the system, giving them full control over the box.
In another case, an outdated BIOS allowed us to reboot the device and launch malicious code from a USB key, creating a man-in-the-middle attack. The exploit would give the attacker visibility into all of the traffic through that appliance.
You can read the article here.
Before MDR, Check SD-WAN Security
You need to and should be evaluating SD-WAN and security together but before trusting your SD-WAN provider with advanced security be sure they’ve taken care of business at home and protect their own appliance from attack.
Here, the simpler the appliance the better. Fewer components mean fewer vectors to exploit. If the appliance uses open source or third-party components, check that they’ve been hardened. If the devices have gone through security testing, ask for the results. Regardless, the supplier should be keeping the SD-WAN solution updated to protect against new threats.
From our own experience, I can tell you there are significant differences in how SD-WAN vendors approach security both in terms of restricting access and inspecting content, as well as the security of the SD-WAN solutions themselves. If you need help, you know where to reach me.
You might also like:
SASE – Secure Access Service Edge
Managed Detection and Response: Integrated SIEM versus Inherent MDR
