How to securely get started using SDN (2024)

Though some might argue that it's inherently insecure, SDN has changed for the better in recent years, allowing it to be implemented securely

Several security experts suggest that software-defined networking (SDN) is natively unsecure. They say it removes hardware boundaries such as firewalls that maintain security. They say SDN reveals new, unprotected surfaces to attack. These experts put forth a number of SDN vulnerabilities.

[SDN: The security pros and cons of using it in your organization]

Perhaps those experts are thinking of a classic, yet immature SDN. “SDN has changed a lot in five years,” says Vik Mehta, CEO, VastEdge, a software application services firm with an SDN practice. As we learn more about the technology, maybe we can agree that there are two sides to the SDN security coin.

As SDN ages, it increasingly secures itself using resources that become available as the technology blossoms. Consider how to apply a mix of common sense and SDN’s strengths to intrinsically and dynamically protect the technology from within. Get started with today’s SDN with state-of-the-art tools and approaches. See how SDN security done right holds up in the data protection prize ring.

Transition Using Proper Steps

To securely get started using SDN, the enterprise must correctly get started using it. “SDN is a transition from a configurable to a programmable network,” says Mehta. There are steps in that transition that the enterprise cannot ignore.

First, the enterprise must integrate every device, whether a load balancer, firewall, telecom system, wireless controller or storage system into the SDN controllers. “SDN vendors have tools that abstract or migrate the configurations out of the switches and move them to the SDN controllers,” says Mehta.

[Key recommendations for SDN IT buyers]

OpenFlow is an open protocol for controlling traffic flow across multiple switches through a centralized controller. OpenStack is an open source software initiative for building clouds based on network connectivity as a service between network devices managed by OpenStack devices, Mehta explains. Choose either OpenFlow or OpenStack from the start based on the enterprise’s existing investments in network technology and the kind of SDN network the enterprise needs.

When abstracting or migrating the configurations out of the switches, carefully define security policies for full migration, realizing that vendor tools can extract security policies and put them on the SDN controller as well.

“The second step is to carefully test and deploy SDN controllers,” says Mehta. Create a test environment where network devices talk to the controllers to see that everything is working. Having selected either OpenFlow or OpenStack and vendors aligned with one or the other, the enterprise should be able to ensure successful communications between devices and controllers.

“The third and most critical step is to SDN enable the applications,” says Mehta. To poise applications to fully leverage the SDN network, apply rules such as prioritizing order data over reporting data so the most important data flows smoothly through the network first. Through SDN enabling, the enterprise can equip applications to send additional identifiers in the header and not simply the protocols, tcp/udp and port data. “SDN controllers will have to identify packets using headers without having to read the entire data to identify the data types,” says Mehta.

At this point, the enterprise should also build security into the application layer. Enterprises can add rules-based security at layer seven by first identifying appropriate and inappropriate application interactions and then applying conditional rules based on behavior (if this behavior appears, do this). “A lot of companies are aggressively working towards that, including Juniper and Cisco. That’s why those networks are so successful,” Mehta says.

[Why network security is the foundation for cyber strategy]

Once the SDN network is in place, the enterprise should monitor the network through the SDN controllers. “Some companies separate the monitoring function from the controllers, for application monitoring and packet monitoring, for example. These use monitoring tools that sit at a higher level and interface with the SDN controllers, network and applications,” says Mehta. The enterprise should also monitor the security policies.

Common SDN Security Concerns Solved

A properly deployed SDN network using appropriate security measures mitigates SDN security concerns. For example, some security experts have stressed that SDN removes layered, protective hardware boundaries like firewalls. But, SDN actually monitors packets at multiple levels throughout the network, from the load balancers to the firewalls to the applications to the wireless LAN controllers to storage and to telecom phone systems, Mehta explains.

Through centralized control of the network topology together with service chaining capabilities, SDN produces security methods in ways that were not previously possible. “The administrator can deploy firewalls, IDS/IPS and other security measures in conjunction with changes in the network, dynamically in real-time. This enables SDN to introduce stronger security practices and overcome challenges that hardware boundaries could not,” says Randal Asay, CTO, Catbird.

Security experts argue that decoupling the control plane from the data plane creates new surface areas such as the SDN network controller, protocols and APIs that are open to attack. But, the control plane is an elevated privilege and the enterprise needs to secure it just as it would any other elevated privilege. Elevated privileges require elevated logging and monitoring. “The control plane should have expected activities and be highly sensitive to any anomalies or unexpected logins or activities,” says Asay.

The elevated privilege of a decoupled control plane also requires that the enterprise limit administrative access. “The controller should be highly regulated, accessible by only a few administrators. Much of the work is done at the API and so configurations to the controller should be minimal, requiring few access privileges,” says Asay.

With a decoupled control plane, API communication should be restricted to known endpoints on the network. “API communication is between network nodes. Enterprises should close APIs, ensuring they communicate only with registered devices on the network via a secure channel. In the event nodes on the network are compromised, this will limit the capabilities of the compromised devices,” Asay says.

Security experts suggest that an SDN controller installed on COTS OSs is subject to the same attacks that typically plague the OS. However, an enterprise should not program the OSs to permit installations, traffic or running services other than those necessary for SDN controller function. “Users won’t be able to go to a command prompt, install browsers or open explorer windows,” says Mehta.

[HP to scale up TippingPoint network security with SDN]

An enterprise should further secure the controller by carefully managing patches and updates and thoroughly leveraging AAA server controls. “Treat an SDN network controller much as you would treat a domain controller. It is a critical piece of infrastructure and requires a higher level of attention,” says Asay.

Security professionals have said that an APT need only compromise the controller to bring down the network. But, an APT is not a concern if the enterprise uses common sense, ensuring that it never connects the SDN controller to the Internet.

There are concerns and uncertainties about what will happen under extreme load conditions. But, centralized SDN controllers intelligently manage loads by prioritizing packets across the entire network, without having to write rules across individual switches, Mehta says.

Finally, there is the uncertainty about how individual network nodes will handle line rate traffic. There are a couple of ways to address the node line-traffic concern. One is a rate proxy, which only allows as much line rate traffic in as the node can absorb. “This is not optimal and is more of a defensive measure,” says Asay. The other method is to improve the communication capabilities on the individual nodes. “As virtualization and SDN evolve, vendors are producing faster and more robust nodes for better communication,” Asay says.