Network Security is a critical element of an organization's security strategy. As a result of the public cloud and remote workers, the attacking surface of the WAN has expanded drastically in recent years. Network and security teams are constantly pressured to defend their domains against cybersecurity attacks and data breaches. However, the traditional WAN environment has multiple security problems:

• There is not much attention on ensuring the authenticity of network devices. In many environments, you can quickly go and plug in a new router or switch in the network and get it up and running. In large-scale environments spread across thousands of branches, this becomes hard to track and defend against.
• Each control plane protocol implements its own security mechanisms. For example, BGP, OSPF, PIM, and SNMP implement keys and key rotation differently.
• Securing the data traffic across all links involves lots of manual setup of tunnels and shared keys.
• Network (router, switches, etc.) and Security (firewalls, IPS, proxies, etc.) are generally implemented via separate hardware appliances, resulting in network sprawl.
• High availability and security solutions are often in conflict.

SD-WAN Security Fundamentals

Cisco has taken a completely different approach to WAN security based on three fundament principles:

• Fabric Security - The solution ensures that all devices participating in the network are genuine and trusted. All communication between network devices is automatically encrypted, eliminating the manual box-to-box approach involved in securing each WAN link.
• Integrated Security - The solution integrates all security functions such as Firewall, IPS, and AMP in routers' firmware, eliminating the need for separated dedicated hardware appliances performing the security functions. This eliminates the network sprawl at branches.
• Cloud Security - It provides seamless integration with multiple cloud-security providers, making the transition to a hybrid security model very easy.

Figure 1 illustrates a summary of all security functions provided by Cisco SD-WAN as of today. 

Fabric Security

In this lesson, we will deep-dive into the SD-WAN fabric security and leave the integrated and cloud security for the next lessons.

Hardware-Based Trust (SUDI)

The first foundational step in an organization's network security strategy is to ensure that all network devices are trusted and run uncompromised software images. This leads to an essential security question for each organization: what is trusted?

With the traditional security mechanisms such as "this router is deployed by our trusted engineer" and "we use BGP/OSPF/PIM/HSRP authentication," – do you feel confident that you operate a trusted infrastructure?

How do you know for sure that your hardware hasn't been compromised during the supply chain? You don't.

How do you know a device's firmware hasn't been compromised during boot-up or runtime? You don't.

Security starts way before software security mechanisms such as protocol authentication kick in. In recent years, there is a rapid increase in supply-chain attacks and exploits. Many hardware components such as RAM, SSDs, and CPUs are being replaced with compromised ones with pre-installed Trojans and rouge programs.

Nowadays, security begins in hardware during manufacturing. All Cisco physical devices have a Trust Anchor module (TAm) installed during manufacturing.

The TAM module provides several trustworthy technologies:

• Secure boot: The micro loader installed in the TAM module monitors the startup process and protects against malicious code at boot-up.
• Secure storage: The TAm module provides secure storage for crypto keys, passwords, customer credentials, and other critical security information for the device. One of its advantages is the ability to store private encryption keys and passwords for even greater security. Allocating secure storage outside the TrustAnchor module is also possible.
• Secure Unique Device Identifier (SUDI): SUDI is an SSL certificate (X.509v3) that holds the device's serial number and product identifier. It is installed during manufacturing and is verifiable by a public root certificate authority. The SUDI SSL certificate, along with the associated keys, is stored within the hardware Trust Anchor module (TAm) chip. Furthermore, the private key can never be exposed because the key pair is cryptographically bound to the specific TAm chip. 
• Runtime defense (RTD): RTD protects against the injection of malicious code into the firmware at runtime.

Whitelisting (WAN Edge list)

Once WAN edge routers have IP reachability to the SD-WAN controllers, they can start joining the SD-WAN network. However, organizations want to be sure that all devices participating in the SD-WAN domain are known, trusted, and authorized. It is essential from a security standpoint that the SD-WAN network prevents rogue devices from joining the overlay fabric and compromising security.

