Skip to end of metadata
Go to start of metadata

Although we tend to think of the CVD process as ending with the disclosure of a vulnerability, if the fix is not deployed the rest of the exercise is futile. A patch that is quietly posted to a website and not well advertised is almost useless in protecting users from vulnerabilities. 

Deploying patches typically implies getting users, customers, and deployers to take positive action. Many software products are used by non-technical users. These users are often unaware of how to take remediative action for a vulnerability. A vendor's disclosure plan should consider how to reach the widest audience.

Products with secure automatic updates provide a good way to get a patch deployed quickly to a wide audience. However, not all users are able or willing to use automatic updates, so it is still important for vendors to draw attention to their fixes. Vendors should strive to implement easy and secure update methods in their products. In situations where this is not possible, the vendor's disclosure plan should be specific about how to spread the word of a new patch as quickly as possible.

Avoid Silent Patches

Many system deployers use vulnerability scanning tools to discover systems on their network that need to have patches applied. In turn, many vulnerability scanning tools depend on public vulnerability databases such as NVD. Furthermore, NVD entries are largely dependent on CVE ID assignments. When vendors issue updates without acquiring CVE IDs for the vulnerabilities they address, the patch can go unnoticed by the vulnerability databases, scanning tools, and deployers. Therefore we strongly recommend that vendors acquire as many vulnerability IDs as necessary to clearly indicate which vulnerabilities are fixed by specific patches.

A related issue arises when vendors fail to increment their product version numbers when issuing a fix for one or more vulnerabilities. This makes it much harder for coordinators, vulnerability database providers, vulnerability scanning tool vendors, and deployers to differentiate systems affected by a vulnerability from those that are not.

Amplify the Message

Sometimes it is necessary to draw more attention to a problem or fix. Critical vulnerabilities, including those that are already being exploited or are highly likely to be exploited, may warrant attracting attention beyond merely publishing a document on the vendor's support site. In such cases, additional measures should be taken to draw attention to the existence of the vulnerability or the availability of its fix.

Vendors should consider using:

  • Announcements via social media. Many defenders use services like Twitter or Reddit as part of their daily situation awareness process, routinely sharing useful links and references with each other.
  • Mass media such as press releases, press conferences, and media interviews
  • Working with a coordinator or government agency to draw attention to a vulnerability or its fix. In particular, National CSIRTs can often provide advice or assistance with publicity on important issues.

Post-Publication Monitoring

Once a vulnerability and/or its fix has been disclosed, both vendors and reporters should look for feedback concerning any problems with either the documentation or the fix. In some cases, this can take the form of technical monitoring (e.g., monitoring download logs from the vendor's update service, checking inventories of deployed system versions, or even scanning) to ascertain the rate of defender deployments. Even if such technical monitoring is not possible, not permitted, risky, costly, or otherwise impractical, it is usually possible to monitor for user feedback via support requests, online discussions, and so forth.

In the event of slow uptake of the fix, additional effort might be warranted to call attention the vulnerability (for example, using social media).

It is also possible that the remediation advice is incorrect, or may not apply to all scenarios. Therefore the vendor and reporter should monitor for public discussion or reports of problems, so that the disclosure advisory and remediation information can be updated as necessary. Remember, the goal for remediation is to fix vulnerable product instances or at least reduce the impact of the vulnerability. Consequently, if a significant portion of the vulnerable product instances have not been remediated, that goal has not been achieved.

  • No labels