Bug Bounty

Essentially, Coordinated Vulnerability Disclosure (CVD) and Bug Bounty help discover and disclose vulnerabilities in a company’s security systems. CVD is a way for external parties to disclose security vulnerabilities to an organization without fear of punishment. Bug Bounty programs, in contrast, incentivize people to find and report security vulnerabilities in a company’s software or systems and get rewards for doing so.

While CVD is a passive agreement, Bug Bounty programs actively ask reporters to find vulnerabilities and get paid for reporting them. By combining the two, you can strengthen security without directly hiring experts or taking action against reporters who want to disclose vulnerable information. In fact, Bug Bounty programs can be seen as a type of CVD, just with extra motivators.

One difference between Bug Bounty programs and CVD is that Bug Bounty programs can be controlled in size, which differs from the principle of CVD being public. Despite the differences, the two programs go hand-in-hand and can be invaluable to organizations looking to improve their security.

Bug Bounty Programs can vary in duration depending on a few different factors, such as the size and complexity of the digital assets being tested and the goals and resources of the organization running the program. Here are some guidelines for determining the length of a Bug Bounty Program:

• Typically, a testing period lasts one to three months, giving hackers enough time to test the system and identify any vulnerabilities thoroughly. 
• We recommend a minimum of 5 weeks for a Bug Bounty program to run to provide enough time for hackers to search and report their findings. 
• Some organizations wisely choose to run their program continuously, allowing hackers to continuously test the system and report any new vulnerabilities as they are discovered. This approach ensures the system remains secure over time, regardless of how fast you release software. 
• Balancing a thorough testing period and a manageable program that doesn’t lose effectiveness is essential.
•  It’s also important to consider your available resources to manage the program, like personnel, time, and budget.

There are a lot of things involved in making your Bug Bounty a success, and setting up a good program is a lot of work. Zerocopter will take a lot of the work from your hands and assist you with:

• Setting up your scope and creating the perfect briefing for the hackers
• Advising on the right budget for your program
• Vetting and selection the right hackers for your scope
• Triaging all the incoming reports
• If needed, asking for additions on report, and filtering out duplicates
• Communication with the hackers and your team
• Getting a fixed finding retested
• Paying the rewards to the hackers
• Giving you uniform access to all your security reports in one place

All of the above through our proven platform, with a network of world-class hackers, for a fraction of the price that would be needed if you would have to set it up yourself.

That off course depends on your organization and your team. Having many years of experience with creating Bug Bounty programs, we encountered multiple situations where the organization didn’t know if they were ready for a Bug Bounty program. For example: 

• If you have never tested something before, or have no idea where to start, a Bug Bounty is not the thing to start with. Please look at our infographic [here], and start with a <Recon> or <Dedicated Hacker Time> to get a good view of your online attack vector. 
• If you already did some pentest on your assets and have fixed all the issues and all your pentest reports start looking the same, Bug Bounty is an excellent match for you!

In any situation, your team needs to be ready to receive the bugs coming in one by one, in an unstructured way -eg no pentest report-, and they need to be fixed as soon as possible. We also know that your first Bug Bounty program might reveal a lot of stuff that might have been missed in previous tests. But once you get the hang of it, we will promise you that you will be looking forward to receiving new findings!

When you set up a bug bounty program, hackers may report potential security issues in your systems or applications. These reports can come in anytime but don’t worry, you don’t have to be glued to your email all day. However, it’s a good idea to check for reports regularly. If a report with high or critical severity comes in, it’s best to react sooner rather than later. This will help you address the issue quickly and ensure the security of your systems.

There’s no hard and fast rule on what the minimum budget for a bug bounty program should be. However, based on our experience, we highly recommend starting with a minimum of 5000 euros, especially if it’s your first time running a bug bounty program of this scope.

Just so you know, the budget you set aside includes the cost of any reports that need to be reviewed by a triage team. For example, if you have a budget of €10,000 and a report comes in that’s valued at €1,000, your remaining budget will be €9,000. If the report is approved after review, your budget will remain at €9,000. However, if the triage team doesn’t approve the report, the budget will return to €10,000.

When a report is approved, the average cost for addressing the issue will be reserved, based on the severity, until the final payment is scheduled.

Unlike CVD, In a Bug Bounty program our hackers will  for sure assist you in fixing the problem. Not only because they are keen to show their expertise, but also because they have more chances to get selected for more programs and sometimes get a bonus. And you can also always ask our triage team, or even hire a hacker from our pool for advice via our Dedicated Hacker Time.

For our Bug Bounty programs we work with a carefully selected group of security hackers worldwide. We check personal information through an ID verification, review their track record through an internet background check and assess their skills. The selection of Zerocopter hackers is done by the Zerocopter team. When irregularities occur we are authorized to exclude a hacker from the network, according to our Code of Conduct

Hackers at Zerocopter are skilled in what they do. They know that their testing should not affect the normal functionality of a system or its users/customers and will not go further than necessary to prove the existence of a vulnerability.

There are a few rules that can be set in the scope to make sure that the security testing does not impact the normal use of the system or create any unnecessary risks.

It is important to set the following rules:

• Do not take advantage of the vulnerability or problem you have discovered, for example, by downloading more data than necessary to demonstrate the vulnerability or deleting or modifying other people’s data.
• Do not reveal the problem to others until it has been resolved.
• Do not use distributed denial of service attacks.
• Another way to guarantee the security of your asset during a private program is to create a separate environment. This way, the hackers can do all their testing without any risk to the production environment or affecting any regular customers/users.

To get more insight and control over the program, you can request the hackers to use a VPN or set a HTTP header in their requests. This allows you to separate their traffic from other traffic and gives you more information on the behavior of the hackers in your online environment.

After the Zerocopter Triage team accepts a report, you can start working on fixing the vulnerability. For the hackers, it’s nice if they get a simple message thanking them and with an estimated timeline on when this will be fixed.

Once the vulnerability has been fixed you can request the hacker to do a retest to confirm that they can no longer reproduce the issue.

Some vulnerabilities take some more time to fix. When this happens, inform them of the delay and keep them updated with a new estimated timeline. 

These interactions show the hackers that you value their efforts and take the security of your systems seriously.

Sometimes, a report is accepted by the Zerocopter Triage team that, after further investigation, is not as impactful as it seems. Certain mitigations may be in place that only your organization knows about, or the vulnerability was already known to your organization.

To prevent this from happening, list the known vulnerabilities in private programs. When a report like this does get accepted, explain to the hacker why you believe this issue is not relevant to your organization before closing the report.

It will always be disappointing for a hacker when this happens, but providing an explanation and thanking them for their time can mitigate any hard feelings.

Sometimes, in their enthusiasm, reports can be lacking some information, making the vulnerability harder to understand. In the Zerocopter platform, it is possible to talk directly to hackers and ask for clarification. Never hesitate to do this, as almost everyone is passionate about their work and will help you understand the vulnerabilities.