Security implications of software-defined networks

Sorensen

With only a handful of very small software-defined networks actually in production around the world, most SDN conversations are purely academic. But that hasn't impeded the interest and announcements that seem to be on an accelerated pace in recent weeks and months (see sidebar below). Why the flurry of announcements? The reason is because of the enticing potential of SDNs.

By separating the control plane from the data plane, which essentially removes and then centralizes the "brains" from the "muscle" of the network, you can quickly make changes to improve the speed, reliability, efficiency and even security of that network. You control the network's layout and flow, so you can define and distribute loads, optimize and prioritize traffic, and scale services or capacity up or down with just a few clicks, that is in theory. That's the key. Commercially available solutions that enable you to realize the potential of SDNs are simply not there yet. Assuming they are on their way, from vendors, such as IBM (NYSE: IBM), NEC, HP (NYSE: HPQ), Big Switch, Nicira, and still unknown/unannounced players, it's important to think through some of the security implications of this new architecture.

What to consider
The following are the top security issues and implications for SDNs that need to be thought through before any large-scale deployments can be reasonably undertaken:

Secure the controller: Because controllers (the "brains" of the network) can theoretically be used to do anything, their compromise could have potentially endless threat implications. First and foremost, controllers, need to be secure, both physically and logically. This will require the controller technology, itself, to mature from a security standpoint, as well as IT personnel taking precautionary measures during deployments.

For example, direct access needs to be restricted; who and how users can interact with controllers needs to be clearly defined (best practice dictates access should be limited to only those administrators who absolutely need it and be authenticated and logged).

Understanding and limiting what controllers are connected to (nothing other than the switches/routers/ servers) and tightly controlling the applications that can be deployed (should come from only trusted, verifiable sources) must also be normal practice. 

Protect the controller: If the controller goes down (for example, because of a DDoS attack), so goes the network, making the availability of the controller a top priority. The technology must advance to easily enable redundancy, through controller clusters, distributed controllers or some other mechanism. While this may require significant synchronization and added complexity, it is needed to mitigate the impact any one controller could have on the entire network.

Another thing you should pay attention to when evaluating technology is the fail-over mechanism. You need to understand and be comfortable with what happens if communication fails; understand the reliability and latency implications to ensure they are within your acceptable range.

Establish trust between the controller and switch: Currently, the communication channel between the controller and the switches/routers/servers is open; it needs to be secured and encrypted (SSL) to prevent man-in-the-middle, packet injection, snooping, and other attacks.

(Note, some SDN protocols already have SSL/TLS built into the specifications but are either poorly implemented or not implemented at all by existing solutions.)

There also needs to be strong, mutual authentication between the switch/router/server and controller to validate the identity and integrity of each controller.

Some pilot SDNs are built as out-of-band networks to keep them isolated and the threats contained. This is obviously only a temporary work-around and not scalable or reasonable for the long term.

Ensure the integrity of the applications: You need to make sure rogue applications cannot bind themselves to the controller and take over the network. Authenticating the application is a start, as well as being able to then identify and validate any changes to those applications that are authorized. Building in privilege separation between processes can help ensure changes are controlled and authorized; more standardized, powerful APIs into the controllers will also enable a more consistent, predictable application ecosystem. 

Develop a robust policy framework: In theory the management of SDNs should be simpler. Controllers are the centralized decision points for the hundreds, thousands, even tens of thousands of switches/routers/servers in your network, which means you should be able to make changes with just a few clicks to keep up with the demands of your ever-changing environment in real time.

However, what's needed is a system of checks and balances to make sure the controllers are doing what you actually want them to do. If a change is made to the forwarding table, you need to be confident it is the right change. This requires a robust policy framework that can guarantee overall corporate policies are followed. Any violations can pose a risk to your organization or knock you out of compliance. For instance, if you have a corporate policy that no one should be able to get to the finance server and the controller reroutes traffic to that server, there needs to be a system in place that flags and prevents it from happening.

Forensics and remediation: If an incident happens, you must be able to determine what it was, recover and then protect against it in the future. Log analysis and event correlation have always been a challenge, but in SDNs it will fast become a big data issue.  Tools need to be developed that can address all the forensics and compliance requirements--from management, event correlation to reporting--of any network.

Exploring the opportunities
The opportunities for SDN applications are infinite and this also applies to security. The potential to use SDNs to architect easier, cheaper, better security solutions needs to be explored.

For example, one network in pilot wrote an application to distribute its traffic load across a cluster of intrusion detection systems (Snort® loaded onto virtual servers) to ensure inspection without any performance degradation. The SDN offered a less expensive way to implement this solution and significantly reduced the capital needed to invest in appliances had this provider gone with a more traditional approach.

While SDNs are still in their infancy, their potential is intriguing. As vendors jump into the market and providers deploy more networks, it will force hard questions around how these networks are actually architected and secured.

Over the next three to five years, developers will wrestle with how to solve the issues of availability, policy enforcement, mitigation, management, and overall security. There are several competing ideas and approaches, for example, there's a debate about where the management and control will actually take place. Will it be within the network or within the servers (hypervisors)?

The good and bad news for security in all this is the same: the possibilities appear endless.

Sarah Sorensen is the Senior Security Analyst at ACG Research. She can be reached at [email protected].