Today a bug bounty program is a must for all businesses, but engaging the hackers community and preparing your internal organization for it can be a challenge. In this article I am going to tell you some experiences acquired, rules and tips for managing a bug bounty program.
A bug bounty program is a sensor
The first questions from the stakeholders in your company that you will have to answer will certainly be of the type:
Why do we need a bug bounty program ? we have already done a lot of pentests and we corrected all reported bugs. Our application will be re-developed very soon so is a new testing phase on this version really necessary ? How could we trust an external and anonymous community to do the testing ?
I usually answer these questions by not only presenting the bug bounty program as a new test method but as a new sensor which allows the catch of the majority of bugs before third parties and general public are aware of them (and actually I do not invent anything it’s very close to the definition of bug bounty on Wikipedia).
In other words your CVD has to be extended by an incentive program and futhermore it can be and should be complementary to other components of your CVD such as security.txt standard, CERT teams, security policy for open source products or websites like zerodisclo.com.
It’s necessary to enrich your CVD and encourage hackers with bounties to disclose vulnerabilities according to your process otherwise others will take the place. For example I usually quote the numbers of reports sent to personal data authority of my country (which have exploded since the introduction of the GDPR regulation), the number of unwanted disclosures to openbugbounty.org or zerodium.com and of course the numbers of security incidents identified by our internal blue teams. This approch has also the advantage to involve your defensive teams and it will be an asset later.
Bug bounty platforms are starting to offer penetration testing services in addition to bug bounty services but one does not replace the other, in fact the both are not done during the same period, the bug bounty takes place essentially when the first version of your application is finished and exposed online contrary to the pentests that can occur a little bit earlier. As a security guide in your company your goal is to fix the bugs the earlier possible so pentests are mandatory and even essential to maintain the quality of a bug bounty program (the majority of bugs will be identified and corrected without stress before the bug bounty).
You also need to communicate on the differences of a bug bounty program, the elements that make this project unique, such as the crowd testing, the paying for results model, the ability to control every version of your applications (the security tests are performed continuously) and the identification of defects in your procedures that may be difficult to detect internally:
- online exposure of assets that should remain private (dev or test environments, metadata in documents ect).
- the lack of robustness during the decommissioning of applications: data, servers, sub-domains not “deleted” correctly (we rarely do a pentest on a product after its end of life, right?).
- sensitive data stored on inadequate web hosting provider.
- the discovering of shadow IT.
- hacking of helpdesks.
Valorize bug bounty data
In this chapter I will give some examples of how the data, which is in our case, bug reports, could flow through all your SDLC thus saving time for security experts and developers.
In a bug report, the data is structured into several fields such as the severity of bug exprimed with the CVSS standard, bug type exprimed with the CWE standard, endpoint, vulnerable HTTP method, payload and many more.
The first opportunity is for example to write the template of a virtual patch on your WAF automatically. This is just the template and there will always be a manual part, made by an human, to guarantee that the patch will not block legitimate trafic and at the same time block the variations of an attack.
With the same idea you can write automatically the template of the test case of a vulnerability and so do some regression testing easily.
And my last illustrated example on this subject is the ability to automate forensics analysis to look for occurences of previous malicious exploits of the same vulnerability but well before the report date.
Bug bounty platforms like yeswehack.com are partner, among other software editors, with commercial WAFs vendors and develop a lot of tools for their customers to efficiently use this data. I have presented some cool methods but you have guessed the more general idea: you must capitalize on the results of your program. It’s not just about fixing bugs in firefighting mode but ensuring that best practices are in place so that the same mistakes do not happen again during application development. Use the data inside the platform as inputs for other security activities that you can perform.
Improve your security monitoring with the bug bounty program
As soon as your program is launched your monitoring teams will be flooded by a lot of alerts related to the activity of hackers and they may lose their ability to identify the ones they call “real attackers”. With a bug bounty program white-hat and black-hat hackers are allowed to do some attacks, of course, before this, black-hat hackers did not wait for your authorization to conduct malicious activity on your network.
It’s essential to remind hackers that they are allowed to do security testing only under certain conditions. To prove that a hacker follow your rules and hasn’t crossed the border (we will see in the next chapter how to attract the best and gentle hackers) you have to work closely with your blue teams and change the way to approach security detection if it not already the case.
In the past, when cyberattacks were not as common as today, monitoring teams used methods such as adding a unique and secret HTTP user-agent to identify and filter the trafic of the “not real attackers” like pentesters allowed to do tests. Sadly these practices continue to be common but this is not an option in a bug bounty program.
In addition, with the introduction of devsecops methodology, tests are executed during each build of your applications and some companies go even further by giving developers the permission to do some amount of manual and automated security tests during the main releases, actually it’s like an internal bug bounty program without financial compensation. To sum up, everyone inside and outside can do legitimately security tests and that’s great, but as a result, there are no more real attackers and false attackers, thus everyone should be monitored.
In general and as a rule don’t make assumptions about some categories of employees, subcontractors or volunteers as “this entity will be always nice and loyal to the company” this is actually the best way to develop a sence of impunity and to create severe security holes. On the contrary be always suspicious and steer towards red vs blue teams exercises to improve the maturity of your organization.
It’s easy to say that but more complicated to practice: you need to correlate the attacks and the impacts to reduce false positives (worry only when impacts are detected) and orchestrate your SOC. For example in a real bug bounty program some hackers have seen the virtual patching of bugs so quickly that they didn’t have enough time to report the vulnerability to the program (the vulnerability was detected in real time from the attacks during the bug bounty). Of course when you are a hacker make a lot of screenshots as proof that the bug was there and report it to the program, it should be accepted. It’s a good example of how a blue team should detect and respond to the exploitation of a vulnerability.
Attract and retain the best hackers
The key to the success of a bug bounty is without a doubt the relationship with the hackers, you must embrace this community.
The first thing to do but the most difficult is to “facilitate the hunt”:
- Your scope should be wide, for example *.yourcompany.com, so that hackers can detect some transverse bugs (tipically “rebound attacks”), shadow IT / websites created outside your control ect. Do not waste hacker’s time by offering small and limited scopes to test.
- Have you heard about Facebook initiative, the white-hat settings menu, in their mobile apps ? This is a very good example of awesome work that Facebook is doing to advantage white-hat hackers.
- Of course, be quick to solve a bug: the faster you are the more you avoid the appearance of duplicate bugs so that hackers continue to test your program.
- You must provide a sort of “safe harbor” to protect hackers for good-faith security research against anti-hacking laws.
The second and essential point is to use “standard methods”:
- Use CVSS, CWE for your entire organization, you will gain interoperability between your entities, services and tools.
- It’s also a good way to be trusted by the hackers, if you don’t use standard methods to qualify the reported bugs you will not be impartial during the reward process: each vulnerability of the same type and on the same website sensitivity must result in the same CVSS and bounty otherwise the hackers will move on another program.
- Your policy about duplicates should be transparent, what are your criteria ? the domain ? the url ? the root cause of a bug ? In practice that’s all of these but put it in writing and do not deviate from your rules. And think about a policy on bypasses too.
The third step is your “compensation strategy”:
- “Do not be stingy” I will go very precisely into it in the next chapter, but for the moment, think only of your competitors, all the other programs like those of Microsoft, Google, Facebook or Dropbox which can inject a lot of money to reward hackers.
- Like for any job, money is not the only motivation for people, if your program is not fun, challenging, respectful you will lose good hackers even if you pay them well. A short story about the Swisspost’s e-voting system bug bounty program in March 2019: three researchers including Sarah Jamie Lewis found a trapdoor in the system but refused to send bug details through the Swisspost’s program (they could expect a reward of 50 000$) and publicly disclosed it, claiming that any information that could impact the democraty should be public. Some people are trying to do good in world, you can’t buy them.
The last step is “hire the best” :
- Hackers like everyone else want to be recognized for the quality of their work, so involve them in the security of your products and services: at first you must recognize your mistakes when a bug is discovered, don’t try to hide it, then ask the hackers for advices: how to fix the bug ? According to your experience in which websites this bug could be found again ? It would be really pretentious to think that only your internal security knows how to secure applications. At the end, go even further by hiring the best hackers in your company !
- Today I write this article to share something I like, hackers want the same thing: talk about their findings, their tools ect. You should go to public disclosure of bugs as soon as you are ready.
Budget allocated to the project
In the last chapter, I urged you to be generous, which is really important if you want to attract the best hackers, act effectively on the community and get some sort of recognition in specialized newspapers or conferences.
But there are some prerequisites:
- If you don’t want to always pay for the same bugs (like XSS) you must have a solid secure development process: give resources, responsibilities and an ambition to your internal teams of developers and security experts.
- You must reward a bug according to your security maturity: increase your payment grid when bugs become harder to find.
- If you know that you are vulnerable with a class of bugs, exclude them of your rules for beginning ! Of course it’s possible for not the most dangerous like open redirect maybe. In this way you focus hackers community on the challenge of breaking your toughest protections.
- Because more the bounty to find a bug is high the more skilled computer scientists take the direction of offensive security career (abandoning defensive security) and, therefore, inside a company nobody knows how to properly resolve a bug with a strategic long term vision. However, as seen before in this article I have given some tips to involve your defensive teams on your bug bounty program and we can also talk about bug bounty programs like FOSSA that reward not just bugs but also fixes.
- On a more social aspect of things, we can see incentive program as a way for companies to buy hackers silence: without public revelations companies that make mistakes are never sanctioned. Are incentive programs good for the end-users / customers ?
- It has also been reported in some countries, like in Asia or Africa, that skilled computer scientists earn a lot in Dollars or Euros with the bounties compared to the low salaries that local companies can offer. Therefore, these last have difficulties to hire the best hackers or developers. I disagree with that, bounties can be an opportunity to negociate a better salary or to have a compensatory income. Hackers who live from bounties are very rare and even if for few it’s possible this doesn’t replace the benefits (other than money) of working for a company.
On the last chapter, I said to use “standard methods”. For example, to facilitate the use of CVSS, I developed a small survey that, once completed, automatically calculates the CVSS and the associated bounty amount :
With the help of Owasp to CVSS tool, your CVSS will always be calculated in the same way, so there will be no more errors for prioritizing the fix or rewarding hackers. This tool is based on Bugcrowd’s vulnerability-rating-taxonomy and Edoverflow’s work to link severity to the bounty amount.
Private and public bug bounty program
Most companies have many programs, some public and some privates. Wladimir Palant, creator of Adblock Plus, says that private programs are a kind of pentest and not bug bounty, and he is absolutely right. You should start with a private program but if you don’t have the goal to open a public program on most of your assets that means you don’t understand how the search for vulnerabilities works: most people outside of your company want to help you to secure your applications.
Enterprises that run private bug bounty programs know exactly what they are doing, they want to reduce the noise of the hackers community (for instance, Microsoft receives 200 000 reports per year that need to be triaged) especially duplicates, they want to select the hackers to invite or maybe they simply want to stay in a defined rewards budget. The bug bounty was created to engage the entire hackers community because more eyes scrutinize your products and services and more you will have the chance to find bugs. In fact, it’s often the elite who is invited to private programs, even if they will find some bugs they will not be able to spend a lot of time testing your applications because they are overbooked.
It’s maybe the best time to speak about the choice of a platform :
- All platforms share the same type of UI, features, services and they do bug bounty of their platform on their own platform.
- They are different by the hackers community and how it is managed, the first criteria is of course the number of hackers registered on a platform but also their location. You may want to maintain relashionship with your local hackers community near your business to organize, for example, social events or try to hire some of them in the future.
- Also the regulation tie to a platform may be important: US platforms are subject to the patriot / freedom act for instance.
- We can notice that big companies like Google are not customers of a platform and they organize their bug bounty with their own. Some organizations try also to not be dependent on one platform and share their programs on many.
Create an internal newsletter
Bug bounty is a very lively and rich area, there are many things to consider, for example, more and more students learn from the past bugs disclosed on bug bounty platforms, these last are very interesting and offer interfaces with WAFs, security scanners, static analysis technologies or ticketing systems and free services such as cyber security trainings (CTF, quiz ect) or information security jobs board like jobs.yeswehack.com.
Some bug bounty take place on open source projects : the FOSSA program organized by the European Commission on open source projets used by the Commission (Apache, VLC, drupal …) or the Gitlab bug bounty program are good examples. In these cases, patches that fix the bugs identified during the bug bounty are visible to everyone and this is an opportunity to link your bug bounty program with your application security program. For example, you can reproduce on a test / training environment real bugs reported during your bug bounty program to give the opportunity to all the employees of your company to try to break your applications like the hackers did it.
For all these reasons I recommend you to create an internal newsletter . To do that, watch news platforms and tools:
And some interesting hackers:
Tell the stories about bugs discovered on other programs :
- June 2019, 5 000$ for a bug in WhatsApp voice call that allows the caller to switch it to a video call without the authorization of the receiver.
- May 2019, 5 000$ for the leak of a valid Grammarly’s GitHub token in Travis CI logs.
- February 2019, 20 000$ for a bug that could lead to denial of service on Facebook infrastucture.
- February 2019, 15 000$ for a bug in Facebook messenger that allows to access to private attachments of users.
Remember that even with a bug bounty program your products will never be bug-free, there will always be security incidents, breaches, privacy impacts ect. The bug bounty doesn’t replace another security process, it’s actually an additional cost that will not help you to fix your bugs quicky, robustly and at a scale on the same kind of vulnerable assets. I think bug bounty programs are essential and very interesting project to manage, but first and foremost you need to focus your efforts on security by design.
Other resources on the same subject