On Security in OpenDaylight

It’s now been a bit more than two months since OpenDaylight dealt with the the “netdump” vulnerability reported in August. The good news then was that we fixed the vulnerability and we were able to fix it and ship a new release of ODL with the fix in four days once we knew about the vulnerability. I want to echo Dave Meyer’s comments in saying just how impressive that is and how well the OpenDaylight community comes together when something needs to be done. The list is much longer than this, but in particular, Robert Varga and David Jorm were absolutely critical in pushing things through quickly and efficiently.

The bad news then, was that there was about a 4.5 month lag between when the vulnerability was discovered and and when we found out about it. However, the even better news now (and really this all happened over a month ago, but I haven’t had time to blog about) is that we have a bunch of new things in place that will prevent that kind of lag in our responding in the future. Some of them have even been covered elsewhere.

Better Publicized Ways to Report Security Issues

Even at the time netdump was first made public, we had a private security mailing to report security issues, but it was unfortunately not very well-advertized. Today, it’s publicly listed on OpenDaylight’s contact information page. It’s also listed on our new security advisories page and you can find both on the first page of results for “opendaylight security” at your favorite search engine. For good measure, I’ll also put it here: to report any security issues in OpenDaylight, please e-mail  security@lists.opendaylight.org.

Formal Security Response Process

Again, we’ve had a long-standing security response team in ODL who monitored our security mailing list, but we didn’t have a complete understanding of what we needed to do next when a vulnerability was reported. Now, we have a very clear idea of what happens, who’s responsible for driving things once a vulnerability is reported, how to work with developers to create a fix, how to release the fixed version of OpenDaylight, and how to let our users know in a timely fashion.

More Good Things are Coming

We’ve already dealt with our second disclosed vulnerability, so we know the process works and we’re learning how to make it even better as we deal with each incident. We’re also actively working to take up a broader array of security issues with a combination of code changes and the development of security best practices for deployments as part of the Lithium release of OpenDaylight.

Security in Open Source

Lastly, I’d be remiss if I didn’t mention that open source software has a huge set of advantages when it comes to security. First, since the code is open to anyone, anyone can come find vulnerabilities and report them. Second, you can draw on a wide array of experts and developers across companies to discuss and fix any vulnerabilities that are found. Third, the community at large can see how such issues are addressed transparently and understand if the issue has really been fixed. All of this is made easier and more robust because, in open source, a community spanning companies can collaborate transparently.

Content republished with permission from the author, Colin Dixon. Original post published March 2, 2015  at Cyberpunkture.