Date: Fri, 29 Mar 2024 03:00:06 -0400 (EDT) Message-ID: <1741812214.545.1711695606819@windcrest.sei.cmu.edu> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_544_1808466797.1711695606817" ------=_Part_544_1808466797.1711695606817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
While we can't tell you what to do in every possible combination= of contingencies that may arise in the CVD process, we can suggest the fol= lowing guidelines to help you navigate the complexity.
Although problems with the disclosure process can be stressful, it's bet= ter to keep emotions in check while resolving issues. Recall from Section 2.2 that = a presumption of benevolence is helpful when navigating the CVD process. As= we have described thus far in Section 6, multiple things can go wrong in the disclosur= e process, but often these problems do not arise as a result of intentional= acts of malice. So even if something has gone wrong, it's still good to gi= ve the benefit of the doubt to the good intentions of the involved stakehol= ders.
Whatever the issue is in the context of a vulnerability disclosure, lawy= ers alone are rarely the right answer. Cease-and-desist letters tend to bac= kfire as described in Section 6.8.
Responding with legal threats can have negative public relations effects= in the long term for vendors as well:
For vendors: A person who shows up at your door to tell you about a vuln=
erability in your product is not the enemy. That person is your friend.
For researchers: A vendor who is responsive is doing better than many.
For all parties involved in CVD: Give credit where it's due. Many partic= ipants in CVD are there because they care about making things better (see <= a href=3D"https://www.iamthecavalry.org/motivations/" class=3D"external-lin= k" rel=3D"nofollow">Cavalry's Finder / Reporter Motivations). Recognizi= ng them for their good work keeps them engaged and helps everybody in the l= ong run.
Recall that the goal of CVD is to help users make more informed decision= s about actions they can take to secure their systems. Sometimes it becomes= obvious that the coordination of a disclosure has failed. In these cases, = it may make more sense to publish earlier than expected than to continue to= withhold information from those who could use it to defend their systems.<= /p>
See also Sections 6.4, 6.5, and 6.6.
We have outlined a variety of ways in which the CVD process might not go= as smoothly as you'd like, whether you are a finder, reporter, vendor, coo= rdinator, or deployer. When problems arise that you're not prepared to hand= le, or even if you just need a quick opinion on what to do next, there are = a number of coordinating organizations available to help. These include the= following:
Any process =
worth doing more than once is one worth improving. To that end, we recommen=
d that participants in CVD take good notes. Hold a retrospective to identif=
y things that went well, things that didn't, and explore changes you can ma=
ke to your process for next time. This very document is in large part the r=
esult of notes taken during "lessons learned" sessions with vulnerability c=
oordinators at the CERT/CC.
As an example of questions to begin a retrospective discussion, consider t=
his list derived from the Scrum Alliance [1]: