![fulldisclosure logo](/images/fulldisclosure-logo.png)
Full Disclosure mailing list archives
Re: it\'s all about timing
From: full-disclosure () lists netsys com (full-disclosure () lists netsys com)
Date: Wed, 7 Aug 2002 11:36:09 -0700
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
This to me sounds like it is acceptable that there are going to be vulnerabilities. Continue cranking out shodware because we have a set of guidelines that people who stumble across them are expected to adhere to.Vulnerabilities will happen, even in the best of circumstances, as long as new types of vulnerabilities are discovered. If there are 20 individuals who decide to audit a package for a new type of vulnerability, but the vendor only has 5 developers, then it seems like there's a good chance that someone other than the vendor will discover the issue. Then you've got "interaction" vulnerabilities, which I loosely define as when a vulnerability occurs in the way that two products interact with each other. Developers can't always predict how their product will be used, or how it will interact with other products, so interaction-based vulnerabilities may be around in one form or another.
This is not my problem. You want to make something and sell it to me, make sure it works as advertised. Your problems are "interaction" with other products, and your lack of developers, not mine. Give me one good reason why I should be concerned with how you make your product and your inabilities to ensure that what I paid for (probably as a result of your snake oil marketing)work. I don't understand your stance that my giving you money in exchange for your goods somehow gives you license to not provide me with my money's worth. The commerical world simply doesn't work like that. Time to change the fantasy software world. You've been riding on the "that's software" coat tails too long.
Given the likelihood of vulnerabilities in a "perfect" world, it seems reasonable that the vendor should be prepared to respond to incoming reports.Why not draft a guideline for release of software onto internet. Security guideline (defaults of configs. etc.) and Quality Guidelines (vendor (a) is a known creator of crudware etc.). if you want to connect to the interne or peddle your internet connect warest, you the vendor must follow these guidlines. Penalise them them if they fail. Fine them real money if the repeat.This is a very interesting proposal if I understand what you're saying, but it's outside the scope of a disclosure process document.
I think it goes hand-in-hand. You're drafting a guidline for people who are responding or reacting to something. What is it that they are responding or reactiving to? Your guidline is the chaper two or step number 2. Where is Chapter one. People don't find and report vulnerabilities out of thin air. it is a result of something. That something is either buying or installing a vendors product. There must be a step one or chapter one. The vendors guidlines. Against which your reporting guidline is the process as a result of buying or installing the vendors software. Chapter One. Vendor Guidline: vendor promises to ensure his product works Chaper Two. Customer who finds it doesn't work, will do this. Simple cause and reaction. You must have a guidline for the vendor first and then a guidline for the customer second. Is there is no guidline for the vendor now and that is why your guidline simply will not wash.
I can't think of any document that specific says "use secure-by-default" (and defines what that means), "avoid buffer overflows," "conduct third-party evaluation of product design," "make security-based patching and configuration easy" (and try to define *that* :-), etc. Such a document might be useful for less-technical customers to ask their vendors to make more secure products. I suspect that many customers want security, but they don't know how to ask for it. - Steve _______________________________________________ Full-Disclosure - We believe in it. Full-Disclosure () lists netsys com http://lists.netsys.com/mailman/listinfo/full-disclosure
-----BEGIN PGP SIGNATURE----- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wmYEARECACYFAj1RZ5IfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT 5JkCl0iMkCyhAJ9IZQYzYKhDkQXCPpGXi3BXJpDBdQCgqLIFUfRr7wHDDXCdTkHrmFYL KX4= =vXD2 -----END PGP SIGNATURE----- Communicate in total privacy. Get your free encrypted email at https://www.hushmail.com/?l=2 Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
Current thread:
- Re: it\'s all about timing, (continued)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 02)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 02)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 02)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 05)
- Re: it\'s all about timing Steven M. Christey (Aug 05)
- Re: it\'s all about timing Steven M. Christey (Aug 05)
- Re: it\'s all about timing Steven M. Christey (Aug 05)
- Re: it\'s all about timing Steven M. Christey (Aug 05)
- Re: it\'s all about timing Steven M. Christey (Aug 05)
- Re: it\'s all about timing Ron DuFresne (Aug 05)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 07)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 07)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 07)
- Re: it\'s all about timing full-disclosure () lists netsys com (Aug 07)