View on GitHub



« Back

7 Security


Table of Contents

7.1 Introduction

This chapter examines multiple aspects of security as it relates to the platform and security aspects for workloads. After discussing security attack vectors and security standards, this chapter delves into the Platform Security requirements. The chapters culminates with a consolidated set of “must” requirements and desired (should) recommendations; it is suggested that operators carefully evaluate the recommendations for possible implementation.

7.2 Principles and Guidelines

To Be Developed

7.3 Security Scope

7.3.1 In-scope and Out-of-Scope definition

The scope of the security controls requirements maps to the scope of the Reference Model architecture.

The Reference Model scope is shown below (as outlined in chapter 1 of the reference model):

ETSI NFV architecture mapping

Figure 7-2: ETSI NFV architecture mapping

This means that the security of the Reference Model requirements must cover the virtual resources (including the virtualisation layer), the hardware resources, and the VIM (Virtualised Infrastructure Manager).

There will be a different set of security requirements for each Cloud Infrastructure reference architecture. In this case, the first reference architecture is OpenStack.

7.3.2 Security Requirements

The following diagram shows the different security domains that impact the Reference Model:


Figure 7-3: Reference Model Security Domains

7.3.3 Platform security requirements

At a high level, the following areas/requirements cover platform security for a particular deployment:

7.3.4 Workload security requirements

At a high level, the following areas/requirements cover workload security for a particular deployment:

7.3.5 Certification/validation requirements

*(An overview/introduction to workload certification requirements and
incl types of workloads covered)*

7.4 Common standards

Security vulnerabilities and attack vectors are everywhere. The telecom industry and its cloud infrastructures are even more vulnerable to potential attacks due to the ubiquitous nature of the infrastructures and services combined with the vital role Telecommunications play in the modern world. The attack vectors are many and varied, ranging from the potential for exposure of sensitive data, both personal and corporate, to weaponized disruption to the global Telecommunications networks. The threats can take the form of a physical attack on the locations the infrastructure hardware is housed, to network attacks such as denial of service and targeted corruption of the network service applications themselves. Whatever the source, any Cloud Infrastructure built needs to be able to withstand attacks in whatever form they take.

With that in mind, the Cloud Infrastructure reference model and the supporting architectures are not only required to optimally support networking functions, but they must be designed with common security principles and standards from inception. These best practices must be applied at all layers of the infrastructure stack and across all points of interconnections with outside networks, APIs and contact points with the NFV network functions overlaying or interacting with that infrastructure. Standards organizations with recommendations and best practices, and certifications that need to be taken into consideration include the following examples. However this is by no means an exhaustive list, just some of the more important standards in current use.

A good place to start to understand the requirements is to use the widely accepted definitions developed by the OWASP – Open Web Application Security Project. These include the following core principles:

Additional Cloud Infrastructure security principles that need to be incorporated:

7.4.1 Potential attack vectors

Previously attacks designed to place and migrate workload outside the legal boundaries were not possible using traditional infrastructure, due to the closed nature of these systems. However, using Cloud Infrastructure, violation of regulatory policies and laws becomes possible by actors diverting or moving an application from an authenticated and legal location to another potentially illegal location. The consequences of violating regulatory policies may take the form of a complete banning of service and/or an exertion of a financial penalty by a governmental agency or through SLA enforcement. Such vectors of attack may well be the original intention of the attacker in an effort to harm the service provider. One possible attack scenario can be when an attacker exploits the insecure VNF API to dump the records of personal data from the database in an attempt to violate user privacy. Cloud Infrastructure operators should ensure that the applications APIs are secure, accessible over a secure network (TLS) under very strict set of security best practices, and RBAC policies to limit exposure of this vulnerability.

7.4.2 Testing demarcation points

It is not enough to just secure all potential points of entry and hope for the best, any Cloud Infrastructure architecture must be able to be tested and validated that it is in fact protected from attack as much as possible. The ability to test the infrastructure for vulnerabilities on a continuous basis is critical for maintaining the highest level of security possible. Testing needs to be done both from the inside and outside of the systems and networks. Below is a small sample of some of the testing methodologies and frameworks available.

• OWASP testing guide

• PCI Penetration testing guide

• Penetration Testing Execution Standard

• NIST 800-115

o VULCAN: Vulnerability Assessment Framework for Cloud Computing (NIST)

• Penetration Testing Framework

• Information Systems Security Assessment Framework (ISSAF)

• Open Source Security Testing Methodology Manual (“OSSTMM”)

