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]
Message-ID: <Pine.BSO.4.55.0701091235580.29556@vikki.vulnwatch.org>
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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