Blog & News

A software-defined wide area network (SD-WAN) can be seen as a combination of a software-defined networking (SDN) technology and a Wide Area Network (WAN) using common connections such as the Internet or Multiprotocol Label Switching (MPLS), a routing technique often used by service providers. But how does an SD-WAN look like and what are its implications on security? And how do the initial steps for a security assessment look like? This article is about to clarify those questions and provides an SD-WAN security assessment checklist at the end.

Drawbacks in a traditional WAN

In a traditional WAN problems may occur because of the given components and architecture. Often there is a heterogeneous mix of different devices from several vendors. As the devices may use different proprietary protocols to communicate, administrating all of them might be difficult. Although there are management tools which try to centralize the administration and help to manage the WAN they are limited in their functionality. Moreover, if a device has reached its limit in computational power it will probably need to be exchanged entirely. A change of only the respective part, e.g., the CPU of a router is nearly impossible to handle. Therefore, increasing (or decreasing) hardware power is accompanied by maintenance windows and increased costs.

Properties of SD-WAN

A software-defined Wide Area Network (SD-WAN) has several advantages compared to a traditional WAN. It is more agile during the provisioning of new devices and more flexible for adjusting the network traffic. Another big advantage is the possibility to program the network through the use of Application Programming Interfaces (APIs). A direct connection between the application and network is established. Therefore, the behavior of a network device and the traffic flow in the network is handled by software which operates independently from the network hardware. In the end a fully programmable network enables the re-programmability of the network infrastructure instead of having to re-build it manually, e.g., by replacing hardware devices. A central management based on a so called controller is given. Therefore, administrators have a better overview of the network.

Basic components of an SD-WAN

In general there are two technologies behind a SD-WAN which are Network Functions Virtualization (NFV) and Software-defined Networking (SDN). NFV leverages standard IT virtualization technology to consolidate many network equipment types onto industry standard servers. That means instead of using many different expensive proprietary hardware devices only standard x86 servers are needed. On these servers full network devices like routers, switches or firewalls are running as virtual machines (VMs). A related concept to NFV is VNF. Virtual network functions (VNF) are only carrying out specific tasks like Network Address Translation (NAT) or Domain Name System (DNS) on a standard server instead of virtualizing complete devices. Therefore individual VNFs can be seen as the primary component of an overall NFV architecture, because for virtualization of a whole network device several virtualized network functions are required.

There is no single precise definition of the term SDN. Most definitions have in common to declare an SDN to be the physical separation of the network control plane from the forwarding data plane. Mostly, the control plane controls several devices. The following figure illustrates some differences between SDN and NFV.

The definition of an SDN also applies to a SD-WAN. An SDN and an SD-WAN therefore share the same concept but are used in different environments. The SDN started out in data centers whereas the SD-WAN is used in Wide Area Networks. It might seem that there is just a little difference between SDN and SD-WAN but regarding security there is a big difference whether a solution is used internally (in the own data center) or externally (maybe even over the Internet).

The purpose of the control plane is to make decisions regarding protocols such as routing, spanning tree, authentication, Simple Network Management Protocol (SNMP), etc., by performing computations on a CPU. This task is shifted to a dedicated device which is often called an SD-WAN Controller. Therefore, an SD-WAN Controller is the “brain” of the SD-WAN solution. The controller makes all decisions and instructs the SD-WAN Edge devices to act on these decisions.

The data plane usually runs on dedicated hardware ASICs which take control of the actual forwarding of the traffic such as Layer 2/3 Switching or MPLS Switching. Devices in an SD-WAN (physical or virtual) which are in charge of traffic forwarding are often called SD-WAN Edges as they are placed at the perimeter of the network, e.g., to connect branches to the main office. Their main purpose is the forwarding of traffic within the SD-WAN which is done over encrypted tunnels. Besides, SD-WAN Edges can be configured to act as enforcers of the security policy and to conduct WAN optimization tasks. For configuration of an SD-WAN Edge an automated process called Zero Touch Provisioning (ZTP) is used. Because of the ZTP process an SD-WAN Edge only needs to be powered on and connected to a LAN and a WAN port. The SD-WAN Edge device will automatically establish the required connections to get any necessary configuration e.g. for connecting the new branch to the main office.