• FedRAMP Penetration Test Guidance (US Only)

• CREST Penetration Testing Guide

Insuring that the security standards and best practices are incorporated into the Cloud Infrastructure and architectures must be a shared responsibility, among the Telecommunications operators interested in building and maintaining the infrastructures in support of their services, the application vendors developing the network services that will be consumed by the operators, and the Cloud Infrastructure vendors creating the infrastructures for their Telecommunications customers. All of the parties need to incorporate security and testing components, and maintain operational processes and procedures to address any security threats or incidents in an appropriate manner. Each of the stakeholders need to contribute their part to create effective security for the Cloud Infrastructure.

7.5 Platform Security

7.5.1 General Platform Security

The security certification of the platform will typically need to be the same, or higher, than the workload or VNF requirements.

The platform supports the workload, and in effect controls access to the workload from and to external endpoints such as carriage networks used by workloads, or by Data Centre Operations staff supporting the workload, or by tenants accessing workloads. From an access security perspective, the following diagram shows where different access controls will operate within the platform to provide access controls throughout the platform:


Figure 7-4: Reference Model Access Controls The high-level functions of these different access controls The following general security requirements apply to the platform

7.5.2 Platform ‘back-end’ access security

7.5.3 Platform ‘front-end’ access security

7.5.4 Platform Patching

Cloud Infrastructure operators should ensure that the platform including the components (hypervisors, VMs, etc.) are kept up to date with the latest patch.

7.6 Workload Security - Vendor Responsibility

7.6.1 Software Hardening

7.6.2 Port Protection

7.6.3 Software Code Quality

7.6.4 Alerting and monitoring

7.6.7 Identity and Access Management

7.6.8 CVEs and Vulnerability Management

7.6.9 Encryption suite support

7.6.10 Password complexity support

7.6.11 Banner

7.7 Workload Security - Operator Responsibility.

The Operator’s responsibility is to not only make sure that security is included in all the vendor supplied infrastructure and NFV components, but it is also responsible for the maintenance of the security functions from an operational and management perspective. This includes but is not limited to securing the following elements:

7.7.1 Remote Attestation/openCIT

Cloud Infrastructure operators must ensure that remote attestation methods are used to remotely verify the trust status of a given Cloud Infrastructure platform. The basic concept is based on boot integrity measurements leveraging the Trusted Platform Module (TPM) built into the underlying hardware. Remote attestation can be provided as a service, and may be used by either the platform owner or a consumer/customer to verify that the platform has booted in a trusted manner. Practical implementations of the remote attestation service include the open cloud integrity tool (Open CIT). Open CIT provides ‘Trust’ visibility of the cloud infrastructure and enables compliance in cloud datacenters by establishing the root of trust and builds the chain of trust across hardware, operating system, hypervisor, VM, and container. It includes asset tagging for location and boundary control. The platform trust and asset tag attestation information is used by Orchestrators and/or Policy Compliance management to ensure workloads are launched on trusted and location/boundary compliant platforms. They provide the needed visibility and auditability of infrastructure in both public and private cloud environments.

Insert diagram here:

7.7.2 Workload Image Scanning / Signing

It is easy to tamper with workload images. It requires only a few seconds to insert some malware into a workload image file while it is being uploaded to an image database or being transferred from an image database to a compute node. To guard against this possibility, workload images can be cryptographically signed and verified during launch time. This can be achieved by setting up a signing authority and modifying the hypervisor configuration to verify an image’s signature before they are launched. To implement image security, the VNF operator must test the image and supplementary components verifying that everything conforms to security policies and best practices.

Use of Image scanners such as OpenSCAP to determine security vulnerabilities is strongly recommended.

7.8 Application Vendors responsibility

The application vendors need to incorporate security elements to support the highest level of security of the networks they support. This includes but is not limited to securing the following elements:

Image from Will replace with a better image when I create it in the future.

7.9 Cloud Infrastructure vendors and Cloud Infrastructure Manager vendors responsibility

The Cloud Infrastructure vendors and Cloud Infrastructure Manager vendors need to ensure security of the infrastructure they support and manage.

7.9.1 Networking Security Zoning

Network segmentation is important to ensure that VMs can only communicate with the VMs they are supposed to. To prevent a VM from impacting other VMs or hosts, it is a good practice to separate VM traffic and management traffic. This will prevent attacks by VMs breaking into the management infrastructure. It is also best to separate the VLAN traffic into appropriate groups and disable all other VLANs that are not in use. Likewise, VMs of similar functionalities can be grouped into specific zones and their traffic isolated. Each zone can be protected using access control policies and a dedicated firewall based on the needed security level.

