With the announcements of attacks against major IT organizations that now regularly percolate through mainstream media, the need to understand how software-defined networking (SDN) adoption will affect an organization's security posture has never been more pressing. I've heard a range of opinions about SDN security, from those who think these two terms are inherently incompatible, to those who would argue that SDNs have virtually no new impact on a network's security posture from that of existing networks. While I would argue neither extreme is accurate, the middle ground leaves us with a substantial need to understand what fundamental security challenges do SDNs pose, and how do we address them?

Several months ago, I participated in an interview, "SDN Security — an Oxymoron?" wherein Roy Chua and I spoke about the challenges and opportunities that SDN poses to the network security community. (Roy chose the title.) We also discussed my group's recent effort to develop a reference implementation of a security enforcement kernel embedded within an OpenFlow controller, providing features that could address such security requirements. We called that controller Security-Enhanced Floodlight (SE-Floodlight), the successor to our first such reference implementation, FortNOX.

Today, we are pleased to make available our first beta release of SE-Floodlight, along with two other quite useful SDNSec applications. Here, I'll briefly recap the security challenges that SE-Floodlight overcomes, particularly when facing security compliance or accreditation requirements that are regularly imposed for sensitive computing environments. Then I'll discuss some opportunities that our two other security packages provide: assisting developers and end users in exploring new innovations toward self-defending networks.

From a security perspective, our core challenge, which we discussed last year, remains the need to reconcile the traditional notion of a predefined and completely specified network security policy against the dynamism of reactive flow rule generation, which is a tenet of SDN networking (e.g., a simple SDN filter challenge is demonstrated here). We proposed the need for an integrated security solution into the SDN control layer that would provide a solid trust model, resolve (inline) flow policy conflicts produced amongst co-resident OpenFlow apps (including complex interactions across flow rules), and enforce the flow policies expressed by security OpenFlow apps over non-security OpenFlow apps in a manner that cannot be bypassed.

OpenFlow applications should be allowed to co-exist within a common SDN network, which may of course lead to flow-rule conflicts, contradictions, and many unforeseen interactions between flow rules. Indeed, we have no assumption that OpenFlow apps will maintain any awareness of the current network security policy. They may contain vulnerabilities, backdoors, or produce flow rules in a predictable manner that may open exploitable opportunities by nefarious remote users who know how to craft just the right packet streams. Security of an SDN network should not depend on the absence of bugs or vulnerabilities at the application layer.

SE-Floodlight represents our first distributed reference implementation of a security-enhanced SDN controller in our ongoing attempt toward that ideal secure SDN control layer. It's an extended version of the latest Floodlight controller from Big Switch. Here is a quick summary of several key security features that SE-Floodlight introduces:

1. Privilege separation: It adds a secure programmable northbound API, enabling SE-Floodlight to operate as a truly independent mediator between the application layer and the data plane.
2. Flo-rule authentication: Flow-rule producers, operating both through the remote API or as local Java classes, can now be digitally authenticated and associated with an authenticated operating role. (This function generalizes beyond Floodlight),
3. Runtime OpenFlow-app verification: SE-Floodlight introduces a runtime integrity validator of class modules that produce flow rules. The runtime image of the local flow-rule producer is compared to the original class image installed by the administrator.
4. Inline Flow-Rule Conflict Detection: An improved version of our Alias Set Rule Reduction (ARR) algorithm, described in our FortNOX HotSDN 2012 paper, enables SE-Floodlight to conduct inline rule-conflict detection.
5. Role-based conflict resolution: SE-Floodlight can assign authorization roles to OpenFlow apps, enabling itself to resolve rule conflicts by comparing the authoritative roles of the producers of the conflicting rules.
6. PACKET_OUT Control: PACKET_OUT messages produced by OpenFlow apps can now be restricted or granted by administrative authority. This permission addresses a potential route to bypass secure flow rule mediation.
7. Security Audit: SE-Floodlight introduces a new OpenFlow audit subsystem that tracks all security-relevant events occurring within the OpenFlow control layer. This audit subsystem satisfies an important prerequisite for environments requiring conformance with most security compliance specifications pertaining to audit of administrative functions. More broadly, it offers substantial help in tracking OpenFlow app behavior, such as for troubleshooting OpenFlow app correctness or comparing performance between applications.

Along with SE-Floodlight, we are also releasing an sample OpenFlow security directive actuator. This is essentially a middleware service that implements a collection of intelligent flow-based remediation directives designed to combat various threats that may be detected by existing host- and network-security services. It enables security technologies to select and launch high-level threat-response directives, which the actuator then translates into the stateful OpenFlow flow-rule insertion logic necessary to implement the directive. It abstracts flow-rule and control-layer details from the security service, ideally to help accelerate the rate (and ease) of adoption of OpenFlow's substantial threat-response capabilities by mainstream security tools.

We provide two reference implementations of an SDN Security Actuator: one Java-based implementation and one in Perl. Both actuators implement 11 security directives, including advanced threat-remediation logic such as dynamic host quarantine, redirecting hostile flows to counterintelligence services, or isolating machines under potential threat, among many possible responses. Our SDN Security Actuator enables the security tool provider to remain focused on finding malicious or infected entities within the network, as it shields them from a fair degree of complexity needed to implement threat-response logic in OpenFlow.

The third package in our SDN Security Suite is our first reference implementation of an SDN-empowered botnet remediator, called OpenFlow BotHunter. Its based on our well-established BotHunter system, which is a network-based passive traffic analyzer. BotHunter detects when systems inside your network are producing communication patterns consistent with coordination centric malware (botnets, spam, infection, spyware, worms, adware, etc.). BHResponder extends BotHunter with an automated interface to convey security directives to the SDN Security Actuator in response to botnet infection profiles generated by BotHunter. An XML specification language enables end users to modify and extend BHResponder antimalware response policies for their needs.

Our SDN Security Suite provides reference implementations of our ongoing research toward future intelligent and dynamic network security defenses. We post this software with the hope of continuing the conversation between the SDN and Infosec communities on how to secure SDN deployments, and to hopefully spawn collaborations that can accelerate our ability to produce compelling SDN-enabled defenses that can be adopted in the networks that need them most.

Next month, we will present a new project called Avant Guard at ACM CCS 2013 in Berlin, Germany. Avant Guard examines two strategic security-focused extension to the SDN data plane (switch layer) to help defend an SDN from control-to-data-plane flow saturation attacks, and for enhancing the scalability of security services hosted on SDN-enabled switches. Finally, we are looking forward to soon releasing a second SDN-enabled security application, called FlowBoss, which will offer a substantial opportunity for exploring context-aware network flow policy enforcement.