-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Matta Consulting Ltd
- Security Vulnerability Disclosure Policy -
####
This policy describes the Matta process regarding the public disclosure of security vulnerabilities. The purpose of this policy is to enable all related parties (i.e. software vendors, researchers and customers) to address the vulnerability and minimise any associated risks.
All vulnerabilities Matta reports will be disclosed to the public 45 days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors.
Special circumstances, such as active exploitation, exceptional or circumstances that require changes to an established standard may result in earlier or later disclosure.
Publication dates will be disclosed to the vendors upon notification through the vendors established security channels (if one exists), and Matta will make every reasonable endevour to inform the vendor of all pertinent information. Matta will not disclose affected client information without prior consent of that client.
Matta does not distribute exploits in our disclosure process.
The final determination of a publication schedule will be based on the best interests of the community overall.
This policy establishes the guidelines followed by the research team upon the discovery of a security vulnerability, it details the steps followed by the research team and the interaction with the software vendor.
The goals of this policy are the following:
- Educate all parties involved, providing the security community with the necessary information to reproduce, study, and verify the vulnerability in question
- Minimize the risks to all affected parties.
- Contribute in making software more secure
- Provide the software vendor with the necessary information to release a solution to the vulnerability in question
- Contribute to research in the security field
####
Steps involved in the process of disclosing vulnerabilities
This section outlines the basic steps taken by Matta’s research team regarding the disclosure of a security vulnerability. Depending upon the specific situations not all steps may be followed, the specific approach would depend on the vendor’s effort to provide a solution and validate the vulnerability.
Below is an enumeration of the different steps involved:
1 - Discovery: Matta identifies a security vulnerability
2 - Vendor Notification: The vendor is notified of the vulnerability and is assisted by the research team with as much technical information as possible
3 - Vendor Corroboration: The vendor should proceed with the reproduction of the vulnerability to verify Matta claims
4 - Fix Development: Once the problem is correctly diagnosed and isolated, the vendor should develop a fix (patch) to the problem in question. If possible, the fix may be tested by Matta prior to its general release, to ensure the issue is correctly resolved
5 - Advisory Release: The security advisory is publicly released by Matta in a coordinated fashion with the vendor involved. The vendor may then release his own advisory regarding the availability of a fix
####
Steps involved in the process of disclosing vulnerabilities
*
Discovery:
Once the vulnerability has been discovered, it is then studied until it can be fully reproduced. Then an internal document regarding the vulnerability is produced, which includes the following information:
- Description of the vulnerability discovered and the potential risks it imposes
- Technical information (as detailed as possible) regarding the steps required to reproduce the vulnerability.
- Proof of concept code, if applicable.
*
Vendor Notification:
Once the document has been produced, the vendor is contacted (via email or phone, depending on the vendor), and a copy of the internal document is handed to the vendor.
This first contact is to be referred as ‘initial notification date.’ Should the Vendor be uncontactable the following steps will be followed:
- If the vendor does not provide security related contact information, Matta tries the official contact avenues of the vendor. If none are given, the advisory is made public
- A new attempt to contact the vendor is made, if the vendor has not acknowledged the previous contact after a 3-day period since the initial notification date
- The advisory will be made public if the vendor has not acknowledged the previous contact informing them that they have either not read the document, or outlined a schedule for the resolution of the security issue during a 7-day period since the initial notification date.
*
Vendor Corroboration:
This phase is only considered for timing purposes. The details of this phase will depend upon the internal processes and the responses of the vendor. Matta provide the following suggestions to enable a mutually agreeable solution to the security issue in question:
- Reproduce the security vulnerability.
- Determine if the vulnerability has already been solved or was already known, in which case Matta should be informed of this situation.
- Determine if any other of the vendor’s products (based on the one with the vulnerability or with similar functionality) have the same vulnerability.
- Isolate the code involved.
- Correct the vulnerability.
The vendor should contact Matta weekly during this phase to provide status updates. If this fails to happen, Matta will release the security advisory.
*
Fix Development:
This phase primarily involves the vendor as it is their responsibility to address the vulnerability by creating a patch or providing a workaround.
The vendor may request time extensions when necessary, with accompanying justification of the time that they will require to address the vulnerability.
The vendor should test the patch prior to release, to ensure that it will not disrupt currently functioning installations. The vendor is actively encouraged to ask for Matta's collaboration for the testing phase of the developed patch.
The vendor is encouraged to resolve the issue within 30 days of the initial notification date. If the vendor has asked for additional time to address the issue, and Matta feels that the vendor is justified in doing so, more time shall be given prior to Matta releasing the Security Advisory. If Matta are unsatisfied with the situation after 45 days of the initial notification date, Matta will make the advisory public.
*
Advisory Release:
Through cooperation from the vendor, a date for public release of the security advisory will be reached. This date will be set allowing for a patch to be made available as soon as the advisory is released. The ‘release date’ will only be changed for one of the following reasons:
- A third party makes public the vulnerability; therefore Matta will publish the advisory in order to help provide a workaround to the community.
- If the vendor asks for a time extension and Matta considers this has been done in good faith.
- If the vendor cannot agree a release date with Matta the security advisory will be published after 15 days.
- If at the date assigned for release, the vendor has not resolved the vulnerability and has not contacted Matta, the advisory will be released.
The following information will be contained in the security advisory:
- Advisory Name: A name assigned to the vulnerability by Matta
- Vulnerability Class: The type of vulnerability in question
- Release Date
- Affected Applications: Vendor's products on which the vulnerability has been detected and successfully tested Unaffected Applications: Other versions of the products mentioned previously where the vulnerability is not present.
- Affected Platforms: Platforms on which the product has been tested positively for the vulnerability.
- Unaffected Platforms: Platforms where the product seems unaffected by the vulnerability.
- Local / Remote: Whether the vulnerability can be exploited remotely or locally.
- Severity: Risks imposed by the vulnerability.
- Researcher: The name of the researcher who originally identified the vulnerability.
- Vendor Status: Whether the vendor is aware of the vulnerability (i.e. has acknowledged our communications with him), and if a patch is available from the vendor.
- CVE Candidate: CVE candidate number.
- Reference to Vulnerability Disclosure Policy: Link to this policy.
- Overview: Description of the product involved and the vulnerability detected.
- Vulnerability Description
- Solutions: Possible solutions, including links to vendor information (patch releases, etc.) and workarounds.
- Vendor Response: A description of the vendor’s response regarding how they dealt with the vulnerability.
- Technical Details*
* Technical details may not be present. In that case the publication will be Catalogued as a pre-advisory and an advisory (including technical details) will be Published three (3) months later.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBCAAGBQJMcn3IAAoJEJafGimXQsJC7FkH/jlV2d1JI3DuTclTlY0z7AbQ
Rh0vMZdT1OBVetbj0qkA0VbwGSYnSh3HDbbIiEZzYwTZwGbZi8tWUFZH7z8jreBN
Y173Y7DMODIfRmX0TX2piwebOd6xIszp+ZW+I9YVY0m/nzuuvVCuehsfMz1zExyg
iHa3fjB/5xQkywsB198m4aobgC0mQMHtjptlqyRZEa+y7FynKDFAmYO1FzdxqnnX
7ESskjPFI1s4HGMYRbSnyziTcXjEa8AmctVkN2lJyylMoJTfBTJqj/74u9pEKOYP
MeA2BJv4PJJhak0ySxLEM4nKEk379TGBlg4LjM4F2cCY7UrFLseeGmlNO7LMv/g=
=98Ed
-----END PGP SIGNATURE-----