These guidelines are seriously flawed and misguided. They are being advanced by a group of people who appear to have devised economic models in which they benefit from control of other people's freedoms and profit by limiting the potential for security while attaching a brand name to those limits. http://www.oisafety.org/about.html > What companies are members of OIS? > The current members are: @stake, BindView, Caldera International (The SCO Group), > Foundstone, Guardent, ISS, Microsoft, NAI, Oracle, SGI, and Symantec. If everyone who puts effort into attempting to devise a code of conduct for vulnerability disclosure would instead put effort into improving our collective ability to respond to full-disclosure events like DCOM RPC then we'd all be better equipped to deal with the real world. Every bit of contribution to such Vulnerability Reporting and Response Process takes away from contributions to full-disclosure incident response readiness. Nothing will ever do away with full-disclosure, but there is much that can and should be done to make full-disclosure irrelevant to security. My comment to you is this: You're behaving as though if we all just agree to filter our thoughts in a particular way then nobody will think anything that is prohibited, or if anyone does then at least the prohibited thoughts won't spread. Wake up, you're delusional. Everyone who contributes effort to such guidelines who cannot at this very moment prove forensically that the code that resides on their hard drives or that executes within their microprocessors is the most up-to-date version of the code published by the vendors (closed source) or contributors (open source) they've elected to rely on for software should take a moment to realize that vulnerability reporting or no vulnerability reporting makes no difference: you are still unable to determine whether or not it is reasonable to continue to trust your own computer -- ask yourself why you're putting any effort into attempting to curtail full-disclosure of security risks when you presently have no provable security and do not fully understand the extent of your risk exposure; why it takes you as long to figure out if you're fully patched as it takes for the next zero-day exploit to emerge. Your own answer to these questions are the best evidence that you're doing something harmful and wasting your time by trying to control the uncontrollable. All vulnerabilities deserve a public fear period prior to patches becoming available. The alternative is complacency and increased ignorance due to the removal of the short window of opportunity for every admin and programmer who cares to do so to contribute openly to analysis of the threat. When vulnerabilities are disclosed along with alleged fixes, fewer people bother to mount any type of incident response in spite of the fact that the fixes often fail or introduce new vulnerabilities. Closed source software is especially destructive to security in this respect because it encourages blind acceptance of alleged fixes. Anyone can analyze and discuss the threat openly but the solution we receive from our vendors is closed and its technical design is arbitrary. This makes no sense. There is a world full of smart people who kick and scream in an attempt to gain some level of influence in the technical design of security-sensitive features of closed source products and with few exceptions closed source software vendors systematically ignore our input. I understand that certain security software vendors and some infosec researchers derive income from such Vulnerability Reporting and Response Process; but the economic interests of the few do not outweigh the interests of the many. We've already been down that path, and the result is Microsoft. Jason Coombs jasonc@science.org -----Original Message----- From: full-disclosure-admin@lists.netsys.com [mailto:full-disclosure-admin@lists.netsys.com]On Behalf Of Ian Wilson Sent: Thursday, July 31, 2003 5:55 PM To: full-disclosure@lists.netsys.com Subject: [Full-Disclosure] Guideliens for Security Vuln reporting and response process Hello folks; The Organization for Internet Safety announced a version of their "Guidelines for Security Vulnerability Reporting and Response process, v1.0", ( http://www.oisafety.org/reference/process.pdf ). It's an interesting read, and there's a public comment period. Haven't seen it yet on this list, thought others would enjoy the read. Ian -- Ian Wilson ian@iwcg.net