Vulnerability Disclosure Policy

This vulnerability disclosure policy serves as a guideline of how Virtual Security Research, LLC (VSR) and its affiliates handle vulnerability notification and disclosure, and further to instruct Maintainers as to the expectations when a researcher discovers a security vulnerability. This document is not in any way legally binding to any party, rather serving strictly as a guideline. This policy may be updated at any time solely at the discression of VSR.

Executive Overview

This policy outlines the typical responsible disclosure procedure used by VSR and its affiliates. The primary goal of the disclosure process is to minimize the negative impact of security vulnerabilities on consumers. This policy encourages cooperation between all those involved.

This policy and its procedures are not set in stone. Indeed, it is encouraged that all parties regularly communicate with each other during the process, adjusting the process as needed.

Table of Contents

Purpose of the Policy

This policy exists to establish a guideline for interaction between a researcher and software Maintainer. It serves to quash assumptions and clearly define intentions, so that both parties may immediately and effectively gauge the problem, produce a solution, and responsibly disclose the vulnerability.

First and foremost, a note to the software Maintainer: the researcher who contacted you has chosen NOT to immediately disclose the problem, but rather make an effort to work with you. This is a choice they did not have to make, and a choice that hopefully you will respect and accept accordingly.

The goal of following this policy, above all else, is to minimize the impact of security vulnerabilities on consumers. The policy seeks to balance numerous factors which place computing infrastructures at risk and to find the most effective way to notify consumers without unnecessary negative impact.

Definitions

Maintainer: the individual, group, or vendor that maintains the software, hardware, or product that are affected by the Issue.

Patch Release Date: The estimated date when the Maintainer will publish a fix for the identified vulnerability.

Advisory Prerelease Date: The date when VSR will release limited information about the flaw to warn the public.

Advisory Full Release Date: The date when VSR will release full details about the vulnerability to the public.

Discussion

The ultimate goal of VSR's responsible disclosure process is to minimize the exposure of consumer systems to attack. A determination must be made as to how much technical information should be released, and when it should be released. Releasing detailed exploit information before users have the ability to correct or mitigate a flaw will clearly have a negative impact. However, allowing software Maintainers to drag out a release process indefinitely will also negatively impact consumers since, with passing day, a chance exists that an unethical researcher will independently discover and use the flaw to attack consumers.

While it is likely impossible to accurately quantify the true risk of any vulnerability, there are clearly several factors at play in how vulnerabilities and their public release could impact consumers. When determining how and when to publish information about any given vulnerability, VSR considers at least the following criteria:

Keeping these factors in mind, VSR has developed a disclosure process which hopefully strikes a reasonable balance for responsible disclosure.

Disclosure Process

The VSR disclosure process is broken down into five stages: notification, triage, support, prerelease, and full release. These stages typically occur in that order, but several may be omitted depending on the results of previous stages. Each stage is described below.

Notification

After identifying and assessing a vulnerability, a VSR researcher will attempt to contact the Maintainer. The researcher will start by searching for information published by the Maintainer (such as on its website) on how to report vulnerability information. If this fails, the researcher will attempt to contact the Maintainer through generic email addresses or contact forms. If this information is not available or a timely response to these inquiries is not received, the researcher may use third-party resources, such as the OSVDB to attempt to reach the Maintainer. The researcher may also attempt to contact the Maintainer at commonly used email addresses such as secure@{maintainer} and security@{maintainer}.

Maintainers are expected to manually respond (not solely through automated responses) to notifications within 7 calendar days. All reasonable attempts to contact the Maintainer will be made by VSR researchers, but after published methods of contact are exhausted, VSR will consider the Maintainer to be non-responsive.

Triage

Once the Maintainer has responded to the initial notification, VSR will arrange to provide the full technical details of the flaw. VSR encourages the use of PGP, S/MIME, or other secure forms of transfer of detailed vulnerability information during this stage.

Upon receiving the vulnerability information, Maintainers are expected to review the technical details and respond to VSR within 14 calendar days. Maintainers should provide a brief summary of how they expect the flaw to impact users and if there are any mitigations for the flaw that customers could implement which VSR did not previously identify. Maintainers must also provide an expected Patch Release Date for the distribution of a fix to customers. This date should be no more than 180 days in the future.

