On disclosure, confidentiality, and norms…

A few weeks ago I was tagged by Art Manion of the CERT Coordination Center (CERT/CC) in a tweet asking about Bugcrowd’s approach to disclosure policy defaults. The short version of the thread was concern about a statement in our product documentation that infers that Bugcrowd actively recommends Non-Disclosure as the default policy for our customers. Before I even address our stance, it’s important to clarify why there’s anything to be concerned about to begin with.

There are two definitions for the word disclosure, with regard to security vulnerabilities. To overly simplify, the first is the presentation of a vulnerability from Hacker to Company, while the second is the presentation of this vulnerability, by either group, to the general public (to raise awareness, stop the spread, #teamsport, etc). The benefits of the latter were the cause for Art’s concern. Lots of good comes from ultimately disclosing vulnerabilities for the benefit of your peers, customers, and the broader security community. We agree. But we also understand that sometimes this topic can be a bit confusing [read: alarming] without the appropriate context.

WIth regard to our product documentation, we’ve adjusted the language to more explicitly spell out our stance, but it’s important to provide context here as well. In short, we’re pro-disclosure. In… long(?) there’s a lot more that goes into that than you might realize.

First things first: The model that we default to and recommend for all Public programs is Co-ordinated Vulnerability Disclosure (CVD). Under this model, the hacker and the company agree to release content about the vulnerability after it has been fixed, and once the content has been agreed on. These conditions are non-trivial, and might even help settle any opposing perspectives. If not, allow me to continue.

In an ideal world, we would like to see this as a standardized approach to vulnerability handling across the board – CVD informs of past risk allowing preventative user measure to be taken, it shares knowledge and educates both the whitehat hacker and the vendor communities on how to do security well, and – critically – it takes vulnerabilities from the realm of “secret dirty laundry” to the true state of affairs… Humans write code, humans make mistakes, and sometimes mistakes result in vulnerabilities. The more normalized this truism becomes, the better we’ll be able to focus on identifying vulnerabilities, fixing them, and learning how to prevent them in the future.

All of this said, CVD is both early in its adoption, and not always appropriate for every program or organization. A perfect example of this is the Next Generation Penetration Testing offering Bugcrowd provides where the normal expectation for penetration testing is Non-Disclosure (NDA), and the environments and scenarios where testing is performed are more likely to be negatively impacted by post-fixed public disclosure of vulnerabilities. A large part of Bugcrowd’s mission is to connect as much of the latent creativity of the whitehat hacker community with as much of the cybersecurity problem-space as we can, and the engagement of cybersecurity experts is most often done in private.

This is why Bugcrowd supports both models: To lead the market towards normalization of vulnerability disclosure with CVD, and to maximize the use-cases for connecting our crowd to help solve security problems by supporting NDAs.

So, once and for all, let’s clear this question up:

For public vulnerability disclosure programs and bug bounty programs, the default policy is Co-ordinated Vulnerability Disclosure with the option to select Non-Disclosure. If the customer requests Non-Disclosure on a public program we’ll work to talk them out of it, but we’ll still support it in order to get the program rolling. For private bug bounty programs, private pre-launch VDPs, and for Next-Gen Pen Tests, the default policy is Non-Disclosure with the option to select Co-ordinated Disclosure. In the case of absence of no disclosure policy, or if there’s ambiguity, we default to “ask first” for both the hacker submitting the vulnerability and the program owner.

By having clear defaults and supporting both models, Bugcrowd positions itself to lead and educate the market towards normalization of vulnerability disclosure with CVD, while maximizing the use-cases for connecting our crowd to help solve security problems by supporting NDAs.

The post On disclosure, confidentiality, and norms… appeared first on Bugcrowd.