By: David Amzallag - Alcatel-Lucent Vice President, Virtual Telecommunications and CloudBand CTO
While network functions virtualization (NFV) introduces new challenges to security, it also presents unique opportunities for addressing security problems due to the unprecedented scale, flexibility, and central control it affords. Compute, storage, and network resources can be optimally allocated and stitched together as required by the security policy. Our approach to address NFV security is based on a recursive, divide-and-conquer methodology, which involves securing the Alcatel-Lucent CloudBand™ NFV Platform, cloud nodes, and the network that interconnects them. CloudBand uses policy-based placement capabilities enabled by the CloudBand Management System to install virtualized functions in their appropriate security zones, and re-uses the security services provided by NFV applications.
I thought it would be a good idea to describe the journey to this approach together with its "making of" episodes.
When ETSI NFV started its security effort a year and a half ago, the founders’ expectation was a small (no more than six people) expert group that was sharply focused on a single objective, which was to formulate the NFV security problem statement. Igor Faynberg from the Alcatel-Lucent CloudBand™ team and Hui-Lan Lu from the Alcatel-Lucent IP Platforms team were invited to the first unofficial and very informal NFV security planning meeting, which took place in the corridor during the spring meeting of the IETF. Bob Briscoe from BT, a well-known networking expert and then convener of the ETSI NFV SEC group, and Bob Moskowitz from Verizon, an author of IPsec, Private IP Addressing, and Host Identity Protocol working for years on the enterprise side, made up the NFV Security Group at the time. These four had lively conversation, as many opinions differed.
Bob Briscoe was focused on virtualizing enterprise customer premises equipment (CPE) as the first step in a far reaching strategy. Bob Moskowitz was also interested in CPE, secure identities for NFV components, and network-independent secure communications. From the Alcatel-Lucent side, we suggested a systematic approach to NFV security based on the experience that we had gained in an earlier study and development of hypervisors, network operating systems, and the ITU-T Next Generation Network Security and Cloud standardization effort.
Two months later we were asked to present this approach to the ETSI NFV leadership. By that time, CloudBand had already developed an embryo of the NFV security vision: The NFV security could be developed recursively, layer-by-layer, in a way that applications (such as IMS) could in fact be re-used to enhance the platform security. Igor was elected as the convener of the NFV Security group, as Bob Briscoe decided to take on the essential role of outlining the Security Problem Statement as a rapporteur.
Within a year, the group grew to 14 regular participants and contributors spanning both major operators (AT&T, BT, DT, Telefonica, Sprint, and Verizon) and other vendors (notably Citrix, Huawei, Ericsson, and Intel). The mailing list today comprises passive participants of around 10 times more members. The group completed the work on the NFV Security Problem Statement while also contributing security considerations to the output of the Infrastructure (INF) and Software (SWA) groups. In this year, the group’s security expertise has been consistently sought after by the NFV Management and Orchestration (MANO) group. Based on these results, the ETSI NFV leadership encouraged the SEC group to widen its charter with two major work items: Security & Trust Guidance for NFV environment and OpenStack security evaluation. The latter item was developed by the specific request of NFV Chairman, Prodip Sen of HP (was at Verizon at that time), to Hui-Lan Lu, who was unanimously appointed the rapporteur. Analyzing OpenStack security capabilities is among the tasks the CloudBand team is running today together with RedHat as part of our partnership. The resulting mapping will enable us to understand what is missing in OpenStack to support NFV security and to prioritize the required "derived roadmap" in our products.
By the way, so far, OpenStack has over 1.7 million lines of code, which can be roughly "translated" into a 6 meters high tower of A4 paper. How high do you think the security part of this tower is?
Our vision emphasizes the necessity of building the trust chain for NFV components in three major steps. The first step is securing the platform— reinforcing deliberately disconnected islands of compute, storage, and networking infrastructure as well as the management system. The second step is the deployment of virtual security appliances, such as firewalls that transform the islands into controlled network zones, and virtual DNS servers that help to mitigate denial-of-service attacks. In the third step, virtualized functions in support of applications are placed in the zones established previously. The security of that deployment is assured by a combination of native application security controls and virtual security appliances, and then it is further enhanced by NFV platform capabilities. Once deployed, the security services provided by the applications can, in turn, be used to improve platform security further. For instance, the IMS virtualized Home Subscriber Server (HSS) can be used to provide an extra authentication factor for access to platform software. With these three steps in place, a centralized management and orchestration system can ensure a consistent, horizontal implementation of security through systematic application of security policies that will be enforced through the policy management mechanism of an NFV orchestrator, as in the CloudBand Management System.
Within Alcatel-Lucent, a team that comprises the IP Platforms CTO (Hui-Lan Lu), CloudBand PLM (Chris Deloddere), CloudBand Security Operations (Mark Hooper), and CloudBand CTO (Igor Faynberg) have been shaping the security vision over the course of the past year or so. The team demonstrates how the vision can help in solving problems documented in the ETSI NFV Security Problem Statement among others, and AT&T, BT, DT, Telefonica, and Verizon help with validating the approach. To this end, a recent report on the ETSI NFV Security Proof of Concept activity related to virtual routers performance in the face of distributed denial of service attacks has confirmed our observation that NFV can improve the security of the provider’s network. All the right ingredients were "orchestrated" (I just can't stop using this word . . .) here. This was an innovative and unique technology vision, customer validation, initial implementation in the CloudBand 2.1 NFV Platform, worldwide leadership at ETSI NFV ISG, pioneering work at OpenStack (together with RedHat), and a strong collaborative effort between the PLM, R&D, and CTO groups.
Remember that question on the "height" of the security portion in the OpenStack "tower"? Well . . . to be honest, I think that there’s no more than an approximately 20cm high stack of explicit cryptographic and other security-functions-related code in an OpenStack "paper tower" (mostly in Keystone), but this is not catalogued. Furthermore, there is no clear mechanism for advertising the new cryptographic-function related features to OpenStack. So far, in OpenStack, there is no common and focused security catalogue. Obviously, we need to change this; more importantly, our customers are asking us to change this.
Having a clear and focused view is a necessary step in getting our customers out of the lab, beginning NFV field trials and launching commercial deployments.
Learn more by reading our white paper on “Providing Security in NFV”.