Why addressing security issues related to NFV is important for the Middle East service providers.
By replacing dedicated network appliances, such as routers and firewalls, with software running on commercial, off-the-shelf servers, Network Functions Virtualisation (NFV) is transforming the way communication service providers (CSPs) deliver network services.
And the benefits that NFV offers are becoming increasingly clear to CSPs in the Middle East. As well as delivering savings by reducing operation costs and the need for truck rolls to deploy new hardware, it also allows operators to improve the speed at which new services are introduced.
But, with more network functionality being managed by software than ever before come some unique considerations around security, particularly when an organisation moves its Domain Name System (DNS) infrastructure to an NFV implementation.
Planning such a transition requires extra thought to be given around the protection in place. Many operators are still using open source or commodity software, for example, to protect their virtualised environments, which can involve risks they may be unaware of.
A more intelligent approach
Firewalls, intrusion detection tools and other traditional security solutions tend not to be designed with DNS protection in mind, especially in an NFV environment. Some aspects of NFV, such as centralisation and virtual machine (VM)-level security, can offer improved protection.
However, the increased flexibility and higher level of configuration available can potentially result in network functions being misconfigured, which can open up new attack vectors.
And even if these configuration issues don’t actually lead to security being compromised, the cascading effect they can create can impair the overall functionality of a network by giving the appearance of security issues where there are none.
But, of course, genuine malicious actions do exist.
Network resources can be quickly overwhelmed by a DNS-based DDoS attack which, by generating too many resolution requests for the DNS system to handle, will prevent legitimate requests from being resolved and effectively shut down the network.
Attackers can replace a valid IP address with another that redirects the requestor to a malicious website. In other cases, individual VMs will be attacked using tunnelling techniques, which encrypt and exfiltrate information through channels not normally analysed by traditional security software.
Furthermore, VMs, in common with physical hardware, are susceptible to infection by malware. If a machine isn’t quarantined sufficiently quickly after becoming infected, the infection can rapidly spread, disrupting the functionality of other machines throughout the network from within.
Built in, not bolted on
Such examples serve to illustrate why DNS-based security needs additional attention, and why monitoring the virtualised environment requires a different set of tools to those used in traditional network security.
Rather than being bolted on, DNS security needs to be built into the NFV architecture. The integration of DNS-specific protection will help minimise any gaps in coverage that may be overlooked by add-on solutions, and exploited by attackers.
Steps must be taken as soon as possible to minimise the impact of any attack that does take place. For example, the virtual environment must be able to rapidly deploy resources by spinning up new VMs without the need for operators to be involved. Automatically adding capacity in this way, while at the same time managing the attack, will prevent any interruption to service, thus reducing the risk of lost productivity and revenue.
NFV-based security ought to be capable of detecting previously unknown threats such as zero-day vulnerabilities by continuously analysing network behaviour while simultaneously defending against established threats.
Virtualised infrastructure should be able to track provisioned VMs, analyse their IP addresses, and monitor all DNS traffic to detect suspicious behaviour as it occurs. It should also be able to quarantine infected VMs when necessary to prevent the infection from spreading.
And importantly, while threats such as DDoS attacks may come from outside the firewall, malware on existing VMs can be just as dangerous. For this reason, any DNS-based security for NFV should include internal analysis and resource tracking as well as external.
Lastly, we’ve seen how issues around configuration can cause security and performance problems, illustrating the need for network discovery and automation tools which are able to determine correctly – and incorrectly – configured network functions, and identify potential issues.
NFV is emerging as the next stage in creating highly dynamic, automated networks. But, as technology continues to evolve, so network planning must evolve with it, managing the risks while reaping the rewards. Security must be addressed at the implementation stage rather than seen as an afterthought. Only then can service providers enjoy a flexible and transparent network that will meet their current and future needs, while ensuring continuing to protect their most valuable resources.
