How to work with hackers

bug bounty

Setting up a Bug Bounty program can be an incredible asset to your organization. By setting up relations with hackers or security researchers, you build a team that works towards helping you be as secure as possible while keeping an eye on your vulnerabilities. At Zerocopter, we differentiate hackers into two groups: those who are participating in private programs, such as Bug Bounty or Dedicated Hacker Time, and those hackers from all over the world who report their findings with Coordinated Vulnerability Disclosure.

By using our platform, you can communicate directly with experienced hackers who have found vulnerabilities in your assets. This is an opportunity to get better insights into how they think and search for vulnerabilities. Here are some frequently asked questions on how to work together with hackers.

Who are the hackers at Zerocopter?

During private programs, only invited hackers can participate. They have been chosen for their skills and knowledge of security. Before being accepted as a hacker for a private program, their identities and backgrounds have been checked. You can be assured that these hackers only use their knowledge to improve the security of your systems. They will never disclose a vulnerability without permission.

How do I set up a program that will get a lot of hackers to participate?

Any program needs a scope with clear rules for the hackers. In the scope of a private program, it can be specified what assets you want the hacker to test for security. It can also specify what isn’t relevant to this program, issues like social engineering or the physical security of your company’s office are often excluded from programs.

The scope also clarifies what the hacker can expect from the company after they send in a report. For a closed program, it is a good idea to add any known vulnerabilities that have not been fixed yet to the scope to prevent hackers from being disappointed when they find these issues. A simple example of a scope can be found here.

Public programs, such as Coordinated Vulnerability Disclosure, will always get a lot of attention. The group of people that will try to find vulnerabilities is much larger compared to closed programs since anyone can participate. For closed programs, the group is smaller, and these invited hackers often have more than one program they can participate in. 

To get more engagement from hackers on private programs, it is advised to give them as much freedom as possible. This can be done by including as much as possible in the program. 

When a system does not have open registration, provide the hacker with accounts with different permissions so that all functionality can be tested.

How should I reward hackers?

For our private programs, rewards are mandatory, for CVD, on the contrary, you can decide how and if you want to reward the hacker. For both types, only valid reports will get a reward.

The more severe the finding, the higher the reward gets. Programs that offer higher rewards get more engagement from hackers. 

To show extra appreciation, a bonus can be given on top of the reward, a place in the hall of fame, or they can be sent some company swag. For example, the Dutch government sends this t-shirt to hackers who report vulnerabilities in their systems.

I want to have a specific function of my assets tested, how can I set up a scope that does not restrict the hackers?

A private program can be used to test for specific issues while also having a broad scope.

Hackers like to have a broad scope for a program, restricting the scope of your program by only adding one specific function in scope will make them lose interest. A solution to having that function tested without restricting the scope is by offering higher rewards to reports regarding the functionality.

This way, hackers do not feel restricted and are more inclined to test the parts that have priority. 

How can I make sure that the security testing does not affect my systems?

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. 

A vulnerability has been accepted by triage. What now?

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.

A report that has been accepted by triage is not relevant to us, can I close this report?

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. 

A report has been accepted by triage, but I don’t understand how the vulnerability works. 

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 all are passionate about their work and will help you understand the vulnerabilities.