Sidestepping SDN Security Woes

As IT departments consider the potential security upsides of building out software-defined networking (SDN) infrastructure, they should also mull over the flip side of the coin. The earlier they can prepare for SDN control issues and bake in protection, the less likely they'll be surprised by security issues that could present themselves without proper foresight, experts say.

Even if it can be used for the greater security good, SDN is a design strategy, not an out-of-the-box security tool. That means security needs to be thoughtfully architected from the beginning.

"In some ways, SDN is just another concern for security people -- another thing that needs to be protected," says Reuven Harrison, CTO of Tufin Technologies. "It's not like security is automatically provided by SDN."

And in spite of paradigm shifts in the way networking is done, some of the same problems will stick around, Harrison says.

"When SDN does become more popular, it will have a very similar problem to today's problems because it will be different vendors with different APIs. Although there is a standard, the vendors aren't actually following the standard, and so there will be multivendor complexity," he says. "It's another big business problem we'll need proper management, automation, and orchestration to be able to control."

According to Christofer Hoff, vice president of strategic planning for the security business group at Juniper Networks, the increased dependence on automation and the interconnectivity between network controllers in an SDN network will actually make the security basics even more imperative than it is today.

"We really have to make sure the Is are dotted and the Ts are crossed, so that we make sure we have strong authentication, and that we don't allow elements like SSL/TLS and encryption be optional between, let's say, a forwarding plane and a control plane," he says, explaining that the increase in controllers will expose northbound interfaces to other applications that will interact with the controller and the rest of the network. "If I start opening up the crown jewels of my network, the control plane, to external elements that beforehand had to go through these disintermediated correlation elements, we really need to make sure we nail that."

Additionally, with controllers requiring a secure, dedicated connection to elements they're managing, the threat of denial of service and the risks caused by it go up.

"So we need to ensure that these different elements-- the controllers, the forwarding nodes, the analytics planes -- are protected against denial of service," Hoff says.

Perhaps more importantly, though, is the issues arising from SDN's consolidation of control.

"In a centralized architecture like SDN, the central control framework for network services is the absolute arbiter of connection rules, and if you compromise it, you have compromised everything," says Tom Nolle, president of CIMI Corporation, a strategic IT consultancy. "With centralized SDN, now there's this nice, convenient central place to attack, and if you successfully attack it, you gain complete control of the network."

And attacks against that control plane aren't the only risk posed by this central arbiter of policies. There's also the issue of policy collisions, says Hoff, explaining that while SDN enables automation, without proper management of the policies that drive the automatic control of the infrastructure, problems may well lurk.

"There are any number of scenarios you can paint where you imagine administrator A and admin B, both of whom are trusted users and not doing anything bad," he says, "but they could do things that could cause all sorts of problems with visibility and transparency that might be difficult to troubleshoot."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.