Monshizadeh and Khatri
332
NFV and platform security. Some of the major threats on vNFs and their mitigation
mechanisms are explained here [28–30]:
1) Malicious loops that are caused by routing loops, unavailability of management network due to network failure: to prevent these threats, the network should be logically
validated to make sure that management interfaces are accessible; even if vNFs
are down;
2) Improper data removal due to VM crash, execution of malicious vNF and therefore
unauthorized changes to Basic Input/Output System (BIOS) or Unified Extensible
Firmware Interface (UEFI), hypervisor and Operating System (OS): for mitigation
secure boot, i.e. Trusted Platform Module (TPM) and crash protection can be used;
3) Abuse of hypervisor resources by malicious VM (impacting other VMs) and QoS
degradation: performance isolation by segregating resources to each VM is recommended as a prevention mechanism [31];
4) Insufficient vertical and horizontal VM AAA mechanism: to prevent this threat,
AAA mechanisms among vNFs, between vNFs and the application layer and between
vNFs and management stations, should be revised;
5) Software unreliability such as:
● Coding flaws: that affect all MVNOs using the same software: Correction and
security patches should be applied on all VMs using the same software;
● Configuration changes or correction patches: that need reboot and cause service
outage on MVNOs; backup and load balancing are the mitigation mechanisms for
such a threat;
● Test and monitoring backdoors: closing test and monitoring and debug interfaces
are recommended;
● Stored password and private keys in VM images: using unique private key for each
image could prevent these threats.
14.4.2.3 OPNFV Security
OPNFV is an open‐source platform used for vNF deployment and Proof of Concept
(PoC). While the OPNFV security group improves security of OPNFV via code review,
vulnerability management and documentation, in general, their focus is on network
virtualization, SDN controller framework, OpenStack and virtual storage [32–34]. At a
research level, there is not much on OPNFV security, but they are following the ETSI
security group activities and will eventually develop the upstream, and improve the
audits and security guide, which covers how to secure an OPNFV‐based deployment.
For AAA, most of the threats are already mitigated in various OpenStack projects. In
the Virtual Infrastructure Manager (VIM) or SDN controller, AAA is inherent in keystone Open DayLight (ODL). There are also some blueprints being worked on for the
Federation and use of Security Assertion Markup Language (SAML), OpenID connect,
etc. However, these considerations are not applied if we intend to go a layer above
the VIM.
In data security, OPNFV only covers transport of data; for example, various service
APIs. The data at rest or in motion of the application is not covered.
For hypervisor, SDN and NFV security, OPNFV only concentrates on OpenStack,
while some security issues such as execution of malicious and non‐verified vNFs have
332
NFV and platform security. Some of the major threats on vNFs and their mitigation
mechanisms are explained here [28–30]:
1) Malicious loops that are caused by routing loops, unavailability of management network due to network failure: to prevent these threats, the network should be logically
validated to make sure that management interfaces are accessible; even if vNFs
are down;
2) Improper data removal due to VM crash, execution of malicious vNF and therefore
unauthorized changes to Basic Input/Output System (BIOS) or Unified Extensible
Firmware Interface (UEFI), hypervisor and Operating System (OS): for mitigation
secure boot, i.e. Trusted Platform Module (TPM) and crash protection can be used;
3) Abuse of hypervisor resources by malicious VM (impacting other VMs) and QoS
degradation: performance isolation by segregating resources to each VM is recommended as a prevention mechanism [31];
4) Insufficient vertical and horizontal VM AAA mechanism: to prevent this threat,
AAA mechanisms among vNFs, between vNFs and the application layer and between
vNFs and management stations, should be revised;
5) Software unreliability such as:
● Coding flaws: that affect all MVNOs using the same software: Correction and
security patches should be applied on all VMs using the same software;
● Configuration changes or correction patches: that need reboot and cause service
outage on MVNOs; backup and load balancing are the mitigation mechanisms for
such a threat;
● Test and monitoring backdoors: closing test and monitoring and debug interfaces
are recommended;
● Stored password and private keys in VM images: using unique private key for each
image could prevent these threats.
14.4.2.3 OPNFV Security
OPNFV is an open‐source platform used for vNF deployment and Proof of Concept
(PoC). While the OPNFV security group improves security of OPNFV via code review,
vulnerability management and documentation, in general, their focus is on network
virtualization, SDN controller framework, OpenStack and virtual storage [32–34]. At a
research level, there is not much on OPNFV security, but they are following the ETSI
security group activities and will eventually develop the upstream, and improve the
audits and security guide, which covers how to secure an OPNFV‐based deployment.
For AAA, most of the threats are already mitigated in various OpenStack projects. In
the Virtual Infrastructure Manager (VIM) or SDN controller, AAA is inherent in keystone Open DayLight (ODL). There are also some blueprints being worked on for the
Federation and use of Security Assertion Markup Language (SAML), OpenID connect,
etc. However, these considerations are not applied if we intend to go a layer above
the VIM.
In data security, OPNFV only covers transport of data; for example, various service
APIs. The data at rest or in motion of the application is not covered.
For hypervisor, SDN and NFV security, OPNFV only concentrates on OpenStack,
while some security issues such as execution of malicious and non‐verified vNFs have