Hiring a Good Hacker

Cyber Security is a key issue, which affects nearly every industry. The frequency and severity of cyber attacks continues to rise, and organizations of all sizes need to learn how to defend themselves. This is where bug bounty comes in.

what is bug bounty ? Essentially, it's a platform that provides a space for security researchers to find and report bugs—whether they are vulnerabilities in software, or problems with the website or system infrastructure.

The goal of a bug bounty program is to give independent security researchers the confidence and flexibility to find and report security flaws, independently and confidentially. This encourages a healthy relationship between security researchers and software/system developers, and provides software/system developers with the confidence that their security efforts are effective and won't be easily bypassed by determined hackers.

Let's examine each part of a typical bug bounty program, and how you can put one in place to find and fix security problems with your website or software.

This role is vital to any bug bounty program. Without a good hacker, the entire endeavor is useless. They will find and report the most critical security issues, which you may not even know were there. Before you start thinking about who you might want to interview, consider the following points:

• They should be a computer scientist (e.g., developer, architect, or a research scientist)
• They should have a good knowledge of modern database technologies
• They should be skilled in finding vulnerabilities in software or systems
• They should have good penetration testing skills (e.g., hackers, white hats, red hats)
• They should have a strong desire to contribute to security of open source projects
• They should have a good understanding of how to research a bug efficiently (e.g., how to break things, how to find the boundaries of a system, etc.)
• They should be familiar with ethical hacking, and breaking and entering (e.g., social engineering, cracking passwords, scanning for vulnerabilities, etc.)
• They should have an excellent record of being reliable and confidential
• They should be able to demonstrate that they have the skills required to conduct a successful attack against a website or system (e.g., via social engineering, brute force, password guessing, etc.).

After the hacker completes the assignment, they must disclose the results to you. This is where the contribution to security of open source projects comes in. Being able to remain anonymous while disclosing critical security flaws is a major key to the whole program. While there are some exceptions for good hackers (e.g., when they discover a serious vulnerability and must disclose it to the vendor), for the most part, the researcher must shoulder the burden of proof that they are who they say they are. This is why you must receive the results confidentially. The following are some of the things you should be looking for in their report:

• The bug should be properly categorized (e.g., vulnerability, security issue, etc.)
• The bug should be properly detailed (e.g., the exact steps required to reproduce the bug, potential impact, etc.)
• The bug should be properly explained (e.g., why it is a bug, how it works, etc.)
• The bug should be properly documented (e.g., through screenshots, binaries, etc.)
• The hacker should provide you with adequate evidence to confirm that the issue exists (e.g., via screenshots, logs, etc.)
• Before you pay the hacker for their findings, you must make sure that the bug is properly understood and confirmed (e.g., by further debugging, testing, or investigation)
• The hacker should be able to provide you with proper assistance, as needed, to help you reproduce the issue and confirm it.
• In the event that you are unable to reproduce the issue, the hacker should be able to help you find the root cause.
• Once you have confirmed the issue, you must be able to confirm that it has been fixed.
• If applicable, you should have the option of fixing the issue yourself (e.g., through a patch, update, or configuration change)
• You must be able to provide proper assistance to the hacker, as needed, to help them fix any issues that you might encounter.

This is the part that you, as an organization or individual, spend the most time working on. It's up to you to decide what kind of vulnerability you want to focus on (e.g., an input validation issue in the login form that any brute force attacker might use, or a format string issue in the code that a good hacker might spot)

The following are some of the things you should be looking for in the report:

• A clear and concise explanation of how the issue can be exploited
• Potential impact of the issue (e.g., data loss, integrity issues, privacy concerns, etc.)
• Detection techniques (e.g., using firewalls, intrusion detection systems (IDS), content filters, etc.)
• Proof of concept (e.g., via code, screenshots, etc.)
• In the event that you are unable to reproduce the issue, the hacker should be able to help you find the root cause
• Before you pay the hacker for their findings, you must make sure that the issue is properly understood and confirmed (e.g., by further debugging, testing, or investigation)
• The hacker should be able to provide you with proper assistance, as needed, to help you reproduce the issue and confirm it
• The hacker should be able to provide proper documentation of the issue (e.g., through code or an explanation letter)

This is where you, as an organization or individual, come in. After you receive the report, you formulate a plan to fix the issue. It's important that you take your time to do this properly, and don't just rush into fixing the issue. Once you have a plan, you can assign a time frame to fix the issue, and get on with your life. While it's always a good idea to patch up any bugs as soon as possible, don't just rush into applying a quick-fix without thinking about the long-term consequences.

The following are some of the things you should be looking for in their report:

• A clear and concise explanation of how the issue can be fixed
• A list of any other issues (e.g., dependencies, configuration issues, etc.) that might occur as a result of fixing the first issue
• The approximate cost of fixing the issue (e.g., if you run into any unexpected issues, or have to spend additional time on the project)
• In the event that you are unable to reproduce the issue, the hacker should be able to help you find the root cause
• Before you pay the hacker for their findings, you must make sure that the issue is properly understood and confirmed (e.g., by further debugging, testing, or investigation)
• The hacker should be able to provide proper documentation of the issue (e.g., through code or an explanation letter)
• The solution should be supported by the evidence provided (e.g., via code or an explanation letter).

As you can see, putting in place a bug bounty program is a lot of work, but it's definitely worth it. Not only does it encourage responsible disclosure, but it also encourages a healthy security community, as well as the open source projects that hackers help maintain. If you want to learn more, here are a few places to start: