By Mike Bursell, Architect and Strategic Planner for the Software Defined Network Division at Intel and the chair of the ETSI Security Workgroup.
Telecom operators are getting very excited about network function virtualization (NFV). The basic premise is that operators get to leverage the virtualization technology created and perfected in the cloud to reduce their own CAPEX and OPEX. So great has been the enthusiasm, in fact, that NFV has crossed over and is now being used to also describe non-telecom deployments of network functions such as firewalls and routers.
A great deal of work and research is going on in areas where a telecom operator’s needs are different to those of other service providers. One such area is security. The ETSI NFV workgroup is a forum where operators, Telecom Equipment Manufacturers (TEMs), and other vendors have been meeting over the past two years to drive a consensus of understanding around the required NFV architecture and infrastructure. Within ETSI NFV, the “SEC” (Security) working group, of which I am the chair, is focusing on various NFV security architectural challenges. So far, the working group has published two documents:
The various issues that they address are worth discussing in more depth, and I plan to write some separate pieces in the future, but they can all be categorized as follows:
- Host security
- Infrastructure security
- Virtualization network function (VNF)/tenant security
- Trust management
- Regulatory concerns
Let’s cover those briefly, one by one.
For NFV, the host is the hypervisor host (an older term is the VMM or Virtual Machine Manager), which runs the Virtual Machines. In the future, hypervisor solutions are unlikely to be the only way of providing virtualization, but the type of security issues they raise are likely to be replicated with other technologies. There are two sub-categories – multi-tenant isolation and host compromise.
The host is not the only component of the NFV infrastructure. There may be routers, switches, storage, and other elements which need to be considered, and sometimes the infrastructure requirements, including the host and any virtual switches, local storage, etc. should be included as part of the overall picture.
The VNFs, and how they are protected from external threats, including the operator and each other in a multi-tenant environment, would fall under this point.
Whenever a new component is incorporated into an NFV deployment, issues of how much – or whether – it should trust the other components arise. Sometimes trust is simple, and does not need complex processes and technologies, but a number of the use cases which operators are interested in may require significant and complex trust relationships to be created, managed, and destroyed.
In most markets, governments place regulatory constraints on telecom operators before they are allowed to offer services. These concerns may have security implementations.
Although the ETSI NFV workgroup didn’t set out to specifically focus on problem areas, these categories have turned out to be useful for generating possible concerns which need to be considered. In future blogs, I will consider these questions and a number of the possible answers.