Gartner predicts that by 2023, 93% of organizations will be doing some form of SDWAN for the WAN edge. And the reasons for this disruption are pretty obvious: Save money by not being as reliant on the private circuit, better application performance with intelligent monitoring and steering, simplified management with orchestrators and zero-touch provisioning. However, with all these moving parts, come old and new security concerns. Before we look at the specific ways of securing your SD-WAN, let’s take a quick look at the current SD-WAN vendor landscape.

Introduction

Not all SD-WAN is created equal. With the explosion of SDWAN over the last few years, we’re seeing more and more vendors incorporate SDWAN as a feature into their existing product offerings. That means that we have an influx of traditional network, wan opt, and security vendors who are now competing with the pure-play SDWAN vendors. While this means more options for the consumer, you also have an abundance of SDWAN vendors to pick from with varying levels of proficiency.

The security offerings of the various vendors can be grouped into three general categories:

 Cloud-based security,  3rd party integration or  Built-in security.

Cloud-based security means the SDWAN device is not doing any local security inspection, and instead – it offloads packets that require an inspection to a cloud service. This means that for every packet that needs to be inspected, the SDWAN device is forwarding it to the cloud service for security inspection.

3rd party integration usually comes in the form of service chaining using VMs. Service chaining is an SDN terminology to describe multiple virtual services working together within a physical box. In this case, the SDWAN vendor would provide the networking service while another security vendor would provide the security services. All of this happens within the same physical box using a hypervisor and SDN.

Built-in security offerings mean the security inspection is happening in the SDWAN appliance itself. These are generally traditional security devices, like a UTM or NGFW, that have SD-WAN features.

All three options have their pros and cons. From a security perspective, there’s one option you should only use as a last resort – and that leads us to the first item on our list.

To secure your SD-WAN, these five practices will come in handy;

Opt For On-Premise Security When Possible
Application Routing Best Practices
Lookout for Network Leaking
Look at the Transport Security
Use Cloud Access Security Broker (CASB)

1. Opt For On-Premise Security When Possible

From a security perspective, on-premise security is always preferred over the cloud for several reasons. Not only does it provide additional security services that cloud-based solutions simply cannot offer, but it will also lower your bandwidth cost and increase your performance. For cloud inspection to work properly, “all branch Internet traffic” must be forwarded to the cloud through GRE or IPSEC tunnels. That means that a regular user’s traffic needs to be forwarded to the nearest cloud data center, inspected, and then forwarded to the destination.

Therefore, if you have an SDWAN rule to route an application, like Office365, directly out to the internet – without going to the cloud-first- it will bypass security inspection altogether. In other words, everything needs to route through the security cloud, which removes almost all the benefits of implementing SD-WAN in the first place. It also means higher WAN usage which leads to higher costs. Particularly if you’re using an LTE/4G card backup link that charged per MB.

On-premise security can be accomplished with an SDWAN vendor that either provides security services natively on the same box or through service chaining with a security VNF (or Virtual Network Function). Both options greatly increase the performance on traffic that requires security inspection while also lower your cost by reducing the amount of traffic being sent to the cloud for inspection. Not to mention the number of security services that cannot be performed in the cloud, like:

Segmentation
Access layer security
Intra-branch security inspection. For example, scanning malware on a file share at the branch.
Breach containment
Quarantining
And local authentication has many caveats if your branch is behind a NAT – so if your users are being NAT’d at the branch, you should find out how that’s handled by the cloud provider.

Ultimately, cloud security services should only be used when on premise security is simply not an option. This seems to be the case with many popular, pure-play SD-WAN vendors who will partner with a cloud security vendor to provide security.

2. Application Routing Best Practices

If you ultimately decide to offload security inspection to the cloud, then this point becomes all the more important. In SD-WAN, we create rules that specify where to route applications or groups of applications. So a question you’ll want to ask yourself is what you need to do with applications that may be a security risk?

Before you get to that point, you have to first identify the applications your business uses. Next, identify which of these applications need to be backhauled to your cloud or datacenter. These will be called the ‘Known Corporate Applications’. For the applications that can use a direct internet connection, let’s call them ‘Known SaaS Applications’. For business continuity, these applications must work – at all times – through redundant paths.

The next group of applications can be a group of ‘Allowed Applications’. These may be applications that pose little to no security risk and are allowed to the internet.

Now, we want to group the applications that pose a security risk. If you’re choosing an SD-WAN product that does not have built-in security, this part may be non-existent which is why you’ll need to forward off to the security cloud service for inspection. Again – not ideal.

SD-WAN products with built-in security help in the identification of potentially risky applications. This category can include things like:

Botnet activity,
Security evasion software
Proxy avoidance and many more.

We’ll also want to create an application for applications that we know should not be used. For example, if your company is using an internal file share, we could block all other forms of file sharing like Dropbox and Google Drive.

Ultimately, these unwanted categories should be blocked before ever leaving the site. And if your SD-WAN product does not support this feature, make sure they are being black hole routed or transmitted to another device that can do more inspection.

3. Lookout for Network Leaking

