Responsible Disclosure Policy

NowSecure’s mission is to advance mobile security worldwide. This document explains the NowSecure Responsible Disclosure Policy and what we do when we find software security vulnerabilities.

Summary

Our responsible disclosure policy is informed by our mission and ethics. The process and timeline we follow depends on the type of vulnerability, divided into two main classes:

1. Basic App Vulnerabilities

Affect many apps, and easiest to fix. May be mitigated by the end user by uninstalling or avoiding use of the app. Demonstrate a failure to apply security best practices, and readily avoided by responsible developers.

Disclosure Timeline: Immediate on discovery

2. System Vulnerabilities

Affect web services, mobile OS or system software, or embedded components. Users cannot easily protect themselves by uninstalling a single app, and developers may require extended time to repair and deliver patched software.

Disclosure Timeline: 30 days (may be extended up to 90 days)

As security researchers, we discover software vulnerabilities in mobile apps and operating systems. We follow a responsible disclosure process to translate these findings into actionable intelligence for enterprises, mobile software developers and individuals. This policy explains our responsible disclosure philosophy and process to all parties concerned including software developers, vendors, researchers, organization partners, the media and the public. Some software is commercial, while other projects may be free and/or open source. For simplicity, throughout this document we refer to the “developer” to denote the party identified as responsible for a particular piece of software.

Ethics

Responsible disclosure is well established as a beneficial and ethical practice, and our process incorporates leading standards and reasonable practices to promote mobile security. Our purpose in disclosing software vulnerabilities is to help the affected parties – software developers and mobile users – avoid exploitation by malicious parties. We recognize that in some cases, releasing detailed information regarding certain vulnerabilities (“full disclosure”) could provide information to malicious parties who do not otherwise have that information. At the same time we also recognize that, in most cases, individuals empowered with information can take steps to protect themselves from attack. In all cases we apply reasonable judgment regarding the type of software, degree of risk, and remediation available to users for a given disclosure. We do not always agree with developers on how long a security remediation should take. In some cases we will inform users of a vulnerability before it is patched, because it empowers them to proactively protect themselves.

Disclosure types and timelines

1. Basic app vulnerabilities – Immediate disclosure

For user-installed mobile apps that can be readily uninstalled, we will normally alert developers and users immediately upon discovery of basic vulnerabilities such as man-in-the-middle, sensitive data exposure, lack of input validation, and similar issues. This class of vulnerability affects many apps, and is the easiest to fix. These issues may also be mitigated by the end user by uninstalling or avoiding use of the app. Generally these issues demonstrate a failure to apply security best practices, and can be readily avoided by responsible developers.

2. System vulnerabilities – Deferred disclosure

We sometimes discover vulnerabilities affecting web services, mobile OS or system software, or embedded components such as widely-used libraries. In these cases users cannot easily protect themselves by uninstalling a single app, and developers may require extended time to repair and deliver patched software to users. For this type of issue we provide a deferred disclosure timeline, while maintaining the importance of rapid remediation for protection of users. The standard deferred disclosure timeline is 30 days from notification, and with developer action and collaboration we may extend this timeline. Disclosure extensions require progress in the remediation process and regular status updates. For the security of the mobile community, we do not extend disclosure beyond 90 days from notification, and open reports are automatically disclosed after this time period. We reserve the right to adjust disclosure timelines in cases where expediting or delaying disclosure is in the interest of users’ security.

Disclosure Process

When we discover a software vulnerability the following steps are taken after internal review and validation of the finding. It is important to note that timelines vary significantly depending on the type of vulnerability.

1. Developer Notification – We notify developers of software vulnerability discoveries using their supplied security report email, contact form, or using available contact information. Our disclosure describes the security vulnerability finding, including a description of the method of exploit and result (damage). We may include an impact assessment based on CVSS and reference to CWE or other standards which help classify the vulnerability. We may also request assignment of CVE identifiers for specific vulnerabilities. If we do not receive a substantive response to our notification, we will make multiple attempts to notify a developer. Nevertheless, it is a developer’s responsibility to make it easy to report security vulnerabilities and to respond promptly to such reports (typically within 7 days). NOTE: For basic app vulnerabilities, disclosure will immediately follow the developer notification.
2. Assistance with Confirmation – We help developers understand and replicate the issue we have reported to them. This may take the form of procedural descriptions, videos, and in some cases proof-of-concept code. If the developer provides information contradicting our finding or requiring further research, we will evaluate such information and defer or amend our disclosure. Ultimately if peer review deems our research to be sound, we consider a finding valid whether the developer confirms it or not.
3. Remediation – Developers are invited to provide a timeline to remediation and maintain communication with us, and we understand that the timeline to deploy patched software depends on the complexity of the patch and type of software affected. Regardless of remediation timelines, users have a prevailing interest to be informed of the risk they face within a reasonable time after discovery of a vulnerability.
4. Disclosure – We complete public disclosure on the timeline communicated in our notifications, which may be adjusted based on communications with the developer. Disclosure will normally take place via our security feed (web/api) and alerts to affected NowSecure mobile users. We may notify other researchers, security organizations, media outlets, or use social media to promote awareness of a vulnerability. In cases where a full remediation is not available to users, we may issue a security alert regarding the existence of the vulnerability and its impact, without full disclosure of exploit details. This enables users to make decisions regarding use of the impacted software, while withholding technical details that could enable attackers.

Contact Information

Our security notifications are sent to developers directly via email from a nowsecure.com address, with detailed security information protected using PGP or HTTPS. Any questions about this policy, particular security disclosures or related issues may be submitted through our web site contact form at https://www.nowsecure.com/contact/.

Disclaimer

This policy is a framework and describes a process; it is not a legal agreement. We reserve the right to modify this policy and process, and determine our actions in a given case. In cases where this process conflicts with applicable law or contractual obligations of any party, the law or such obligations take precedence. This document makes no representations or warranties of any kind, and NowSecure assumes no responsibility for errors, omissions or damages resulting from the use of or reliance on the information herein or disclosed by NowSecure.

References

There are many papers, articles and discussions about disclosure of security vulnerabilities. These are a few references that inform our approach.

• Christey and Wysopal’s IETF Draft “Responsible Vulnerability Disclosure Process”
• CERT vulnerability disclosure policy
• Bruce Schneier in CSO Online: Full Disclosure… a “Damned Good Idea”

This document was last revised April 22, 2015.