Why You Should Have an Internal Bug Bounty, and How to do it Right!

This is the beginning of a series of articles for AppSec professionals. Having spent over a decade in the industry, I want to share my knowledge so that you can be more effective and make your job easier. I hope that you will find this series helpful!

Many companies have started to crowdsource their security efforts through bug bounties, but managing a bug bounty also comes with its own challenges. Filtering the quality bug reports from the noise is time consuming. A bug bounty could be very costly, if you have a lot of security issues. And you may find that the security team becomes inundated with so much information that they become overwhelmed and spend less time on all the other things they have to do.

It’s not that a bug bounty can’t be beneficial to your security posture, but if you’re not ready for it, you may find that it creates more problems than it solves. An internal bug bounty, on the other hand, prevents the excess noise you get from all the script kiddies, is based on your budget, and helps the security team be more effective in the long run by generating good will. So, before you create external bug bounty program, start with an internal one.

Step 1: Ensure you have commitment to fix security issues.

It’s common knowledge that you need executives to “buy into” security initiatives, but for your security efforts to be effective, I’d challenge you to take it one step further. It’s not enough that they’ve signed off on security. The executives need to be seen talking about how important security is to the success of your company. In my experience, this is often the single biggest challenge to any AppSec program. What the bosses talk about the most becomes the top priority. For most companies, the focus — and therefore the priority — is getting the product/features out the door as soon as possible.

Q. What if your executives don’t prioritize security?

A. Perhaps they don’t understand security in terms of how it will affect the business, so be sure that you’re telling them the right story. Instead of, “we have x, y, z critical vulnerability” which is how we as security people think about it, explain it to them in terms of the bottom line. The Ponemon Institute does great research every year on the cost of a data breach. The latest study shows that the average cost of a data breach is $3.92 million. So instead of focusing on the details of how SQL injection works, tell them that you have found a vulnerability that could cost the company millions of dollars. If that doesn’t get their attention, remember that your skills are highly valuable and brush up the resume. 😉

Step 2: Set up tracking of vulnerability type, severity, and age

Something I’ve come across in many companies is that vulnerability data is rarely organized in a single place. I understand how this happens - you get information from scanning tools, pen tests, and bug reports, but if you don’t have it organized then it’s hard (nay, next to impossible) to actually get those vulnerabilities fixed. It’s a critical step for any AppSec program to get that information in a central place where it’s actionable for the people who will be doing the fixing.

Q. Where should vulnerability data be centralized?

A. The best place for vulnerability information is in your existing ticket/bug tracking system, but with one caveat - the more accessible the vulnerability data is to your internal network, the higher the chances of that data being misused by a malicious insider (or an outsider with some clever malware). Consider restricting access to security tickets to those with a need to know (i.e., the security department, scrum masters, and developer assigned to the ticket). There’s no reason for Susan in accounting to be able to query all the critical open issues.

Q. Does this mean that the security team is going to spend all their time creating tickets?

A. Oh please, no! Don’t do that to them! The only way that this will work long-term is if you automate the creation of tickets from your scanning tools. Use a script to create tickets for new issues and close out tickets associated with vulnerabilities that have been fixed. Depending on the tools you use, this may get complicated but believe me, it’ll be well worth the effort in the long run.

Step 3: Establish a standard for prioritization and service level agreements

Often, as AppSec professionals we have a reputation for . . . perhaps . . . overreacting . . . at times. This creates a “boy who cried wolf” reputation with the software engineers who we rely on to fix security issues. You can fix this by using an objective standard for prioritizing issues. I’m a big fan of CVSS v3, which gives you a numerical value on a scale of 1-10, with 10 being “absolutely critical, you must fix this right away!”

By using an objective rating system, it not only helps dev teams prioritize security work, but it also lessens potential objections to the severity of an issue.

It’s also important that you set a standard for the length of time it takes to fix security issues, based on severity. Assuming you have completed steps 1 and 2, this gets a lot easier. My recommendations, based on CVSS score, are as follows:

• Critical (9-10): ASAHP (as soon as humanly possible), but definitely no longer than a week. If you can get the executives to agree to a 24 hour deadline, even better.
• High (7-8): ideally within 7 days, but no longer than 30
• Medium (5-6): within 60 days
• Low (1-4): within 120 days

You should adjust this based on the risk profile for your company and your current backlog of issues. If you have 497 critical issues, it may not be reasonable to ask that they all be fixed within the week, but I’d recommend pushing for dropping all feature work until they’re fixed. That’s a lot!

Step 4: Create initiatives for reporting security issues

Now it’s time for the fun part! I call this “the Lord Varys approach to security” because he had his “little birds” everywhere reporting information to him. Shamelessly steal that strategy and create your internal bug bounty! The idea is to reward people for reporting issues and make it fun. A lot of times, people are scared of the security team which de-incentivizes them from coming to you with problems. So, make it fun for people and thank them for their efforts.

Q. Won’t this just incentivize people to create security bugs so they can report them?

A. Maybe. . . So I’d recommend making it part of the rules that they can’t report their own bugs. You know who checked in what code. Do a spot check of the reported security bugs to keep people honest.

Also, I’d advise against giving out cold hard cash. Instead, give out prizes to the top 5 reporters each quarter, rather than the external bug bounty approach of paying for each bug. The rewards can be anything, based on your budget. It could be a candy bar, donuts, or something as fancy as a trip to the Bahamas. What’s important is not necessarily the monetary value of the prizes, but recognition and appreciation. You’re in AppSec, which can be a thankless job at times, so I’m going to guess that you know as well as I do how a little appreciation can go a long way. Even if you simply send out a company-wide email recognizing the winners, you’ll be creating goodwill with your developers, as well as getting more visibility into those hard-to-detect vulnerabilities.

Good luck! Please let me know if you have any questions in the comments below. Better yet, let me know how it goes! I’d love to hear your results.

If you liked this, please subscribe for more AppSec advice!

Originally published on LinkedIn.