Lastly, it would be bad if an attacker created their own controller and got network elements to believe flows from the "rogue" controller. The attacker could then create entries in the flow tables of the network elements and the SDN engineers would not have visibility to those flows from the perspective of the production controller. In this case, the attacker would have complete control of the network.
1-3. Attacks at SDN Layer
Attacking the security of the northbound protocol would also be a likely vector. There are many northbound APIs that are used by SDN controllers. Northbound APIs could use Python, Java, C, REST, XML, JSON, among others. If the attacker could leverage the vulnerable northbound API, then the attacker would have control over the SDN network through the controller. If the controller lacked any form of security for the northbound API, then the attacker might be able to create their own SDN policies and thus gain control of the SDN environment.
Often times, there is a default password that is used for a REST API which is trivial to determine. If an SDN deployment didn't change this default password and the attacker could create packets toward the controller's management interface, then the attacker could query the configuration of the SDN environment and put in their own configuration.
2. Hardening an SDN System
With the introduction of SDN, a new method is needed for securing the control plane traffic. In traditional IP networks the control plane security came in the form of routing protocol security measures that involved using MD5 for EIGRP, IS-IS, or OSPFv2, IPsec AH in the case of OSPFv3, or GTSM/ACLs/passwords for MP-BGP. Some implementers do not even follow these simple techniques for traditional IP networks. If they approach deployment of an SDN with the same disregard for security, then they will be exposing their organization to attacks. Let's look at how one can secure an SDN system based on hardening the three layers illustrated in the above architecture diagram.
2-1. Securing the Data Plane Layer
Typical SDN systems leverage X86 processors and use TLS (formerly SSL) for the security of the control plane. These long-lived HTTP sessions are susceptible to a wide range of attacks that could jeopardize the integrity of the data plane. This would bypass the multi-tenancy of these solutions and cause cloud-based services to be compromised. Organizations should prefer to use TLS to authenticate and encrypt traffic between network device agent and controller. Using TLS helps to authenticate controller and network devices/SDN agent and avoid eavesdropping and spoofed southbound communications.
Depending on the southbound protocol being used, there may be options to secure this communications. Some protocols may be used within TLS sessions as previously mentioned. Other protocols may use shared-secret passwords and/or nonce to prevent replay attacks. Protocols like SNMPv3 offer more security than SNMPv2c and SSH is far better than Telnet. Other proprietary southbound protocols may have their own methods to authenticate network device agents and controllers and encrypt data between themselves, thus thwarting the attacker's eavesdropping and spoofing.
Sign up for Computerworld eNewsletters.