Virtual network security can be an important element of software-defined networking (SDN). Virtualization of networks can deliver flexibility and efficiencies not present in logical networks based on hardware architectures.
When virtual networks are decoupled from the underlying infrastructure this makes them more dynamic and adaptable, taking full advantage of the fact that they consist mainly of software. The goals of virtual network security are the same as for any other network, but the strategies and deployment tactics can be somewhat different.
How Virtual Networks Protect
One of the original purposes of network virtualization was to provide isolation for the resources they host, thus limiting the scope of any attacks. Using virtual network APIs such as the libvert toolkit for Linux, an administrator may set up a sandbox for virtual assets, such as Palo Alto Networks’ WildFire. By default, this sandbox has no access to the outside network whatsoever – API functions enable the mapping between the two types of endpoints and the access level allowed to a specific network access at that mapping point.
The U.S. National Institute of Standards and Technology is in the midst of redrafting its security compliance standards, including those for Special Publication 800-125B, to update its suggestions for the application of network segmentation in virtual network security. One of NIST’s suggestions is the deployment of pairs of virtual firewalls (depicted above), enabling the addressable space between them to be apportioned as a “virtual DMZ.” Network engineers will recall the use of the wartime term “DMZ” to refer to a safe network area, typically along the perimeter, separated from the public Internet.
Virtual Identity and Access Control
Virtual networks are attached to the broader physical network by means of connection points such as virtual tunnel endpoints (VTEPs), or between endpoints managed by a virtual networking scheme, such as Nuage Virtual Routing and Switching technology. The virtualization serves as a bridge between the Internet at large and internal data center networks.
Because such virtual network resources are not IP addresses in the larger scheme, the virtual network security management tools and services that determine how they are accessed through physical IP – as well as by identities normally associated with physical IP (e.g., Intel Security Controller) – are different from management tools for physical infrastructure.
Administrators typically keep separate access control lists (ACLs) for virtual machines that may require access to virtual network resources. This is trickier than it seems, because these VMs may not necessarily reside in the virtual network; and since network access points are mapped using IP addresses, the mappings between the VM and the VN may be incompatible. Conceivably, the VM may be spun up and assigned an IP address on a subnet that has access through a VTEP, pursuant to rules, policies, and permissions.
With modern server-based and Web applications, however, resources may be contacted by way of the API. This simplifies the access control problem somewhat, since an API function may be accessed through HTTP, and the matter of granting or denying privilege can be left to the server application. In such instances, requesting entities may authenticate themselves by way of third-party identity providers. This way, VMs or containers need not traverse the network, transcending from the physical to virtual realm, just to obtain data or conduct transactions.
Fault tolerance over virtual networks can be accomplished at will, as opposed to after a budget negotiation, through the application of redundant virtual components. Cisco has demonstrated the efficacy of multiplying the number of control planes in use at any given time, simply to remove the impact of one unpredictable workload upon the remainder of the network.
Cisco’s scheme involves the use of virtual route forwarding (VRF, pictured above, courtesy Cisco), which takes advantage of virtual routers’ capabilities to behave in ways physical routers don’t. In this diagram, three separate control planes (blue, yellow, and green) are made possible by redundant virtual routers. Access points along these routes, or VNETs, are determined by way of IP network segmentation, and packets are labeled using tags that have been assigned to each VNET. As packets get exchanged from the edges along the outside to the trunk in the center, the virtual routers exchange these tags. This way, high-volume traffic such as videoconferencing can share the same infrastructure as low-volume text traffic, sent between the same two endpoints, without the two classes tagging along with one another.