Skip to main content

NFV Security: Emerging Technologies and Standards

  • Chapter
  • First Online:

Part of the book series: Computer Communications and Networks ((CCN))

Abstract

This chapter addresses the network function virtualization (NFV) security while reflecting on the work of the ETSI NFV Security Working Group (NFV SEC WG) and the industry view it has formulated in the past 4 years. To this end, the chapter explains the differences between the “generic” cloud and NFV and discusses the security threats as well as new benefits for security provided in the NFV environment. The chapter further explains how the trust is bootstrapped from hardware and established among the execution components, the discussion culminating in the treatment of the subject of remote attestation. The requirements and architecture for lawful interception (LI) in the NFV environment, as well as the security monitoring and management in the NFV environment, are treated in much detail. Finally, a separate section is dedicated to the analysis of the OpenStack security. There is substantial bibliography offered to a reader who wishes to understand the background and minute detail of the subject.

This is a preview of subscription content, log in via an institution.

Buying options

Chapter
USD   29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD   54.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD   69.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info
Hardcover Book
USD   69.99
Price excludes VAT (USA)
  • Durable hardcover edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Learn about institutional subscriptions

Notes

  1. 1.

    For the history of the initial development of the NFV Security Working Group, see [1].

  2. 2.

    The fact that security problems are introduced by sloppy programming is well known, although it is often overlooked because it is rarely mentioned. As Dijkstra famously noted in [8], “The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don’t master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.” In the same page is a quote from an early 1984 EWD: “Machine capacities now give us room galore for making a mess of it. Opportunities unlimited for fouling things up! Developing the austere intellectual discipline of keeping things sufficiently simple is in this environment a formidable challenge, both technically and educationally.” As unfortunate as it is, the “software crisis” must be a primary factor in security assessment.

  3. 3.

    Over the years, the NFV ISG has considered a number of such use cases.

  4. 4.

    This term has been subsequently changed to “Trustworthy Boot,” defined in [11] as the means to encompass “the technologies and methods for validation and assurance of boot integrity.” This subject will be addressed in the next section, but, in a nutshell, the same result can be accomplished with different alternative technologies based on different standards. Since the NFV Security Problem Statement has not changed, we keep the old term throughout this section. (As pedantic as it may sound, the term “Secured Boot” was created for a similar reason: to refer to a generic set of mechanisms vs. the UEFI Secure Boot.)

  5. 5.

    A storage network also needs to be isolated, as does the operations-and-management network. This issue will be addressed later in this section.

  6. 6.

    It is noted, however, that the SDN is still an emerging technology, in which (as of 2014) the full set of controls has not been standardized.

  7. 7.

    And thus an inside attacker.

  8. 8.

    Indeed, there has been a long-standing work item in the NFV Security Working Group on this subject.

  9. 9.

    Implemented as a dedicated ASIC or a subcomponent of another processor. The chip would provide external mechanisms to prevent or make difficult tampering or inspection and also provide mechanisms to destroy stored secrets if tampering is detected.

  10. 10.

    As we will see later, the industry has introduced a new, generic term, “trustworthy boot.”

  11. 11.

    An important point to remember is that certain data may need to be retained, for regulatory reasons (such as lawful interception). For detail, see [12].

  12. 12.

    Trust delegation is typically established for the purposes of authorization. An example: when a person wants to use a printing service to print photos available on a social site, this person delegates the authority to do so to the printing service. We will see a detailed example when reviewing the OpenStack security below.

  13. 13.

    The detail of this is not elaborated on and “left for further study.”

  14. 14.

    We can see now how remote attestation of geographic attributes can be useful in meeting this requirement.

  15. 15.

    As of December 2016.

  16. 16.

    Several such scenarios are discussed in [16].

  17. 17.

    This term is rather loosely defined in the NFV, but the authors have ascertained two firm implementation examples: (1) that of the Intel’s Software Guard Extensions (SGX) (https://software.intel.com/en-us/sgx) and (2) a joint proprietary implementation developed by ARM and Apple (https://www.quora.com/What-is-Apple%E2%80%99s-new-Secure-Enclave-and-why-is-it-important).

  18. 18.

    As part of now extinct work item 8 (https://portal.etsi.org/webapp/workProgram/Report_WorkItem.asp?wki_id=45992).

  19. 19.

    Work item 12.

  20. 20.

    This depiction is likely to change as some participants in the NFV Security Working Group share the opinion that security management should not be performed by MANO.

  21. 21.

    In fact, for the first 2 year of its existence, the group was an expert group (rather than a working group—the status achieved in 2015). As an expert group, the security group was not expected to produce its own documents except for the Problem Statement. Yet, the founders felt that a bottom-up study was necessary both to develop a sound standard and to influence OpenStack.

  22. 22.

    Keystone provides the flexibility of employing an external authentication system.

  23. 23.

    A project is defined as a specific set of OpenStack resources.

  24. 24.

    There is the gap in numbering because of renaming a former work item 8, as explained in Sect. 6.

References

  1. Amzallag David (2014) “NFV Insights: The making of NFV Security—from Vision to Reality. Published by TNT at http://blog.tmcnet.com/next-generation-communications/2014/06/nfv-insights-the-making-of-nfv-security---from-vision-to-reality.html. Retrieved on December 14, 2016

  2. ETSI Group Specification (2015) ETSI GS NFV-SEC 001 V1.1.1 (2014–10): Network Function Virtualization; NFV Security; Problem Statement

    Google Scholar 

  3. ETSI Group Specification (2015) ETSI GS NFV-SEC 002 V1.1.1 (2015-08): Network Functions Virtualization; NFV Security; Cataloguing security features in management software. Sophia Antipolis, France

    Google Scholar 

  4. Faynberg I, Lu H, Skuler D (2016) Cloud computing: business trends and technologies. Wiley, LTF, Chichester

    Google Scholar 

  5. Open Network Foundation (2016) TR-530, Threat analysis for the SDN Architecture Version 1.0 (https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/Threat_Analysis_for_the_SDN_Architecture.pdf. Retrieved on December 19, 2016

  6. Open Network Foundation (2014) OpenFlow switch specification version 1.3.4 (Protocol version 0x04). https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf. Retrieved on December 19, 2016

  7. Open Network Foundation (2016) TR-535 “ONF SDN Evolution Version 1.0 ONF.” Retrieved on December 19, 2016

    Google Scholar 

  8. Edsger W. Dijkstra, EWD 1305. https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1305.html. Retrieved on December 19, 2016

  9. Scarfone K, Souppaya M, Hoffman P (2011) Guide to security for full virtualization technologies. Special Publication 800-125. National Institute of Standards and Technology. US Department of Commerce

    Google Scholar 

  10. Trusted Computing Group (2011) Virtualized trusted platform architecture specification. http://www.trustedcomputinggroup.org/virtualized-trusted-platform-architecture-specification/. Retrieved in December 2016

  11. ETSI Group Specification (2016) GS NFV-SEC 003 V1.2.1. Network Functions Virtualization (NFV); NFV Security; Security and Trust Guidance

    Google Scholar 

  12. ETSI Group Specification (2016) GS NFV-SEC 010 V1.1.1. Network Functions Virtualization (NFV); NFV Security; Report on Retained Data problem statement and requirements

    Google Scholar 

  13. Draft ETSI Group Specification ETSI GS NFV SEC 007 Network Functions Virtualization (NFV); NFV Security; Trust; Report on Attestation Technologies and Practices for Secure Deployments. Work in progress. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=44578. Retrieved on December 5, 2016

  14. Simpson AK, Schear N, Moyer T (2016) Runtime integrity measurement and enforcement with automated whitelist generation. In: Proceedings of annual computer security applications conference (ACSAC). Available at https://homes.cs.washington.edu/~aksimpso/publications/ACSAC2014Abstract.pdf. Retrieved on December 5, 2016

  15. ETSI Group Specification NFV-SEC 004 V1.1.1 (2015) Network Functions Virtualisation (NFV); NFV Security; Privacy and Regulation; Report on Lawful Interception Implications

    Google Scholar 

  16. Draft ETSI Group Specification NFV SEC 11 V0.0.6 (2016–05) Network Functions Virtualization (NFV); NFV Security; Trust; Report on Report on NFV LI Architecture. Work in progress. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=47603. Retrieved on December 12, 2016

  17. Draft ETSI Group Specification NFV-SEC 012 V0.0.13 (2016) Network Functions Virtualisation (NFV); Security; System architecture specification for execution of sensitive NFV components. Work in progress. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=47619. Retrieved on December 15, 2016

  18. Draft ETSI Group Specification NFV-SEC 013 V0.0.6 (2016) Network Functions Virtualisation (NFV); Security Report; Security Management and Monitoring for NFV [Release 2]. Work in progress. https://portal.etsi.org//tb.aspx?tbid=799&SubTB=799. Retrieved on December 21, 2016

  19. ETSI Group Specification NFV-SEC 002 V1.1.1 (2015–08) Network Functions Virtualisation (NFV); NFV Security; Cataloguing security features in management software

    Google Scholar 

  20. Leach P, Mealling M, Salz R (2005) RFC 1422, A Universally Unique IDentifier (UUID) URN Namespace. (https://tools.ietf.org/html/rfc4122)

Download references

Acknowledgments

The authors thank all participants of the ETSI NFV Security Working Group for the continuous discussion and development of the very subject of this chapter. In particular, thanks go to the Rapporteurs—who have been leading the work on the group’s work items as follows:

Problem Statement (work item 1)—Bob Briscoe;

Cataloguing security features in management software (work item 2)—Hui-Lan Lu;

Security and Trust Guidance (work item 3)—Mike Bursell, Kurt Roemer, and Mihai Serb;

Report on Lawful Interception Implications (work item 4)—Scott Cadzow

Report on Certificate Management (work item 5)—Markus Wong;

Report on Security Aspects and Regulatory Concerns (work item 6)—Scott Cadzow;

Report on Attestation Technologies and Practices for Secure Deployments (work item 7)—Diego Lopez and Mihai Serb;

Report on use cases and technical approaches for multi-layer host administration (work item 9Footnote 24)—Mike Bursell and Anne-Marie Praden;

Report on Retained Data problem statement and requirements (work item 10)—Mark Shepherd;

Security Report on NFV LI Architecture (work item 11)—Alex Leadbeater;

Security Management and Monitoring specification (work item 12)—Ashutosh Dutta, Wei Lu, and Kapil Sood;

Security Specification for MANO Components and Reference points (work item 13) and Security Specification for other MANO reference points (work item 14)—Pradheepkumar Singaravelu.

We are very grateful to Michael Bilca whose LI architecture figures we re-used. Special thanks go to Don Clarke, whose leadership in the NFV ISG ensured that the work on security got the attention, support, and resources needed to produce the results partially described here.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Igor Faynberg .

Editor information

Editors and Affiliations

Rights and permissions

Reprints and permissions

Copyright information

© 2017 Springer International Publishing AG

About this chapter

Check for updates. Verify currency and authenticity via CrossMark

Cite this chapter

Faynberg, I., Goeringer, S. (2017). NFV Security: Emerging Technologies and Standards. In: Zhu, S., Scott-Hayward, S., Jacquin, L., Hill, R. (eds) Guide to Security in SDN and NFV. Computer Communications and Networks. Springer, Cham. https://doi.org/10.1007/978-3-319-64653-4_2

Download citation

  • DOI: https://doi.org/10.1007/978-3-319-64653-4_2

  • Published:

  • Publisher Name: Springer, Cham

  • Print ISBN: 978-3-319-64652-7

  • Online ISBN: 978-3-319-64653-4

  • eBook Packages: Computer ScienceComputer Science (R0)

Publish with us

Policies and ethics