Panel defends flaw disclosure guidelines
A security group thinks researchers should give software companies at least 30 days to come up with a patch before going public about a flaw.
The Organization for Internet Safety (OIS) held a panel discussion at the Black Hat Briefings security conference here to field questions regarding its latest attempt to create a standard way for security researchers to report flaws to software vendors. Currently, researchers handle flaw information in widely different ways. Some immediately publish the information on the Internet, while others work with software makers to fix the issues.
The group hopes that researchers will give software companies at least 30 days to come up with a patch for a problem before going public with a flaw. Scott Culp, security program manager for Microsoft and an OIS member, stressed that more time does not mean the companies won't take security seriously.
"These guidelines don't let us off the hook--they increase the pressure on us," he said.
The group's guidelines, released Tuesday, also call for security researchers to give the public 30 days to apply a patch before they release details of a vulnerability that could be used to attack a system.
Such grace periods are a contentious concession for the security community, which has had to deal with reticent software makers for the past decade. Companies' slowness to acknowledge and solve security flaws resulted in the so-called open-disclosure movement, a philosophy to which many researchers subscribe. Under open disclosure, the public is notified of any flaw as soon as possible
Chris Wysopal, research director for the digital security firm @Stake, released information about a fair number of such vulnerabilities when he was part of the Boston hacker group The L0pht. Wysopal, now part of the OIS and author of the original guidelines, said software makers handle security much better today, so immediate disclosure is no longer needed.
"The environment has changed in the last seven years," he said. "At some point, we started to see that releasing (details and) code was doing more harm than good."
Security researchers attending the event questioned whether software makers would resort to their old ways if given the chance. Wysopal stressed that if that were to happen, it would be time to re-evaluate the guidelines.
"If companies delay (fixing flaws), then the environment has changed from what it is today. Then we need to change the document" guidelines, he said.
Other members of the audience worried that stopping the immediate public release of information about vulnerabilities would be a boon to some security firms, such as Internet Security Systems, that sell early information on flaws to customers who subscribe to a closed security list. That tactic also is being used by the Computer Emergency Response Team Coordination Center, a security clearinghouse that gives sponsors early access to information.
OIS hasn't created a policy for that sort of disclosure because a consensus on the matter could not be reached. However, Wysopal said the benefits to the guidelines should outweigh any abuses of the system. "We want to see if this type of process works," he said. "We shouldn't just say we aren't going to try it, because there are still issues."
The group said that information on more than 70 vulnerabilities has been released under the guidelines.
Other members of OIS include anti-virus software maker Symantec, Unix seller SCO, database maker Oracle, security software maker Network Associates, digital security firm @Stake, and network protection firm BindView.