In this News Insight, Forbes looks at the growing interest in bug bounty programs to enhance application security. Looking for a framework to reassess your mobile security? Download our in-depth guide. —Samsung Insights editorial team
The idea of crowdsourcing information security help from hackers might seem like an odd accepted practice, but it’s clear that bug bounty programs are here to stay. Bug bounties have become an important part of many security programs. Companies that are dedicated to protecting trade secrets and personal information collected from customers and employees have successfully used bug bounty programs to enhance their security efforts.
To define what a bug bounty program is, at their core, bounty programs should act as an incentive for legitimate security researchers to report security vulnerabilities in software that could be targeted by external attackers. These efforts provide researchers an avenue to hunt for bugs without fear of legal retribution, and at the end of the day, also collect a paycheck.
The temptation for some companies who see other enterprises publicly touting the success of their programs is to dive headfirst into their own. But this isn’t an easy path. A certain level of maturity is required for a successful bug bounty program, not to mention a fair amount of preparation, legwork, and restraint.
Many organizations see a bug bounty program—whether it’s a self-managed program or one that’s run through a commercial platform provider—as a way to cost effectively crowdsource their vulnerability identification process. It can also be a useful tool in your vulnerability management toolbox. But there are pitfalls to jumping into a bug bounty program too quickly, and most organizations simply are not mature enough or staffed well enough to withstand the deluge of reported vulnerabilities.
Test Your Mobile Security
White Paper
Download this guide to conducting a mobile security assessment for your enterprise. Download Now
Many public bounty programs are also launched with notable public relations and marketing fanfare. If you’re a big enough company, the media is going to write and podcast about your program and the industry leadership you’re demonstrating in reaching out to a trusted community to find bugs in your web apps. You better be ready.
Here are five milestones you need to hit before you know you ready for a bug bounty program:
1) Know How this Will End
What do you want to accomplish? Companies run private bug bounties and public programs for many reasons, ranging from the obvious of enhancing a vulnerability management program or secure development lifecycle, to garnering some good publicity for your security team. Setting these objectives at the outset will shape your program, from what’s in scope for outside researchers to test, to the rewards you’ll eventually offer. There has to be internal alignment on program goals, or you’re doomed from the start.
2) Fair Game
Speaking of scope, this is crucial and it’s probably wise to start small. Many programs begin public bounty programs with a narrow scope, limiting what’s fair game for bounty participants to, for example, public-facing web applications that do not require authentication. Spell out targets clearly for bug hunters otherwise misunderstandings are sure to discourage participants, hurt the reputation of your program, and leave you well shy of the goals you want to achieve through the program.
3) Receive in Order to Remediate
So many bug bounty programs stumble out of the gate because they don’t have a proper mechanism in place to receive and triage bug reports. It seems like a simple and obvious step, but it’s among the most important. This is your program’s doorway to the public and it has to be clearly visible and spelled out on your website for bug hunters. It could be as simple as a plainly visible security@company email address, or a well-thought-out submission form. Show you are security savvy too; provide participants with public encryption keys to simplify the submission process via email.
4) Talk to Me
Money motivates bug-hunters, it’s true. But most are genuinely motivated by doing the right thing and making the Internet and ecommerce secure. When a submission happens, have a mechanism in place to communicate expectations with a bounty participant. Have the resources in place to evaluate bug reports, confirm bugs as legitimate, and respond to the researcher that the bug is in scope and unique, qualifies for a reward, and that they’ll be paid within x-number of days/weeks/months. Many relationships with bug hunters fall down at this stage, and frustration quickly grows to the point where a researcher could decide to disclose a vulnerability, or publicly express their frustration with the program to the point it damages its credibility.
5) SDL is Hungry; Feed It:
You must be ready to feed bug reports and remediation options to your secure development lifecycle, otherwise, what’s the point of finding bugs in the first place if you’re not going to fix them? Internal engineering and quality control teams must be onboard and trained for the volume of bug reports you’re going to receive, especially at the outset. Be ready for the onslaught and understand the importance of assessing only unique bugs and quickly reporting duplicates to submitters. The stress on engineering, QA, and developers will be significant as a bounty programs rolls out and reports roll in. Don’t proceed without a framework in place to receive and remediate bugs. Otherwise, you run the risk of not only failing to meet your program’s goals, but also, in a worst-case scenario, of paying out for bugs that don’t really matter.
Bug bounties are part and parcel to a vulnerability management program and should never comprise the entire process. They are a complement to ongoing penetration testing engagements and should never preclude an organization from continuing and managing their own vulnerability assessments. The clear goal should be a proactive approach to security and remediation, with a reasonable goal of wiping out classes of bugs rather than fixing one-offs for all eternity (wipe out those cross-site scripting bugs once and for all). Invest in your SDL and triage processes and be sure about what you want to accomplish, and it helps to start small and limit your scope. You want to create incentives for researchers to find bugs, and a great experience keeps them coming back and keeps your company safe.
This article was written by Christie Terrill from Forbes and was legally licensed through the NewsCred publisher network. Please direct all licensing questions to legal@newscred.com.
Looking for a framework to reassess your mobile security? Download our in-depth guide.