Recommended practice to set network security policies following the principle of least privileged, only allowing approved protocol flows. For example, set ‘default deny’ inbound and add approved policies required for the functionality of the application running on the NFVI infrastructure.

7.9.2 Volume Encryption

Virtual volume disks associated with workloads may contain sensitive data. Therefore, they need to be protected. Best practice is to secure the workload volumes by encrypting them and storing the cryptographic keys at safe locations. Be aware that the decision to encrypt the volumes might cause reduced performance, so the decision to encrypt needs to be dependent on the requirements of the given infrastructure. The TPM module can also be used to securely store these keys. In addition, the hypervisor should be configured to securely erase the virtual volume disks in the event of application crashes or is intentionally destroyed to prevent it from unauthorized access.

7.9.3 Root of Trust for Measurements (RTM)

The sections that follow define mecahnisms to ensure the integrity of the infrastructure pre-boot and post-boot (running). The following defines a set of terms used in those sections.

Values stored in a PCR cannot be reset (or forged) as they can only be extended. Whenever a measurement is sent to a TPM, the hash of the concatenation of the current value of the PCR and the new measurement is stored in the PCR. The PCR values are used to encrypt data. If the proper environment is not loaded which will result in different PCR values, the TPM will be unable to decrypt the data.

7.9.4 Static Root of Trust for Measurement (SRTM)

Static RTM (SRTM) begins with measuring and verifying the integrity of the BIOS firmware. It then measures additional firmware modules, verifies their integrity, and adds each component’s measure to an SRTM value. The final value represents the expected state of boot path loads. SRTM stores results as one or more values stored in PCR storage. In SRTM, the CRTM resets PCRs 0 to 15 only at boot.

Using a Trusted Platform Module (TPM), as a hardware root of trust, measurements of platform components, such as firmware, bootloader, OS kernel, can be securely stored and verified. Cloud Infrastructure operators should ensure that the TPM support is enabled in the platform firmware, so that platform measurements are correctly recorded during boot time.

A simple process would work as follows;

  1. The BIOS CRTM (Bios Boot Block) is executed by the CPU and used to measure the BIOS firmware
  2. The SHA1 hash of the result of the measurement is sent to the TPM
  3. The TPM stores this new result hash by extending the currently stored value
  4. The has comparisons can validate settings as well as the integrity of the modules

Cloud Infrastructure operators should ensure that OS kernel measurements can be recorded by using a TPM-aware bootloader (e.g. tboot or shim), which can extend the root of trust up to the kernel level.

The validation of the platform measurements can be performed by TPM’s launch control policy (LCP) or through the remote attestation server.

7.9.5 Dynamic Root of Trust for Measurement (DRTM)

In Dynamic Root of Trust for Measurement (DRTM), the RTM for the running environment are stored in PCRs starting with PCR 17.

If a remote attestation server is used to monitor platform integrity, the operators should ensure that attestation is performed periodically or in a timely manner. Additionally, platform monitoring can be extended to monitor the integrity of the static filesystem at run-time by using a TPM aware kernel module, such as Linux IMA (Integrity Measurement Architecture) for linux platforms, or by using the trust policies functionality of OpenCIT.

The static filesystem includes a set of important files and folders which do not change between reboots during the lifecycle of the platform. This allows the attestation server to detect any tampering with the static filesystem during the runtime of the platform.

7.9.6 Cloud Infrastructure & Cloud Infrastructure Manager

Resources management is essential. Requests coming from a higher orchestration layer to the Cloud Infrastructure manager must validated and the integrity of these requets must be verified. Internal security capabilities

Ref NFVI capability Unit Definition/Notes
i.sec.cap.001 VNF-C<->VNF-C memory isolation Yes/No Are VNF-C memories isolated from each other by hardware support
i.sec.cap.002 VNF-C -> Host Yes/No Can VNF-C access host memory
i.sec.cap.003 Host -> VNF-C Yes/No Can Host access VNF-C memory
i.sec.cap.004 External storage at-rest encryption Yes/No Is external storage encrypted at-rest

Table 7-1: Cloud Infrastructure internal security capabilities

Table 7-2 shows security capabilities

Ref VIM capability Unit Definition/Notes
e.sec.cap.001 Resources management requests verification Yes/No Capability to validate and verify the integrity of a resources management requests coming from NFVO or VNFM

