NFV and NFV-based Security Services 357
will still need to perform the normal acceptance testing procedure. However, with
VNFs, this testing procedure can be fully or largely automate. As security‐related risks
or bugs are identified, new releases can be quickly on‐boarded and tested again through
full automation in a Continuous Integration/Continuous Deployment (CI/CD) chain.
Security verification is an important step in that tool chain. It also ensures that VNFs
from different vendors follow the same rigorous process to achieve same level of security level and same security architecture standard. As early example of an automation
security testing component in CI/CD is Amazon Web Service’s Inspector [7].
Once on‐boarded, a VNF is ready for deployment. Deployment involves creation of
an instance of the VNF, for example, one or more virtual machines or containers. It is
given an identity and a private management IP address for communication, first with
its VNF Manager (VNFM). The identity is usually provided as a service by the Virtual
Infrastructure Manager (VIM). With the identity and management IP address, and the
assistance of the Identity and Authentication/Authorization service, the VNF instance
can now establish a trust relationship with VNFM, VIM and other MANO entities.
While a VNF could be simple and contained within a single instance of VM or container, more often it is much more complex, with many VMs or containers collaborating
to accomplish its functionalities. Each of these could have its own unique trusted identity, and the identity manager with the VIM facilitates trust establishment among them.
It is also possible that a complex VNF or a legacy implementation may conduct the VNF
internal trust management on its own. For example, a container manager or a vendor‐
specific PaaS layer may substitute for or complement the identity function.
The VNF Manager (VNFM) can be a common entity for many or all VNFs in a NFV
environment. We can also see VNFM proprietary to a vendor and its VNFs. In either
case, the VNF needs to locate the VNFM and then establish a trusted communication
channel with the VNFM. Finding VNFM can be facilitated by the VIM’s or MANO’s
instance creation phases via metadata to the VM (e.g. a model configuration), or by a
common service discovery protocol. In a model‐based approach, this VNFM identity
can be one of the meta data in the descriptor that defines this VNF. There are efforts
underway to standardize how a VNF should be formatted and described or modeled.
Among other benefits, a model‐based approach can ensure that security policies are
uniformly expressed and enforced. Either way, the VNF establishes a trusted and
secured management channel with the VNFM, and now it can be managed.
Let us first look at the simple case where the VNF is the only entity required for the
example service. In this case, once the VNF can be securely managed and configured,
it is now operational. There are a few things the VNF typically needs from the VIM to
be fully operational, and they do have security implications. Common examples include
publically addressable floating IP address, DNS service, and NTP time service. These
services are usually provided by the VIM and NFVI, and therefore it is the responsibility
of the operator to secure these services. DDoS attacks against DNS service have been
widely reported in recent years, for example in [8]. The operator can also outsource
some of these services, for example DNS, to professional DNS service providers. We
will further discuss these XaaS scenarios in a later section.
The next step in a VNF’s lifecycle is updating its software image. Software upgrade
is a major undertaking in physical network devices, including extensive testing and
preparation. In the NFV methodology, the Continuous Integration and Continuous
Deployment (CI/CD) [9] paradigm is a large part of changing the whole feature delivery
will still need to perform the normal acceptance testing procedure. However, with
VNFs, this testing procedure can be fully or largely automate. As security‐related risks
or bugs are identified, new releases can be quickly on‐boarded and tested again through
full automation in a Continuous Integration/Continuous Deployment (CI/CD) chain.
Security verification is an important step in that tool chain. It also ensures that VNFs
from different vendors follow the same rigorous process to achieve same level of security level and same security architecture standard. As early example of an automation
security testing component in CI/CD is Amazon Web Service’s Inspector [7].
Once on‐boarded, a VNF is ready for deployment. Deployment involves creation of
an instance of the VNF, for example, one or more virtual machines or containers. It is
given an identity and a private management IP address for communication, first with
its VNF Manager (VNFM). The identity is usually provided as a service by the Virtual
Infrastructure Manager (VIM). With the identity and management IP address, and the
assistance of the Identity and Authentication/Authorization service, the VNF instance
can now establish a trust relationship with VNFM, VIM and other MANO entities.
While a VNF could be simple and contained within a single instance of VM or container, more often it is much more complex, with many VMs or containers collaborating
to accomplish its functionalities. Each of these could have its own unique trusted identity, and the identity manager with the VIM facilitates trust establishment among them.
It is also possible that a complex VNF or a legacy implementation may conduct the VNF
internal trust management on its own. For example, a container manager or a vendor‐
specific PaaS layer may substitute for or complement the identity function.
The VNF Manager (VNFM) can be a common entity for many or all VNFs in a NFV
environment. We can also see VNFM proprietary to a vendor and its VNFs. In either
case, the VNF needs to locate the VNFM and then establish a trusted communication
channel with the VNFM. Finding VNFM can be facilitated by the VIM’s or MANO’s
instance creation phases via metadata to the VM (e.g. a model configuration), or by a
common service discovery protocol. In a model‐based approach, this VNFM identity
can be one of the meta data in the descriptor that defines this VNF. There are efforts
underway to standardize how a VNF should be formatted and described or modeled.
Among other benefits, a model‐based approach can ensure that security policies are
uniformly expressed and enforced. Either way, the VNF establishes a trusted and
secured management channel with the VNFM, and now it can be managed.
Let us first look at the simple case where the VNF is the only entity required for the
example service. In this case, once the VNF can be securely managed and configured,
it is now operational. There are a few things the VNF typically needs from the VIM to
be fully operational, and they do have security implications. Common examples include
publically addressable floating IP address, DNS service, and NTP time service. These
services are usually provided by the VIM and NFVI, and therefore it is the responsibility
of the operator to secure these services. DDoS attacks against DNS service have been
widely reported in recent years, for example in [8]. The operator can also outsource
some of these services, for example DNS, to professional DNS service providers. We
will further discuss these XaaS scenarios in a later section.
The next step in a VNF’s lifecycle is updating its software image. Software upgrade
is a major undertaking in physical network devices, including extensive testing and
preparation. In the NFV methodology, the Continuous Integration and Continuous
Deployment (CI/CD) [9] paradigm is a large part of changing the whole feature delivery