VSR will then assign Advisory Prerelease and Advisory Full Release dates. If the Maintainer supplies a Patch Release Date that is within a reasonable period of time, then the Advisory Prerelease will typically be skipped and the Advisory Full Release Date will occur on or shortly after the Patch Release Date. However, in situations where the risk to consumers is deemed significant, an Advisory Prerelease Date may be assigned on or before the Patch Release Date with the Full Release being delayed until the overall risk subsides. If the Maintainer provides a patch release date greater than 180 days in the future, refuses to provide a date, or becomes non-responsive, VSR will assign a reasonable Advisory Prerelease and Full Release Dates. Assigned release dates are selected based on the criteria described in the Discussion section above and will generally fall between 90 and 180 days into the future, from the end of the Triage stage. The assigned release date will be communicated to the Maintainer. Note that advisory release dates may be altered at any time by VSR. Changes most often occur when indications of active exploitation in the wild come to VSR's attention, but may also occur for other reasons. In any case, changes to release dates will be communicated to the Maintainer.

Support

The support stage begins once a Patch Release Date is established. During this stage, VSR awaits the patch and provides the Maintainer support in correcting the flaw. Support may include additional technical details such as exploit scenarios or recommended approaches to correct the flaw. Support for Maintainers may even include testing of preliminary fixes for the flaw. However, note that this support is a free service provided to the Maintainer and the level of support provided is completely up to VSR to decide.

During this stage, VSR may also provide support to VSR customers who are potentially impacted by the flaw. For instance, VSR may provide limited prerelease information to customers in order to help them secure their environments. In all cases, the utmost care is taken in providing prerelease information in order to minimize the possibility of dissemination to unethical parties.

Prerelease

VSR may publish a prerelease advisory to the public on or before the established Patch Release Date. Prereleases are commonly published on the Patch Release Date when the severity of the vulnerability is perceived to be high or if a vendor failed to release a fix for the flaw by the previously established deadline. VSR may also opt to publish a Prerelease Advisory prior to the Patch Release Date if evidence exists that a third-party researcher may have also discovered the flaw, or the flaw is being actively exploited in the wild. VSR may also opt to skip the Prerelease stage entirely if the release process goes smoothly and the severity of the flaw does not warrant giving consumers an early "heads up".

Prerelease advisories include very general information about the flaw, along with information to help consumers mitigate the issue. All attempts are made to help consumers protect themselves while making it difficult to develop an independent exploit for the vulnerability without significant additional effort.

Full Release

During the Full Release stage, VSR publishes full technical details about the vulnerability. The Full Release may occur on the established Patch Release Date, or if a Prerelease was published, will typically occur within 30 days of the Prerelease. Ideally, the Full Release Advisory will occur after a fix is provided by the Maintainer, but this may not be possible if the Maintainer is uncooperative.

Maintainers are asked to credit at least the first researcher who brought a given issue to their attention. For instance, a simple attribution of credit might read:

"Thanks to {researcher name} of VSR for bringing this issue to our attention."

Questions and Answers

Do you use the CVE to identify vulnerabilities?

Yes. If the Maintainer acts as a candidate naming authority (CNA), then VSR will ask that the Maintainer assign an identifier after the triage phase. Otherwise, VSR will request a number directly from MITRE.

Isn't it unfair to set arbitrary deadlines for Maintainers?

No. The recent past has shown that the lack of deadlines for Maintainers only leads to longer and longer fix times. VSR strives to avoid "arbitrary" deadlines by trying to understand Maintainers' and consumers' situations for each and every vulnerability. For more information on security community trends in this area, see the similar approaches employed by Google and Tipping Point.

Where does VSR publish advisories?

We publish all advisories on our website and on popular security mailing lists such as Full Disclosure and Bugtraq.

History

This policy was heavily revised in November, 2011 to provide a more modern and reasonable approach to responsible disclosure.

It is loosely based on the disclosure policy released by rain forest puppy.

2013-06-19
IBM WebSphere Commerce: Encrypted URL Parameter Vulnerable to POA

2012-10-23
Timothy D. Morgan presents No Crack Required: Cryptanalysis in Real-World Applications at OWASP AppSecUSA 2012.

2012-07-29
Michael Coppola presents Owning the Network: Adventures in Router Rootkits at DEF CON 20 [slides].

2012-04-20
HTC IQRD Android Permission Leakage

more...

Contact us by phone,
fax or e-mail:

Phone: 617.933.8919
Fax: 617.933.8920
Email: inquiry@vsecurity.com