Open-source software projects are often well intended, but security can take
a back seat to making the code work.
OpenDaylight, the multivendor software-defined networking (SDN) project, learned that the hard way last August after a critical vulnerability was found in its platform.
It took until December for the flaw, called Netdump, to get patched, a gap in time exacerbated by the fact that the project didn’t yet have a dedicated security team. After he tried and failed to get in touch with OpenDaylight, the finder of the vulnerability, Gregory Pickett, posted it on Bugtraq, a popular mailing list for security flaws.
INSIDER: 5 ways to prepare for Internet of Things security threats
Although OpenDaylight is still in the early stages and generally isn’t used in production environments, the situation highlighted the need to put a security response process in place.
“It’s actually a surprisingly common problem with open-source projects,” said David Jorm, a product security engineer with IIX who formed OpenDaylight’s security response team. “If there are not people with a strong security background, it’s very common that they won’t think about providing a mechanism for reporting vulnerabilities.”
The OpenDaylight project was launched in April 2013 and is supported by vendors including Cisco Systems, IBM, Microsoft, Ericsson and VMware. The aim is to develop networking products that remove some of the manual fiddling that administrators still need to do with controllers and switches.
Having a common foundation for those products would help with compatibility, as enterprises often use a variety of networking equipment from many vendors.
Security will be an integral component of SDN, since a flaw could have devastating consequences. By compromising an SDN controller—a critical component that tells switches how data packets should be forwarded—an attacker would have control over the entire network, Jorm said.
“It’s a really high value target to go after,” Jorm said.
The Netdump flaw kicked OpenDaylight into action, and now there is a security team in place from a range of vendors who represent different projects within OpenDaylight, Jorm said.
OpenDaylight’s technical steering committee also recently approved a detailed security response process modeled on one used by the OpenStack Foundation, Jorm said.
If a vulnerability is reported privately and not publicly disclosed, some OpenDaylight stakeholders—even those who do not have a member on the security team—will get pre-notification so they have a chance to develop a patch, Jorm said. That kind of disclosure is rare, though it is becoming more common with open-source projects.
The idea is that once a flaw is disclosed, vendors will generally be on the same page and release a patch around the same time, Jorm said.
OpenDaylight’s security response process is “quite well ironed out now,” Jorm said.
OpenDaylight, the multivendor software-defined networking (SDN) project, learned that the hard way last August after a critical vulnerability was found in its platform.
It took until December for the flaw, called Netdump, to get patched, a gap in time exacerbated by the fact that the project didn’t yet have a dedicated security team. After he tried and failed to get in touch with OpenDaylight, the finder of the vulnerability, Gregory Pickett, posted it on Bugtraq, a popular mailing list for security flaws.
INSIDER: 5 ways to prepare for Internet of Things security threats
Although OpenDaylight is still in the early stages and generally isn’t used in production environments, the situation highlighted the need to put a security response process in place.
“It’s actually a surprisingly common problem with open-source projects,” said David Jorm, a product security engineer with IIX who formed OpenDaylight’s security response team. “If there are not people with a strong security background, it’s very common that they won’t think about providing a mechanism for reporting vulnerabilities.”
The OpenDaylight project was launched in April 2013 and is supported by vendors including Cisco Systems, IBM, Microsoft, Ericsson and VMware. The aim is to develop networking products that remove some of the manual fiddling that administrators still need to do with controllers and switches.
Having a common foundation for those products would help with compatibility, as enterprises often use a variety of networking equipment from many vendors.
Security will be an integral component of SDN, since a flaw could have devastating consequences. By compromising an SDN controller—a critical component that tells switches how data packets should be forwarded—an attacker would have control over the entire network, Jorm said.
“It’s a really high value target to go after,” Jorm said.
The Netdump flaw kicked OpenDaylight into action, and now there is a security team in place from a range of vendors who represent different projects within OpenDaylight, Jorm said.
OpenDaylight’s technical steering committee also recently approved a detailed security response process modeled on one used by the OpenStack Foundation, Jorm said.
If a vulnerability is reported privately and not publicly disclosed, some OpenDaylight stakeholders—even those who do not have a member on the security team—will get pre-notification so they have a chance to develop a patch, Jorm said. That kind of disclosure is rare, though it is becoming more common with open-source projects.
The idea is that once a flaw is disclosed, vendors will generally be on the same page and release a patch around the same time, Jorm said.
OpenDaylight’s security response process is “quite well ironed out now,” Jorm said.
No comments:
Post a Comment