Software Defined Networking (SDN) is a concept and a trend that is set to revolutionize the world of IT. SDN is not a panacea for all that ails networking, however, and it is not without its own set of risks that need to be addressed for secure deployment.
Christopher Hoff, Chief Security Architect at Juniper Networks, has a long history in the IT business of securing networks. When it comes to SDN, his view is that the same rules and best practices continue to apply in order to create a secure infrastructure.
“If we’re adding connectors or agents that let us talk between existing infrastructure and external controllers, we have to ensure that the communication path is well protected,” Hoff told Enterprise Networking Planet. “Today what that generally means is I’ll run SSL/TLS and do encryption on the transport with certificates and that’s about the extent of it.”
“That’s not really taking security concerns of attack vectors and threats too seriously,” Hoff added.
In an SDN environment, there are typically the networking devices that handle the actual traffic, then there is the controller that manages the flow. Sitting on top of the controller are SDN applications that provide functionality and capabilities to the network. Hoff referred to the SDN applications as ‘Trusted Apps,’ which also need to be properly secured.
Single Point of Failure?
In an SDN network, the controller could potentially be seen as a single point of failure risk for the network. If the controller is attacked, the entire network it controls is potentially at risk.
“Any time we put control and management capabilities outside of the routers and switches, we are expanding the attack surface,” Hoff said.
Are Controllers Secure?
Hoff noted that today, controller architectures are somewhat lacking when it comes to security.
“Some of the security, if you read through the specs, is optional,” Hoff said. “You don’t have to use SSL/TLS between the controller and the switch.”
Fundamentally, securing SDN is all about defense in depth, just as is the case with the rest of IT. Security professionals still need to think about how attackers might compromise a network and then develop an effective threat model to mitigate the risk.
Visibility into all the different layers that might exist in an SDN network is also critical to effective security. It’s visibility that involves both physical hardware as well server software and virtualization attributes and functions.
Source of Truth
When it comes to determining where control and ‘truth’ exists in an SDN network, there are multiple sources, which can further complicate security efforts.
“The persistency as well as the consistency of the types of data we’re talking about, some is very ephemeral and some is very long lasting,” Hoff said. “So you may not see a lot of network configuration changes but you might see a tone of network state changes.”
The OpenFlow model where there is a single controller that configures network assets is not how actual SDN is likely to be deployed in Hoff’s view either. He expects there to be multiple controllers in heterogeneous environments interacting with lots of other controllers.
How to Secure SDN
Securing SDN is similar to securing all other forms of IT. It’s about threat modeling, risk analysis and being able to attach policy to the workloads.
“I don’t think there is anything that SDN brings to the table, when we think from a threat modeling perspective, that we have not seen before, any time we’ve gone from a centralized to a distributed network back to centralized.” Hoff said.
With consist approaches like SSL/TLS encryption, SDN much like other IT capabilities can be secured.
“A lot of it is common sense and really understanding what the workflows look like, how the provisioning and orchestration systems are going to interoperate, auditing, logging and forensics capabilities,” Hoff said.
Watch the interview with Hoff below:
Sean Michael Kerner is a senior editor at InternetNews.com, the news service of the IT Business Edge Network, the network for technology professionals Follow him on Twitter @TechJournalist.
