Maksim Pasko - Fotolia
By 2021, the majority of IT decision makers will have started to adopt software-defined networking (SDN). With this figure alone, it is clear that we are on the cusp of a significant software-defined shift in the wide area network (WAN) space – as traditional WAN is being outstripped by its software-defined younger brother.
Of course, the main driver behind software-defined WAN (SD-WAN) is the increasing use of cloud-based services by organisations. We are not just talking about public cloud – it also includes using software-as-a-service (SaaS) applications.
While it is very rare for an organisation to shift all their applications suddenly to the public cloud, they are increasingly dipping their toes into hybrid environments to test them out.
Typically, a distributed enterprise with many locations connects these locations by multiprotocol label switching (MPLS). As we know, MPLS circuits can be very costly and resource-intensive. However, they are undeniably reliable and highly secure.
The problem is that MPLS circuits were great when the organisation’s datacentre held all of its apps, but in a world where Microsoft Exchange is increasingly becoming Microsoft Office 365, the data that was previously held in that datacentre is now in the cloud.
A paradigm shift is happening, whereby the datacentre is being vacated, and the old model of the infrastructure is becoming increasingly irrelevant.
With MPLS, even though you are using cloud apps, you are actually backhauling all of your cloud traffic down to your centralised firewall on premises. While this is of course very secure, it does slow the network down, contributing to latency issues and complicating the architecture.
What your network should be doing is simply ensuring that data travels from branch to cloud securely. As already mentioned, organisations’ apps are now in the cloud, meaning there is nothing left in the datacentre. So why have costly MPLS circuits at all?
The move to cloud calls for a new architecture, one that embraces cloud technology and the migration of apps to public cloud – SD-WAN.
Of course, this brings with it a whole new set of security requirements, and a new way of thinking about WAN security. In this era of sophisticated cyber attacks, we cannot afford to go backwards with security – we have to go forwards.
SD-WAN calls for new security rules
When you move away from backhaul architecture to centralised security, you need to create the same security posture as you would have had at your central headquarters and provide that in all your remote locations.
The well-defined security perimeter has vanished – it is now dispersed across multiple locations. Your apps are now in the cloud, but you still need to recreate a consistent security posture regardless of which platform users are accessing.
It is generally recognised that to do SD-WAN securely you need five pieces of functionality:
- SD-WAN termination – The aggregation of consumer-grade connections.
- WAN optimisation to make the best use of bandwidth.
- Routing to route traffic.
- Firewall at every location to recreate the perimeter around the branch office.
- Advanced threat protection, such as sandboxing technology.
Crucially for security purposes in the land of SD-WAN, we no longer need one huge centralised firewall – we only needed it before as it was the single point for all traffic to go through.
However, no firewall means exposing every user in your network to malware and other cyber attacks, so we need the same level of security as we enjoyed before with a centralised firewall.
You can do this by replacing it with lots of smaller firewalls at every single location. They need to be connected into the SD-WAN, but this time you can use cheap consumer-grade circuits from your service provider, rather than costly MPLS.
The next conversation centres on sandboxing. When you had a centralised firewall, you likely also had a centralised sandbox to filter everything including emails and downloads from malware and other cyber attacker tools.
Typically, this sandbox would live in a central location at the heart of your organisation. It would scrub downloaded data and then pass it on its way back through the backhaul circuit.
Now a centralised sandbox is not going to work, as once a user starts to download a file, you would have to backhaul that file over to your centralised sandbox and then get it back to the user. Effectively, the sandbox is now isolated on an island if you cannot afford to install a sandbox at every location.
But you do need to tunnel between locations to secure the traffic so it cannot be hacked by external forces. So what’s the answer? A cloud-based sandboxing mechanism. Using SD-WAN, you can send information to a sandbox in the cloud, simultaneously optimising traffic to prioritise what is important to your organisation.
The same, if not better
So there you have it – a combination of processes that affords you the same security posture as before, if not better, without it being centralised. As it is also in the cloud, it can be accessed from anywhere, meaning users working from any location are protected.
However, what you do not want to have to do is to configure and maintain these five different elements of SD-WAN. As you can imagine, if you are an organisation with a few hundred locations, this could quickly become complicated.
Always look for zero touch provisioning where applicable, saving you money and time. Zero touch provisioning is the holy grail of SD-WAN, as it can be directly shipped to the end location and be configured from the cloud. Once installed, the configuration is pushed automatically to the device and it is all complete.
With cyber criminals’ tactics becoming increasingly sophisticated, it is only natural to assume that they will soon start to target attacks at SD-WAN environments, looking for vulnerabilities in your architecture. Ensure there is no weak link by creating a purpose built security posture for the software-defined environment.