Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Network Security //

SDN

12/10/2018
09:35 AM
Alan
 Zeichick
Alan Zeichick
Alan Zeichick
50%
50%

SD-WAN Security: Why Zero-Trust Authentication Is Key

SD-WAN provides big benefits compared to traditional WAN connections between data centers and remote locations. However, authentication remains a concern. Here's why zero trust is a must.

Internet-based SD-WAN has an authentication problem. In fact, Internet-based SD-WAN is an authentication problem. Let's see what that problem is, and how to overcome it.

SD-WAN is a broad term used for a variety of alternatives to traditional fix-point wide-area networking (WAN) technologies, like T-1 lines or the more modern multi-protocol labeling switching (MPLS). Those traditional WANs are private networks provisioned through one or more carriers or telcos. They are reliable and secure, but are also very expensive, slow to provision and difficult to change. Those traditional WANs don't offer good solutions for short-term or mobile connections, but are excellent for tying together corporate sites, or for linking a data center to a cloud provider.

By contrast, software-defined WANs -- SD-WANs -- are everything that traditional WANs aren't.

SD-WANs leverage standard Internet connections at one or both ends; those might be based on phone lines (DSL), cable modems, cellular modems (4G or 5G), or even high-speed leased lines. Sometimes the SD-WAN terminates in a traditional data center, but increasingly, the link goes directly to a cloud service provider (CSP) to tap into dedicated or virtual servers.

What are SD-WANs used for?

Just about everything that a traditional WAN could be used for in the enterprise. For instance, tying a branch office to a central office's data center. Another benefit is that it can be provisioned as fast as you can get Internet service to a specific location, which can be instant if using cellular modems, or a matter of days of DSL or cable. Additionally, there's no need for dedicated WAN customer premises equipment (CPE), like you would need for MPLS or T-1 circuits. Finally, there's improved quality of service over a traditional Internet link, especially when SD-WANs aggregate multiple connections to add quality of service (QoS) with service-level guarantees.

What about security? That's the issue that SD-WAN providers are constantly trying to address with customers. Nobody truly trusts traffic going over the public Internet, but that's exactly what many SD-WAN providers do for at least part of the journey.

Encryption and authentication
There are two basic ways of ensuring that traffic going over the Internet remains private: Strong encryption and strong authentication. The first is a strength of SD-WANs in general; the other is a concern.

Nearly every SD-WAN provider touts the quality of its encryption: 256-bit, 512-bit, whatever. Whether you call it "military grade" or not, that's more than adequate for most purposes, unless your data is sufficiently valuable that someone is going to try to break your encryption.

Authentication is trickier, because both parties need to trust each other.

A bank kiosk connected through SD-WAN technology to the bank data center needs to know, absolutely, that it's really talking to the bank, and not a faker. The bank needs to know, absolutely, that it's talking to a genuine kiosk.

A challenge, however, with some SD-WAN solutions is that a third party is handling the authentications: the SD-WAN provider itself.

That's due to the architecture: The kiosk uses the public Internet to access not the bank data center but the SD-WAN provider's local node. It authenticates to that node and routes its traffic through that node. The bank's data center or cloud-hosted servers similarly authenticate to the SD-WAN provider. The SD-WAN provider vouches for everyone and establishes the bidirectional link.

The data is encrypted, so there's not a real worry that the SD-WAN provider is listening into confidential communications. However, the bank has outsourced its authentication process to the SD-WAN provider. That concerns me and should concern you as well -- unless there's zero trust in the SD-WAN itself.

And that's what I recommend. Despite what the vendors promise, don't trust it.

Use SD-WAN, by all means.

It's significantly less expensive than any traditional WAN technology, in some cases by orders of magnitude. It's hugely faster to provision and move than MPLS, especially when the SD-WAN needs to span multiple countries or carriers. It's easier to manage, thanks to web-based administrative tools. And it can offer superior QoS over vanilla Internet connections as well -- some SD-WAN providers have done an excellent job with compression and load-balancing.

Use the SD-WAN to establish an authenticated and encrypted link -- and once that link is established, use virtual private network technology, specifically, not one offered by the SD-WAN provider, to authenticate an end-to-end secure communication that's re-encrypted by the VPN.

Does that add complexity? You bet. But I wouldn't have it any other way.

Related posts:

Alan Zeichick is principal analyst at Camden Associates, a technology consultancy in Phoenix, Arizona, specializing in enterprise networking, cybersecurity, and software development. Follow him @zeichick.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Considerations for Seamless CCPA Compliance
Anurag Kahol, CTO, Bitglass,  7/2/2020
Introducing 'Secure Access Service Edge'
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  7/3/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-12421
PUBLISHED: 2020-07-09
When performing add-on updates, certificate chains terminating in non-built-in-roots were rejected (even if they were legitimately added by an administrator.) This could have caused add-ons to become out-of-date silently without notification to the user. This vulnerability affects Firefox ESR < 6...
CVE-2020-12422
PUBLISHED: 2020-07-09
In non-standard configurations, a JPEG image created by JavaScript could have caused an internal variable to overflow, resulting in an out of bounds write, memory corruption, and a potentially exploitable crash. This vulnerability affects Firefox < 78.
CVE-2020-12423
PUBLISHED: 2020-07-09
When the Windows DLL "webauthn.dll" was missing from the Operating System, and a malicious one was placed in a folder in the user's %PATH%, Firefox may have loaded the DLL, leading to arbitrary code execution. *Note: This issue only affects the Windows operating system; other operating sys...
CVE-2020-12425
PUBLISHED: 2020-07-09
Due to confusion processing a hyphen character in Date.parse(), a one-byte out of bounds read could have occurred, leading to potential information disclosure. This vulnerability affects Firefox < 78.
CVE-2020-12426
PUBLISHED: 2020-07-09
Mozilla developers and community members reported memory safety bugs present in Firefox 77. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 78.