Virtual network security measures to thwart access threats

1. Connection policies and address validation

Virtual networks ride on real networks -- usually, IP networks, such as IP VPNs or the internet. Every virtual endpoint is also a real network endpoint, and it's possible to either jump onto or attack the virtual network from the real network or endpoint below. It's a mistake to think virtual network overlays will solve security problems; the real network still has to be secured.

Generally, improving virtual network security means creating forwarding policies between subnetworks. In IP networks, all users and resources are connected via subnets with their own defined address ranges. If these subnets should only support connections with certain other subnets, enforce those limits at the subnet boundary using filtering policies.

Another important element in virtual network security is performing source address validation on packets to prevent spoofing. Every packet in an IP network will originate in a subnetwork, and the address of every subnet member is assigned from a range of addresses. If the gateway device for the subnet checks the source address of a packet to ensure it is within the subnet range, it greatly reduces the risk of intrusion through spoofing.

2. Secure gateway access between networks

A related security point is on-ramp security for virtual networks -- securing the gateway points between networks and subnets.

A virtual network will normally have a number of places where its users can access outside resources like the internet and outsiders can access virtual network resources. This connectivity has to be provided explicitly through one or more virtual network gateways, which must enforce access policies to ensure unauthorized connections aren't made at those connection points. An open connection between an organization's virtual network and the internet could potentially act as an entry point for hackers into the larger enterprise network.

Only defined access points in a virtual network should communicate outside the virtual network. Any attempted connection directly to the outside at another point in the virtual network should be considered a breach in security -- and, potentially, a hack, malware or denial-of-service attack.

3. Connection access control

It is important to note that limiting communications to the outside won't eliminate the need for virtual network access security -- on-ramp connection policies are designed to keep intruders out, not keep users in line. More specific connection policy controls are vital to keep network users from maliciously or inadvertently leaking data. Virtual network implementations vary widely in terms of offered connection security features. This is particularly true with SD-WANs, which can augment MPLS VPNs by adding sites where MPLS isn't available or is too expensive to deploy. The right SD-WAN implementation can greatly improve connection policy controls, in turn improving network security across the board.

Most SD-WAN implementations don't offer incremental connection security features, however, which means users will have to provide connection and access control rules for network traffic below the SD-WAN, i.e., in the underlying IP network. About 15% of SD-WANs offer specific connection policy control, and only a few provide explicit session and connection controls for all traffic.

Explicit connection control at the virtual network level is the most significant advancement in network and IT security. Most network security mechanisms now focus on keeping intruders off the network, which isn't helpful against people who have the right to use the network and elect to misuse it instead -- i.e., insider threats. With explicit connection control, enterprises can define which users and resource sessions they consider valid, and all other connections will be barred. Explicit connection control replaces permissive connectivity, the existing IP network presumption. While some users might consider it a burden to determine in advance the range of valid connections, something like this is always necessary in security management. The task can often be completed by classifying users and resources by role or subnet, thus reducing the number of rules that need to be defined.

To use connection security features, organizations should be sure not to weaken them with excessive generalization. If rules admit connectivity between all members of two subnets and then broaden who or what is in each of them, an organization may inadvertently create a security hole.

On the horizon: NetDevOps

If there's a Wild West in today's networks and virtual network testing, it's control and management plane security. Virtual networks add a set of elements and control and management APIs. If these are not secured, a hacker could gain partial or full control of a virtual network and be able to disrupt users, steal information and disable applications. While virtual networking vendors do their best to harden control and management plane interfaces, one more step is necessary: NetDevOps.

Errors are, in part, proportional to the number of things that have to be done -- things being anything requiring manual intervention, such as adding networks layers or features that require human setup and operational support. Virtual networking adds a layer of such things and thus creates more potential for error. The interplay between virtual and real transport layers also adds complexity. Errors in network configuration can not only impact stable operations, but also security. Using NetDevOps automation similar to that used in cloud deployments -- DevOps -- is the final step in creating secure networks and securing IT overall. With proper operations automation, virtual networks can improve security rather than creating new holes to fill.