A group of 11 security companies and software developers, known collectively as the Organization for Internet Safety (OIS), this week released the first version of a consensus document governing the reporting and release of security vulnerability information.
The OIS, a voluntary group of 11 high-profile vendors formed last September, on Tuesday released Version 1.0 of its long-awaited Guidelines for Security Vulnerability Reporting and Response. The 25-page document is the result of a yearlong effort to standardize how security researchers and software vendors work together to find, fix and release information to the public on software vulnerabilities. A draft version of the document had been released in early June for public comment.
The current industry model of full disclosure has been a contentious and often politically charged issue. It has divided the security community into two camps, one consisting mainly of independent researchers, who feel that vendors are only out to protect themselves and their customers, and the other of vendors, which feel that researchers don't always adhere to the accepted practice of first notifying a vendor before making vulnerability and exploit data public.
"The environment has changed during the past seven to 10 years," said Chris Wysopal, director of research and development at @stake Inc. and co-author of the infamous Windows password-cracking program, L0phtCrack. "(In the past), vendors weren't communicating with anybody who wasn't a big customer. And they had no process at all."
The OIS guidelines are an effort to create a process acceptable to both researcher and vendor, one that keeps the security interests of users at the forefront, said Scott Blake, vice president of information security at BindView in Houston. "The process relies on good faith by both parties, and users' interests are the primary consideration."
According to Blake, the OIS incorporated substantial feedback from the security community in its final guidelines and devised a five-step process. Key to that process is a standardized and predictable point of contact that must be provided by the vendor so researchers know exactly who to notify, said Blake. In addition, a vendor has seven days to acknowledge receipt of the vulnerability report, or the researcher is free to make a public announcement. Finally, the OIS will rely on a 30-day grace period after a fix has been issued by the vendor to hold back the release of what he called "supplementary data" related to exploit code.
That should afford everybody affected by the vulnerability enough time to install patches before exploits begin to appear in the hacker community.
However, security experts attending the Black Hat security conference here questioned the motivations of the OIS, saying that it appears to be an effort to increase the value of for-profit early-notification lists that some security companies offer. "It sounds like a wonderful way to notify customers who pay for advance notification," said one audience member.
Blake denied that characterization, saying that most of the OIS member companies stand to gain nothing because they don't operate fee-based predisclosure lists. But the OIS does identify certain classes of companies, such as owners and operators of critical-infrastructure facilities and systems, as being eligible for early notification. Wysopal acknowledged that the OIS hasn't yet come up with a good definition of what those critical infrastructures are.
Others at the security conference raised concerns about whether the effort would remove the pressure that full disclosure has placed on vendors such as Microsoft to develop rapid fixes for known vulnerabilities. Even @stake's Wysopal acknowledged that the issue is "an open question."
Scott Culp, senior security strategist at Microsoft, said the pressure won't let up. "These guidelines don't let us off the hook," said Culp. "They actually increase the pressure. If you send a report to us and we don't respond, there's a timetable (built into the process), and you can take us to town."
"The vendors forming the OIS represent anybody but the security researchers," said Thor Larholm, a security researcher at PivX Solutions LLC, a network security consultancy in Newport Beach, Calif. "The OIS is a specification made by vendors for vendors. The guidelines provide absolutely no incentive for most security researchers to follow the process. There are simply too many loopholes for any vendor to continue their current process of downplaying the severity of vulnerabilities."
With more than 120 steps involving lengthy reports, nondisclosure agreements and other legalities, the current process is "lengthy, bureaucratic and without consideration for the researcher" who discovers vulnerabilties, Larholm said.
"Responsible disclosure won't work," said Pete Lindstrom, an analyst at Spire Security, a Malvern, Pa.-based consultancy, in a research note. "It provides no incentive or alternative for black hats and advocates of immediate, unadulterated disclosure to alter their practices." Instead of focusing only on the number of discovered vulnerabilities as a measure of software security, it might be better to use other metrics such as "cost to break" or "defect density" to identify the strength of software, he said.
OIS member companies plan to hold another meeting this week to discuss expanding their membership. The group also plans to revisit the guidelines in six months to see whether they're working and to incorporate recommendations from the security community in what Wysopal described as "a living document."
Computerworld's Jaikumar Vijayan contributed to this report.