MPLS, Broadband, LTE and IPSec tunnel overlays are just a few of the interfaces that SD-WAN has to manage. To simplify administration, SD-WAN vendors will usually group these interfaces into one single interface to remove the complexity of having to manage SDWAN rules and policies for each WAN interface. In some cases, this could lead to less than desirable routes to or from protected zones.

Look at this example: your MPLS link, broadband, and IPSec broadband overlay are all part of your SDWAN interfaces. You receive a default gateway from your MPLS and broadband providers which mean users now have two routes to your DC from MPLS or the Broadband. So you create a policy to allow Internal Users out of your SDWAN interface, which includes multiple individual interfaces. Simple Right? Except Internal users should never go out the broadband port to your DC without routing through your IPSec overlay.

So you create an SDWAN rule that allows users to your DC through the IPSec tunnel, in the event your MPLS link goes down. But here’s the part you have to be careful with. Some vendors treat SDWAN rules like firewall policies (reading from top to bottom) with a generic catch at the bottom to route everything. And rules will only be active as long as their SLAs, or health checks, are met. In a scenario where your MPLS link is unavailable, and your backup link is underperforming, your SDWAN rules won’t take effect and you end up using the routing table from the catch-all policy.

And since we have our default gateway through our broadband link as well, we end up with internal users going through the public internet and leaking private IP information.

There are many examples and scenarios we could review but the takeaway is this:  analyze your network requirement,

 Make sure your vendor gives you the flexibility you require to make individual interface decisions.

This can vary greatly by the vendor so make sure you understand the different scenarios in which routing can be influenced by the SDWAN rules. When not used properly, the simplicity of SDWAN can bring on unexpected security challenges that were not seen on traditional routers.

4. Look at the Transport Security

As companies move away from private circuits and utilize the unsecured public internet to transport data into private resources, strong encryption in your VPN tunnels becomes critical. Therefore, you need to make sure you have strong VPN encryption settings and have it tunneled back to your DC and Cloud services. For starters, you need to make sure you’re utilizing a VPN anytime you are accessing private resources across a WAN. This applies to both private circuits and direct internet access, like broadband or LTE cards. In a common branch scenario with one MPLS and one broadband connection; you have at least one IPSec tunnel through each WAN port.

If your Datacenter has redundant ports or paths, then you’ll also need redundant IPSec tunnels to each port. You could see that even in this basic setup, we already have four IPSec tunnels. If you have a backup LTE/4G card – consider using an on-demand IPSec tunnel that will only come up when the other ports are down to save on mobile data charges.

VPN Best Practices

Always use a secure protocol like IPSec. If you have legacy requirements for GRE, PPTP, or L2TP, make sure they ride over an IPSec tunnel first.
Older protocols do not encrypt the data in transport so they should always ride over IPSec. This part is critical if you have to use a cloud security provider, which sometimes recommends unsecured protocols for traffic offloading like GRE or HTTP proxies.
When using IPSec, consider the following best practices:
Use Certificates over pre-shared keys. If you must use PSK, use keys longer than 20 characters
Use IKEv2 whenever possible
Avoid weak encryption methods like DES and 3DES,  Avoid weak hashing algorithms like MD5 and SHA-1  Avoid Diffie Hellman Groups 1 & 2.

Don’t assume these basic requirements are given on modern SDWAN vendors. Many SD-WAN vendors have simplified the deployment process to the point where basic IPSec changes are either impossible or very difficult to do at scale.

5. Use Cloud Access Security Broker (CASB)

Part of the appeal with SD-WAN is the ability for remote offices and branch locations to access their cloud applications directly without having to ride back an expensive MPLS circuit to get there securely.

From a business perspective, I may want my branch locations to only ride the expensive MPLS connections for services in my data center or cloud – but use the cheaper broadband connections for direct internet access of SaaS applications. This creates a massive problem for security admins as more and more organizations use cloud applications like SalesForce and O365 to store sensitive data.

So how could we secure and control access to our SaaS applications? One way is to use a CASB in combination with our SD-WAN at the branch.

CASB stands for Cloud Access Security Broker, and it enforces security and governance policies for our cloud applications. This means that we can have much greater visibility and policy enforcement on our cloud applications we couldn’t get with a traditional security appliance. With CASB, you can see and control how your data is used on these SaaS offerings. Some common uses could be a user downloading sensitive data to an unsanctioned device, or a user moving PII on or off approved cloud storage. These are things we would be blind to without a Cloud Security Access Broker.

When working in conjunction with your SD-WAN appliance, you can now do global enforcement of those policies. If my organization is using O365, CASB gives me control down to the file of what can and cannot be done within that application. If my CASB has integration with my SDWAN vendor, I can now do things like quarantine users who started to move files around suspiciously – or cut a user’s access altogether if we notice malware from the endpoint.

As the digital transformation moves more and more services to servers we cannot control, CASB is becoming as essential to our security plan as the firewall was once. Gartner predicts by 2020, 60% of all large enterprises will use a CASB to govern cloud services.

5 Steps To Securing Your SD-WAN