bugtraq - Re: Vendor guidelines regarding security contacts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 9 Jan 2007 12:40:50 -0500 (EST)
From: Chris Wysopal <weld@...nwatch.org>
To: "Steven M. Christey" <coley@...re.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Vendor guidelines regarding security contacts


Researchers and vendor contacts should also be aware of the great vendor
dictionary created by OSVDB at http://osvdb.org/vendor_dict.php that
contains many security contact addresses.

-Chris

On Mon, 8 Jan 2007, Steven M. Christey wrote:

>
> We frequently see requests for contact on this mailing list.  Readers
> are encouraged to ensure that their software vendors are aware of the
> following documents, which have more specific guidelines for vendors
> to establish.  Because these documents have been co-authored by major
> organizations, they might provide more leverage for researchers who
> have difficulty in reaching unresponsive or uninterested vendors.
> Whether you subscribe to the whole "responsible disclosure" process or
> not, presumably most of us agree that it's important for vendors to be
> easily reachable.
>
> - Steve
>
>
> The US Department of Homeland Security's "Vulnerability Disclosure
> Framework" document here:
>
>   http://www.dhs.gov/xlibrary/assets/vdwgreport.pdf
>
> lays out some recommendations for how vendors can make their security
> POC's more available (see Figure 2 as well as "Reporting Mechanism" in
> section 6.)
>
> The Organization for Internet Safety's web site Security Vulnerability
> Reporting and Response Process document has similar recommendations,
> e.g.
>
>   5.1.3 The Vendor shall post information for contacting it to one or
>       more publicly accessible locations. The Vendor.s security
>       response policy shall indicate where this information is posted,
>       or provide the contact information itself.
>   5.1.4 The Vendor.s posted contact information shall, at a minimum,
>         include:
>   . A reference to the Vendor.s posted security response policy.
>   . A listing of the contact methods the Vendor supports.
>   . Contact instructions for each of the methods listed above.
>   . Instructions for using the secured communication channel discussed
>         in paragraph 5.1.8 below, along with any needed cryptographic
>         key material.
>   5.1.5 The Vendor shall exercise reasonable efforts to ensure that
>         misdirected mails to the following email addresses can be
>         re-routed to the appropriate point of contact:
>   . abuse@[vendor_domain]
>   . postmaster@[vendor_domain]
>   . sales@[vendor_domain]
>   . info@[vendor_domain]
>   . support@[vendor_domain]
>
> Those are from
> http://www.oisafety.org/guidelines/Guidelines%20for%20Security%20Vulnerability%20Reporting%20and%20Response%20V2.0.pdf
>
>
> The site even has an implementation guide:
>
>   http://www.oisafety.com/reference/implement.pdf
>
>
>
> - Steve
>