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%20Vulnera
bility%20Reporting%20and%20Response%20V2.0.pdf
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%20Vulnera
bility%20Reporting%20and%20Response%20V2.0.pdf
The site even has an implementation guide:
http://www.oisafety.com/reference/implement.pdf
- Steve
[ reply ]