How to secure the SDN infrastructure

The trend may be towards implementing software-defined networking (SDN) in organisations, but it must be secure from the start.

SDN is still in the early stages of adoption, but is growing. According to a Gartner SDN session in June 2014, only 4% of organisations were in the process of deploying the technology, but other research shows that many firms are keen to adopt it.

Infonetics Research's 2014 SDN Strategies: North American Enterprise Survey found that 45% of enterprises will have SDN live in production in their datacentres in 2015, a figure that will rise to 87% in 2016.

SDN is rapidly gaining ground in organisations, despite its nascent status. Given how the trend is developing, how should an organisation deploy SDN in a secure fashion?

Get right skills mix

Brent Lees, senior product marketing manager at Riverbed Technology, says there are security risks in implementing a technology that is still in its infancy. One of the biggest challenges for organisations is having the necessary skills in place to ensure SDN's vulnerabilities are not exploited by malicious attacks.

“Learning a completely different security architecture will be a challenge in itself,” he says. “Furthermore, the same open interfaces and known protocols in SDN that simplify network programming also present opportunities for attackers.”

Vectors for attack

It is the separation of the control plane from the forwarding plane that could prove a security issue for organisations using SDN. The architecture is divided into three layers: the application layer, the controller layer and the infrastructure layer, with the latter including the applications and services that configure and request the SDN infrastructure. All three can be vectors for attack and the problem is compounded by the fact that the technology adds an extra level of complexity.

“SDN completely changes the security model,” says Steven Harrison, lead technologist atExponential-e. “What is worse is that because many SDN technologies rely on new overlay and encapsulation techniques, many of our current security tools are not able to really inspect and understand SDN traffic.

“In the same way as virtualisation made servers instantly both more and less secure – more because of the abstraction layer, less because you no longer needed physical access – we see this pattern repeated with SDN.”

If the deployment of an SDN infrastructure disregards security, an organisation will be exposed to attack. Let us look at how each of these layers could be attacked and how best to secure them.

Data layer (southbound)

A number of southbound APIs and protocols are used by the controller to communicate on the network, such as OpenFlow (OF), Open vSwitch Database Management Protocol(OVSDB), Cisco onePK, and Application Centric Infrastructure (ACI), to name but a few.

Each of these employs its own way of securing communications, but these are new and may not have been developed with security fully in mind.

The ability to use APIs to create more user-friendly management interfaces increases the attack surface of the network infrastructure considerably, because security is no longer limited to the network equipment supplier, says David Chismon, senior security researcher and consultant for MWR InfoSecurity.

“The security of your network could potentially be thwarted by an insecure implementation of the management application,” he says.

This could easily allow an attacker to add their own flows into the flow table and spoof traffic that would otherwise be disallowed on the network.

Securing the data layer

SDN systems typically use general-purpose x86-based systems and TLS to secure the control plane, but sessions with a long life could make the data plane susceptible to attack.

“Control protocol traffic should be segregated from the main data flows, either through network security measures or an out-of-band network,” says Chismon. “Organisations should factor in the availability of security options [such as SSL] when choosing controllers.”

The use of TLS (nee SSL) to authenticate controllers and endpoints would help to prevent eavesdropping and spoofed communications on southbound connections.

Controller layer

The SDN controller is also an attack target of interest to hackers. “The powerful centralised orchestration afforded by the SDN model, namely the SDN controller, also represents a single point of failure and a high-value target for bad actors,” says Hongwen Zhang, CEO ofWedge Networks and co-chair of the security initiative for the Cloud Ethernet Forum.

“If they can compromise it, they can begin to directly affect flows on the network.”

David Noguer Bau, head of service provider marketing at Juniper Networks, says the network components are now open to commands from the controller and this could be a way in for cyber criminals.

“Potential attackers can try to get control of the network, pretending to be an SDN controller or just break into the controller itself,” he says. “There are also new types of DDoS attacks trying to exploit potential scaling limits of the SDN infrastructure by finding out automated processes that take large amounts of CPU cycles.”

Securing the controller layer

Security best practices for hardening public-facing Linux servers can be applied to this situation, says Chismon. However, organisations may still want to oversee controllers for suspicious activity.

Access to the SDN control network should be controlled to prevent unauthorised activity. Administrators would be advised to set up role-based access control (RBAC) policies as well as audit trails to look out for unauthorised changes to controllers.

A high-availability controller architecture could go some way to mitigating a DDoS attack by using redundant controllers to make up for the loss of other controllers.

Ronen Shpirer, SDN security expert at Fortinet, says: “As the network’s centralised decision point, it is first critical to secure the SDN controller within the architecture. Strong access control is required, alongside trust zone segmentation. DDoS protection, anti-virus and other threat prevention and mitigation techniques are needed here.” 

Application layer (northbound)

Northbound protocols and APIs are also a target for attack and there are many to choose from for the discerning hacker. The APIs use Java, JSON and Python, among others, and attackers could gain control of the SDN infrastructure by exploiting vulnerabilities in any of these. Security on the northbound API is therefore a must – otherwise, SDN policies could be created by an attacker in order to take control.

Leaving a default password on such APIs would allow a hacker to easily guess it and then create packets to forward on to a controller’s management interface to determine the structure of the SDN network or even set up their own one.

“The most common challenge is to ensure there is a mechanism in place to authenticate an application’s access to the control plane and prevent this authenticated application from being hacked,” says Riverbed's Lees.

Securing the application layer

Using TLS or SSH to secure communications on the northbound is considered best practice here. Another way to help secure this end is making sure northbound applications are coded securely. This also means authentication and encryption methods should be deployed on all communications between applications and services requesting SDN services and data, and the controller serving these requests.

Markus Nispel, vice-president of solutions architecture and innovation at Extreme Networks, says: “End-users should leverage the relevant SDN capabilities to introduce new security capabilities into the network – pervasively. They should pay a lot of attention to the security configuration that protects the controller and the communication between the controller and applications on the northbound API side.” 

Can SDN improve security?

Some analysts believe that rather than causing a security headache, SDN may well improve security across the organisation.

“The security of these solutions is materially better because, with these overlay schemes, it is possible to define a virtual network architecture that exactly reflects the logical architecture of the application, having all application pieces on a single private virtual network,” says Peter Christy, research director at 451 Research.

With these virtual networks, the rules for appropriate and inappropriate communication among the parts can be defined clearly and then the rules for this private network communicating to the rest of the network are also defined precisely and clearly. “None of this is possible with legacy network architectures,” says Christy.

Anticipating future threats

It is difficult to foresee exactly how hackers will target SDN infrastructure because deployments are still so new, as are the controllers and protocols. We can only best guess how and where an attacker will strike. As with the testing of any security, it is only when we put ourselves in the position of the cyber criminal that we start to see where vulnerabilities exist.

As organisations get to grips with deploying the technology, it is important to bake security into SDN from the start. If this is done as an afterthought, securing the flow of traffic northbound and southbound is likely to cause problems around service delivery. Getting things right from the beginning will avoid many problems further down the road.