lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ILEPILDHBOLAHHEIMALBIENNGEAA.jasonc@science.org>
From: jasonc at science.org (Jason Coombs)
Subject: Guideliens for Security Vuln reporting and response process

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@...ence.org

-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com]On Behalf Of Ian Wilson
Sent: Thursday, July 31, 2003 5:55 PM
To: full-disclosure@...ts.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@...g.net


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