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 following guidelines to help you navigate the complexity.
| Anchor |
|---|
| Keep_Calm_and_Carry_On |
|---|
| Keep_Calm_and_Carry_On |
|---|
|
| Anchor |
|---|
| _Toc479938953 |
|---|
| _Toc479938953 |
|---|
|
| Anchor |
|---|
| _Toc489873239 |
|---|
| _Toc489873239 |
|---|
|
Keep Calm and Carry On| Anchor |
|---|
| Keep_calm_and_carry_on_1 |
|---|
| Keep_calm_and_carry_on_1 |
|---|
|
Although problems with the disclosure process can be stressful, it's better 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 disclosure 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 give the benefit of the doubt to the good intentions of the involved stakeholders.
| Anchor |
|---|
| Avoid_Legal_Entanglements |
|---|
| Avoid_Legal_Entanglements |
|---|
|
| Anchor |
|---|
| _Toc479938954 |
|---|
| _Toc479938954 |
|---|
|
| Anchor |
|---|
| _Toc489873240 |
|---|
| _Toc489873240 |
|---|
|
Avoid Legal Entanglements| Anchor |
|---|
| Avoid_legal_entanglements_ |
|---|
| Avoid_legal_entanglements_ |
|---|
|
Whatever the issue is in the context of a vulnerability disclosure, lawyers alone are rarely the right answer. Cease-and-desist letters tend to backfire as described in Section 6.8.1. Responding with legal threats can have negative public relations effects in the long term for vendors as well:
- It gives the appearance that the vendor is more concerned about protecting its image than users' security.
- It can give the impression that the organization is bullying an individual.
- It can drive future researchers away from reporting the vulnerabilities they find.
| Anchor |
|---|
| Recognize_the_Helpers |
|---|
| Recognize_the_Helpers |
|---|
|
| Anchor |
|---|
| _Toc479938955 |
|---|
| _Toc479938955 |
|---|
|
| Anchor |
|---|
| _Toc489873241 |
|---|
| _Toc489873241 |
|---|
|
Recognize the Helpers| Anchor |
|---|
| Incentivize_dont_punish_ |
|---|
| Incentivize_dont_punish_ |
|---|
|
For vendors: A person who shows up at your door to tell you about a vulnerability 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 participants in CVD are there because they care about making things better (see Table 1:I Am the Cavalry's Finder / Reporter Motivations). Recognizing them for their good work keeps them engaged and helps everybody in the long run.
| Anchor |
|---|
| Consider_Publishing_Early |
|---|
| Consider_Publishing_Early |
|---|
|
| Anchor |
|---|
| _Toc479938956 |
|---|
| _Toc479938956 |
|---|
|
| Anchor |
|---|
| _Toc489873242 |
|---|
| _Toc489873242 |
|---|
|
Consider Publishing Early| Anchor |
|---|
| Consider_publishing_early_ |
|---|
| Consider_publishing_early_ |
|---|
|
Recall that the goal of CVD is to help users make more informed decisions 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.
See also Sections 6.4, 6.5, and 6.6.
| Anchor |
|---|
| Engage_a_ThirdParty_Coordinato |
|---|
| Engage_a_ThirdParty_Coordinato |
|---|
|
| Anchor |
|---|
| _Toc479938957 |
|---|
| _Toc479938957 |
|---|
|
| Anchor |
|---|
| _Toc489873243 |
|---|
| _Toc489873243 |
|---|
|
Engage a Third-Party CoordinatorWe 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, coordinator, or deployer. When problems arise that you're not prepared to handle, 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:
- CERT/CC
- national CSIRTs that handle CVD cases
- JPCERT/CC
- NCSC-FI
- NCSC-NL
- larger vendors (Google, Microsoft, etc.)
- bug bounty operators (BugCrowd, HackerOne, etc.)
| Anchor |
|---|
| Learn_from_the_Experience |
|---|
| Learn_from_the_Experience |
|---|
|
| Anchor |
|---|
| _Toc479938958 |
|---|
| _Toc479938958 |
|---|
|
| Anchor |
|---|
| _Toc489873244 |
|---|
| _Toc489873244 |
|---|
|
Learn from the Experience| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="04f0a23c-8735-41cd-aee8-c40b936108d6"><ac:parameter ac:name="">Learn_from_the_experience_</ac:parameter></ac:structured-macro>Any process worth doing more than once is one worth improving. To that end, we recommend that participants in CVD take good notes. Hold a retrospective to identify things that went well, things that didn't, and explore changes you can make to your process for next time. This very document is in large part the result of notes taken during "lessons learned" sessions with vulnerability coordinators at the CERT/CC.
As an example of questions to begin a retrospective discussion, consider this list derived from the Scrum Alliance \[120\]: |
- What went well?
- What went wrong?
- What could we do differently to improve?
