4 steps to ensure virtual machine security in cloud computing

Protect hosted elements by segregating them

Step one in securing virtual machine security in cloud computing is to isolate the new hosted elements. For example, let's say three features hosted inside an edge device could be deployed in the cloud either as part of the service data plane, with addresses visible to network users, or as part of a private subnetwork that's invisible. If you deploy in the cloud, then any of the features can be attacked, and it's also possible your hosting and management processes will become visible and vulnerable. If you isolate your hosting and feature connections inside a private subnetwork, they're protected from outside access.

In container hosting today, both in the data center and in the cloud, application components deploy inside a private subnetwork. As a result, only the addresses representing APIs that users are supposed to access are exposed. That same principle needs to be applied to virtual functions; expose the interfaces that users actually connect to and hide the rest with protected addresses. 

Ensure all components are tested and reviewed

Step two in cloud-virtual security is to certify virtual features and functions for security compliance before you allow them to be deployed. Outside attacks are a real risk in virtual networking, but an insider attack is a disaster. If a feature with a back-door security fault is introduced into a service, it becomes part of the service infrastructure and is far more likely to possess open attack vectors to other infrastructure elements.

It's important to insist on a strong lifecycle management compliance process flow for all hosted features and functions -- one that operators can audit and validate.

Private subnetworks can help in addressing virtual machine security in cloud computing. If new components can only access other components in the same service instance, the risk is reduced that malware can be introduced in a new software-hosted feature. Yes, a back-door attack could put the service itself at risk, but it's less likely the malware will spread to other services and customers.

This approach, however, doesn't relieve operators of the burden of security testing. It's important to insist on a strong lifecycle management compliance process flow for all hosted features and functions -- one that operators can audit and validate. If the companies supplying your hosted features or functions properly test their new code, it's less likely it will contain accidental vulnerabilities or deliberately introduced back-door faults.

Separate management APIs to protect the network

Step three is to separate infrastructure management and orchestration from the service. Management APIs will always represent a major risk because they're designed to control features, functions and service behavior. It's important to protect all such APIs, but it's critical to protect the APIs that oversee infrastructure elements that should never be accessed by service users.

The most important area to examine to ensure virtual machine security in cloud computing is the virtual-function-specific piece of the Virtual Network Functions Manager (VNFM) structure mandated by the ETSI NFV (Network Functions Virtualization) Industry Specification Group. This code is provided by the suppler of the VNF, and it is likely to require access to APIs that represent infrastructure elements as well as orchestration or deployment tools. Nothing more than bad design is needed for these elements to open a gateway to infrastructure management APIs that could affect the security and stability of features used in virtual-cloud services.

Securing the VNFM means requiring that providers of VNFs offer their architectures governing VNFM connections to infrastructure or deployment/management APIs for review and possible security enhancements. The important point is to ensure that no service user, VNF or VNFM associated with other VNFs or services can access an infrastructure management API.

By containing access, you limit your security risk. Additionally, operators should require that access to infrastructure management and orchestration APIs by any source is chronicled, and that any access or change is reviewed to prevent a management access leak from occurring.

Keep connections secure and separate

The fourth and final point in cloud-virtual network security is to ensure that virtual network connections don't cross over between tenants or services. Virtual networking is a wonderful way of creating agile connections to redeployed or scaled features, but each time a virtual network change is made, it's possible it can establish an inadvertent connection between two different services, tenants or feature/function deployments. This can produce a data plane leak, a connection between the actual user networks or a management or control leak that could allow one user to influence the service of another.

Ironclad practices and policies governing virtual connectivity can reduce the risk of an error like this, but it's very difficult to prevent one altogether. That's because of the indirect relationship between a virtual network that connects features and a real network that connects users. One remedy is to use a network scanner or inventory tool to search for devices and virtual devices on a virtual network and compare that result with the service topology that's expected. This can be run as the last step of a virtual network change.

Cloud-virtual networking introduces the cloud to networking, but it can also usher in server, hosting and virtual network security issues as well. Anyone who thinks these risks can be addressed through traditional means -- using tools and practices from the era when we built networks only from devices -- is going to face a hard reality, and soon.