Duo Security Disclosure & Bug Handling Policy

The following outlines how Duo Labs handles vulnerability disclosure as well as what security researchers and customers can expect when they disclose a vulnerability to Duo Security.

Our Disclosure Policy

Before we define our general rules of engagement when we attempt to report a security vulnerability to an outside third party, it is important to point out that regardless of the text written here, we will always use our experience and best judgment when handling new vulnerabilities. This means, in some cases we may determine that it is in everyone’s best interest to deviate from our policy. For example, in some cases we may decide that a vendor may need more time to handle a vulnerability, while in others we may determine that the risk is high enough that we need to immediately publish.

Two examples that help illustrate this point are as follows:

A vendor is new to the technology space and has never had to deal with a bug disclosure before. In this case, we will be more tolerant of delays and offer our advice on setting up an effective security response program. We have already experienced this in the IoT space when working with a vendor who has no previous technology/security experience.

or,

We identify a vulnerability that is either being actively exploited or the details of the vulnerability became public via another party. In this case, we may determine that it is best to simply release what we know about the issue and provide mitigation advice so that people can protect themselves while the vendor develops a patch. We have experienced this scenario in the past with issues such as eDellroot.

Our Policy

Bug disclosure is not as easy and straightforward as it sounds. Not all vulnerabilities are equal; some can be fixed very quickly, while others may have a wider impact that requires more thought and engineering behind the scenes. In recognition of this, our policy defaults to giving what is felt to be a reasonable amount of time to respond to and fix more complex issues. However, depending on the specific situation and the conversations taking place between Duo and the folks who are responsible for fixing the problem, there may be deviations from the policy stated below.

To sum up our entire policy in a sentence, We will make our best effort to coordinate disclosure with the affected parties and will always put what we feel are the security interests of the end users at the center of any decisions we make.

Reporting

When we find security issues, we follow these steps to try and find the right point of contact and share with them the details of the problems we want to make them aware of:

Once we have confirmed that we have an actual security vulnerability and have gathered all the necessary information to properly communicate the details to the affected party, we will report it immediately.
We will make a best effort to identify the correct method of reporting a vulnerability to the affected party. We encourage all organizations to provide a centralized contact, such as a security@ or secure@ email alias. However, we understand this is not a standard and may not be possible. This means we will comb the vendor's website, LinkedIn page or if necessary, even work through their support channels.
When possible, we prefer to send vulnerability details in an encrypted format. This means that our initial contact may not include any sensitive vulnerability details but will serve as more of a method to confirm that we have the right point of contact and determine what secure communication options are available.
Also when possible, we will provide an exploit or other proof of concept to help demonstrate the bug. When this is not possible, we will share all technical information we have and even share how we found the issue in the first place.
We will be transparent with the affected parties about our disclosure plans. This includes the sharing of this policy, as well as informing about our publishing plans.
We are more than willing to communicate directly with engineering teams and/or vulnerability handlers and answer any questions or provide more details where necessary.

Response Expectations

What you can expect from us during the entire disclosure process:

The clock (see the Disclosure Timelines section below) starts ticking from the moment we send the first contact attempt via email – not when we receive a response from the vendor. If no response is received, we will continue to attempts to make contact to the best of our ability but will not reset the disclosure clock.
We encourage those who receive a vulnerability report from us to be as transparent with us as possible. We totally understand and are sympathetic that our research may impact your release planning, but our motivation is to protect everyone by getting issues fixed and disclosed in a timely manner.
Please do not ask us to sign a non-disclosure or any other confidentiality agreement specific to the vulnerability we have reported. Our goal is to publicly disclose once a fix is available, as we feel this is the best way to protect end users. Unrelated to the vulnerability disclosure, we would consider entering into such an agreement if it is with the intent to have broader security discussions and information sharing.
COMMUNICATION IS KEY. We will ask affected parties for updates and status on a regular basis. Please respond to us so we do not make any bad assumptions on how the process is going. In general, “over-communication” is the best route to go because it helps prevent any misunderstandings or surprises.

Disclosure Timelines

Our default window of disclosure is 90 days from first contact attempt. This means we expect that the vulnerability being reported is dealt with and resolved within that window. We fully appreciate there will be corner cases and exceptions to this rule that may increase the timeframe beyond 90 days, but communication is key here in order for us to be able to properly assess the situation and the circumstances, which could cause the window to exceed 90 days.
In the event that a vendor does not respond within the first 30 days of attempted reporting, we will assume that no action will be taken. We will disclose the issue publicly and, where possible, include mitigation guidance.
Our 90-day window does not mean that we will sit on a fixed vulnerability for the duration. If the reported issue can be fixed and a fix can be released faster, we encourage this and will coordinate the disclosure with the fix date.
Once the 90-day clock runs out, we will notify the affected parties that the deadline is here and then begin planning the release of vulnerability details and mitigations or fixes. In most cases, this can be considered a small grace period to allow the affected party to coordinate with us as necessary. This grace period shall not exceed 14 days. Via email, we will share details on what we will be releasing and, if available, drafts of any content we are planning to publish.

What We Disclose

By default, we will not release what is known as a “weaponized” exploit. However, Duo may share relevant technical details with partners who are committed to using the information to help protect users.
We will release full details of the vulnerability and all the necessary technical details to properly illustrate the risk. This is typically achieved via a detailed white paper with an accompanying blog post that summarizes the paper.
Where appropriate, we may release videos or other media showing successful exploitation of the vulnerability.
Also where appropriate, we may release tools, scripts or other technical details that can help others identify similar or related vulnerabilities. An example of this might be a fuzzer we developed, or other tooling to automate testing.
Our releases will include a disclosure timeline that outlines our experience of working with the affected party during disclosure, along with the time spent resolving the issue.
If disclosure occurs without coordination with the affected parties, we will make our best effort to include mitigation advice when we are able to do so.
We will work with the affected party to ensure that a CVE entry, which is used to track vulnerabilities, is assigned to the vulnerability when possible.

We believe security is an iterative process, so we fully expect to update and improve this policy over time. If you have any feedback about this policy, we would be interested in hearing from you. For any other questions or concerns related to our approach to vulnerability disclosure, please contact us at labs@duo.com. If you wish to communicate securely, our PGP key is here. You can also find us on Twitter @duo_labs.

##Our Security Response You can find details on how to report a bug to Duo Security and what you can expect from us on our Security Response page. Once our internal Security and Engineering teams have worked through our process we will, when necessary, publish a security advisory on our PSAs page.