Kindred Group has been running a private bug bounty programme since November 2017. Approximately a month ago, we took the next step in our bug bounty journey by going public. We’re taking a step back to look at what has been done and why we have done it.
What is a bug bounty programme?
The internet is a place where a lot of different people co-exist. There are people with malicious intentions, who will try to find ways of exploiting your applications and sites. There are also a lot of people with good intentions, who try to find possible vulnerabilities and report them to the companies behind the applications. That is where a Bug Bounty programme comes in.
A bug bounty programme is a way for ethical hackers to report security vulnerabilities to a company in a controlled manner. As a sign of gratitude, the company can reward swag or money to the ethical hacker for the time spent.
Kindred Group’s Bug Bounty Programme
Kindred’s Bug Bounty Programme launched in November 2017 as a private programme. The main reason for launching this was to get a broader and more extensive security testing of our sites and applications. A community is stronger than one individual. That is also true when it comes to Security.
When launching Bug Bounty, we wanted to aim for the perfect amount of scope, or ‘Lagom scope’, as said in Swedish. So we decided to go with our main site and include all of the subdomains *unibet.com. We wanted to be sure that we could provide the bug bounty researchers with the best possible experience of reporting issues to our program, hence the smaller scope.
We invited around 20-30 Hackers to our private programme and our first valid finding was submitted 6 days after the launch. Since then, we received around 140 valid reports and increased our scope by 1300% by including native apps and more brands. We also made our programme more attractive to the best security researchers by increasing the bounty payouts by 70%.
Captain Hindsight, reporting for service!
Do your preparations
Before launch, we were rather confident that our internal processes would work well to handle any reports coming in through the bug bounty programme.
It turned out our initial process worked in around 50% of the times: if the internal ticket has been assigned to the correct team and placed into their backlog within 1 business day, then the ticket is prioritised according to the severity. We had to go back to the drawing board to agree on a new process, later communicated to all of our tech department. In short, we injected these tickets alongside regular bugs to piggyback on an already existing process built to receive tickets on a regular basis. The success rate is now 95%.
All in all, we learned that we should have been clearer with our expectations, but also more diligent when reviewing and relying on an old process
Scope
Deciding on the initial scope and how it can be approved is crucial. We’ve always tried to have as much scope as possible. Some things, however, can't easily be made in scope: mainly assets related to third parties that we have very little control over. As a result, we are now working on pushing more security requirements towards the third parties, such as forcing them to acknowledge responsible disclosure of vulnerabilities and the existence of our bug bounty programme.
It's important to find a sweet spot of what your initial scope should be. In our case, it was *unibet.com. While starting out with a wildcard domain is not suitable for all programmes, for us, it worked out well. We still try to have as much scope as possible, as malicious hackers don’t care if things are out of scope or not. We’d highly recommend this for all programmes. The same philosophy should be applied to anything that is related to third parties.
Friendly and responsive
Although we’re using HackerOne's triage services to help us handle all the reports, we’ve also tried to be responsive and transparent towards the security researcher. There have been situations where we didn’t quite do our best on this, but are working on it constantly.
Being friendly and responsive, but also transparent towards security researchers will generate a good feeling about your programme and make them more loyal. In other words, they will come back to your programme to try and find more vulnerabilities. In the end, it all comes down to the golden rule of ‘treating others as you want to be treated’. Having bounty hunters who manage the programme internally in their spare time is a big plus.
Going Public
When we went public there was an initial rush of tickets, as expected. It’s very important that your internal team is prepared to handle them and other teams who may be impacted are notified (developers and infrastructure teams). This includes having a clear scope and policies: what assets are in scope vs out of scope and what type of bugs are out of scope.
This will help the team triage the new tickets coming in and make sure they are handled correctly. This will also speed up the response time of the security researcher submitting reports. Going pubic has been a great experience; some reports made us scratch our heads in a good way.
We build on trust
One of our values here at Kindred Group is - We Build On Trust.
Security isn't just a thing that you tick off once a year - it’s something that needs continuous work. By having a public programme, we would like to show that we take trust and security very seriously. We encourage security researchers all around the world to help us protect our customers and assets.
