Vulnerability Disclosure Policy

Vulnerabilities are everywhere. You can be assured your systems have them. There is a good chance the vulnerabilities in your systems may be discovered by an outside party. Do you have internal policies and procedures in place on how to deal with that when it happens? Do you have a public version of that posted? If not, this article is for you.

We commonly find no information in typical locations indicating how one should contact an organization to disclose a discovered vulnerability in one of their systems. Here are a few places we look when attempting to make a disclosure:

• “Vulnerability disclosure policy” on the organization’s website
• A securty.txt file – example: https://penconsultants.com/.well-known/security.txt
• Sending an email to security@example.com

If we were trying to make a disclosure to you, would we find those for your organization?

Recommendations

• At minimum: Create a Vulnerability Disclosure Policy (VDP) which details how one is to get in contact with you, what actions your employees should take, etc., when a vulnerability with your software or systems is found. Google “vulnerability disclosure policy” for more details and resources. Your external policy could be something as simple as this: https://penconsultants.com/vulnDisclosurePolicy
• Create a security.txt file at https://EXAMPLE.com/.well-known/security.txt and populate it with the appropriate information. More information can be found: https://securitytxt.org/.
• Create an email alias security@CLIENT.com and ensure multiple people are on the distribution list.
• Consider creating a Bug Bounty program, either on your own or by joining one (or more) industry leading programs. Google “bug bounty program” for more details.
  • Open Bug Bounty has a free option you may wish to start with: https://www.openbugbounty.org/.
  • If you want something a little more polished and refined, HackerOne and Bugcrowd are two well-known programs worth checking into. Note: These programs are approximately $12,000 per year for VDP, $20,000 per yer for VDP+Triage, and higher for a full bug bounty program. (Price dependent on size of company).
• Alternatively, your VDP could simply specify that a disclosee may be provided compensation on a case-by-case basis.
  • We would encourage that compensation consider the amount of time it took the researcher to verify the vulnerability (after discovery), write-up the details, work with you to disclose, etc.
  • A researcher could spend 2-3 hours on even a basic and simple vulnerability disclosure. Depending on country of origin and skill level, researchers are accustomed to making anywhere from $25/hr to $500/hr. Median is ~$75/hr, which is a good starting point, and increased based on the risk level and potential impact of what was discovered. Another way to look at the compensation is, “How much would this have cost us (direct and in-direct costs) had it been exploited?” and ensure you provide a percentage of that to the researcher (ex. 10%).
  • Another method that could be used to determine fair compensation is to find similar bug bounty disclosures and compensation amounts. Example: https://hackerone.com/hacktivity
• Once your VDP is created, and perhaps a bug bounty program created/joined, ensure those details are easily found.
  • The examples of what we check (see above) would be a good start.
  • Important: A growing number of researchers are refusing to disclose discovered vulnerabilities unless there is some assurance on how the disclosure will be treated – professionally and gratefully, versus hostilely, to include threat of prosecution. Having clear guidelines on how both parties will behave gives confidence to well-intentioned researchers, while still providing you the freedom to prosecute if there is malicious intent or harm caused.
• Other resources:
  • https://disclose.io/

_{Featured image is a derivative work from the following images: https://pixabay.com/illustrations/security-professional-secret-5199236/}