Disclosure policy

Mobile Security Lab – Vulnerability disclosure policy

Policy definitions

MSL is Mobile Security Lab. The ISSUE is the vulnerability, problem, or otherwise reason for contact and communication. The OWNER is the individual, group, or vendor that maintains the software, hardware, or resources that are related to the ISSUE. All dates, times, and time zones are relative to MSL. A work day is generally defined in respect to the MSL.

Policy

  • 1. FIRST CONTACT – An email will be sent from MSL as a first contact attempt with OWNER, informing that a possible ISSUE has been found and asking to provide a proper point of contact (POC) for managing the whole process.
    • 1.a The point in time when email is sent is considered the DATE OF CONTACT.
    • 1.b In case a suitable email address for contact is not readily available (e.g. on the public web page of OWNER), the email will be sent to generic addresses such as:security-alert@[OWNER]
      secure@[OWNER]
      security@[OWNER]
      support@[OWNER]
      info@[OWNER]

      MSL is aware that these addresses may not be populated and/or controlled by the OWNER and avoids, at its best, disclosing confidential information to unidentified parties. The only disclosed information will be the possible existence of an issue (MSL encourages population of these addresses and availability of easily accessible security-dedicated address(es)).

    • 1.c Because of the possibly sensitive nature of the issue, no further details will be disclosed until a proper POC has been provided and an adequate security level for the communication has been agreed upon.
  • 2. COMMUNICATION PROCESS – The OWNER must provide a POC within 10 (ten) working days from the DAY OF CONTACT. Failure in doing so will free MSL from any obligation regarding the public disclosure of issue-related details.
    • 2.a Email auto-responses will not be considered as a valid reply.
    • 2.b MSL will provide all the available information that are needed for reproducing and analyzing the issue; in addition to this, OWNER may request additional MSL support for further investigation of the ISSUE.
    • 2.c After a proper contact has been established, OWNER is responsible for providing to MSL regular status updates regarding the ISSUE. Failure in doing so will free MSL from any obligation regarding the public disclosure of issue-related details.
    • 2.d MSL can choose to delay public disclosure of the ISSUE if OWNER provides feasible reasons for requiring so. The decision to delay disclosure is at sole MSL discretion; prerequisite for such a delay is the existence of regular status updates from OWNER to MSL.
    • 2.e During all the process, OWNER is encouraged to keep in touch with MSL following an agreed schedule with regard to ISSUE evolution.
  • 3. DISCLOSURE – MSL will do its best to coordinate with OWNER a public disclosure strategy for the ISSUE and to protect all the involved parties’ interests. If OWNER choose to release an advisory, it is required to provide proper credit to MSL for its research activity in the ISSUE.
    • 3.a Failure to provide credit to MSL may leave it unwilling to follow this policy with the same OWNER on future issues, at MSL’s sole discretion. Suggested (minimal) credit could be: “Credit to Mobile Security Lab for researching the ISSUE”.
    • 3.b OWNER is encouraged to coordinate a joint public disclosure with MSL, so that advisories of problem and resolution can be made available together.
    • 3.c If the ISSUE is publicly disclosed by a third-party, MSL will attempt discussion of the current status of the ISSUE with the OWNER; based on that discussion, MSL may choose to disclose the ISSUE independently.
    • 3.d Should OWNER disclose fully or partially (patches, fixes, etc) the ISSUE, MSL may choose to release an additional advisory.
    • 3.e Should MSL and OWNER arrive at a unified resolution and disclosure, it may be of interest to contact the CVE officials (http://cve.mitre.org) to assign a CVE identifier to the vulnerability. Doing so allows the ISSUE to be referenced and cataloged, facilitating it’s acceptance and use into the community.

    This policy has been inspired by http://www.wiretrip.net/rfp/policy.html and may be revised from time to time; MSL disclaims any obligation to provide notice of changes. Revised policies will bear a new revision date.

Policy Rev. 20081031