Microsoft CVD and Efforts for Industry Collaboration

Wolfgang Kandek

Last updated on: September 7, 2020

Guest Blog by Rodrigo Branco, Vulnerability and Malware Research Director, Qualys

As Microsoft noted in an MSRC blog post, April was a great month for industry collaboration. Using Coordinated Vulnerability Disclosure (CVD), 21 vulnerability researchers (myself included – see MS11-021) worked together with Microsoft and other vendors to identify bugs, assess threats, and come up with fixes to protect customers.

The Microsoft CVD was introduced last July as a way to strengthen responsible disclosure, where researchers work with vendors to provide fixes for vulnerabilities before reporting them to the public. We at Qualys believe that the CVD is an excellent effort by Microsoft to involve researchers in the advanced notification and patching of a vulnerability, and this collaboration between vendor and researcher is the best interest of computer end-users.

The CVD process also outlines the process for a vulnerability that involves multiple vendors. In general when a vulnerability affects multiple vendors, the amount of work spent in coordination rises substantially. For example, different vendors may be on different patching schedules (some release every few months, some release every year), so the policy of each vendor will affect the release of the patch. Typically the researcher should wait for the last vendor and be very clear with all of the vendors about when the vulnerability will be released publicly.

However, the larger the differences of the patch release schedules the more challenging the release process becomes. Each vendor release becomes the equivalent of a public disclosure and gives the skilled attacker sufficient information through the patched and unpatched code to develop an exploit. In such cases going public with the vulnerability information can be acceptable and even preferable, especially if mitigation information is included. Coming to an industry wide consensus will be challenging and require many more discussions on the timeframes involved and what reactione time can be considered reasonable. Microsoft’s own Exploitability Index uses 30 days as the baseline for their exploitability scores of Consistent Likely, Inconsistent Likely and Code Unlikely

The other case important to consider is when a vendor never replies or is unwilling to fix a vulnerability. Microsoft usually responds quickly, but other vendors cannot always respond as quickly. It is important for researchers to consider how long they will wait before releasing the information to the public. This applies frequently with older products that have only infrequent maintenance schedules. In more extreme cases the product is discontinued and the researcher has no reason to wait since there will not be a patch.

The same thinking applies also to Open Source. Sometimes developers don’t have an interest in researching the ramifications of vulnerabilities or have no time or resources to release updates.

Researchers on the other hand sometimes also have problems to get their vulnerabilities accepted by vendors, especially if both researcher and vendor have had little prior exposure to the process. One solution is to submit vulnerabilities to a 3rd party, such as CERT, that will take care of the notification process and has more influence with the vendors. Qualys Vulnerability Research Department is assisting security researchers in understanding the impacts of vulnerabilities, the range of products involved and the best disclosure procedure for the vendors involved.

Share your Comments

Comments

Your email address will not be published. Required fields are marked *