eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Worried about the state of security incident response among open-source software projects, a group of computer security professionals has launched an ambitious effort to manage the coordination of vulnerability warnings and patch release information between open-source vendors large and small.
The new organization, called oCERT (Open Source Computer Emergency Response Team), emerged from stealth mode at this year’s CanSecWest security conference with a grand plan to be the go-to place for security incident response when an open-source software project is affected.
Backed by search technology giant Google, security consulting firm Inverse Path and the Open Source Lab at Oregon State University, oCERT wants to manage advance vulnerability warnings, offer resources for analyzing and fixing software flaws, coordinate the patch release notification process and hold tardy vendors to the fire when security fixes are delayed.
“Small open-source projects often don’t have any form of security handling but the same code they manage [is] included by bigger projects and distributions. When there’s a compromise, there’s no proper coordination and that’s not acceptable,” says Andrea Barisani, oCERT founder and project coordinator.
The Downside to Diversity
Barisani, a well-respected researcher who maintains several small open-source security projects, believes oCERT can fill the gap by providing resources to small vendors and active coordination with larger distributions that might be affected by a security flaw or compromise.
“Open source is wonderful for the diversity of software and projects that can affect users with the most advanced technology, but this extreme diversity has the downside of missing global coordination, and quality is not always the best,” he said in an interview with eWEEK. “When it comes to security, this is a problem.”
Barisani added: “We wanted to create a public organization that would help in coordinating security issues like vulnerabilities and compromises. Only very few security issues affect only a specific vendor in the open-source world. Most of the time, code is re-used all over the place and that’s why there’s this need for coordination.”
In the first week since the launch of oCERT, several big-name vendors and distributions have signed on as active members. They include Gentoo, Mandriva, OpenBSD, OpenSSH, Nmap and Annvix.
Barisani said all the major players in the open-source software world will be approached to join and actively participate in the oCERT effort. To qualify for oCERT membership, an open-source distribution or project must be active and must have a good record in being proactive and responsive to dealing with security-related problems. A member must also have an active security contact and must agree to the oCERT disclosure policy. Members must also agree to avoid silently fixing vulnerabilities without proper disclosure.
In the Footsteps of CERT
The idea is to mimic the CERT security incident response teams around the world by offering help to both large infrastructures and smaller projects that can’t afford a full-blown security team. The goal, Barisani said, is to reduce the impact of compromises on small projects with little or no infrastructure security and, more importantly, avoid the ripple effect of badly communicated or poorly handled compromises.
He said oCERT will also provide security vulnerability mediation for the security community, maintain reliable security contacts between registered projects and vulnerability researchers who need to get in touch with a specific project regarding infrastructure security issues.
oCERT has already put together a high-profile team that includes Tavis Ormandy and Will Drewry from the Google Security Team; Barisani and Rob Holland from Inverse Path and Marcel Holtmann from Intel. Solar Designer from Openwall and Dragos Ruiu from the SecWest security conferences form part of the organization’s advisory board.
With this list of renowned security experts, Barisani believes oCERT can emerge as a credible organization to help in assessing whether a vulnerability submission is actually a real security concern.
Barisani, an active member of the Gentoo Foundation’s security and infrastructure teams, has first-hand experience dealing with security-related emergencies.
Back in 2003, he found himself smack dab in the middle of a major compromise of one of the servers that make up the rsync.gentoo.org rotation. During that incident, Barisani was closely involved with containing the damage, performing live analysis of the hijacked server to look for lost data and evaluate the visibility of other systems in the network to reduce the risk of further compromises.
The rsync.gentoo.org issue was resolved in 36 hours and is often cited as one of the best collaboration and response examples in the open-source community but, five years later, there are still major gaps that need filling.
“Let’s just say that there’s a good history of security issues in the open-source world that could have been handled better and there’s also a good history of compromises which are worrying,” he said, declining to provide details on vendors with a poor history of responding to security incidents.
He insists oCERT will be tough on vendors that take too long to fix software vulnerabilities. “We’re committed to keeping things moving as fast as possible and we have a disclosure policy that enforces an upper limit on disclosure time,” Barisani said.
“If a vendor is lazy and takes six months to fix something, we won’t tolerate it,” he declared.
The oCERT policy is to give a vendor an embargo time of 60 days to create and release a security patch. “We’ll always have a fixed limit specifically to prevent the problem of lazy handling [of vulnerability warnings]. We will be stricter if we think it’s necessary,” Barisani said.