Certainity
reliable.
trustworthy.
bespoke.
office@certainity.com


CERTAINITY Responsible Disclosure Policy

Website: https://certainity.com/offensive/documents/responsible-disclosure/ | Contact: research@certainity.com

The Offensive Security team of CERTAINITY regularly discovers security vulnerabilities in third-party software during assessments for our customers. We aim to achieve a responsible disclosure where the third-party vendor has the opportunity and time to investigate and mitigate the identified flaw, but customers of the software product are also informed in a timely manner. This responsible disclosure policy defines the timeframe and frame conditions until the public release of a security advisory by CERTAINITY.

Benefits and Goals

The benefits of a responsible disclosure are [1]:

  • Increased security: The primary benefit of responsible disclosure is that it helps to increase the security of software, hardware, and systems. By allowing vendors and organizations to address vulnerabilities before they can be exploited by malicious actors, responsible disclosure helps to prevent data breaches, identity theft, and other types of cybercrime.
  • Improved collaboration: Responsible disclosure promotes collaboration between security researchers and vendors or organizations. By working together to identify and address security vulnerabilities, vendors and researchers can develop stronger and more secure products and systems.
  • Trust and reputation: Responsible disclosure helps to build trust and improve the reputation of both vendors and security researchers. Vendors that respond promptly and professionally to security vulnerabilities are viewed as more trustworthy and responsible, while security researchers who follow responsible disclosure practices are seen as ethical and responsible members of the security community.
  • Legal protection: Following responsible disclosure practices can also provide legal protection for security researchers. By reporting vulnerabilities to vendors or organizations before disclosing them publicly, researchers can avoid potential legal issues related to unauthorized access or hacking.
  • Public safety: Responsible disclosure also benefits public safety by reducing the risk of cyberattacks and other security incidents that could result in harm to individuals or organizations.

Responsible Disclosure Process

1. Advisory Preparation

CERTAINITY will create a security advisory containing detailed information about the uncovered issues including version information and a proof of concept. If the vulnerability was detected during an assessment for a customer of CERTAINITY, the advisory is fully anonymized.

2. Vendor Notification

CERTAINITY will notify the vendor of the affected software in order to establish a direct and secure communication. The security advisory is transmitted to the vendor. The date of the first vendor notification is the start date of the public disclosure deadline (see 4. Public Disclosure). A timeline for remediation until the public disclosure is discussed with the vendor.

The contact will be established via one of the following ways:

  • Bug Bounty Program: If the vendor is part of a well-known Bug-Bounty program or maintains one itself, the advisory is submitted via the bug-bounty program.
  • Public Security Contact: If the vendor has a public security contact that provides encryption capabilities these will be used to transmit the security advisory as well as needed PGP/SMIME certificates. If the contact does not directly provide encryption capabilities, a communication will be established to obtain the needed certificates to initiate an encrypted submission.
  • No Public Security Contact: If no public security contact is available for the vendor, CERTAINITY will use available contact details that can be found online to request a security contact. If the customer, in which environment the vulnerability was found, has a B2B relationship with the vendor and the customer agrees to be disclosed to the vendor’s security contact (public advisories will still be anonymized), CERTAINITY can also use this internal contact to request a security contact. If a security contact is received encrypted communication is established as described above.

Even though it is not recommended, CERTAINITY can send advisories via unencrypted channels if and only if explicitly allowed and wanted by the vendor’s security contact.

If the vendor does not respond to multiple contact attempts, CERTAINITY will revert to a “full disclosure”. In this case the phase 3. Vulnerability Resolution is skipped and the public disclosure (see 4. Public Disclosure) is directly performed after the deadline has expired.

3. Vulnerability Resolution

After receiving the security advisory, the vendor validates the issue and tries to identify the core issue in order to develop patches or workarounds that mitigate the vulnerability. The following is to be considered

  • The vendor should assess the impact and complexity of the vulnerability and provide feedback to CERTAINITY when they estimate it will be possible to provide and roll-out a fix.
  • A coordinated release is scheduled with the vendor. CERTAINITY may extend the public disclosure deadline up to 3 months if compelling reason is provided why the issue cannot be resolved earlier.
  • The vendor must provide a patch or workaround for the vulnerability before the public disclosure. If not, the vendor must provide reasoning why no patch or workaround is provided.
  • Even if the vendor does not agree that the uncovered issue is a security vulnerability and/or no patch is provided, CERTAINITY will still release the public advisory after the public disclosure deadline.
  • CERTAINITY encourages the vendor to share detailed information about software versions and how-to information about the patch to be included by CERTAINITY in the public advisory.
  • The vendor is expected to credit the security researcher and CERTAINITY in the public communications / release notes of the vendor.
  • If the vendor requires additional support by CERTAINITY during the resolution phase (meetings, lengthened email conversations, workshops, additional mitigation ideas, extended explanations), this will be regarded as consulting activities and will need a signed contract and the efforts will be charged. Without further contract, the security advisory is provides “as-is” and CERTAINITY will only perform the required steps to fulfill the described steps in this policy.

4. Public Disclosure

The advisory will be publicly disclosed depending on the scenario:

  • A coordinated release discussed with the vendor during the previous phase is performed containing all information from the security advisory plus the mitigation approaches / patch instructions provided by the vendor.
  • If the vendor did not respond or if no other coordinated release was scheduled, CERTAINITY will release the public advisory after 60 days with all the information from the prepared security advisory but without additional instructions for mitigation approaches / patch instructions by the vendor.
  • If CERTAINITY agrees on an extended disclosure period, a coordinated or individual release is performed latest 5 months after the initial contact date.

Depending on the criticality and impact of the vulnerability, CERTAINITY may withhold detailed proof-of-concept information and/or contact CERT teams of countries if extended user groups are affected

Advisory Content

  • Title
  • Vendor
  • Software Name / Identification
  • Affected / Fixed Versions
  • Criticality Rating (CVSS)
  • CVE Number (if available)
  • Discovery date
  • Vulnerability Researcher(s)
  • CERTAINITY Vulnerability Research Contact
  • Vendor description of the product
  • Vendor / Software homepage
  • Overview of the Vulnerability
  • Proof-of-Concept (PoC)
  • Solution / Patch information / Workaround
  • Disclosure Timeline