With the increasing interest around SDN and security, and given that this is the week of the RSA Conference, we felt it was an opportune time to reach back out to Phil Porras of SRI International to get an update on the work he and his team have been doing around SDN and security.

SDxCentral: Since we last chatted, there's been significant momentum around the SDN movement. Looks like our observation that in 2013, every networking company will be an SDN company, is coming true. What's your overall view of the maturity of the SDN movement?

Phil: “I'm impressed with the efforts that vendors have been making to incorporate OpenFlow into a growing base of products, and overall the OpenFlow community is clearly vibrant and providing considerable thought leadership toward the future of networking. I think that anyone responsible for managing large networks, as well as those responsible for developing advances in network management or security applications, are remiss if they are not closely following what is happening in the SDN community. (This is not to suggest that OpenFlow is currently achieving the adoption rate that the OpenFlow community desires.)

As an application developer, in my case, security applications, there is clearly a need for greater maturity of APIs, and perhaps for some consolidation of what we can expect from the control layer. I'd like to be less concerned with the problems of porting my apps to different controllers, worrying about OpenFlow versions, or being concerned with switches that do not fully comply with specs. There is also need for maturing in mechanisms that will allow OpenFlow apps to coexist on a controller. Perhaps as these challenges are resolved and more compelling OpenFlow applications become portably accessible, the adoption rate will increase.

Finally, security should be a major consideration for those defining the OpenFlow standards and designing the software stacks that will operate OpenFlow networks. I think the state of OpenFlow security is very immature and would not recommend OpenFlow in highly sensitive networks. While it's true you won't find many to argue that the current state of network security is robust to attack, we've have a long time to understand how to securely configure and manage these networks in sensitive computing environments. I think that we can extend OpenFlow to be capable of providing similar strong security policy enforcement, while maintaining the dynamism of OpenFlow applications, as long as those dynamic flow decisions remain consistent with the security policy.”

SDxCentral: The last time we talked about FortNOX, your efforts in creating a secure application framework on NOX. What's happened since to FortNOX?

Phil: You might recall that with FortNOX we designed and prototyped a security mediation service that was integrated into the NOX-Classic controller (which unfortunately ceased development). With FortNOX we proposed the basic security mechanisms that the INFOSEC community would expect in order to enforce network security policies in sensitive computing environments. We used FortNOX to host several experimental security applications, and to more broadly understand the functional northbound requirements these applications need for detecting and responding to various attacks.

Since then we have been working toward a reimplementation and release of a fully operational security mediation service on a supported open source controller. We're now working on SE-Floodlight (a security extended version of BigSwitch's Java-based Floodlight controller), which will fully implement the FortNOX security mediation service within Floodlight. As we make progress and produce demos we'll be posting more information about SE-Floodlight on our www.openflowsec.org.”

SDxCentral: We also talked about FRESCO in our last chat. Looks like FRESCO is moving right along. Your paper on FRESCO has the distinction of being the first SDN/OpenFlow security paper to make it into an upper-tier INFOSEC-focused security conference. Does this mean SDN is entering the mainstream?

Phil: “I have a positive outlook for the increased attention the INFOSEC community will pay to OpenFlow. This past year I have seen OpenFlow gain greater awareness among network security researchers, and we've had several contacts with other colleagues who are studying OpenFlow, both to explore it as an opportunity for novel security as well as to conduct critical analysis of the security challenges it poses. I would not consider OpenFlow or SDN a mainstream subject among the INFOSEC community just yet. FRESCO will be published this week at the ISOC Network and Distributed System Security conference, which is a excellent audience to promote academic researchers to explore how SDNs can change the ways we counter malicious network traffic. I'm very excited by the potential for OpenFlow to drive new innovations in intelligent and dynamic network security defenses for future networks. I'm also realistic that there is still significant work needed to address the security challenges that OpenFlow (and SDNs) impose on our traditional notions of network perimeter defenses.”

SDxCentral: Can you share a few key tidbits and highlights from the paper for our readers?

Phil: “Sure, our team, which include Guofei Gu and Seungwon Shin from Texas A&M, developed FRESCO, an application development framework to facilitate the rapid design, and modular composition of OF-enabled security modules. FRESCO is itself an OpenFlow app, which we host over FortNOX. It provides a Click-inspired scripting language that enables us to develop and share many different security detection and mitigation modules. Researchers can write and compose these modules to quickly prototype more complex security services. When deployed, these services operate with FortNOX (now SE-Floodlight) to ensure that the flow rules (security policies) they produce are enforced by the controller. The paper goes on to evaluate several unique anti-malware and other security applications that we wrote using FRESCO's scripting language.”

