In a rush to capitalize on the SD-WAN market opportunity, some SD-WAN vendors seem to be playing fast and loose with their appliances.\nAt a recent customer site of ours, Nirvik Nandy, CISO of SD-WAN Experts and CEO of Red Lantern, a security and compliance consultancy, and I collaborated on a security analysis of SD-WAN architectures. We conducted penetration testing of several SD-WAN solutions, looking at\nthe appliances and cloud architectures. Details of how we tested and vendor results are necessarily confidential. However, I can share with you some of our overall findings about appliances \u2013 we\u2019ll get to the cloud at a later date.\nSD-WAN security: what it really means\nFirst, some context: SD-WAN vendors speak about their architectures as being secure and that\u2019s true to an extent. All SD-WAN solutions secure traffic in transit. But there\u2019s more to network security than protecting data against eavesdropping and wiretapping, which is why companies deploy next-generation firewall (NGFW), intrusion prevention systems (IPS), and more. \u00a0SD-WAN and security vendors have been addressing this need, integrating the functionality of one another into solutions that provide networking and security.\nBut none of those architectures speak to the security of the SD-WAN appliance. And checking the security of that appliance is critical. Vendors are asking you to trust them that they can provide firewalls, proxy servers, and more with comparable functionality and security as your existing devices. It\u2019s your responsibility to verify those facts.\nThe security of SD-WAN appliances is particularly important because of how we provide Internet access today. Until SD-WAN, there were far bigger concerns than an attacker physically accessing our Internet connectivity devices. The Internet points were centralized in a datacenter or server room. Physical access to the room was restricted through access cards, staffed 24x7, and often under video surveillance. \u00a0\nSD-WAN and Internet increase the risks of physically accessing appliances\nBut as we move from a single or limited set of centrally managed, secure Internet gateways to a very distributed set of internet gateways, the attack space grows. The routers, which SD-WAN appliances replace, are mature, battle-tested products. They\u2019re often deployed in a hub-and-spoke configuration. Compromising a branch office router, at best, provides access to the traffic between the branch office and the datacenter. Even then the attacker would need to find a way to exfiltrate the data through a closely monitored, centralized firewall.\nSD-WAN appliances are different, particularly when branches are connected directly to the Internet. SD-WAN devices are fully-meshed, which potentially means comprising one device can give attackers visibility into the traffic flow from across the company. And with direct Internet access,\u00a0attackers have a greater likelihood of exfiltrating data undetected.\nOur testing and findings\nTo uncover the vulnerabilities in appliances, we examined the security of the appliances from the bare metal on up. SD-WAN appliances often run on white-box servers, off the shelf server hardware, with microservices from various sources. Each of those microservices represent a potential point of attack. As such, you need to check everything from the chipset, BIOS, and firmware \u2014 \u00a0on up.\nVendors might dismiss this kind of analysis, assuring you that their appliances are secure. But our findings say otherwise.\nThe 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 latter was common with 80 percent having known Common Vulnerabilities and Exposure (CVEs), some more than a decade old.\nTwo 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\u2019s 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.\nIn 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.\n\u201cThese are emerging technologies by new companies and they have not paid the level of attention that a seasoned security person would pay to the entire operational model of security. Failure at any layer of the stack or any level exposes the organization to cyber incident (if detected) or data loss (if undetected).\u201d\nYour approach\nOf course, security threats must be prioritized. Exploits that can be launched remotely against many targets at once take priority over physical access, which can be deterred with a padlock.\nBut that\u2019s not an excuse for not investigating the security of your branch appliances. They often do sit in less sterile environments than centralized firewalls \u2014 \u00a0wiring closets accessed by multiple vendors or, let\u2019s be honest, an admin\u2019s desk.\nOur branch appliances are often exposed to \u201cinnocent\u201d threats, such as being inadvertently disabled by third-party sales engineer. And even worse, they can be exposed to truly sensitive data. Social and physical engineering attacks \u2013 used in combination with remote attacks \u2013 by threat actors may yield access to the secure environments. One thing\u2019s clear: if you going to rely on SD-WAN to security your enterprise be sure the SD-WAN appliance is secure.