The Cisco SD-WAN solution uses an explicit whitelisting model for authenticating and trusting WAN edge devices. This means that before a router or a controller is allowed to join the SD-WAN network, it has to be known by all controllers beforehand. In simple words, controllers are explicitly given two lists:

• Controller list - A list of all controllers allowed to join the overlay network. Controllers are always manually added through the vManage user interface by a network administrator. Once the admin adds a controller via the GUI (step 2c in figure 3), vManage updates and sends a list of the serial numbers of all trusted controllers to all other SD-WAN controllers (step 3).
• WAN Edge list - A list of the serial numbers of all routers that are allowed to join the organization's network.

The WAN edge list results from the following process, shown in figure 3 below: 

• Step 1 - The organization purchases WAN edge routers through Cisco Commerce Workspace (CCW). CCW is linked to the Cisco Plug-and-Play (PnP) Connect portal. The serial numbers and PIDs of purchased devices are automatically registered into the PnP portal. 
• Step 2 - The list of the serial numbers of all purchased WAN Edge routers is made available to vManage either by syncing the vManage controller directly with the PnP connect portal (2a) or by manually downloading the file from the PnP portal and uploading it to vManage (2b). Of course, the list can also be modified manually by network administrators.
• Step 3 - vManage sends the list to all SD-WAN controllers.

In the end, all SD-WAN controllers have a whitelist of all WAN edge routers and controllers that are allowed to join the network. This prevents unauthorized devices from joining the centralized control and management planes and ensures that all devices in the overlay can be trusted.

Identity (Certificates)

We have seen that Cisco SD-WAN has an explicit whitelisting mechanism that redistributes the serial numbers of all routers allowed to join the network to all controllers. The question now is, when a router initiates a connection to a controller, how the router proves its identity? How can the controller be sure that the router is the one it tells it is?

Identity for all SD-WAN devices is provided by SSL certificates (x509v3). All devices come with pre-installed DigiCert, Symantec, and Cisco root certificates, as shown in figure 4. Additionally, all physical routers come with a pre-loaded device certificate installed during manufacturing and protected in a hardware chip (SUDI). All software devices, such as cloud routers and controllers, don't have pre-loaded device certificates and must go through the Certificate Signing Request (CSR) process. 

The essential point here is that every SD-WAN device must have a valid SSL certificate that cryptographically confirms its identity.

If you are not confident in understanding the difference between CSR, root certificate, and device certificate. Or what are Certificate Authority and Chain-of-Trust - you can check out our lesson on certificates.

Verifying controllers' identity

When controllers establish control connections to each other (as shown in figure 5 below), they exchange their device SSL certificates during the DTLS/TLS handshake process. Then each controller validates the following parameters:

• Validates the trust for the received device certificate using its pre-installed root certificates.
• Compares the certificate's serial number against the authorized controller list distributed from vManage (as shown in figure 3).
• Compares the organization name of the received certificate's OU field against the locally configured organization name.

The controllers establish a permanent DTLS/TLS connection if all validation steps succeed.

Verifying edge routers' identity

When a WAN edge router establishes control connections to SD-WAN controllers, it exchanges its device SSL certificate with the controller during the DTLS handshake process. Figure 6 illustrated how a controller validates the identity of physical and virtual edge routers.

Notice that there is a difference in the validation process for virtual and physical routers. The SSL certificate of a physical edge router is installed during manufacturing. Therefore, it is impossible to encode an organization's name into the certificate because it is unknown at the manufacturing time which organization will use this exact router.

On the other hand, virtual routers generate a Certificate Signing Request (CSR) after the org-name is configured on the router, so the OU field is then present in the SSL certificate after the CSR is signed by the CA.

If all validation steps succeed, the router establishes a permanent DTLS/TLS connection to the SD-WAN controller.

Secure Control-plane

Once two sdwan devices establish a secure DTLS/TLS control connection, the control-plane integrity is ensured by two security elements: AES-GCM message digests and public-private key pair.