SDxCentral: What is your hope for FRESCO and the SDN community?

Phil: “Ultimately, we hope efforts like FRESCO could help to lower the cost for security researchers to begin designing new defenses for OpenFlow networks.

With FRESCO we've developed a scripting language the lets us focus on writing security response (and diagnosis) modules once, and in a way that lets us easily compose and reuse these modules. For example, we could use FRESCO to define a module that implement local host quarantine, and through FRESCO's API any legacy-DPI based security application could invoke a quarantine response when an infected host is detected. The details of how our notion of quarantine translates into an ongoing stream of flow rules into the OF-switch is abstracted by the FRESCO module. We can compose of variety of modules together to develop more complex FRESCO-only security services. As we port FRESCO, these security modules can migrate unchanged, with FRESCO, to operate over whatever controller we have integrated our security mediation logic.”

SDxCentral: Will we see the SE Kernel make its way into more controllers soon?

Phil: “Internally, we don't currently have the resources to support our security mediation service across many controllers. I hope this will change. As we have been re-implementing our security mediation logic from NOX Classic to Floodlight we've had to consider how to modularize our security mediation service (the enforcement guts of FortNOX) from controller to controller. While the move from NOX to Floodlight certainly involved a complete reimplementation, so far the original FortNOX design has survived well inside Floodlight. We are also keen to identify what elements we can share across controllers. In particular, we are talking with various people who share a common interest in Northbound APIs and we'd like to contribute a base set of requirements that will enable application frameworks like FRESCO to be more easily ported across controllers.”

SDxCentral: Has there been any commercial interest in taking the SE kernel and moving into commercially-backed controllers?

Phil: “I think there is a strong need for reference implementations to address OpenFlow's fundamental security challenges. Ultimately, for OpenFlow to be adopted within sensitive computing environments, such as within the financial community, governments, healthcare, and all the other industries where security compliance is a central requirement, the OpenFlow community will have to engage the INFOSEC community. I am a big proponent for us engaging as soon as possible. In short, I would equate strong solutions to enhance OpenFlow's security as a prerequisite to its overall viability as a commercial success, at least for these industries.”

SDxCentral: When do you think we will see an increased focus on security in SDN? The early work appears to be more focused around finding cool network applications.

Phil: “As you suggest, there are two sides to this coin: a critical analysis of the security challenges posed by SDNs, and the exploration of potential new defensive capabilities that SDNs may enable. I expect more work will published (this year) to discuss the underlying insecurities that must be address in the OpenFlow stack. This is going to be a fruitful area of study for a while, and it may hurt the confidence of some to operate OpenFlow networks. But critical security evaluations are need to ultimately develop the security extensions and protocol changes to address these challenges (or to at least inform us where the vulnerabilities lie).

With respect to security application, my take is that OpenFlow really doesn't offer anything new or advantageous to those who want to build detection systems (particularly DPI-based detection). Keep in mind that the INFOSEC community has been developing malicious traffic analysis technologies for the last two decades, and I don't see OpenFlow providing significant new opportunities to improve threat detection.

Rather, my excitement with SDNs is entirely around the opportunity for intelligent response. For decades, the response to any security threat from legacy networking devices has remained essentially unchanged: BLOCK. OpenFlow enables INFOSEC developers to standard protocol to reprogram the data plane of all the switch in ones network at one to implement much richer responses to a perceived threat. For example, I'm excited about OpenFlow applications that implement far more complex response, such as Reflector Nets, Quarantine Systems, Emergency Broadcasts, Tarpits, Advanced OpenFlow enabled Honeynet. Our FRESCO paper provides examples of some of these response strategies, and demonstrates how efficiently they may implemented under OpenFlow. Regardless of how OpenFlow ultimately transitions into the market, I expect the utility of SDN-enabled network defenses can prove to be one of the more impactful developments to occur in the network security community.”

SDxCentral: Thank you again for your time, Phil! And for educating us on your work on security within SDNs. It was a pleasure. Hope you enjoy your time at RSA this week!