Group to set bug-reporting standards
Published: 22 Feb 2002 11:56 GMT
Microsoft and other software makers met with several computer-security companies Thursday to hash out the last details of a group that will set guidelines for reporting software flaws that affect Internet security.
Currently named the Organization for Internet Safety, the group is still in flux, with members and rules not yet finalised, said sources knowledgeable with the discussions. The talks took place in San Jose, at the RSA Conference 2002.
Stuart McClure, OIS member and president and chief technology officer of digital-security company Foundstone, wouldn't give details about the meeting but confirmed that no form has been settled on for the organisation. He did say that such a group is sorely needed by the security industry.
"There is no unified procedure, policy or expectation for software companies today regarding vulnerability disclosure," McClure said. "This will help clarify."
The group springs from discussions between Microsoft and a handful of security companies on the responsible reporting of software bugs, known as vulnerabilities, that affect a business' security. Those discussions resulted in an announcement in November at Microsoft's Trusted Computing conference that a new group would be forming.
The initial group consisted of Microsoft and security companies Foundstone, @Stake, Guardent, BindView and Internet Security Systems. It's unknown what other companies are taking part in the current discussions.
Microsoft chairman Bill Gates last month sent an email to his employees urging them to make the giant's software more trusted by focusing on improving security and privacy. While many have doubts about whether the company can pull it off, the move puts security first in an industry where it has almost always taken a backseat to features.
Delaying the disclosure of vulnerabilities and urging legitimate researchers to allow software makers time to fix software problems before they're made public could play a large role in limiting the effect of newly discovered vulnerabilities in Microsoft's products.
Earlier this week, two security researchers released a draft proposal outlining what would be considered a responsible report of a security bug.
Known as a request for comment, or RFC, the draft guidelines aim to help companies eliminate vulnerabilities, help customers minimise the risk from security flaws, and provide tools for identifying security holes and managing a company's response.
"We are concerned about vulnerability reporting standards, and we have been talking with others in the industry and working to come up with best practices about what you can do so you don't learn the hard way," said Chris Wysopal, director of research and development for digital-security company @Stake, and one of the RFC's two authors.
The debate about vulnerability-disclosure policies involves two main parties. Researchers at security companies say they want to get their latest findings out quickly to hasten software makers' response to bugs. Software makers, on the other hand, say they aren't given enough time to deal with a problem, and that publicising it simply alerts malicious hackers to an opportunity.
And some software makers would like to avoid any publicity whatsoever about holes in their programs -- for obvious reasons. For security researchers, too, there's a publicity angle: Catching a software maker flat-footed can mean plenty of media coverage.
Earlier in February, security company Cigital touched off a responsible-disclosure debate when it informed The Wall Street Journal of the limitations of a security feature in Microsoft's latest tools for creating Windows and .Net applications. The company gave Microsoft less than 12 hours to respond and made the information public on the same day the tools launched. While some cried foul, others defended the company's actions.
Little wonder, then, that software companies are looking for a measure of what is responsible disclosure and what is not.
The draft RFC requires security researchers who find software flaws to report them to the application's maker, or, if they are unable to reach the company, to report them to a reliable third-party coordinator, such as the Computer Emergency Response Team (CERT) Coordination Center at Carnegie Mellon University.
Once notified, the software maker must respond to the report within seven days, or if an automated response is provided, the software maker must specify when a more detailed response will be made -- and that response must be made within 10 days. In addition, the draft proposal requires that the software maker update the researcher on the status of the problem every seven days and try to resolve the problem within 30 days of being notified.
The RFC 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.
The draft also proposes that every software company have an email address specifically set aside for security alerts and reports from security experts on software flaws. The address being suggested is "secalert@companyname.com."
If it bears fruit, the effort will let "new and existing companies have accepted and agreed-upon guidelines for fixing vulnerabilities," said Foundstone's McClure.
The Organization for Internet Safety is expected to announce its final structure and name within two months, a source said.
Have your say instantly, and see what others have said. Go to the Security forum.
Let the editors know what you think in the Mailroom.
Did you find this article useful?
63 out of 101 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
