The world of telecommunications has been marching down a path towards NFV (network functions virtualization) and even containerization over these past 5-10 years, but if there’s no security between VMs, isn’t it time to call a halt to this process and go back to dedicated custom hardware?
What’s Spectre?
- For the past 20+ years CPUs have used a technique known as speculative execution to improve their performance. This technique involves running some code before they know for sure whether they should do so or not (pending the result of a conditional query – an “if statement”).
- If they execute the wrong code they mostly clean-up the mess, as if it never happened, but there are some subtle artifacts left over (including some information stored in the CPU cache).
- A malicious program can use the side-effects of the speculative execution to access data owned by other programs (one byte at a time).
- Some of these exploits are dangerous only for programs running within the same operating system (Meltdown), but others can actually access data running in either the hypervisor or an entirely different virtual machine.
The Spectre flaw is particularly concerning because it’s actually a whole category of problems, and while some of the more obvious angles can be patched in software it’s likely that hackers will be continuing to find new exploits based on this flaw for years to come.
The long term fix is to replace all CPUs in the world, which isn’t even possible until such CPUs become available.
How does this impact NFV?
- There are not likely to be any patches that can fully secure a computer against the Spectre category of flaws until the CPUs are replaced – likely several years from now.
- Spectre allows an application in one virtual machine (VM) to access data in an entirely different VM.
So if you’re running a network function in a VM, it’s possible that an entirely different VM running within the same virtual architecture (same host CPU) could find a way to access your data.
In other words, the entire concept of a virtual machine – that you can run a separate guest operating system without worrying at all about the underlying hardware, and that you can share your hardware resources with a variety of other guests to improve efficiency and costs – is invalid.
So you’re saying NFV can’t be secure?
The Spectre security flaw means that you can’t rely on the isolation of each VM from others running on the same host hardware. If some malicious code is executed on the same hardware – even in a different VM – this code could potentially access your data. But if you have ironclad security in place for all applications running on all the VMs on your hardware then you don’t need to worry.
This means, for example, that if you create your own dedicated virtual environment to run some core voice applications (e.g. a call agent, media gateway controller, voicemail platform, application servers, SBCs etc) and you have a few physical servers dedicated to running these applications, then this environment should be safe from the spectre of… well, Spectre. [Sorry.]
On the other hand, the fewer applications that share a particular virtual environment, the more limited the benefits of virtualizing in the first place.
One of the key benefits of virtualization is that you can share physical resources among many types of applications, each with different usage patterns, so that you don’t have to provision enough hardware to handle peak capacity on all the applications simultaneously, as their different usage profiles mean they’ll peak at different times. If you need a separate set of physical servers to securely partition each function then you lose that benefit.
So now you have a classic trade off.
- The more applications that share your virtual environment, the greater the cost savings.
- The more applications that share your virtual environment, the greater the risk that one of them will be compromised, leading (potentially) to all of their data being accessible to an attacker.
So should we go back to dedicated custom hardware?
Personally however I’d take a more measured approach – I still think NFV is the right direction, but you might consider taking things a little more slowly.
For example, i
f you’re running a handful of voice applications in a virtual environment on some dedicated servers (your own private cloud for voice applications), then this still has some significant benefits.- You’re using commodity hardware (Intel-based servers) which is cheaper than custom telecoms equipment.
- You don’t have to worry about hardware end-of-life issues – new versions of these servers are being released every year or so, and you can easily replace servers in your deployment one-by-one when they need to be upgraded.
- You can share resources among the servers – so you don’t have any wasted capacity where there’s a mismatch in size between your needs and the specs of a particular server.
- You are architecturally well-placed to migrate to a grander NFV architecture in the future.
While these advantages are real, they are more limited than the long-term vision of what NFV can provide – where a wide range of applications are all sharing the same infrastructure.
My hope is that this future vision will one-day become a reality, perhaps in a few years time once new CPUs are available that address these flaws, but until then I would isolate your voice applications on different hardware from any other more general purpose VMs that you have running in your network.
This approach allows you to receive some of the benefits of NFV while still ensuring that your network is secure from all CPU spectres and meltdowns.
