|
IMPORTANT: This policy is currently under review and does not necessarily apply. A new commercial vulnerability disclosure policy will be published soon.
Vendor
Throughout this policy, "vendor" is defined either as
the producer, seller, developer or maintainer of the affected
system (software, hardware, web site, network etc.) - or more
generally, the organization or person responsible for and capable
of correcting the vulnerabilities in their system.
Discovery
When we discover a security problem in a system upon which
we are not hired to conduct a security analysis, we may analyze
it for our internal learning purposes. The problem is analyzed to a degree
where it is reasonably reproducible and is then documented in a private
report.
Private Report
Private report contains (when possible):
1. detailed description of the problem,
2. demonstration of the problem,
3. possible scenario(s) of its exploitation and
4. recommendation(s) for vendor's actions.
Just like the information about security problems that we discover in our customers' products, the private report is classified as strictly confidential.
Priorities
Our subsequent activities regarding the discovered security problem are subject to the following priorities:
1. Security of our customers
2. Security of global community
3. Fair vendor treatment
Notification
When completed, we send the private report to the vendor.
Additionally, in case the discovered security problem affects our customers and we have a solution (fix or workaround), we notify them and provide recommendations for protecting their systems and their customers. Note that, in order to protect the vendor and other users, we take extreme care not to disclose to them unnecessary details of the security problem.
Helping the vendor
We're willing to grant the vendor reasonable effort on our side to help him reproduce the security problem and find an effective solution for it. When the vendor provides a fix, we are prepared to test it in our lab.
In case the vendor wants to publish his own security bulletin
about this vulnerability (the usual method of informing users
of fix availability), we are prepared to review this bulletin
for technical accuracy before it is published.
Public Report
Public version of the report differs from private one in that it doesn't include sufficient details for actually exploiting the described vulnerability. Its purpose is to inform the public of the existence of the vulnerability, its potential impact and ways to eliminate or avoid it. Details about the vulnerability remain strictly confidential even after the fix is available and/or applied to affected systems.
Publishing
When the vendor has corrected the problem and/or made the solution
available, we distribute the public report to the general
public. This is done by:
1. sending it via e-mail to our customers,
2. including the public report in our Advisories
page,
3. sending it via e-mail to subscribers of ASPR
Mailing List and
4. sending it via e-mail to security mailing lists.
Exception to this are reports about security problems that
would in our opinion provide no significant benefit to the general
community (e.g. a trivial vulnerability in some site which has
already been fixed). We don't publish these reports, but we may
name them in our Advisories page
We may give the vendor an opportunity to review the public report before we publish it.
Unresponsive vendors
Sometimes the notified vendor is very responsive and cooperative,
while other times we get absolutely no response even after several
months of trying to establish a contact. Regardless of this,
our actions are governed by the Priorities stated above.
Therefore it may well happen that we find a vulnerability in
a public site, but the
maintainer neither responds nor fixes the problem. In such cases,
if we determine that publishing our public report would do more harm
to our customers or global community than it would benefit them,
we only list the report on our Advisories page,
mark the vendor as "unresponsive" and keep trying to
establish contact.
However, when we believe that such a security problem presents a real threat to members of global community, and it seems that publishing is the only way for
pushing the vendor into fixing the problem, we do publish the
public report - as long as publishing would be in
accordance with the Priorities stated above. The same rule applies
when the vendor doesn't exist any more or doesn't support the
affected system any more.
Language and Format
Private reports are written in English or in vendor's local language where possible and are in HTML or PDF format. Public reports are written in English and are in ASCII format for
reasons of general understanding and readability.
Copyright
Our reports are copyrighted because we invest a great deal
of effort in analyzing and documenting the vulnerabilities
they describe.
However, this policy is not copyrighted. Since it reflects
what we believe to be professional and ethical handling of (accidentally)
discovered security problems we encourage everyone to copy and
enhance it.
|
