For this week’s interview, we turn to one of the top cybersecurity experts in the US, Phil Porras at SRI International. Readers familiar with the story about Conficker as covered in the book “Worm” by Mark Bowden of “Black Hawk Down“ fame, will probably recognize Phil’s name. Phil Porras was one of the international team of security experts that helped combat Conficker. In his day job, he is Program Director and leader of SRI’s Internet Security Group which is known for its BotHunter anti-malware efforts. Phil’s recently been looking at security in software-defined networking and will be presenting a paper at SIGCOMM’s upcoming HotSDN workshop around secure controllers. We managed to catch up with Phil to discuss the state of security in SDN and OpenFlow.
SDNCentral: So Phil, tell us why you think SDN needs a security focus?
Phil: Well, traditional security solutions have primarily focused on static networks with static topology and fixed policies. However, OpenFlow and SDN shatters that notion. With SDN, there’s dynamic policy that is continually rewritten, with no predictable notion of what happens next. That presents both a challenge and an opportunity for the security community. While SDN holds significant promise, I think that sensitive computing environments like government, finance and healthcare will insist that SDN platforms have sufficient security baked in before they deploy. The trick here is to reconcile the dynamic nature of SDN with classic notions of network perimeter defense in computing environments today.
SDNCentral: Is this a case of security being designed in after the fact? Will we again end up with similar security challenges to those we have today with TCP/IP because the initial design had weak security?
Phil: I think that it is definitely not too late, which is why we are reaching out to the SDN community, publishing in SIGCOMM, talking to switch and controller vendors around security requirements for SDN. It’s critical that the security community responds to the SDN movement early and engage. I’ve been thrilled at the positive response from key developers and leaders in OpenFlow and SDN when we’ve engaged with them, and they understand the concerns we’ve brought up.
SDNCentral: So what’s your vision of secure SDN? Or secure OpenFlow environments?
Phil: One of the goals of SDN is to provide a programmable environment where network-centric applications can be run. For instance, a 3rd-party load-balancing application running on an OpenFlow controller can intelligently direct traffic to appropriate resources. That’s great, but say if the best load-balancing application comes from Ukraine or some other remote country—now, do you trust it from a security standpoint? Ideally, you would build an OpenFlow networking environment where the security of network is not dependent on OpenFlow applications being free from vulnerabilities or errors. That’s what we want to help build.
SDNCentral: And how would you go about doing that?
Phil: First of all, I think there needs to be a secure controller platform. One that provides a solid trust model and enforcement strategy. This platform would have to understand what organizational security policies have to be enforced and then provide real-time recognition of when network flow policies are violated by incoming candidate flow rules. The platform needs to support many OpenFlow applications simultaneously and enforce security despite complex interactions between application flow rules. I would expect the controller to protect the network regardless of whether applications are malicious or just simply insecure and vulnerable. We already have a prototype of such a controller built on the NOX platform called FortNOX.
SDNCentral: That sounds really interesting! Where can we learn more about FortNOX, and what are you working on next?
Phil: We have more information and demonstration videos at www.OpenFlowSec.org. In addition, we’re looking to build a reference implementation of an OpenFlow security kernel, and are looking for the right OpenFlow Controller on which to implement our first reference security kernel. In addition, we’ve begun conversations with switch vendors around the needs of the security community with regard to OpenFlow-enabled switches. There’s a lot more work to be done and the intersection of OpenFlow with anti-malware, threat mitigation and network defense is of particular interest to us at SRI. We believe that SDN is a compelling movement but it needs a secure foundation, and we’ll continue to help build out that foundation by furthering our research while engaging the community at large.
SDNCentral: We wish you well in your efforts and look forward to catching up with you again in a few months to see how things are going. In the meantime, we’ll encourage the community to visit your website at OpenFlowSec. Thank you very much for your time!
FortNOX introduction video