Rawpixel - Fotolia

Manage Learn to apply best practices and optimize your operations.

Addressing NFV security issues in the enterprise

Network functions virtualization can complement SDN and benefit enterprises, but there are NFV security considerations that must be addressed. Expert Judith Myerson explains.

Network functions virtualization is a somewhat recent effort to replace the services provided by proprietary network hardware devices with virtualized software on commodity servers. NFV is different from software-defined networking but is complementary to it; when SDN runs on the NFV infrastructure, the SDN forwards the data packets from one network device to another while the network routing (control) functions run on a virtual machine in, for example, a rack mount server.

But NFV and SDN come with several security issues that cannot be ignored. Before discussing four NFV security issues, let's briefly cover both technologies' early history.

NFV: Virtualizing network functions

NFV was born out of service providers' frustrations with the need to install proprietary routers, gateways and other network devices to perform proprietary network functions. Service providers wanted to be able to start -- or in this case, virtualize -- network functions from anywhere in the network without regard to network devices, old or new.

In January 2013 the service providers got together to form ETSI's Network Function Virtualization Industry Specification Group (NFV ISG) to develop specifications on separating network functions from proprietary equipment in the NFV infrastructure. A network interface device (NID) does not need to be virtualized; but the NID is needed to provide a point of demarcation and to measure how well the network is performing. While the specifications cover security and trust, new NFV security challenges and issues have emerged.

SDN: Controlling the data plane

SDN was born out of network administrators' frustrations with the need to change software each time they tried out new network protocols. They wanted to be able to monitor from a central point how the entire network would behave in real time after implementing the protocols.

Shortly after the NFV ISG was set up, a new specification group was formed to develop specifications on separating the control plane (i.e., the network control logic) from the data plane (i.e., the physical routers and switches) and setting up an SDN controller to manage the data plane. The control plane controls how the data plane forwards traffic from network devices -- physical and virtual. An SDN controller is the central point that allows a network administrator, via a console, to control the data plane anywhere in the entire network. OpenFlow, the first SDN-based open standard communications interface, is used to access and forward traffic from one device to another in the data plane, but it is not guaranteed to prevent vulnerabilities and other security issues.

NFV security considerations

There are four key security considerations network administrators should address in their plans to run SDN in the NFV infrastructure.

It is not practical to have all SDN controllers to run at the same time when network traffic is light. One controller is sufficient during periods of low network traffic to keep energy costs down.
  1. Hypervisor vulnerabilities are the first security consideration a network administrator should look at when using NFV. In the NFV infrastructure, virtual network functions run on virtual machines. A hypervisor makes this possible by allowing several VMs to share resources of a single computer or server. One vulnerability is hyperjacking, which is a type of attack that allows a hacker to overtake control of a hypervisor and gain access to less secure virtual machines, and possibly to misconfigured SDN controllers and other hypervisors that are not properly secured. For example, a longtime critical flaw in the Xen hypervisor that allowed attackers to gain access to the host operating system was discovered and subsequently patched last fall.
  2. Large network vulnerabilities are the second consideration for network administrators. It's bad news when the disastrous cyberattack shuts down the entire network that includes multihypervisors. To mitigate the risks of complete network failure, the network administrator should consider dividing a large network into smaller segments. With network segmentation the administrator can use a controller to route the traffic from a segment that begins to slow down -- due to, for example, a denial-of-service attack -- to healthy segments without shutting down the entire network.
  3. SDN controller vulnerabilities should be addressed after vulnerabilities in the NFV infrastructure have been fixed. When SDN is first installed, the administrator should properly configure the controller, as an improper configuration can let hackers slip in undetected. Attackers can overtake the system as root users, impersonate a host, divert network flows to an already busy network device, and interfere with conflicts between multiple SDN network devices. It is important to consider the administrator's proper security credentials, skills and training when implementing the controller to make sure there are no misconfiguration errors.
  4. SDN controller capacity should be the last item on the list of NFV security considerations. A large-scale SDN environment needs multiple controllers within a network or between networks. Communication between multiple controllers can be enabled by what's known as SDN east-west interface or SDNi. To get the controllers to forward traffic to one another -- say, from one manufacturing plant to another facility -- they need to be federated using the Border Gateway Protocol to share routing information.

It is not practical to have all SDN controllers run at the same time when network traffic is light. One controller is likely sufficient during periods of low network traffic to keep energy costs down. A network administrator should be able to determine how many controllers are needed during peak hours, when traffic gets unexpectedly heavy, or when expanding a network. Having too many controllers active at the same time makes it harder for the administrator to apply security policies and fix controller vulnerabilities.

Next Steps

Learn how to improve SDN security with a risk management plan

Discover the security pros and cons of software-defined networking

Read more on the latest virtualization security tools

This was last published in March 2016

Dig Deeper on Virtualization security issues and threats