[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200208191935.PAA09673@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: (no subject)
>as much as it is the $companies problem, it is also the users... as
>they are using the software with the hole, and they must protect
>themselves and their clients.
And it's ultimately the users who can force vendors to become more
responsive to vulnerability reports. I've heard several major vendors
(not just one) say that the security community is a small part of
their installation base, albeit a vocal one. Even the US government,
while a major consumer, is a small portion of the overall market as I
understand it.
If the above paragraph has a grain of truth, then to me it seems that
one challenge for those who want secure products, is to educate the
general public to (1) ask their vendors for security (and *how* to ask
for security), (2) monitor their vendors with respect to security, and
(3) live with the fact that security by its nature may reduce some of
the functionality. In the short term we have to live with (3), but
good, solid research into "easy-to-use security" could help with
that.
But the question is, how can we get more "Joe Q. Customers" ask for
security, and base their purchasing decisions on it (thereby affecting
the vendors' bottom line)? And who is "we"?
>By releasing the exploit it allows two things,
>
>1) Experience system administrators to devise temporary hacks to work
>around the bug until it is properly fixed.
One difficulty here is when the only "temporary hack" is to completely
disable the service. If you've got a service that's meant for
complete access to the Internet or some other set of non-trusted
computers (say, a web or mail server), you don't necessarily have a
lot of options. It seems reasonable to give the vendor *some*
opportunity to fix the issue before releasing a fully functioning
exploit, not for the sake of the vendor, but for the sake of most
admins.
- Steve
Powered by blists - more mailing lists