crowdsourcing physics

- 4 mins

I’m not endorsing (see also https://disclose.io) or shouting down any of these things - I’m stating them as facts of the existing physics of the vulnerability disclosure coversation.

What some of the recent conversations around platform bans belie a fundamental minsuderstanding of the difference between crowdsourcing and disclosure.

In crowdsourcing the company initiates the discussion (in the form of an invitation or brief) and therefore sets the ROE for subsequent relationship. Payment is invariably a part of the deal, which forms the incentive for the relationship in the first place.

In disclosure the hacker initates the discussion (in the form of vulnerabilities they’ve already found) and therefore sets the ROE for subsequent relationship. Payment is NOT always a part of the deal, and the incentive for the conversation can range for desire to protect the internet, desire to complete, desire to improve one’s resume, and possible a payment if the terms are set in advance (or the program retroactively decides to reward).

The role of platforms is fundamentally different between these two use-cases. In disclosure, our role is to facilitate and MINIMIZE unintended consequences of the progression of a standardized disclosure discussion between a program owner and a finder. This is a conversation which is offered by the vendor via the platform out to the entire Internet (not just the constituent “crowds” or “hackers” or “elite”). Because of this, the professionalism exhibited by the finders and experienced by the vendors varies significantly, and reducing the cost of managing the overhead of this is a task taken on (and a value provided) by the platforms.

This is where bans come in wrt disclosure. If someone is spamming a vendor, or is behaving aggressively towards a vendor, limiting their ability to do so is a part of allowing the vendor to focus their attention on the OTHER vunerabilities being submitted via their program.

As service providers, the platforms offer this option as a means to reduce the cost of dealing with people who are a) not valuable enough, or b) too expensive.

It’s far from perfect in context of disclosure, because it re-establishes the default adversarial relationship which has existed between hackers and vendors for 30 years or more and leads to things like Full Disclosure and lengthy one-sided blog posts.

Disclosure is messy… QED. None of these bugs were meant to be there in the first place, so it should be little surprise that handling the infinite number of potential conversations is part-art, and part-science. Bugcrowd does it because we believe it’s a fundamental right of the user on the Internet, and because it’s something the Internet still needs a lot of help in figuring out how to do well right now.

The other, less understood, aspect of bans comes in around the rapidly emerging pool of folks who want to be a part of the vulnerability disclosure industry. Seasoned security researchers understand the time, place, and power of Full Disclosure (or the use of a lapsed CVD timeline), but rookies will tend to view these tools in the same way a 5 year old views asking their Grandma for something when their Mother has said no. This is a completely reasonable uninformed assumption to make and Bugcrowd goes to great lengths to educate about the history of disclosure and the correct (and incorrect) time and place, but sometimes these lessons need to be taught more quickly in order to protect vulnerability disclosure AS A MOVEMENT and the hacker community AS A WHOLE. This is where temporary bans come in. Permanent bans apply when there’s either an active, consistent demonstration of bad faith, or a hostile interaction between a finder and a program that the program never wishes to repeat again (again, Bugcrowd does a LOT of work behind the scenes to explain in both directions and defuse this type of situation, but it does happen from time to time).

The more common scenario is that we’ll issue a short platform ban to make a point, the finder will realize and understand the “next things they need to learn” and correct course, usually without further incident.

Now… That’s all in a disclosure (i.e. Vulnerability Disclosure Program or Public Bug Bounty) context.

In the case of a private program, it’s a lot simpler: If a program doesn’t like a finder, or a platform doesn’t trust the finder with that program, they don’t have to invite them. Simple, and no different to the “right to refuse” arrangement that exists in any number of other industries.

Hopefully that clears up the why and the how somewhat.

-cje

comments powered by Disqus
rss facebook twitter github gitlab youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora