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 9/17/2020
Cybersecurity Bounces Back, but Talent Still Absent
Simone Petrella, Chief Executive Officer, CyberVista,  9/16/2020
Meet the Computer Scientist Who Helped Push for Paper Ballots
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
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
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25789
PUBLISHED: 2020-09-19
An issue was discovered in Tiny Tiny RSS (aka tt-rss) before 2020-09-16. The cached_url feature mishandles JavaScript inside an SVG document.
CVE-2020-25790
PUBLISHED: 2020-09-19
** DISPUTED ** Typesetter CMS 5.x through 5.1 allows admins to upload and execute arbitrary PHP code via a .php file inside a ZIP archive. NOTE: the vendor disputes the significance of this report because "admins are considered trustworthy"; however, the behavior "contradicts our secu...
CVE-2020-25791
PUBLISHED: 2020-09-19
An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, the array size is not checked when constructed with unit().
CVE-2020-25792
PUBLISHED: 2020-09-19
An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, the array size is not checked when constructed with pair().
CVE-2020-25793
PUBLISHED: 2020-09-19
An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, the array size is not checked when constructed with From<InlineArray<A, T>>.