Bug bounty: When auctioning off our Math problems

Consider yesterdays headline: Microsoft Offers $250,000 Bug Bounty To Prevent Another Spectre-Meltdown Fiasco

Bug bounties can be a valuable marketing tool to:

🐛 strengthen ties between a company and specialists

🐛 reach hidden “talent pockets”

🐛 ensure customers know you care about your product/service security, but, …

Bug bounties are no panacea or substitute for strong security thinking across different product stages and departments. We had Spectre and Meltdown due to the industry shortcoming in this regard, not because we didn’t conduct enough bug bounties.

When estimating the cost of bounties don’t forget to plan and allocate the time needed by your organization to manage results/findings (can be larger than the reward costs by magnitudes).

Good security is taken for granted because it’s invisible to the user! So creating awareness for your security is an uphill struggle for anyone. I understand the urge to allocate limited budget on a bug bounty instead of investing in internal training or awareness.

It is easy to measure / justify the budget due to quick (but short lived) returns from a bug bounty. Accurately measuring real security improvements over a long time frame is much harder.

If budget is limited then priority should be to raise the bar internally regarding infosec and train everyone within engineering/development. You can’t outsource strong security-thinking of your teams.

Your developers might be rockstars but they often still live in a bubble isolated from having to care about security (more often they don’t have time to care because no security questions were asked when defining the features / user-stories etc …).

IETF RFC’s drafts always lacked sections on “security considerations” and eventually in 2003 (after many years of complaining) there was an RFC 3552 addressing the problem. We can learn something from this RFC when creating user-stories, use-cases and implementing features.

Some simple changes to your agile workflows should be higher priority than planning your first bug bounty:

🐛 describe security challenges and solutions with every new feature

🐛 storing and maintaining the threat-model together with your code and testcases

🐛 If your organization is large enough consider internal bug bounties before you open them up to the public.

🐛 …

Consistently maintaining a dynamic threat model gives insight into parts of your stack which should be refactored. Dynamic threat-modeling requires everyone onboard and allows you to identify which part of your product most effectively benefits from a bug bounty and when is the right time for it.

It’s your team that makes your product so this is where you have the most to gain in the long run (and the most to lose if you don’t). What a bug bounty can always give you though, is a realization that long term investments in your security culture should no longer be postponed.

Successful bug bounties (and security audits) are those that seem to yield little results. Keep in mind that there are plenty unsuccessful bounties which just yield noise or where the company was ill prepared.

In general, the number of flaws found should be an inverse quality indicator of how well your internal security thinking is evolving and whether *real* product/service security is progressing.

Andy Ozment published an interesting paper, in case you wish to dig further:

Valbonne Consulting provides Research & Consulting for emerging technologies in Internet/Web of Things (WoT/IoT/M2M) and Emerging-Tech. We specialise in decentralisation, security and privacy. We work across a variety of traditional industry verticals (Telecommunications, Automotive, Energy, ...). We support Open Source and technologies built on open standards.

Joachim Bauernberger

Passionate about Open Source, GNU/Linux and Security since 1996. I write about future technology and how to make R&D faster. Expatriate, Entrepreneur, Adventurer and Foodie, currently living near Nice, France.

One thought on “Bug bounty: When auctioning off our Math problems

Leave a Reply

Your email address will not be published. Required fields are marked *