This journey began two years ago, and many changes were made until we get where we are today with our bug bounty. In this article we share general knowledge on bug bounty programs and our personal experience on launching and maintaining a program.
Starting from the beginning, let's clarify what is a bug bounty. A bug bounty is a program that consists in the exchange of responsible disclosure of vulnerabilities for recognition or prizes. Security researchers can report vulnerabilities that they have found in the respective organization's bug bounty, and the program will recognize the collaboration. This allows researchers to prove the collaboration which they can latter use in job applications for instance. Also, in most bug bounties, there will be a prize. This can be anything, from a symbolic bounty such as a t-shirt to a huge amount of money.
When organizations don't have a bug bounty, it's very common for the security researcher to not be able to expose the vulnerability that was found to the organization's security team. As support teams don't usually have a process defined for these situations, they often end with the organization remaining vulnerable and the researcher being ignored. In the past, to avoid these situations, we had a dedicated email address published in our web site. This allowed the direct communication between external security researchers and our security team but it was difficult to manage and it wasn't attracting experienced security researchers. These challenges were mitigated with the bug bounty, but more on that later.
In Paddy Power Betfair we have been working the security of our products for many years, and we currently have a security team that develops all areas of security, almost without requiring external services. A few examples of the security areas that are developed internally are Application Security, Infrastructure Security, Security Operations Center (SOC), Risk Management and Security Compliance, and all of these benefit from the bug bounty, as it will be demonstrated below.
The security team supports the Software Development Life Cycle (SDLC) where it provides security expertise to the product development, from its design phase to its delivery to the customers. In an initial phase, support is provided to development teams to design and architecture new products considering threats, in order for them to be resilient and secure. Static Application Security Testing (SAST) tools are also provided and embedded in the Continuous Integration and Continuous Delivery (CI/CD) process. In a near-final version of the product, Penetration Testing (Pentesting) is conducted in collaboration with the development teams and project management. When all identified vulnerabilities are fixed and the product is considered secure, it is finally delivered to customers, and it is daily assessed with Dynamic Application Security Testing (DAST) tools to make sure that it remains secure over time. As new vulnerabilities are identified in licensed and open source products every day, it's important to guarantee that they don't affect our product security.
Although we had all of these controls in place we wanted to leverage our security posture and be another step ahead of attackers. With this in mind, we planned the implementation of the bug bounty. This would allow us to evaluate our work and measure our efficiency by highlighting vulnerabilities that somehow escaped to all of the controls.
Several decisions need to be made when planning a new bug bounty program. Starting with the platform that will be used. The platform should provide at least the following features:
Communicate with security researchers;
Manage vulnerability reports;
Pay bounties to security researchers;
We decided to collaborate with an external company called HackerOne, that provides a multi-featured platform covering all of the mentioned requirements.
To attract security researchers, the existence of monetary bounties is very helpful. We chose this option and reserved budget for the platform and future bounties before launching the program. Also, the response time of the organization is very important. This means that the organization should be constantly improving the internal processes related to the bug bounty - triage, payment, explanation of the vulnerability to its owners and deployment of fixes. All of these tasks require a considerable amount of time and that should be very clear to management.
The bug bounty can be private or public. They are identical, but in a private bug bounty only invited people can participate. In a public bug bounty anyone can participate. We started with a private bug bounty that had around 20 invited security researchers. The platform that we used allowed us to restrict these invites to researchers that had very good reputation only. Having many researchers working actively in a program will most likely result in a big amount of reports, and this is not advised in a program that is recent as internal teams may not be able to deal with all the reports in a reasonable time.
To deal with the reports, there are the concepts of "managed" and "self-managed" program. A "managed" program is a bug bounty where the triage service is provided by a third party and the (owner) organization only handles reports that were previously triaged. In a self-managed program all reports are triaged by the organization. We chose this option when we started our bug bounty. The triage process will determine if a report is accepted as valid or rejected. Reports may be "invalid", for instance, if they are about an out-of-scope domain, or "duplicate" if they are about a vulnerability that was previously reported by another researcher.
The program is always supported by a policy. In the policy, the organization can decide all the rules that they want to implement and enforce to the researchers. One of the main components of the policy is the "scope". We started with a small scope, including only our more mature components, as this reduces the amount of applications that are eligible for a bounty and, consequently, the amount of reports received.
Some vulnerabilities were excluded from our program in an initial phase using the policy, as for instance Denial of Service. Many of these excluded vulnerabilities remain excluded in our program today and may be eligible for bounties in the future. Our policy is also very restrictive with the use of scanners and other tools that may have impact in the performance of our applications.
For two years we gradually increased the number of researchers, scope and bounties. When we went public, we had over 700 invited researchers and all applications in our main domains were in scope. At this point, everyone can see our policy and responsibly report vulnerabilities to us. We also chose to make our program "managed" when we went public, considering that the number of reports would increase considerably, and this has proven to be a good decision. We are now collaborating with an unlimited number of security researchers, with a very distinct set of skills and experience.
The biggest challenge of the program is to maintain the internal processes working smoothly. Good communication between the security team and all other internal teams involved is mandatory. If the time to triage, pay and report vulnerabilities to the internal teams is not difficult to control, the time to fix vulnerabilities is. The development and infrastructure teams need to plan and prioritize the fixes in addition to all their other work. If several vulnerabilities are identified in a short period of time, and are all owned by the same team, providing a fix for all of them in a reasonable time is a difficult problem to solve.
Considering the initial expectations of the program, we can say that the results were surprisingly good. Although we have tight security controls in place, the bug bounty identifies vulnerabilities that managed to be deployed evading detection, allowing us to fix them and improve our security posture. Besides this key improvement, it also helps the Application Security and Infrastructure Security teams to identify gaps in the security controls. It makes the SOC team more confident on the existing controls against the newest threats. As we integrated the data from the bug bounty platform with our internal vulnerability tracker, Risk Management team is able to highlight the vulnerabilities identified by the program to management. Additionally, Security Compliance team is often one step ahead when vulnerabilities are identified by external audits, because they were already identified in the past by the bug bounty and are being addressed. In conclusion, this was a long journey, with outstanding results. Having a public bug bounty is a valuable extra layer of security that we intend to keep for a long time.
by Anett Stoica
by Ovidiu Mățan
by Vlad But
