The security pros and cons of SDN

Software defined networking (SDN) moves networking from hardware to the software plane, under management of a software controller. Benefits include automating and easing network administration duties and improving application performance. As a new technology, SDN is subject to vulnerabilities.

But with SDN, the industry knows certain vulnerabilities are native to the approach. First, according to Chris Weber, Co-Founder, Casaba, centralizing control in an SDN controller removes protective, layered hardware boundaries such as firewalls. Second, according to Gartner analyst Neil MacDonald, by decoupling the control plane from the data plane, SDN introduces new surface areas such as the network controller, its protocols and APIs to attack.

Third, and an advantage of SDN, the software controller can be installed on COTS hardware on top of an OS such as Windows or Linux, also COTS, saving implementation and other costs. But according to Ramsey Dow, a Partner at Casaba, a host of historically recurring attacks such as buffer overflows that lead to remote code execution plagues these operating systems. And that places the SDN controller at the same risk as the OS.

[Still going rogue in the cloud]

Fourth, due to the centralized nature of an SDN controller, an APT only needs to compromise that controller to affect and potentially gain control over the entire network.

To rest easier, follow CSO on this journey through SDN security concerns and the options and controls that help.

SDN Vulnerabilities: Drilling Down

“My biggest concern with SDN is that we’re removing time-honored physical segmentation from the network design and virtualizing all of it,” says Dow, speaking of how SDN replaces layers of firewalls, interior switches and other hardware boundaries that have protected the traditional network with a virtual network.

And when SDN peels these layers away, it replaces them with an exposed layer of highly sensitive network skin, ripe for attack. “SDN creates an abstraction layer, says MacDonald, revealing new surfaces such as the network controller, the OpenFlow protocol, protocols such as XMPP that SDN may apply (depending on the implementation), and even vendor APIs to attack.”

And just as the northbound side of the control plane becomes vulnerable, so does its underbelly. By installing the SDN controller on top of Windows, even on top of Linux, the enterprise opens it to all the software issues that repeat for everyday computer operating systems.

The latest security bulletin from Microsoft acknowledges five new Windows security vulnerabilities, all capable of enabling remote code execution. Developers also recently discovered four new vulnerabilities in Ubuntu, a popular Linux distribution.

Despite OS vulnerabilities, new attack surfaces, and disappearing hardware boundaries, the most common attack vector for new technologies most likely to beset SDN is misconfigurations. “Most attacks make use of misconfigurations rather than vulnerabilities,” explains Neil Rerup, Author, “CyberPeril” and CEO, Enterprise CyberSecurity Architects. Rerup illustrates with a real-world example of a Cisco UCS misconfiguration:

An enterprise implemented a Cisco UCS, which operates under the same concept as an SDN controller except in scope, addressing servers rather than networks. The organization deployed the UCS with nothing but the default settings, UIDs and passwords configured and with none of the controls that were necessary to secure it.

“I could access the control plane because the default roles were in place, the default passwords were not changed, and access to the control plane was through the normal network connectivity used to access the underlying device contexts,” says Rerup.

Because SDN controllers are relatively new and most security personnel do not properly understand them, according to Rerup, the necessary controls are frequently not in place. “Security has always been viewed as an ‘add on’ to solutions,” says Rerup. While new technologies come along that enhance productivity and drive costs down, Rerup continues, this typically happens without due consideration to an enterprise’s security posture.

[7 essentials for defending against DDoS attacks]

Whatever the culprit that enables APTs to usurp authority over SDN controllers, full network compromise can result. As an application system that communicates directly with network devices via protocols that traverse those devices and with the applications living at the other end of the network, the SDN controller is a software system that brokers communications between all components. “By their nature, these controllers have their fingers in everything. If you were to exploit a controller, you would potentially enable unfettered access to the environment,” says Dow.

SDN Security Measures

Little can replace traditional hardware boundaries. Include securing SDN communications in the effort. According to Weber, always require strong versions of core communications protocols between the administrators controlling the devices and between the devices on the network. “Always prefer authenticated, encryption protocols,” says Dow. “Prefer TLS 1.2. Avoid using weaker cipher suites,” Dow says.

To protect the new surface areas, reduce exposure. “Reduce the surface area for attack by hardening the controllers and protocols,” says MacDonald. Using hardened configurations of embedded Linux for the OS, hardening the APIs by using effective identity, authentication, and authorization technologies, and using application whitelisting to prevent unauthorized code execution are some examples of how to do this.

In addition to hardening the OS, remedy the insecurities of an SDN controller riding on Linux or Windows by taking several layered approaches. First, track down the vendor’s best practices for security configurations and follow these.

Stay up to date with patches. “Your operations staff will have to be more proactive than normal in monitoring advisories from multiple sources,” says Dow. Sources include vendors such as Cisco or Juniper (i.e., the vendor concerned) and security organizations such as CERT and NIST NVD.

“Use a fully-functioning, tested incident response program,” Dow continues, “so that if you detect something, you can respond.” Acquire and leverage a support contract for all mission-critical hardware.

“Your vendor should also offer a strong SDN authentication protocol,” says Weber. That means two-factor authentication or greater. The vendor should include a role-based authorization mechanism to assign access levels, permissions, and privileges.

As for misconfigurations, there is a range of best practices that enterprises should use to avoid these and to have the proper security controls in place. Start by treating SDN vulnerabilities the same as vulnerabilities in any virtual solution. “You have to deal with the control plane as an elevated area of privilege,” Rerup says. Enterprises should use the following controls to manage what happens inside the control plane, according to Neil Rerup.

[Too many CSOs ignore the reality of today’s threats]

Manage the SDN control plane out of band, separating the path to it from the path for normal traffic. Remove all default configurations from SDN. Vendors broadly publish these and hackers routinely use them.

Log all activity by privileged accounts and forward the logs to the SIEM (Security Information and Event Management) security log aggregation point for central access. “If you monitor what a privileged account does, you can catch mischief and mitigate it quickly,” says Rerup.

Design your SDN implementation assuming potential failure. “If you do that, then you are also considering what will happen if the SDN is intentionally taken offline,” Rerup explains.

Back up SDN configuration files frequently so it will be easy to get the SDN up and running should it fail. Finally, apply the same security requirements to the SDN control plane that the enterprise would apply to the highest security zone that can leverage SDN.

Some of these measures are old hat; some are new or newly applied. The discussion is ongoing. Consider the alarm sounded. Did we sound it too early? Only if no one ever says, “I told you so.”