Network Visibility for Flexible Security Architectures

Inline security appliances are a fact of modern network security architectures. There are a number of compliance drivers to deliver inline protection for traffic in a number of zones within the network, which can be a real pain for the network admins and architects. Even passive tools such as IDS and packet capture sessions can run into problems because of the limitations on the number of SPAN ports on data centre and campus switch platforms. Inline tools often suffer from severe performance constraints, especially now that 10Gbps has become commonplace. Chaining multiple appliances, all with different throughput capabilities, can become a real bottleneck for your services.

The chained use of inline security tools like IPS, WAF, SSL terminators, VPN concentrators etc., creates a stack architecture with multiple layers of security devices in the physical traffic path. Whilst this is good for security, it’s no good for latency or downtime sensitive environments where getting downtime to implement a new security tool or insert a probe into the network is tricky, to say the least. Not only that, but in a stack architecture, all security devices see all the traffic, even if they are not going to inspect any of it. What we need is a way to easily split traffic out from the stream and send it towards the appropriate device, whilst simultaneously making it easy to insert new inline devices.

One way to do this is to use a network visibility switch. I think of a visibility switch as a sort of advanced tap which is able to dynamically route traffic to the appropriate tool at layers 1 and 2. Other than this, the visibility switch is completely passive in the traffic stream and should be passing traffic at wire speed. This ensures that you have a flexible, low-latency solution that can be configured to send traffic of interest to specific tools and appliances.

How a Visibility Switch Works

A visibility switch is like a passive tap in the network that can dynamically connect ports in the chassis together. Advanced visibility switches can do this based on layer 2 to 4 inspection, using filters to choose a given frame’s path through the network. In this way, an visibility switch can be used to switch traffic that meets a given policy through an inline device, without the appliance needing to be in the physical traffic path. The visibility switch does not interact with the frame at all and is therefore invisible at layer 2.

For those of you worrying about resilience, consider this: in common with many inline devices, most aggregation switches can fail open in a power failure. Since they typically operate as passive devices, some visibility switches can operate normally without power at all, although this obviously means that they can’t be managed.

Using an Aggregation Switch

In the security context, visibility switches are typically deployed at the perimeter, where trunk connections from the edge firewalls commonly connect to service DMZs.

Adding an aggregation layer can improve security

The visibility switch can be inserted into the trunk, with security appliances hanging off on a logical network loop. For example, a visibility switch may be configured with the following policy:

INBOUND TCP/80 –> WAF
INBOUND TCP/443 –> SSL Terminator
OUTBOUND TCP/80 –> Proxy
OUTBOUND TCP/443 –> Proxy
INBOUND TCP/1433 –> DBF
OUTBOUND SUBNET 192.168.0.0/24 && TCP/9000 –> Probe
INBOUND ALL –> IPS
OUTBOUND ALL –> Firewall

Note that there’s nothing wrong with using the visibility switch to chain devices together either. For example, the following rule is perfectly possible to configure:

INBOUND TCP/443 –> SSL Terminator –> INBOUND TCP/80 –> WAF

This ensures that individual security appliances are not overloaded, and don’t need to be sized for the maximum throughput of the link between a service and the perimeter. This makes your security appliance purchase go further. The use of the visibility switch also ensures that you can insert new tools and filters without needing to recable, meaning that less downtime is required to implement new controls.

Dealing with Vendor Confusion

There are a number of vendors in this space, and because this is networking, they all seem to call network visibility by a different name:

• Gigamon: Traffic Visibility Fabric
• Anue (recently acquired by Ixia): Network Visibility Solutions
• NetOptics: Network Visibility Aggregation

If you do decide to go down the aggregation switch route, my advice would be to evaluate all of these vendors’ products against your specific use case. All of these vendors will handle 10Gbps feeds, meaning that you should be covered, at least at the perimeter. Each of the vendors has a different set of functionality that they can provide as well, so don’t assume that one particular vendor is always the right answer for all use cases.

Alternatives

Visibility switches, particularly the high-end ones, don’t come cheap. If you’re looking for an alternative, there are some other options:

1. Use PBR and L3-aware security gateways to route traffic sort-of dynamically. Prepare for hair loss.
2. Cable your data centre like Shelob’s lair to ensure traffic goes down certain paths and passes through the right appliances.
3. OpenFlow may be an option, if you’re already using it in your network. It’s possible to dynamically alter the switch path to ensure that traffic passes through the correct appliance.

In the long term, SDN may make visibility switches redundant other than for specific use cases. In the meantime, I think that they are a good option for deployments where you need defense in depth without needing to supersize every security appliance in the traffic path, and don’t want to take down the network to put in a new IPS.