Network security basics for building better corporate systems
A comprehensive collection of articles, videos and more, hand-picked by our editors
Software-defined networking is supposed to improve networking, including network security, according to most of...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
its proponents. But software-defined networking security has holes, according to a new group of SDN security vendors. Both statements can be true, depending on what you mean by network security, what you mean by SDN and how you put your SDN plans into place. Smart planning always reduces risk, but that's particularly true in the case of software-defined networking security.
Many popular industry terms get used too broadly, and SDN is one of them. Software-defined networks, according to some, are software overlays built on top of existing devices -- like software-defined WAN, for example. Others think SDN is any network with a set of APIs to allow for software control, even if the underlying devices are the same boxes that have been used for years. Overlay SDN security depends on how the overlay network is built, while software-API security depends on the security of those APIs, which is also implementation-dependent. In either case, prospective users will have to augment existing network-layer security to include these new features.
SDN, in its purest form, replaces networks built from devices that cooperate to build forwarding tables with devices that centrally control routing-table forwarding. In this kind of SDN, every data pathway is explicitly created by building forwarding rules in all of the devices involved. Even failure modes that respond to hardware or connection faults can be defined in advance. OpenFlow is commonly used to establish forwarding rules in each device, and the sum of these rules creates the connectivity offered by the network. From this connectivity, the good of SDN flows.
The good of SDN security
The good thing about SDN from a security perspective is explicit route connectivity. In traditional networking, the devices cooperate to establish paths between all network users. If some of these paths represent invalid or insecure interactions, it's necessary to build a firewall process to block them. With SDN, it's possible to define only valid routes; other packets would simply be dropped.
The ability to route in this way means a properly designed software-defined network has a layer of connection security that's not available in traditional IP or Ethernet networks. As long as route creation matches your connection policies, good SDN design will prevent connectivity that doesn't match those policies. The trick is getting that properly designed software-defined network into place.
The bad of SDN security
A properly designed software-defined network starts with the SDN controller, and the bad of SDN security hinges on the way the controller is implemented. Because the SDN controller is the heart of software-defined networking, any central control or management process has an almost literal power of life or death over networks. It is absolutely critical, then, that the controller itself is secure. It must run on a trusted platform, with maximum trust validation of new applications or new platform components. Anyone who controls the SDN controller owns the network, so security is meaningless if the controller is compromised.
The next variable to consider in software-defined networking security is the relationship between the centralized SDN controller and the devices controlled -- by OpenFlow or some other forwarding control mechanism. Two different approaches are available: One depends on predefined routes, and the other supports routes on demand.
In the predefined route model, the SDN controller uses traffic management and analytics to define where it wants traffic flows to go, building a complete connectivity model for the network. Traffic coming into the network is forwarded according to those rules, and rule hierarchies can be defined to respond to changes in basic network conditions.
In the on-demand model, an SDN switch that receives a packet will first see if the packet has a forwarding rule. If it doesn't, the switch will send a route request to the central controller. The forwarding control response can be calculated based on current conditions, and the process can be repeated for the next switch along the route.
Both of these approaches pose a security challenge in the connection between the controller and the switches. Anyone who gains access to the control path has complete control of a given switch -- perhaps of the entire network. Furthermore, the control paths themselves could fail because of a device or connection failure. The result could leave a portion of the network out of contact and subject to either misrouted packets or deliberate hacking.
The on-demand approach is especially vulnerable to failure-generated disconnects of the control path to devices, because backup failure modes aren't normally predefined. If you plan to use this model of SDN, it's critical to ensure you have a reliable way of keeping the controller's path to all switches up and running.
On-demand SDN also creates a risk of distributed denial-of-service attacks on the SDN controller. If a large number of packets without current routes are introduced in the network at multiple points, the result can be a flood of requests to the controller that swamp its ability to respond to legitimate route requests. This would render the network unable to create new routes for new users or applications.
The ugly of SDN security
Proper practices are obviously critical to software-defined networking security; otherwise, the additional risks will swamp the possible benefits of explicit connectivity control. That's the ugly part of SDN security. Early deployments suggest the two biggest risks are the introduction of insecure applications and components into the controller and the failure to properly plan routing policies at the controller level to sustain network-level security.
To secure the controller itself, keep controller servers and virtual machines (VMs) separate from any other resource pool. This will prevent accidental cross-talk with insecure applications or contamination of tight SDN controller security practices. Don't run other applications on the same server or VM, if possible. Where that's not possible, require a stringent trust-management process to validate the components. Require formal application lifecycle management for all SDN controller components and related applications.
Route planning is much more complicated. One possible approach is to define internal routes between switches based on a formal set of preplanned routes and failure modes. These can be fully connective, which means they will pass all packets they receive. Then, use the edge devices, where traffic is introduced from users and applications, to police access to these central routes.
Software-defined networking security depends more on planning than glued-on security elements -- or it should. If you don't plan correctly, you can expect SDN to not only pose the same risks as traditional networks, but to add in new controller-related risks, as well. That's neither an optimal use of SDN, nor is it a smart way to build your future network.
Explore SDN security pros and cons
SDN security is something to be concerned about
A look into potential SDN security challenges