[nc-whois] [Fwd: Re: useless security@ contacts]

[Abel Wisman <abel@able-towers.com>]

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.