Security-flaw guidelines hit pothole

The draft guidelines are intended to make peace between the two sides in the security arena: software companies, who would rather the public didn't know about their products' vulnerabilities at all, and security researchers, some of whom have been known to publish vulnerability information to embarrass a program's maker and garner publicity for themselves.

The proposal would outline how and when researchers should release information on software security holes and the steps software makers should take to fix problems as soon as possible.

Members of the security section of the Internet Engineering Task Force, the organization that sets technical standards on the Net, signaled in comments on the draft submitted in February that human procedures are not its purview, said Steve Christey. Christey is lead information security engineer for government engineering firm MITRE and one of the two authors of the guidelines.

"Enough members of the IETF thought it inappropriate to put forward any document," Christey said. Instead, Christey, along with co-author Chris Wysopal, director of research and development for security company @Stake, will look for another group to submit the draft to.

"I think it is important that it be a forum where there is open discussion," Christey said.

The draft guidelines aim to help companies eliminate vulnerabilities, help customers minimize the risk from security flaws, and provide tools for identifying security holes and managing a company's response.

The proposed guidelines call for software-bug researchers to wait at least 30 days after notifying a company of a hole in its program to release information regarding the flaw, especially if the information could affect the security of the program's users. This is designed to give the companies time to fix the problem before the public--and potential hackers--learn of the bug.

But the draft doesn't hold software makers to any set deadline to fix the problem. As long as the company is acting in good faith, the proposal says, the researcher should not make the information public.

In the past, researchers have accused software companies of being slow to fix problems, or ignoring them altogether, leaving the program's users insecure.

The guidelines could form the backbone of the Organization for Internet Safety, a new group being formed by security companies and software makers interested in gaining breathing space to fix flaws before they are made public. The organization, originally discussed at a Microsoft conference last November, still hasn't finalized its structure.

For Microsoft, whose products draw extreme scrutiny from the majority of security researchers and hackers, gaining a little breathing space is important.

"We said back in November that we thought there was a burning need for some standards that researchers and vendors could agree on," said Scott Culp, manager of Microsoft's security response team. "Anytime you have a miscommunication (in this field), the people that wind up being hurt in the end are the people that we all want to protect: computer users."

The draft, Culp said, is as important as ever for Microsoft, one of the founding members of the OIS. "The IETF was a logical place to start, but if it wasn't the right place, then it wasn't the right place," he said.

The delay while the researchers look for another forum for the proposal should amount to only a minor pothole on the road to deciding what is responsible disclosure, Christey said.

"I don't think of it as a setback," Christey said. "It's just a choice of a different path. Which path we are going to take from here? We haven't decided yet."