Published on December 12, 2016
1. TEN LESSONS LEARNED FROM LAUNCHING A BUG BOUNTY PROGRAMME HACKER HERDING BY: DAN ADAMS, WEB APPLICATION SECURITY SPECIALIST
2. TIP #1: CLARITY OF VISION
3. TIP #1: CLARITY OF VISION People want to get involved in bug bounty programmes, but they need very clear guidance on the programme’s scope, reward structure, eligibility requirements, and agreed disclosure process. It is essential to clearly deﬁne these in order to prevent any expectation gaps from forming.
4. TIP #2: TIMEBOX TRIAGE
5. TIP #2: TIME BOX TRIAGE It is unlikely that managing a bug bounty programme is going to be your sole responsibility in an organisation. It’s essential therefore in order to keep to pre-agreed SLAs (and deliver on those hacker expectations) to clearly delineate and set aside time dedicated to triaging and progressing vulnerability reports.
6. TIP #3: TAXONOMY FOR FUN AND PROFIT
7. TIP #3: TAXONOMY FOR FUN AND PROFIT Very soon you are going to be wanting to provide reports to management on how the bounty programme is progressing. Scrabbling to piece this information together manually is going to rob you of time and become a real ongoing burden. Its much better to spend the time up-front, carefully logging and recording each and every vulnerability and its attributes - what’s its CVSS score? What’s its CVE/CWE category? What system does it impact? Who is the system owner? When was it reported and when was it triaged and closed? Record absolutely everything, and then providing any custom report you want is a breeze. You’ll thank me later. START YOUR FREE BUG BOUNTY PROGRAM ON HACKERONE ANALYTICS AND CUSTOM REPORTS ARE BUILT IN TO THE HACKERONE PLATFORM. CHECK IT OUT FOR YOURSELF
8. TIP #4: KNOW YOUR BOTTLENECKS
9. TIP #4: KNOW YOUR BOTTLENECKS Running a bug bounty programme isn’t just about getting people to report bugs. In fact that’s not even a very signiﬁcant part of a bug bounty programme. The vast majority of your time is going to be spent verifying, triaging and onward-reporting bugs for remediation, and answering queries from current and prospective hackers. The vast majority of a bug report’s lifecycle is going to be spent with it (from the hacker’s perspective) not progressing, and a hacker sat drumming his ﬁngers waiting for a response and resolution. Hours can feel like days to the reporting hacker if he’s waiting on conﬁrmation that his bug has been received or ﬁxed. You’re going to need a slick bug triaging system agreed and in place, and a good downstream workﬂow and commitment from tech teams to ﬁx vulnerabilities fast. Find out where your organisation’s bottlenecks are and try and get focus on these areas. (Fixing bugs fast also prevents dupe reports and hacker frustration).
10. FIND OUT WHERE YOUR ORGANISATION’S BOTTLENECKS ARE AND TRY AND GET FOCUS ON THESE AREAS. (FIXING BUGS FAST ALSO PREVENTS DUPE REPORTS AND HACKER FRUSTRATION). DAN ADAMS
11. TIP #5: START SMALL, START SLICK
12. TIP #5: START SMALL, START SLICK Its easy to get tempted into starting a large public bounty programme, but I would strongly advise you to start small and scale slow - try testing the waters with an internal/private bug bounty programme, or a ﬁxed PoC/pilot with a set bounty pot and a small number of hand-picked hackers. It’s also vital to have a dedicated budget agreed and put aside, with the ability to quickly clear funds. Since no pot of money is inﬁnite, it’s important also to limit your exposure somehow and maintain control over likely expenditure. It may be a good idea, at least initially, to run for a deﬁned trial period, or structure your programme around bursts, sprints or “seasons” so that you have an on-season and an off-season for bug hunting, giving you time in between to clear down vulnerability backlogs and get ready for the next onslaught. READ OUR FREE REPORT ON HOW TO SUCCEED WITH YOUR BUG BOUNTY PROGRAM
13. TIP #6: KEEP YOUR HACKERS HAPPY
14. TIP #6: KEEP YOUR HACKERS HAPPY Your hackers are an amazing resource. And they’re all people, each of whom have slightly different motivations, methods of engagement, bug reporting style and expectations. If you run a bug bounty programme, you’re going to swiftly recognise that its not about bug management, its about people management. The launch of a bug bounty is an amazing way of engaging with other teams throughout your organisation on a positive basis and building a security-focused community. No longer are you a cost centre or the team that likes to say “no”, suddenly you’re the source of bountiful rewards! This can be a real boon that you can build upon.
15. TIP #7: ONE TOUCH
16. TIP #7: ONE TOUCH Templates. Just templates. You’re going to need to manage large volumes of tickets and ﬁnd yourself making the same statements over and over. Save your sanity and as soon as the trends become clear write a few, high quality boilerplate responses for different scenarios. Run them past your teammates, hone them, and use them.
17. TIP #8: MANAGEMENT LIVES MATTER TOO
18. TIP #8: MANAGEMENT LIVES MATTER TOO Its easy to get swept up in the enthusiasm of operating a bug bounty programme but there may be a long list of people that you need to get support from for buy-in both at launch and on an ongoing basis. Are senior management happy at the increased risk proﬁle of operating a bug bounty programme? What about your external comms team? Legal teams? How about your product owners? Do your network team know why they’re seeing a sudden uplift in XSS probes on the web application ﬁrewall? Have you made your compliance teams aware? You’re going to want to engage various teams early as possible, and feed back with the wonderful metrics you’re gathering (see Tip 3) regularly.
19. TIP #9: PARTNER UP
20. TIP #9: PARTNER UP Stick to what you’re good at and don’t try and do everything yourself. Dedicated bug bounty management platforms such as HackerOne (www.hackerone.com) can prove invaluable. They’re not free but they offer solid tooling as well as guidance on programme operation and services such as mediation of any challenges or disagreements with hackers.
21. DEDICATED BUG BOUNTY MANAGEMENT PLATFORMS SUCH AS HACKERONE CAN PROVE INVALUABLE. DAN ADAMS
22. TIP #10: ROOT CAUSE ANALYSIS
23. TIP #10: ROOT CAUSE ANALYSIS Once you’ve been running your bug programme for a while and gathered lots of lovely data (see Tip 3) you’ll get deﬁnite bonus points for going to the next step and instead of just ﬁxing vulnerabilities starting to ask why do we have these vulnerabilities? Analysis of a single ticket in isolation isn’t particularly meaningful but analysis across your entire data set may well show up common causes or vulnerability types, which you can examine for root causes - behaviours of processes in your organisation that are leading to the creation of vulnerabilities. Sort these and you can prevent vulnerabilities being introduced in the ﬁrst place, which is surely the ultimate goal. Even if it means your top hackers may not get the last few hundred dollars they need for that new boat they’ve had their eye on.
24. TOGETHER WE HIT HARDER See the original article at: http://engineering.skybettingandgaming.com/ 2016/11/18/herding-hackers/ Thanks to Dan Adams and Sky Betting & Gaming for allowing us to share this great content!