<<<
Chronological Index
>>> <<<
Thread Index
>>>
[nc-whois] [Fwd: Re: useless security@ contacts]
thought this might be interesting
abel
-----Forwarded Message-----
> From: Steven M. Christey <coley@linus.mitre.org>
> To: vuln-dev@securityfocus.com
> Subject: Re: useless security@ contacts
> Date: 21 Mar 2002 19:15:06 -0500
>
>
> It must be noted that buried underneath all the hubbub surrounding the
> "Responsible Vulnerability Disclosure Process" (RVDP) document that
> Chris Wysopal and I have proposed, we make an explicit recommendation
> that vendors adopt a standard security contact mailing address.
>
> security@example.com is not universally used, and in some cases it's
> actually used for the organization's physical security team. It's
> also overloaded for incident reporting and abuse. For that reason, we
> have proposed that vendors use the "secalert" alias for responding to
> vulnerability reports.
>
> Our RVDP document tries to address the fact that many vendors have not
> set up a capability for recognizing and responding to security
> vulnerability reports. Many vendors aren't even aware that this is a
> problem. This sometimes forces reporters to go public with an issue
> when they would have preferred to give the vendor a chance to patch
> the problem first. Just this week, we have seen several examples.
>
> See our recommendations for yourself in section 3.3.1 of our draft,
> which can be found at:
>
> http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt
>
> We also make suggestions for how the vendor could continue feedback to
> the reporter throughout the disclosure process, in sections 3.4.1,
> 3.5.1, and 3.6.1.
>
> Despite the concern with the current document, "responsible
> disclosure" also applies to the vendor. Vendor accessibility and
> responsiveness will remain an important element of future documents.
> Chris and I hope that the adoption of standards for vendor
> responsiveness will make it easier for vulnerability reporters to
> reach the right people. A standard will (1) make some vendors aware
> that it is good for them to be accessible to vulnerability reporters
> in the first place, and (2) allow customers and others in the
> community to identify vendors who do not live up to such expectations.
>
> Vulnerability reporters: you are encouraged to include a "vendor
> status" section in your public advisory, which explicitly states who
> you tried to contact at the vendor, and when. While vendor status
> sections already appear in some advisories, many of them do not
> provide this type of detail. The more status reports there are, and
> the more comprehensive they are, then the easier it is to understand
> the extent of the problem, and the easier it will become to do
> something about it.
>
> - Steve
>
> P.S. Vulnerability reporters, feel free to email me your own "horror
> story" or "success story." I will not use your name unless you
> explicitly authorize it.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|