Table 7-2: Cloud Infrastructure Manager capabilities related to security

7.10 Certification requirements (Just ideas)

7.11 Consolidated Security Requirements

7.11.1. System Hardening

Ref Requirement Unit Definition
sec.gen.001 The Platform must maintain the state to what it is specified to be and does not change unless through change management process.    
sec.gen.002 All systems part of Cloud Infrastructure must support password hardening (strength and rules for updates (process), storage and transmission, etc.)   Hardening: NIST SP 800-63B
sec.gen.003 All servers part of Cloud Infrastructure must support a root of trust and secure boot    
sec.gen.004 The Operating Systems of all the servers part of Cloud Infrastructure must be hardened   NIST SP 800-123
sec.gen.005 The Platform must support Operating System level access control   Details on OS
sec.gen.006 The Platform must support Secure logging   Details
sec.gen.007 All servers part of Cloud Infrastructure must be Time synchronized with authenticated Time service    
sec.gen.008 All servers part of Cloud Infrastructure must be regularly updated to address security vulnerabilities    
sec.gen.009 The Platform must support Software integrity protection and verification    
sec.gen.010 The Cloud Infrastructure must support Secure storage (all types)   Expand/Delete based on other requirements
sec.gen.011 The Cloud Infrastructure should support Read and Write only storage partitions (write only permission to one or more authorized actors)    
sec.gen.012 The Operator must ensure that only authorized actors have physical access to the underlying infrastructure.    
sec.gen.013 The Platform must ensure that only authorized actors have logical access to the underlying infrastructure.    
sec.gen.014 All servers part of Cloud Infrastructure should support measured boot and an attestation server that monitors the measurements of the servers.    

7.11.2. Platform and Access

Ref Requirement Unit Definition  
  sec.sys.001 The Platform must support authenticated and secure APIs, API endpoints    
    The Platform must implement authenticated and secure access to GUI    
  sec.sys.002 The Platform must support Traffic Filtering for workloads (for example, Fire Wall)    
  sec.sys.003 The Platform must support Secure and encrypted communications, and confidentiality and integrity of network traffic    
  sec.sys.004 The Cloud Infrastructure must support Secure network channels   A secure channel enables transferring of data that is resistant to overhearing and tampering
  sec.sys.005 The Cloud Infrastructure must segregate the underlay and overlay networks    
  sec.sys.006 The Cloud Infrastructure must be able to utilize the Cloud Infrastructure Manager identity management capabilities    
  sec.sys.007 The Platform must implement controls enforcing separation of duties and privileges, least privilege use and least common mechanism (Role-Based Access Control)    
  sec.sys.008 The Platform must be able to assign the Entities that comprise the tenant networks to different trust domains.   Communication between different trust domains is not allowed, by default.
  sec.sys.009 The Platform must support creation of Trust Relationships between trust domains   These maybe uni-directional relationships where the trusting domain trusts anther domain (the “trusted domain”) to authenticate users for them or to allow access to its resources from the trusted domain. In a bidirectional relationship both domain are “trusting” and “trusted”
  sec.sys.010 For two or more domains without existing trust relationships, the Platform must not allow the effect of an attack on one domain to impact the other domains either directly or indirectly    
  sec.sys.011 The Platform must not reuse the same authentication key-pair (for example, on different hosts, for different services)    
  sec.sys.012 The Platform must only use secrets encrypted using strong encryption techniques, and stored externally from the component   e.g., Barbican (OpenStack)
  sec.sys.013 The Platform must provide secrets dynamically as and when needed    

7.11.3. Confidentiality and Integrity

Ref Requirement Unit Definition The Platform must support Confidentiality and Integrity of data at rest and in-transit The Platform should support self-encrypting storage devices The Platform must support Confidentiality and Integrity of data related metadata The Platform must support Confidentiality of processes and restrict information sharing with only the process owner (e.g., tenant). The Platform must support Confidentiality and Integrity of process-related metadata and restrict information sharing with only the process owner (e.g., tenant). The Platform must support Confidentiality and Integrity of workload resource utilization (RAM, CPU, Storage, Network I/O, cache, hardware offload) and restrict information sharing with only the workload owner (e.g., tenant). The Platform must not allow Memory Inspection by any actor other than the authorized actors for the Entity to which Memory is assigned (e.g., tenants owning the workload), for Lawful Inspection, and by secure monitoring services   Admin access must be carefully regulated The Cloud Infrastructure must support tenant networks segregation    

