An MPLS network is a private network. The only way on and off it is through ports allocated by your service provider. Access to and from the internet is typically via one of your data centres, where the perimeter security is often concentrated and traffic flows are configured and limited. Because actual messages being passed can only be seen by people and applications within your private network domain, MPLS traffic isn’t usually encrypted.
Deploying SD-WAN over the top of an MPLS network would be as secure, as well as adding encryption to all traffic crossing your network, but would require SD-WAN devices to handle all traffic at spokes, hubs and cloud gateways. However, there are far simpler ways to achieve the application visibility and performance optimisation features of SD-WAN using the capabilities built into MPLS.
Most SD-WAN deployments are associated with either a change of underlay network to include internet based transport or a change of architecture to move from centralised internet breakout at the hub (heavily firewalled and policy controlled) to local internet break-out at each spoke location.
Moving to internet transport and encrypting your information in IPSec tunnels (as is done by all SD-WANs) is actually a very good way of keeping it safe. But the timing and nature of your traffic flows is exposed. This information, completely hidden in an MPLS world, could be used to identify key locations and times of the day, week or month when large information flows converge into a hub. That hub can then become a potential target for DDoS ransom attacks on the assumption that these flows are important for your company’s operation or regulatory compliance.
Unlike MPLS networks, SD-WAN networks have central controllers which are on the internet. Unless well controlled, these may expose vulnerabilities. A recent study found close to 5000 IP addresses spread over 2000 hosts that appear to be SD-WAN central controller interfaces, most of which were running outdated versions of software which have known vulnerabilities.
These central controllers not only represent a potential to gain the keys to your IPSec security, but also the ability to cut off access to an SD-WAN management server. This could result in you losing visibility and an ability to change routing. After a period of time sites will be unable to exchange updated keys with the manager and so will stop routing all together.
Whilst the move to internet transport and SD-WAN can therefore open up security risks, the biggest impact comes from using a site’s internet connection for local internet break-out. This moves the tightly controlled and controllable internet-facing perimeter from a small number of major data centre location to one where it expands to each remote site. For our largest global customers that could be 3000 locations across 140 countries.
Local internet break-out brings the real promise of SD-WAN – offloading internet bound traffic at source, avoiding tromboning-related performance degradations and providing local access to cloud services wherever they are homed.
There are two approaches that can be taken. The first it to attempt to maintain this impervious expanded perimeter. The second is to focus on more internal security approaches such as identity controls and micro segmentation.
Most SD-WAN vendors include an Access Control List (ACL) which should prevent inbound communication over both the WAN ports and the management channels. Many customers then combine this with the use of a cloud-based proxy for outbound communications, exploiting functionality in many SD-WAN solutions to create and secure GRE or IPSec links to ZEN nodes. However, whilst providing reasonable security on outbound traffic, this solution is relatively weak on inbound traffic. Spoofing traffic to get through an ACL is not very hard for an experienced hacker, which is why maintaining a secure perimeter relies on good and consistent application of ACL policy across the estate.
I frequently come across global enterprises who already have suitable firewalls in place at many sites, making local internet breakout via SD-WAN a low-incremental-risk option.
As we are confident in the security of traffic between SD-WAN devices, local internet breakout to secure services “in the cloud”, for example the customer’s Azure hosting environment, can be achieved by adding virtual SD-WAN devices within the IaaS solution. Alternatively, this can be done by using service provider’s traditional MPLS links into AWS, Azure etc without relying on internet connectivity for this last leg. However, at this point, cloud security controls, together with use of network access control and identity management controls need to be considered depending on what assets and data are at or accessed from particular sites or locations and by whom.
Whilst SD-WAN networks are not as secure as traditional MPLS networks, if I’m asked “how I can deploy SD-WAN and maintain security?”, then I am back to my stock answer. It depends on how you will use the SD-WAN, on your security policy and the equipment you already have at remote sites, on your company’s policies and the regulations it operates under and, as always, it depends on your appetite to risk. You have to weigh up the impact of a breach or loss of network connectivity against affordability to deploy additional security around the network as part of your SD-WAN transformation business case.
One thing that is clear is that SD-WAN deployment is not just in the territory of the traditional network manager and the NOC. Knowing what you are trying to achieve and what applications you are utilising is key, as is the inclusion of the security team and the SOC early in architectural development.
Find out more about how our branch solutions bring together a choice of SD-WAN services, choice of underlay and range of security services, so you can balance performance, reach, cost and security.
