A proposal for a new process for disclosing security vulnerabilities has reignited the old debate over how flaws should be published and whether theres any way to actually regulate the process.
The document, titled “Responsible Disclosure Process,” outlines a detailed, step-by-step process for everyone involved in the discovery and reporting of vulnerabilities—including researchers, vendors and third-party security experts.
Written by Chris Wysopal, director of research and development at @stake Inc. in Cambridge, Mass., and Steve Christey, lead information security engineer at The Mitre Corp., based in Bedford, Mass., the document was forwarded to the Internet Engineering Task Force last week.
Its release comes at a time when the security community is struggling to find a common policy for vulnerability disclosure that is acceptable to everyone involved. This is a goal that many acknowledge may be unrealistic, considering the vastly differing motivations of the various players.
The Wysopal and Christey document, known as an Internet-Draft in IETF terminology, suggests that vendors work closely with the researchers who discover security flaws and to keep them updated as the company works on a patch or workaround for the vulnerability. Specifically, the proposal asks that vendors acknowledge receipt of the vulnerability report within seven days and provide a detailed response to the allegation within 10 days.
The document also suggests that the vendor contact the person who found the flaw, called a “reporter” in the document, every seven days during the patch-research process and try to resolve the vulnerability within 30 days.
The proposal also lays out specific behavior for the “reporters,” a group that includes legitimate security researchers in corporate labs, teenage hackers, researchers at security vendors looking for free publicity and any number of other participants.
However, some critics say the proposal is too detailed and lacks a set of consequences for researchers and vendors who fail to adhere to it.
“In general I think its too detailed and long, fails to define repercussions if its not adhered to, puts too much onus on vendors and fails to put enough responsibility on discoverers,” said Russ Cooper, surgeon general at TruSecure Corp., based in Herndon, Va. “In my mind you have to penalize those people who perpetrate attacks, and those people who dont adequately secure the systems and networks they own or run. You crack down at the ISPs and make them do more to limit the effects of globally disseminated information.”
But, Wysopal says, this proposal wasnt the place to discuss those issues.
“Thats not really an appropriate thing to do in a document like this,” Wysopal said. “Its just trying to document the best practices. Something thats a loose best practices document is the best were going to do right now.”
The relationship and interaction—or lack thereof—between vendors and researchers is often the main reason why documents like Wysopal and Christies are needed. In a grab for publicity and/or business, researchers often release details of vulnerabilities before patches are available, infuriating vendors and endangering users whose systems are left open to attack.
The Internet-Draft encourages reporters to work closely with vendors and grant them time extensions for producing patches if they feel the vendors are working in good faith to fix the problem.
If the IETF approves the proposal, which expires in six months, it would move on to the RFC (request for comments) stage, a prelude to becoming a standard. Wysopal said he has gotten a lot of feedback on the draft, some from people who worry that it will stir government interest in regulating the security industry.
“This is an effort to have a little more self-policing in the industry. I dont think its going to affect the governments interest one way or the other,” Wysopal said. “If it is used as the basis for government regulation, at least the security industry will have an inside track with that effort.”
