When Seungwon Shin was a grad student, few people wanted to talk about software-defined networking (SDN) security.

So say two of his grad students, Seungsoo Lee and Changhoon Yoon (left and right, respectively, in the photo above). But along with Shin, who's now an assistant professor at the Korea Advanced Institute of Science and Technology (Kaist) and a research associate at the Open Networking Foundation (ONF), they're hoping the industry is ready to start looking at the vulnerabilities that SDN introduces.

Presenting at Black Hat on Thursday, Yoon and Lee introduced SDNSecurity.org, an organization focusing on identifying SDN security issues and their possible solutions. The group has been at work for a little while, finishing eight projects with eight more in the hopper, and a relaunch of the website is due in September.

It's a joint effort between Kaist and SRI International. Shin once did a summer internship at San Mateo, California-based SRI, where he met security expert Phil Porras, became involved in researching the Conficker worm, and got introduced to security issues in OpenFlow. (Some of that work can be found at OpenFlowSec.org.)

As for Yoon and Lee, they've been active in SDN security circles. The ONF has launched a security testing framework called Project Delta, which Lee has contributed to, and Yoon has contributed to On.Lab’s Security-Mode ONOS project.

Yoon and Lee's talk outlined some of the SDN problem spots they've been investigating, and they demonstrated how some of the vulnerabilities can be exploited.

Their talk happened to focus on OpenDaylight and ONOS. They would love to try their hand at commercial SDN products, Yoon told some audience members after the talk — but as grad students, they started by looking at free products.

So, how could an attacker take advantage of SDN? Yoon and Lee demonstrated two hacks during their talk.

First, they got access to an SDN controller and changed the network configuration to create a new node — a malicious and unauthorized one, of course. This attack was made possible when a developer downloaded ONOS code from a rogue repository. (They happened to use ONOS, but this could happen during the downloading of any type of code.)

Second, using OpenDaylight code this time, they took over an SDN switch and throttled its performance to half-speed. The culprit this time was an application downloaded from an app store. When added to the network, it changed the forwarding rules being used by the switches, deliberately hobbling the forwarding rate.

A few protections could help block these kinds of attacks, Lee said. A checksum or similar tool could provide a basic integrity check for controllers. There also needs to be a way to authenticate network nodes, they said, to block any rogue nodes from effectively hijacking the network, as in the performance hack.

What's nefarious about the performance hack is that it doesn't affect network connectivity, making it hard to detect. An operator would have to discover that the switches were creating less-than-optimal routes, analogous to cars detouring around a construction site. One possible defense here would be some way to detect and remove flow-rule conflicts among the switches, Lee said.