7.11.4. Workload Security

Ref Requirement Unit Definition
sec.wl.001 The Platform must support Workload placement policy    
sec.wl.002 The Platform must support operational security    
sec.wl.003 The Platform must support secure provisioning of workloads    
sec.wl.004 The Platform must support Location assertion (for mandated in-country or location requirements)    
sec.wl.005 Production workloads must be separated from non-production workloads    
sec.wl.006 Workloads must be separable by their categorisation (for example, payment card information, healthcare, etc.)    
sec.wl.007 The Operator should implement processes and tools to verify VNF authenticity and integrity.    

7.11.5. Image Security

Ref Requirement Unit Definition
sec.img.001 Images from untrusted sources must not be used    
sec.img.002 Images must be maintained to be free from known vulnerabilities    
sec.img.003 Images must not be configured to run with privileges higher than the privileges of the actor authorized to run them    
sec.img.004 Images must only be accessible to authorized actors    
sec.img.005 Image Registries must only be accessible to authorized actors    
sec.img.006 Image Registries must only be accessible over secure networks    
sec.img.007 Image registries must be clear of vulnerable and stale (out of date) versions    

7.11.6. Security LCM

Ref Requirement Unit Definition
sec.lcm.001 The Platform must support Secure Provisioning, Maintaining availability, Deprovisioning (secure Clean-Up) of workload resources   Secure clean-up: tear-down, defending against virus or other attacks, or observing of cryptographic or user service data
sec.lcm.002 Operational must use management protocols limiting security risk such as SNMPv3, SSH v2, ICMP, NTP, syslog and TLS    
sec.lcm.003 The Cloud Operator must implement change management for Cloud Infrastructure, Cloud Infrastructure Manager and other components of the cloud   Platform change control on hardware
sec.lcm.004 The Cloud Operator should support automated templated approved changes   Templated approved changes for automation where available
sec.lcm.005 Platform must provide logs and these logs must be regularly scanned    
sec.lcm.006 The Platform must verify the integrity of all Resource management requests Yes/No  
sec.lcm.007 The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with current time information    
sec.lcm.008 The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with relevant DNS information.    
sec.lcm.009 The Platform must be able to update the tag of newly instantiated, suspended, hibernated, migrated and restarted images with relevant geolocation (geographical) information    
sec.lcm.010 The Platform must log all changes to geolocation along with the mechanisms and sources of location information (i.e. GPS, IP block, and timing).    
sec.lcm.011 The Platform must implement Security life cycle management processes including proactively update and patch all deployed Cloud Infrastructure software.    

7.11.7. Monitoring and Security Audit

The Platform is assumed to provide configurable alerting and notification capability and the operator is assumed to have automated systems, policies and procedures to act on alerts and notifications in a timely fashion. In the following the monitoring and logging capabilities can trigger alerts and notifications for appropriate action.

Ref Requirement Unit Definition
sec.mon.001 Platform must provide logs and these logs must be regularly scanned for events of interest    
sec.mon.002 Security logs must be time synchronised    
sec.mon.003 The Platform must log all changes to time server source, time, date and time zones    
sec.mon.004 The Platform must secure and protect Audit logs (contain sensitive information) both in-transit and at rest    
sec.mon.005 The Platform must Monitor and Audit various behaviours of connection and login attempts to detect access attacks and potential access attempts and take corrective actions accordingly    
sec.mon.006 The Platform must Monitor and Audit operations by authorized account access after login to detect malicious operational activity and take corrective actions accordingly    
sec.mon.007 The Platform must Monitor and Audit security parameter configurations for compliance with defined security policies    
sec.mon.008 The Platform must Monitor and Audit externally exposed interfaces for illegal access (attacks) and take corrective security hardening measures    
sec.mon.009 The Platform must Monitor and Audit service handling for various attacks (malformed messages, signalling flooding and replaying, etc.) and take corrective actions accordingly    
sec.mon.010 The Platform must Monitor and Audit running processes to detect unexpected or unauthorized processes and take corrective actions accordingly    
sec.mon.011 The Platform must Monitor and Audit logs from infrastructure elements and workloads to detected anomalies in the system components and take corrective actions accordingly    
sec.mon.012 The Platform must Monitor and Audit Traffic patterns and volumes to prevent malware download attempts    
sec.mon.013 The monitoring system must not affect the security (integrity and confidentiality) of the infrastructure, workloads, or the user data (through back door entries).    
sec.mon.014 The Monitoring systems should not impact IAAS, PAAS, and SAAS SLAs including availability SLAs    
sec.mon.015 The Platform must ensure that the Monitoring systems are never starved of resources    
sec.mon.016 The Platform Monitoring components should follow security best practices for auditing, including secure logging and tracing    
sec.lcm.017 The Platform must Audit systems for any missing security patches and take appropriate actions    

