Given the National Security Agency's much-publicized propensity for implanting backdoor hacks into IT infrastructure,...
software-defined networking (SDN) must look like a nice squishy target to spies and crooks.
"The NSA thing got me thinking about it again," said Nick Buraglio, a network engineer who works with a global network. "What does it mean when your forwarding plane and control plane are decoupled in completely separate boxes and your control plane is just a Linux box or two? What if someone compromises that box? They can shift your flows any way they want."
The ONF has identified two basic SDN security issues
The SDN community is very aware of the problem. The Open Networking Foundation (ONF), steward of the OpenFlow protocol, published a paper last October that identified two potential SDN security issues, or avenues of possible attack that the industry must address:
- The centralized controller is a "potential single point of attack and failure."
- The southbound interface -- such as OpenFlow -- between the controller and data-forwarding devices is "vulnerable to threats that could degrade the availability, performance and integrity of the network."
"The first thing we hear from customers is, 'We see security as the No. 1 inhibitor to SDN,'" said Matthew Palmer, co-founder of SDNCentral.com and a partner at Wiretap Ventures, a consulting firm for SDN vendors and cloud service providers.
The SDN controller will be a target
The SDN controller is a prime target for hackers because it is both a central point of influence in a network and a potential central point of failure.
"If somebody is not paying attention to [the controller], it becomes an extraordinarily high-profit target for an attacker, who could very easily compromise [it], modify some of your code base and rescript control of your traffic in such a way that it's ex-filtrating data or stashing data somewhere where an attacker can sniff it," said Dave Shackleford, security consultant with Voodoo Security and lead faculty member at IANS.
"There are so many opportunities for an attacker to make changes to the whole underpinning of your network traffic behavior just by modifying your controller. We've never really had that before. Even traditional network management tools didn't give you the flexibility to dynamically change the behavior of a network on a node-by-node basis."
Dave ShacklefordVoodoo security consultant and IANS lead faculty member
The programmability of SDN controllers presents a double-edged sword. Engineers can install security applications on the controller's northbound interface to open up new ways to apply security policies on a network. Those applications instruct the controller to use the switches and routers that it controls as policy enforcement points.
However, that programmable northbound interface is also a potential vulnerability. Those applications can reprogram the network through the controller. Hackers can trick engineers into installing compromised applications. With enough knowledge about the benign applications running on a controller, a hacker could make the network do something completely unexpected by the network manager just by sending a carefully crafted packet stream to the network.
"OpenFlow applications have the ability to contradict each other," said Phil Porras, program director at SRI International, a nonprofit research and innovation center. "They have the ability to insert rules that, when combined, have some interesting interactions that one didn't expect or want to happen."
SDN controllers generally lack the sophistication to understand that security applications should have priority over other applications that communicate with it. Even a harmless application can break security policies if the controller doesn't understand how to handle application requests that contradict security policies.
"Imagine [that] an OpenFlow security application decides an internal machine is operating in a way that makes you believe it's infected," Porras said. "The security application quarantines the machine and removes its ability to communicate with the network. At the same time, a load-balancing application might look at that machine and say it's the least loaded machine on the network. So the load-balancing application decides to start diverting traffic into that machine that's been quarantined."
SE-Floodlight: A model for a smarter, secure controller
"We're working on ways to constrain [SDN] apps such that you can guarantee that certain policies are always enforced," Porras said. "Those OpenFlow apps aren't necessarily malicious. They may just have no idea what the security policies are."
Porras has developed SE-Floodlight, a modified version of the open source Floodlight OpenFlow controller, which is designed to ensure the integrity of security applications.
"SE-Floodlight … introduces the notion that OpenFlow apps can run with [hierarchical] roles. Those roles are assigned using digital authentication," Porras said.
With SE-Floodlight, engineers can assign security applications a higher priority than any other applications, he said. When a load-balancing application sends a flow rule to the controller that conflicts with the policy of a security application, the controller can reject that rule. It can also send feedback to the load-balancing application so it is aware that it needs to find another way to direct traffic.
"I see the work we're doing [with SE-Floodlight] as a prerequisite if we are ever going to incorporate OpenFlow into financial services networks, healthcare networks or government networks. We're going to need a strong security model to make sure we're not making things weaker by adding SDN," Porras said. "I think both [SDN vendors and standards committees] are taking a hard look at security architectures for OpenFlow. I've been in touch with a variety of vendors that care about this topic."
Southbound interface security
The ONF also identified the southbound communications between controllers and data-forwarding devices as vulnerable. Southbound interface protocols such as OpenFlow have fundamental authentication technology that prevents a hacker from spoofing flow commands from a controller to a switch. However, engineers should ask SDN vendors for proof that they have implemented authentication certificates between controllers and SDN switches properly, Palmer said.
But hackers probably won't try to hijack the southbound interface because there are easier ways to disrupt it. Hackers might target controllers, switches or even virtual switches with denial-of-service attacks.
"Someone can saturate or keep the control plane busy or keep the interface between the control and data plane saturated," Porras said. One could slow down the entire network. We can see adversary models where the 'targeter' is not trying to bring down your network, but is crafting strings of packets to saturate data plane and control plane interactions."
What should you do about SDN security issues?
Engineers shouldn't necessarily steer away from SDN because of these security concerns. Every environment has different levels of risk tolerance. And most SDN deployments today are in the pilot or proof-of-concept stage. However, engineers can take steps on their own to protect the SDN stack if they have concerns.
"Lock [the controller] down as best you can," Buraglio said. "Don't let anything in or out that doesn't need to go in or out. Keep [the controller] up to date. Baseline it. Keep records of CPU level, memory utilization, interface statistics. Collect all that data and then set thresholds and alerts on it."
Engineers will need to apply the same level of security to SDN controllers that they apply to the systems that house sensitive data, such as credit card numbers and intellectual property, Shackleford said.
"You've got to look at things like integrity monitoring, extraordinarily vigilant logging, multifactor authentication for access," he said. "You have to make sure those things have tiered, layered access.
But mainstream production deployments of SDN won't happen until the security and integrity of the technology is proved out, Palmer said. Controller vendors in particular will have to prove this to potential customers.
"It's not a security problem," Palmer said. "It's a compliance problem. Unless they can prove to the compliance team's satisfaction that SDN is just as secure as the [legacy] network, they're not going to sign off on a deployment."
Palmer expects vendors to start proving the security of the SDN stack in 2015. "2014 is the year of the [SDN] proof of concept," he said. "People are doing trials. I think the critical security functions are going to rise to the top. But we're still a year or 18 months away before a lot of these security features will make their way into controllers and the rest of SDN products."