Re: useless security@ contacts

["Steven M. Christey" <coley () linus mitre org>]

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.