-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 XPD AB - Security Vulnerability Disclosure Policy This policy describes the XPD AB 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 XPD AB 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 XPD AB will make every reasonable endevour to inform the vendor of all pertinent information. XPD AB will not disclose affected client information without prior consent of that client. XPD AB 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 XPD AB 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 vendors effort to provide a solution and validate the vulnerability. Below is an enumeration of the different steps involved: 1 - Discovery: XPD AB 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 XPD AB 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 XPD AB prior to its general release, to ensure the issue is correctly resolved 5 - Advisory Release: The security advisory is publicly released by XPD AB 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, XPD AB 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. XPD AB 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 XPD AB should be informed of this situation. - Determine if any other of the vendors 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 XPD AB weekly during this phase to provide status updates. If this fails to happen, XPD AB 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 XPD AB'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 XPD AB feels that the vendor is justified in doing so, more time shall be given prior to XPD AB releasing the Security Advisory. If XPD AB are unsatisfied with the situation after 45 days of the initial notification date, XPD AB 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 XPD AB will publish the advisory in order to help provide a workaround to the community. - If the vendor asks for a time extension and XPD AB considers this has been done in good faith. - If the vendor cannot agree a release date with XPD AB 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 XPD AB, the advisory will be released. The following information will be contained in the security advisory: - Advisory Name: A name assigned to the vulnerability by XPD AB - 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 vendors 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----- iQIcBAEBCAAGBQJSjM+jAAoJEH47YPoA7U9kPNAP/Rm+HMYm1n5m3ZOrDH0CJBui BK8tMtlNUIQ9B2LR3miE0d3wD9QtcJLJF0p0ln9ho1LvPCMJ3IVKW19glPv2CJ2Z GUIgfIwGOwvSGFdGA5XSFXxmrg2x4oE6D8b1AG7CwjBGsOA9xIOpRtofeHycwb4x uY+PJVG134t2mz3CFYo1V1BmFf8jdRzwQuzinkj3q4hdQrwDOGhfjMI0jqpYV2U0 AfwkUi6ILaXiNtOZh10Z6eZckt6p63Cr5KF0MpVN5aK7N6WkCn9mqXvzG7EcEKy0 Fpv0b47UaZ4mJ0m9LC30RItH1GgqJkdiBJAvCKVXnv45I9YkqJdIQp2oiH3/cidm wnnuz38AuDM/SmSmJBnHaRILFxmU0B6wB7ocIKt5JHsJ1u+XErYmvJPAA2oECQaQ Wfw8vAccLUcxOCv8VS3xkO5eUQY9IrpTbiS1DSz6Jmxil4gErKUlj4VHN1slLTE6 oT1Z7OION42o3oIAcGovcrWxrQUUPq5S2BR8Tnv8Ren3jt5sl0L0uPcb8C+Q4MXq wlhBNhZeka+o4r6zWBTWQ/+TqR/VpaexwQ4QfO8T543DfZJ+/z8VPtmDe9opthD8 3AdnSOmFOx1fG3t1HFroOBxjAYIKF/gIFwmITQch1DjTC1ciUn7vdG93NmddXm7y p7fyVIdFr4NwQs6+LgL2 =VgW0 -----END PGP SIGNATURE-----