How to Secure Network Function Virtualization Environment?

In the previous article, I shared some of the common risks found in Network Function Virtualization (NFV) domains. In this article, I will delve on how an attacker can exploit different components of the NFV network and provide high-level guidelines that communication service providers (CSPs) could adopt to achieve a measure of security for their NFV environments. 

Security is one of the most challenging aspects in NFV deployments. NFV is a massively-scaled, software-driven environment with varied components managed and continuous shifting traffic flows and network topologies. Such complexity requires a broad security architecture that allows automated and rapid response, with minimum degree of manual intervention, to manage dynamic network conditions. 

• Hardware (Blade/Server) Layer– At the bottom is the Hardware. Any breach that impacts this layer, such as those from Spectre and Meltdown vulnerabilities, exposing data privacy vulnerabilities can be catastrophic for CSPs. To secure this, the root of trust function – a set of hardware and software security modules – should be enabled on the server. This root of trust establishes the secure environment for the operating system to be initiated. 

• Hypervisor Layer– Attackers can take advantage of vulnerabilities present in hypervisors or NFVI. For example, an escape from the virtual computing, network or storage to the host’s physical compute, network or storage resources, could allow an attacker to undermine the confidentiality, integrity and/or availability of VNF resources. Solution to this, is to enable a secure boot system that provides a form of integrity protection, enabling trust that the hypervisor has not been tampered with.

• MANO Layer– Attackers may try to eavesdrop or modify the traffic that passes between and among the NFVI and the NFV MANO, as well as traffic within the NFV MANO.  Attackers may attempt to exploit the NFV orchestrator and VNF manager to disrupt the lifecycle management of the Network Services or of individual VNFs. A typical security feature to safeguard from this, is to focus on nodes hardening and access control within the MANO components itself.

• SDN and Network Layer– Software-Defined Networks are typically exposed to 2 types of attacks: Denial of Service and Man-in-the Middle. Solutions like dividing physical networks into logical ones could be a countermeasure to a DOS attack. SSH/TLS security would be the solution against MitM.   Security measures deployed at this layer should include proper network segmentation, traffic filtering, and perimeter security based on best practices.

• VNF and Application layer– VNFs could be a source or target of an attack. As a VNF is a component provided by a vendor, typically independent of the infrastructure provider, it can have vulnerabilities or even a malware designed to perform attacks.  Therefore, solution deployed at this layer should provide secure management through proper identity and access management and certificate management. Applicable best practices of securing applications are dependent on the applications itself and should cater at the minimum to support automated security policy, VNF scanning and a continuous security monitoring.

The concept of building trust in an NFV domain is similar to a waterfall model, a linear model requiring that the next phase should only begin after the previous phase is implemented successfully. The high-level guidelines presented here are not extensive and were articulated solely for the purpose of providing an overview of baseline security. For further reading on NFV Security, I recommend the following resources:

NFV: Security Threats and Best Practices

ETSI GS NFV-SEC 001 – V1.1.1 – Network Functions Virtualisation (NFV); NFV Security; Problem Statement

Attacks against Network Functions Virtualization and Software-Defined Networking: State-of-the-art