Most SD-WAN solutions consist of several more components beyond an SD-WAN Controller and an SD-WAN Edge. Still, those two types of devices occur in nearly every solution. Nevertheless, the naming, the specific amount of various devices, and their exact task might differ from vendor to vendor. For instance there is most likely some kind of management plane in place since a central management is a key aspect of an SDN. The management plane consists of a service with a user interface such as a WebUI for the administrators to manage the network. The service can be called an SD-WAN Manager.

Additionally, other services like databases might be performed by the SD-WAN Manager. In case of multiple SD-WAN Managers it can be helpful to have an orchestration plane as well. A Service Orchestrator within that plane is used for the overall deployment of several SD-WAN Managers with their respective SD-WAN Controllers and SD-WAN Edges. In the following figure a basic overview of the SD-WAN components is shown.

The naming of the SD-WAN devices in this article is based on the work of MEF: MEF 3.0 SD-WAN

Current state of SD-WAN security

SD-WAN products are almost always in the early stages of development. A lot of open source projects are outdated or unsupported. Regarding the current state of security in SD-WAN solutions it can be stated that it is still a bleeding edge technology. Meaning that even service providers do not have much experience in implementing SD-WAN products. Therefore the main focus lies on the implementation of the functionality. Security is of secondary consideration.

Often there are only minor issues in the design (insufficient Role Based Access Control (RBAC), no Multi-Factor Authentication (MFA),…), but the actual implementation is frequently missing basic security features. Especially the web interfaces are prone to vulnerabilities. Moreover, there is a lot of potential for privilege escalation vulnerabilities when interacting with the devices via CLI or SSH. Another aspect to consider is the partly fast deliverance of patches by the vendors to fix vulnerabilities as well as broken functionalities. Often patches can not be applied that fast because their impact on the network stability needs to be tested first resulting in the use of outdated software in productive environments.

Because of the usage of rapidly evolving products additional issues occur. Regarding the (security) documentation it has to be noted that an incomplete documentation may arise during the implementation of a new SD-WAN because the product itself is still subject to changes and workarounds might be needed to fix broken functionalities. Therefore tasks such as performing a risk analysis can be difficult.

All in all the security in SD-WAN solutions can be considered in its infancy.

SD-WAN Security Assessment Checklist

The attack surface of a SD-WAN solution strongly depend on the actual implementation and use case. Since there is no standard SD-WAN solution every vendor-specific product or free and open source solution will be different. To address this issue the following proposals are formulated generically so that they can be applied to as much SD-WAN solutions as possible.

The SD-WAN New Hop Project released a checklist for an initial security assessment. The following checklist is based on their work.

Common

• What third-party components and libraries are used?
  • How secure are these?
  • Would a change in any external component be noticed?
  • Are the components used in their latest versions?
• Run host auditing tools (e.g. like lynis ) on each node and assess the hardening level.
• Run a host-based vulnerability scanner (e.g. vulners ) and assess the patch management level.
• If certificates are used, how are they managed?
  • Check the renewal process.
  • Are there revocation processes like Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) implemented?
  • Who issues the certificates? A third-party?
• Are there any out-dated versions of software used?
  • Search for known vulnerabilities and CVEs.
  • Why is the software outdated?
    • Missing patch management?
    • Instable patches by vendor?
• How is the network isolation / VPN segregation realized?
• Identify all publicly exposed components (Internet or e.g. cloud internal)
  • Scan these components with a vulnerability scanners (e.g. Nessus ).
  • Are the components scanned on a regular basis?
• If you have console or remote access, try to interact with the underlying OS (mostly *nix based).
  • Keep known CVE’s in mind.
• Are there any connections to legacy networks?
  • What data is transferred between the SD-WAN and the legacy network?
  • Check for any route redistribution (e.g., via BGP).
• If possible review the configuration of the components.
• What happens if direct changes to the configuration of a SD-WAN Edge are made e.g. by CLI?
  • Are the changes noted e.g. by the SD-WAN Controller and corrected?

Management

• Is there a security monitoring?
  • What happens in case of a security event or incident?
• What operational processes are in place?
• How is the configuration management realized?
  • Who is able to make changes to the configuration?
  • Are changes to the configuration logged?
  • Is the configuration management documented?
