Article

Is a SD-WAN network as secure

as my MPLS network?

By Keith Langridge, vice president, networking

I was recently asked by a multinational customer whether SD-WAN was as

secure as their MPLS network. My usual answer to such high level questions
is “it depends”, but this time, I confidently said “no, it’s not”.

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 a 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 breakout at each
spoke location.
Article

Internet-based transport
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 are exposed. This information, completely
hidden in a 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 5,000 IP addresses
spread over 2,000 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 a 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.
Local internet breakout
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 breakout.
This moves the tightly-controlled and controllable
internet-facing perimeter from a small number
of major data centre locations to one where it
expands to each remote site. For our largest global
customers, that could be 3,000 locations across
140 countries.
There are two approaches that can be taken.
The first is 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 the 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.
How can I deploy SD-WAN and maintain
security?
Whilst SD-WAN networks are not as secure as
traditional MPLS networks, if I’m asked “how can I
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 how to get
secure high-performance
connectivity between your
critical sites.

Local internet breakout 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.

Issued: February 2019 Image goes here

Find out more at: www.bt.com/dyns

Offices worldwide
The services described in this publication are subject to availability and may be
modified from time to time. Services and equipment are provided subject to
British Telecommunications plc’s respective standard conditions of contract.
Nothing in this publication forms any part of any contract.

© British Telecommunications plc 2019

Registered office: 81 Newgate Street, London EC1A 7AJ.
Registered in England No: 1800000.