Message-ID: <200208071836.g77Ia9D85774@mailserver2.hushmail.com>
From: choose.a.username at hushmail.com (choose.a.username@...hmail.com)
Subject: Re: it\'s all about timing

-----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@...ts.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

Powered by blists - more mailing lists