Software Defined Networking Enhances Security Management

Software defined networking (SDN) is touted as the greatest development in recent tech history. I agree. It provides a way to centrally manage an entire network infrastructure quickly and consistently. It also provides significant improvements to incident response activities and enhances prevention by enabling vendor diversity.

An Overview

Network devices, such as switches, possess two capabilities: internal configuration and packet management. Until the advent of SDN, locating both on a device usually required device-by-device configuration of access control lists and other packet management controls. This resulted in the traditional complexity shown in Figure 1.

If the network admin wants to block all traffic to Server A except for Desktop 2, multiple switches are involved. The trick is to configure the right switch, or switches, to accomplish this. In a large network, this can take time with a reasonable probability of missing something.

This became more complicated as organizations implemented an additional layer of switching: the edge. Edge switches, as shown in the yellow area of Figure 2, connect devices to the network, connect two different trust zones (including two different networks), etc. Further, edge switches are increasingly virtualized, as server virtualization became the norm in most data centers. A new approach to network management was needed.

According to Scott Shenker (video of 2013 talk at Stanford), director and chief scientist of research initiatives at UC Berkeley, the initial SDN model abstracted the control portion of network devices to what is called the control plane. What remains on the device is the data plane: the functionality that actually moves or blocks packets. See Figure 3.

The administrator uses the control plane, via a management portal, to script or otherwise provide instructions to control traffic in a certain way. This is sent to the Network OS for implementation. The Network OS is simply special software running on a server. Implementation is accomplished by sending the proper reconfiguration commands to the relevant devices. The command interface is currently standardized in OpenFlow and its derivatives.

The approach in Figure 3 still requires knowledge of the network infrastructure at all layers: virtual and hardware-based. Additional simplification was needed. Recently, the model was expanded to include a virtualized network layer (Shenker), as shown in Figure 4.

The virtualized network presents to the admin a picture of the infrastructure, allowing easy identification of relevant components during network reconfiguration. Shenker believes this might be the most important concept to arise from current SDN models. It helps alleviate complexity and improves efficiency when minor or major network changes are rolled out.

Importance to Security

Complexity is the enemy of security, often resulting in higher then acceptable risk due to inconsistent network device configurations. SDN helps with this. The SDN management portal, within the control plane, allows an admin to plan a rollout or remediate risk with a holistic view of the infrastructure. This is possible because the virtualized infrastructure layer helps simplify views of device relationships. It also helps prevent misses because one or more devices might be forgotten during design.

The network OS layer automatically sends configuration information to all relevant devices without the need for human device-by-device adjustments. Removal of the human element from multi-device configurations is a good way to get closer to optimized consistency across all infrastructure components.

Another benefit of SDN is the ease with which a response team can apply certain traffic restrictions during a business continuity event. For example, during a breach, we want to quickly shut down all points of ingress for an attack in progress or all points of egress for attacks that have already reached their targets. This is an important piece of the containment phase in an incident response plan.

Using the SDN portal, an admin or member of the response team can quickly identify and apply containment configurations to choke points. In addition to case-by-case closing of choke points, SDN allows the application of pre-existing scripts. The existence of choke points, of course, depends on how well you manage network segmentation. At the very least, you should be able to quickly isolate the data center.

Finally, part of a defense-in-depth strategy is implementation of different vendor solutions at various infrastructure layers. A common example is using firewalls from two different vendors to create security zones. If a vulnerability exists in one device, the other might just stop an intruder. The problem with this approach is often based in lack of skill sets. Organizations usually can’t staff IT with experts on multiple vendor infrastructure solutions.

SDN helps with this by removing any need to understand device command line interfaces when performing standard configuration tasks. The virtualized network layer can be vendor neutral, relying on the Network OS/device interface to translate control plane commands into formats each device understands. SDN does not eliminate the need for command line tweaks if problems arise, but it can make every day management possible without maintaining highly skilled network engineers on staff.

The Final Word

No technology is a panacea for IT ills. SDN is no different, regardless of vendor spin. However, SDN is a huge step forward in our path toward consistent infrastructure management and faster incident response. However, I advise caution.

No single standard yet exists: except maybe OpenFlow. Each vendor, including Cisco, is vying for standardization of its SDN vision. Keep this in mind as you explore SDN possibilities for upcoming budgets.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.