Look no further: this article will give you answers to both questions. We will detail what VDPs are, who they are for and what you need to include in a VDP. Think of this article as the Vulnerability Disclosure Policy 101 that your proverbial mental library of tech knowledge has been needing.
What is a vulnerability disclosure policy? What is a CVE?
VDPs are the first step that an organization takes to protect itself from an attack and leads to a heightened level of information security awareness within the IT or security team and within the organization itself. Also known as a Vulnerability Disclosure Program, VDPs are intended to give ethical hackers clear communication guidelines for submitting harmful and potentially unknown security vulnerabilities. These vulnerabilities are reported to the organization that created the product and the information is used to improve product security. Later on, the organization adds these vulnerabilities to the Common Vulnerabilities and Exposures (CVE), a list of publicly disclosed vulnerabilities. Aside from the obvious technological improvement that VDPs offer by allowing for faster bug fixes, the PR and face-saving benefits they offer is equally attractive. Instead of having to suffer the negative press and knock to the organization’s reputation that public disclosure can cause, VDPs give the organization an opportunity to fix the issue before it gets worse. Lastly, VDPs smooth over the chaos caused by a lack of streamlined communication guidelines for when a vulnerability is discovered. Imagine how messy things would become if there are hundreds of vulnerability reports with as many different ways to communicate them — the security team would have to spend a portion of each day just deciphering these reports, and good luck getting such a busy group of professionals to do that!
Who uses vulnerability disclosure policies?
Before delving into who specifically uses VDPs, it may be easier for understanding if we use an analogy. VDPs are similar to a neighborhood watch: they provide an avenue of communication that members of the neighborhood can use if they see something so they can say something about it. Neighbors looking to enjoy the use of their neighborhood can use the neighborhood watch to help take care of a problem. Similarly, members of society can use VDPs to catch vulnerabilities or other bugs that they discover so they can keep enjoying the product. Aside from the general public, there are some defined categories of people that are expected to use VDPs to communicate potential vulnerabilities to the organization. These people are:
Ethical hackers/white-hat hackers Organization information security professionals that want to report vulnerabilities to third-party vendors
What needs to be in a VDP?
Writing a VDP isn’t like writing a book. In fact, they can be quite short. What is important is that your VDP contains five critical elements:
Promise Scope “Safe Harbor” Process Preferences
Promise
The promise section should project a clear, good-faith commitment to the organization’s customers and any other stakeholders that may be impacted by the security vulnerabilities. Sometimes referred to as a “brand promise,” the intended audience for this section is the marketplace, which includes partners, competitors, the media and regulators.
Scope
This section indicates what products, vulnerability types and properties are covered by the VDP. It should include what is in scope as well as what is out of scope. Organizations may want to place limitations on which versions of their products or software are covered as well as what products are off limits due to intellectual property or out of customer data considerations. The audience of this section is the vulnerability finders themselves and lays out where the finders should focus their efforts and where to avoid. Scope should also state which vulnerabilities are fair game and which vulnerabilities are ultimately just noise and of no value.
“Safe Harbor”
This section assures that those reporting vulnerabilities in good faith won’t be unduly penalized. The reason for this section is that vulnerability finders open themselves up to risk and ultimately liability to the organization when they report vulnerabilities. A good example of how this would look to the finder is: “If you follow the above guidelines, we will not initiate or support any legal action related to your research.”
Process
This section contains the process that vulnerability finders are to use to report the vulnerabilities they find — such as how to submit reports and what information the organization has requested to be reported. It should include the logistics of submission (whether by email or other means), as well as what specific details about the vulnerability the finders should include in their vulnerability submissions.
Preferences
This section is presented as a living document that lays out the expectations. In other words, the preferences and priorities about how vulnerability reports will be evaluated. This section should state the expected duration of time between report submission and initial response, how many days before remediation must be complete and whether vulnerability finders can publicly disclose the vulnerabilities they find. This is also the section where you would find out how to escalate issues and what mediation consists of.
Conclusion
Vulnerability disclosure policies provide necessary information for vulnerability finders that want to report their findings to the organization that releases the product or software. They provide a road map that vulnerability finders would not otherwise have, and they streamline the flow of vulnerability reports for the organization. VDPs lead to shorter bug fix times and can serve as a useful compromise between guns-a-blazing vulnerability reporting and the desire of organizations to make public disclosure as painless as possible.
Sources
Vulnerability Disclosure Policy Basics: 5 Critical Components, Hacker One What’s a Vulnerability Disclosure Program?, Bugcrowd Facebook Debuts Third-Party Vulnerability Disclosure Policy, Threat Post
