SBN

5 Reasons Not to Rely on Bounty Programs

Congratulations! You’ve made the right decision to start a bounty program. Does that mean that you can maintain a secure posture without a web vulnerability scanner and manual penetration tests? And if not, why not?

Many companies are jumping on the bounty program bandwagon and that’s great! Unfortunately, many of them treat it as the primary solution for their web application security, and that’s not so great.

Having a bounty program in place with no internal web application security activities is like having a bank vault with just a simple lock, no cameras, no security officers, no sensors of any kind, and putting up a poster on the bank door saying “$1000 if you can prove that our bank vault can be broken into”. It’s a recipe for disaster.

Let’s have a look at 5 reasons why you should not rely on a bounty program as your primary guarantee of web application security.

Reason 1. Not Everyone Knows about Your Program

Let’s go back to the bank vault example. If you just put a poster on your bank door, only those who pass by will potentially notice it and even fewer will read it. The chance that one of these people is a security professional who would have the skills to actually test your vault is next to none. It’s exactly the same with a bounty program – if you don’t promote it, nobody will know about it.

It’s not easy to promote a bounty program. The less popular brand you represent, the more you have to invest in specialist advertising targeted at the hacking community – just signing up to a crowdsourcing security program will not be enough. All in all, to make your bounty program effective as a primary means of securing your web applications, you would have to invest quite a hefty sum. It would be one of the least economically sound approaches to web security.

Reason 2. Not Everyone Cares about Your Program

Even if hackers know about your program, even if you’re very effective in advertising it, there is no guarantee that a hacker will have a look at your web applications. Hackers have limited time and resources and focus them on work that pays off best.

There are three factors that influence the probability that your bounty program will be perceived as attractive by the hacking community:

  1. Factor one: The money. If a hacker is offered $1000 from your bounty program but they can expect $10000 from another company, they will obviously attempt to get the bigger prize first. Therefore, to have your security tested, you may end up in fierce competition for attention.
  2. Factor two: Difficulty. Obviously, hackers will go for easy jobs first. Therefore, if your web application is full of minor vulnerabilities, you can expect them to be found quickly. All in all, you will waste money on issues that don’t really pose a threat and the really dangerous and difficult-to-find vulnerabilities may linger on forever.
  3. Factor three: Prestige. If you represent a well-known brand, hackers will more likely attempt to help you out because they will be able to brag about it later. If you have a company nowhere as popular as Google or Facebook, you’ll be much farther down their lists.

Reason 3. Bounty Hunters Focus on Specific Vulnerabilities

As we mentioned, bounty hunters are only human, and finding vulnerabilities takes a lot of time. Hackers can’t find a hundred issues a day. They often spend many days working on just one potential vulnerability. This is why they often focus on specific types of vulnerabilities, depending on their area of expertise and personal preferences.

A bug bounty program cannot guarantee comprehensive coverage of all the potential vulnerabilities. Even if a skilled hacker becomes interested in your program, they will most likely just focus on a small class of vulnerabilities, completely ignoring all the others.

Reason 4. It Takes a Lot of Time for the Bounty Program to Work

Even if all the problems above were addressed, the process would take a lot of time. Even if bounty hunters finally learned about your program, became interested in it, and if you found many specialists focusing on different types of vulnerabilities, it would still take them a long time to perform manual security tests on a complex website or web application.

In practice, it means that it may take several months or more for you to see the results of your bug bounty program. Until you see these results, your web applications remain completely open to attacks. And remember, black hat hackers have just as much of a chance to stumble upon your bugs as the bounty hunters.

Reason 5. Bounty Hunters Make You Pay for Using Software You Could Buy

Last but not least, bounty hunters are smart and know how to make their work easier. If they realize that many companies have bounty programs in place but don’t use any automated software, they will use such software themselves. Therefore, bounty hunters may scan your website using Acunetix, find several vulnerabilities, and this way cover the cost of their license.

In the short term, you may think that it is more affordable to let bounty hunters pay for the software that you should be using. However, in the long term, you won’t be protected at all and this may keep happening to you over and over. Not to mention that you’d be missing out on all the other advantages that a web security solution offers you.

Solution: The Complete Picture

Does it all mean that your bug bounty program is useless and investing in it was a mistake? Absolutely not! It just proves that the program should not be treated as the ultimate solution.

Let’s go back to the bank vault example, again. A well-protected bank vault needs cameras installed in several places. In many cases, there would be pressure and laser sensors, too. There would be security guards on duty 24 hours a day next to it. The door to the bank would be secured as well. There would also be alarm buttons for employees, independent communication lines to call for help, and many other measures.

It’s exactly the same with web application security. You need many elements to make it successful:

  1. At the core of your web application security program, you should have a web application vulnerability scanner (a DAST tool) such as Acunetix. This will help you find and address the most issues quickly and effectively. However, this is not enough.
  2. Additionally, you need to perform manual penetration testing to find issues that cannot be detected by any automatic software. Since an internal security team may be biased or overworked, you should order external penetration tests once every few months. If you have the resources, you could also improve your stance by adding red teaming exercises.
  3. A bug bounty program is a great addition to the two above steps. Its primary purpose is to cover only the vulnerabilities that would be missed by the two above steps and to enable responsible disclosure. It should never be treated as a replacement for vulnerability scanning and penetration testing.
  4. You should also consider using a web application firewall that is integrated with your vulnerability scanner. While a web application firewall on its own is not very useful to find vulnerabilities, when integrated with a scanner it can be used to its greatest advantage – to protect you against exploitation of vulnerabilities that have been found but that could not be fixed immediately.
  5. Last but not least, you should consider shifting left and introducing DevSecOps. This would let you test your software as early as possible, using not only DAST but also SAST and/or IAST tools, thus finding even more potential issues before they become a problem.

If anyone tells you that you can achieve security without taking all the above into consideration, they are misleading you. As proof, just recall the bank vault example.

THE AUTHOR
Tomasz Andrzej Nidecki
Technical Content Writer

Tomasz Andrzej Nidecki (also known as tonid) is a Technical Content Writer working for Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.


*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Tomasz Andrzej Nidecki. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/n9sNnaoJOyE/