• Is a vulnerability and incident management process established?
  • What happens in case of an incident?
• How are the requirements on availability? Is the fail-over process tested and documented?
• How is change and patch management realized?
• Is there a provisioning and de-provisioning process in place and documented?
• Is there a appropriate backup process in place?

Architecture

• Is a vendor-controlled cloud management interface used within the architecture?
• Are the devices physical or virtual?
  • Check for missing secure elements like Trusted Platform Modules (TPMs) or preinstalled certificates on virtual devices.
  • In case of a physical device check for the physical security.
• Identify all APIs or API middleware.
  • Check the APIs for possible abuse.
  • How is authentication implemented?

Zero Touch Provisioning

• How does a network device get its initial configuration?
  • Are there any differences between virtual and physical devices?
• How does a network device discover a controller, orchestrator and other entities?
• How do network devices, the controller, and the orchestrator authenticate each other?
• How is trust provisioned and what mechanisms are used? One-time tokens, X.509 certificates, login and password, pre-shared keys?
• How do re-discovering or re-joining mechanisms work?

Cryptography

• Which cryptographic protocols and implementations are used on the data plane?
• Which cryptographic protocols and implementations are used on the control plane?
• Is authenticated encryption with associated data (AEAD) ciphers supported?
• How is the key management implemented?
• How consistent are the security levels of the various protocols and primitives?
• Look for legacy primitives like DES, 3DES, RC4, MD5, SHA1 or custom primitives.
• Is it possible to control cryptographic mechanisms (e.g., enable TLS 1.3 only, disable unwanted ciphers, etc.)?
• Run a TLS scanner (e.g., testssl.sh , SSL Labs server scanner , sslyze , etc.) against TLS-enabled interfaces and assess the results.
• Run an SSH scanner (e.g., ssh_scan ) against SSH-enabled interfaces.
• Which type of Public Key Infrastructure (PKI) is used?
  • Are the certificates self-signed?
  • Is an external Certificate Authority (CA) engaged?
• If ECC is used, is the security level sufficient?
• Does the solution make use of IPSec?
  • Check the parameters like Diffie-Hellman (DH) group, Perfect Forward Secrecy (PFS), aggressive mode usage.

Secure Communications

• Which protocols are used between orchestrator, controller, and edge devices?
  • Are these standardized or proprietary protocols?
  • Are they secured by encryption, integrity protection and authentication?
• How do SD-WAN entities authenticate each other?
• Run a network sniffer (e.g. tcpdump) on each node (orchestrator, controller, edge router), review traffic and check whether unencrypted sensitive packets are sent.
• Do the chosen protocols and primitives provide the security required by your threat model?
• Where and how are secrets (e.g., private keys, pre-shared keys, tokens) stored?
• Check whether the same hard coded certificate is used on different deployments.
• Is a key renewal mechanism supported on control channels?

(Web-) Management Interface

• How is Authentication, Authorization, and Accounting (AAA) realized?
  • Is Multi-Factor Authentication (MFA) used?
  • Who has access to the management interface?
  • Check for an Role Based Access Control (RBAC) model.
• Conduct a web application security assessment.
  • Especially check for OWASP Top 10 and known CVE’s.
• Are cryptographic secrets accessible via the web interface?

Unfortunately there are nearly no tools which are primarily specializing in SD-WAN security and are still updated.

Conclusion

To sum it up, it can be said that SD-WAN technologies are still in a development state and therefore likely suffer from teething troubles. For the beginning the aforementioned checklist will help with an initial security assessment. Still, the actual implementation of a SD-WAN solution might contain more components than mentioned in this article and therefore the total security assessment might need to be extended.

References / Credits

• 1 - SD-WAN New Hope Project
• 2 - DELTA: SDN SECURITY EVALUATION FRAMEWORK
• 3 - ATTACKING SDN INFRASTRUCTURE
• 4 - HACKING THE BRAIN
• 5 - FlowFuzz
• 6 - modern-network-areas-in-software-defined
• 7 - SDN vs NFV comparison Image
• 8 - Virtual network functions VNF
• 9 - MEF 3.0 SD-WAN
• 10 - programmable network (PN)
• Title Image by Omar Flores on Unsplash.com

~ René Hoffmann