Vulnerability Disclosure Policy

Purpose

This policy describes the process followed by wizlynx group security researchers & penetration testers when identifying a zero-day vulnerability during penetration testing engagements, or while working on research projects and bug hunting during off hours. This policy is intended to define a set of guidelines that ensure a responsible and ethical disclosure.


Vulnerability Disclosure Process

The following workflow shows wizlynx group’s high level process for responsible security vulnerability disclosure:

vulnerability disclosure process

Vulnerability Identification

During this phase, a security analyst employed at wizlynx group identifies a zero-day vulnerability, either during its’ private time, or working time.

Once a vulnerability has been discovered, the first step consists in verifying if it has not been reported already by searching in https://cve.mitre.org/ and other well-known vulnerability disclosure websites.

If the vulnerability has not been disclosed, a PDF report is created with enough information for the vendor to reproduce the problem (detailed explanations, Proof of Concept code, and screenshots).


Vendor Notification

wizlynx group will notify the vendor of the affected product as soon as the PDF report mentioned in section “Vulnerability Identification” is created.

wizlynx group will attempt to identify the vendor’s security contact from the website. If no contacts are available, dedicated E-mail alias will be tested such as the following examples:

  • security-alert@vendor.xyz
  • security@vendor.xyz
  • support@vendor.xyz
  • secure@vendor.xyz
  • info@vendor.xyz

If none of the above methods succeeds, a contact request will be made via the vendor’s standard support method (e.g. online form).


General Information Publication

General information about the discovered vulnerability may be disclosed on the same day as the vendor notification on wizlynx group website https://www.wizlynxgroup.com/security-research-advisories. To ensure the discovered vulnerabilities cannot jeopardize the vendor’s customer, only generic information will be posted such as:

  • Type of vulnerability
  • Advisory ID
  • Affected product and version

Vendor Acknowledgment

wizlynx group estimates to one week (7 days) the maximum duration the vendor may take to acknowledge by a human our initial notification.

If no reply is received after this period, wizlynx group will send a reminder. If no reply is received after 7 calendar days following the reminder, wizlynx group reserves the right to move forward with step 5 “CVE Identifier Request” and step 7 “Detailed Disclosure”.


CVE Identifier Request

After having received the vendor’s acknowledgment email or if the vendor fails to reply to wizlynx group initial notification and reminder in the timeframe mentioned in step 4, a CVE-ID will be requested for each category of vulnerability discovered.

The CVE-ID is important for the security community but also the vendor’s customers to know which version of the product is affected by a vulnerability.


Resolution

Three months after the first notification, wizlynx group expects that a patch, workaround, or at least a clear statement of the vendor is available. If the vendor postpones the patch release without any plausible reason, wizlynx group reserves the right to publicly disclose the vulnerability. In addition, wizlynx group expects the vendor to publish its own security advisory to notify its customer.

The CVE-ID is important for the security community but also the vendor’s customers to know which version of the product is affected by a vulnerability.


Detailed Disclosure

After discussions with the vendor, an agreement will be made on the date to publicly disclose details about the identified vulnerability. This date must be acceptable and realistic for both the vendor and wizlynx group. The vendor may request to postpone the detailed disclosure for maximum 30 days after the patch has been released to ensure its’ customer has time to rollout the patch. In no circumstance will an identified vulnerability be kept secret because a vendor does not want to address it.

The CVE-ID is important for the security community but also the vendor’s customers to know which version of the product is affected by a vulnerability.


Top