7.11.8. Compliance with Standards

Ref Requirement Unit Definition
sec.std.001 The Cloud Operator should comply with Center for Internet Security CIS Controls (   Center for Internet Security -
  [Q: Are we going to verify compliance w Controls? If not, then why a “must” – but making it a “should” implies only guidance and not a control.]    
sec.std.002 The Cloud Operator, Platform and Workloads should follow the guidance in the CSA Security Guidance for Critical Areas of Focus in Cloud Computing (latest version)   Cloud Security Alliance -
sec.std.003 The Platform and Workloads should follow the guidance in the OWASP Cheat Sheet Series (OCSS)   Open Web Application Security Project
sec.std.004 The Cloud Operator, Platform and Workloads should ensure that their code is not vulnerable to the OWASP Top Ten Security Risks    
sec.std.005 The Cloud Operator, Platform and Workloads should strive to improve their maturity on the OWASP Software Maturity Model (SAMM)    
The Cloud Operator, Platform and Workloads should utilize the OWASP Web Security Testing Guide    
sec.std.013 The Cloud Operator, and Platform should satisfy the requirements for Information Management Systems specified in ISO/IEC 27001   ISO/IEC 27002:2013 - ISO/IEC 27001 is the international Standard for best-practice information security management systems (ISMSs)
sec.std.014 The Cloud Operator, and Platform should implement the Code of practice for Security Controls specified ISO/IEC 27002:2013 (or latest)    
sec.std.015 The Cloud Operator, and Platform should implement the ISO/IEC 27032:2012 (or latest) Guidelines for Cybersecurity techniques   ISO/IEC 27032 - ISO/IEC 27032is the international Standard focusing explicitly on cybersecurity
sec.std.016 The Cloud Operator should conform to the ISO/IEC 27035 standard for incidence management   ISO/IEC 27035 - ISO/IEC 27035 is the international Standard for incident management
sec.std.017 The Cloud Operator should conform to the ISO/IEC 27031 standard for business continuity   ISO/IEC 27031 - ISO/IEC 27031 is the international Standard for ICT readiness for business continuity
sec.std.018 The Public Cloud Operator must, and the Private Cloud Operator may be certified to be compliant with the International Standard on Awareness Engagements (ISAE) 3402 (in the US: SSAE 16)   International Standard on Awareness Engagements (ISAE) 3402. US Equivalent: SSAE16

7.11.9. References

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

Network Functions Virtualisation (NFV);NFV Security; Security and Trust Guidance, ETSI GS NFV-SEC 003 V1.1.1 (2014-12)

Network Functions Virtualisation (NFV) Release 3; Security; Security Management and Monitoring specification, ETSI GS NFV-SEC 013 V3.1.1 (2017-02)

Network Functions Virtualisation (NFV) Release 3; NFV Security; Security Specification for MANO Components and Reference points, ETSI GS NFV-SEC 014 V3.1.1 (2018-04)

Network Functions Virtualisation (NFV) Release 2; Security; VNF Package Security Specification, ETSI GS NFV-SEC 021 V2.6.1 (2019-06)

ETSI Industry Specification Group Network Functions Virtualisation (ISG NFV) -

ETSI Cyber Security Technical Committee (TC CYBER) -

NIST Documents

NIST SP 800-53 Security and Privacy Controls for Federal Information Systems and Organizations

NIST SP 800-53A Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans

NIST SP 800-63B Digital Identity Guidelines

NIST SP 800-115 Technical Guide to Information Security Testing and Assessment

NIST SP 800-123 Guide to General Server Security

NIST SP 800-125 Guide to Security for Full Virtualization Technologies

NIST SP 800-125a Security Recommendations for Server-based Hypervisor Platforms

NIST SP 800-125b Secure Virtual Network Configuration for Virtual Machine (VM) Protection

NIST SP 800-137 Information Security Continuous Monitoring for Federal Information Systems and Organizations

NIST SP 800-145 The NIST Definition of Cloud Computing

NIST SP 800-190 Application Container Security Guide