Bug reporting standards proposed

Security researchers are proposing new rules to standardise the way security holes in software are reported and fixed.

Security researchers are proposing new rules to standardise the way security holes in software are reported and fixed.

Steve Christey, lead information security engineer at Mitre Corporation and Chris Wysopal, director of research and development at digital security firm @Stake, have submitted a draft proposal outlining standards for vulnerability disclosures by software vendors and security researchers to the Internet Engineering Task Force (IETF), the Internet's main standards-setting body.

The standards are needed, Christey said, to codify the many unwritten rules that govern disclosure of software security flaws.

There is currently no consensus as to how or when vulnerabilities in software should be disclosed.

Vendors and security experts are often at odds over disclosure policies. Security researchers usually want to inform users of vulnerabilities as soon as possible. However vendors argue that disclosure alerts hackers to the vulnerability.

The proposal by Christey and Wysopal would require those who report vulnerabilities to follow a policy of "responsible disclosure".

Christey and Wysopal suggest that the security researcher who discovers a vulnerability should report it to the vendor or a reliable third-party coordinator (often a member of the security community).

The vendor, in turn, must respond to the notification within seven days, or if the software maker's receipt message is automatically generated, the company should provide a date - not to exceed 10 days - when it will respond in more detail to the notification.

In addition, the proposal also requires that the vendor update the security researcher every seven days and try to resolve the vulnerability within 30 days.

Eric Hemmendinger, an analyst at Aberdeen Group, said standards for vulnerability disclosures are necessary because right now "there is a free-for-all."

However, he expressed concern that the IETF would move too slowly for the proposal to be really effective.

Christey disagreed, saying the proposed standards needed widespread discussion and adoption and that the IETF already had a process for developing standards documents and putting them up for public review.

Read more on IT risk management