Bug Bounty Programmes - Day 0 and Q1 thoughts




My mate Dan set up our bug bounty programme and wrote a post over at the company engineering blog about it back in November. It’s a solid guide to establishing your own with practical considerations for outlining such a programme, getting it off the ground, running it, rendering the benefits to your organisation and extending its coverage and scope over time.

It’s been a triumph and as we approach month 4 I wanted to spend a bit of time outlining some things worth considering before starting your own programme. I also wanted to dig into some of the points of friction we’ve encountered.


Before You Start (Day 0) 


First things first… Is a Bug Bounty Programme right for you?


If this is new to you and you’ve not already got your own programme up and running, it’s worth stopping to check that starting your own is right for you and your business.


Do you have the right people -or- the right people with enough time?


Your programme is going to need feeding and watering. It’s not just the *fixing* of things you’ll have to find resource for. There is the day-to-day running of the programme, the reviews, the triage sessions, the comms with teams and projects, the admin, the admin, the admin…
  • If you know you’re already short on bandwidth consider how you’re going to address this before you start your own programme. If you’re planning to make your programme public, consider and plan for eventualities like annual leave and sickness. Consider paying rewards on Verification rather than on Fix to avoid delays and to remove the need for long running ‘chaser’ communication threads.


Can you fix what people find?


Seriously, let’s assume your programme is a huge success and on day two your bug-hunters find fifty things you didn’t know were there on day one. Brilliant. Now what?

If you don’t already have the arrangements and workflows in place to treat, handle and respond to bugs and vulnerabilities in good time you’ll be in for a rough ride.
  • Before you start down the path, consider reviewing your real-world capabilities for handling issues. If you’re already subjecting your products and services to regular scrutiny (like penetration tests and vulnerability assessments), you’ll probably already have a means for internalising problems and pushing them through to resolution. If you don’t, then you really want to look at addressing your weaknesses here before you find yourself overwhelmed.


Think Legal. Think Tax.


There are real-world considerations to make when it comes to paying people inside your company, outside your company and maybe even outside your country.
  • Speak with your legal and finance people or consider getting external help.


Pick the right tools


The popularity and visibility of bug bounty programmes today can likely be traced to the prevalence of bug bounty management platforms like BugCrowd and HackerOne. Tools like these provide readymade workflows and, if you’re looking to attract outside talent, a public ‘watering hole’ for your programme. They can also offer readily available access to technical expertise which might be something to consider if you’ve identified resource issues.
  • Engage with these suppliers to find out how their service works, how they can help get your programme up and running, what support they can offer to keep it running and what all this costs.
  • If you’re thinking of starting your programme in a closed/internal fashion, to then open it up later, check that they can support both public and private programmes (BugCrowd and HackerOne both do).



Rules of Engagement - Setting the Scope


You need define what’s in scope for your programme. “Everything” is going to land you, and maybe your bug hunters, in trouble.
  • Do the legwork - enumerate as much as you can yourself.
  • Engage stakeholders across the business to verify what you’ve found and give them the chance to highlight anything you’ve missed.
  • Set clear whitelist/blacklist(s) of targets. Third-party, SaaS, and Cloud hosted Solutions shouldn’t be included unless you’ve got written consent. It’s worth checking to see if these suppliers are already running their own programmes.
  • Consider starting small and then expanding your programme over time. This can give you chance to seek any approvals you need but it also means that your bug hunters will initially be focused on your (core) products and services.


You're on your way (Q1)


Once your programme is up and running you’ll find out soon enough just how well your preparations are holding up. Hopefully the plans you put in place have ‘survived contact” and you’re now happily beavering away fixing issues in a healthy cycle of ‘wash, rinse, repeat’. Hopefully the administrative burden hasn’t overwhelmed you too, and you’re managing to stay on top of reports, getting back to your bug hunters in good time, and overall managing to honour your commitments (including paying out).

Some ‘out of left field’ considerations we’ve encountered include:



Competing Priorities


You might find vulnerabilities arising from your programme jostling for focus against issues arising from penetration tests, issues arising from vulnerability management practices and issues arising from customer reports. You might find yourself fielding the question - Which of these should our engineers focus on first? 
  • Be pragmatic. Hopefully you’re already assigning criticality scores and risk ratings to vulnerabilities that you identify, irrespective of how they come to light. Your bug bounty programme is (really) just another way of identifying vulnerabilities. The how they are identified *shouldn’t* effect the way you consider and address them. Sure, there might be a compliance angle to consider (think remediation timescales) but you should remain focused on protecting our systems and information first.



Bug Bounties are NOT a replacement for Penetration Tests


You might find people asking if they can now dispense with organised, focused penetration tests because (to them) the programme should provide some of the same coverage. There is an obvious financial benefit to switching from a day-based cost model to a findings-based one. There is also (typically) an overhead to arranging tests which can be frustrating, especially if you’re up against a pressing deadline.
  • You need to be clear on the differences and communicate these across the organisation. If you have mandatory testing requirements for projects and services, make it clear that these are still mandatory. On the flip side, have you considered how new projects and services will be included and enrolled in the scope for your programme?



Bug Bounties are for Life


You might run into some assumptions about the longevity of your programme. Some people might assume (or assert) that the programme should have an end state, perhaps based on a budget or calculated from the number of findings.
  • Make it clear that the threat landscape is always changing and that the programme goes some way to ensuring these new threats are considered for the services and products in your care. The findings-based cost model should help alleviate any concerns about a never-ending drain on resources, especially if you’ve set expectations correctly.



Popular posts from this blog

Tools & Techniques - Cloud Firewalls (DigitalOcean)

Image
My home lab is (probably) typical of most security professionals: a beefy workstation running VMWare workstation, a beefy-ish workstation running ESXi and a bunch of laptops, switches and other devices.  I utilise a couple of VPS providers for hosting and exposing VMs to the cloud. My VPS provider of choice has been DigitalOcean for the last couple of years (going by my billing history) and to date, they've been excellent. They recently introduced and advertised a new service feature called 'Cloud Firewalls' and I had chance to have a play with them today. Essentially, they've incorporated a network level firewall service to their VPS offering which can be used as an alternative or in addition to host-based firewalls like iptables, firewalld, etc.  Initial Impressions - Pros, Cons and Limitations Pros No Cost (free!!) - Cloud Firewalls are available at no additional cost. Availability - Cloud Firewalls are available in ever region DigitalOcean operate.
Read more

PCI-DSS: Your CDE may be getting bigger

Image
In December, the PCI Security Standards Council released guidance around scoping and network segmentation for card data environment (CDE) assets. In their own words: “Many organizations struggle to understand where PCI DSS controls are required and which systems need to be protected. This document provides guidance to help organizations identify the systems that, at a minimum, need to be included in scope for PCI DSS. Additionally, the document provides guidance on how segmentation can be used to help reduce the number of systems that require PCI DSS controls.” The guidance goes on to visualise a scoping process, considering each category of system in turn: I believe it’s worth highlighting the ‘broadness’ of the “Connected to OR Security Impacting Systems” . These are cases where the: System component is on a different network (or subnet or VLAN), but can connect to or access the CDE (e.g., via internal network connectivity). System component can connect
Read more

WAR GAMES - Simulating Security Incidents

Image
Why it's a good idea There are a myriad of reasons to test in peace time, the controls and processes which collectively represent your incident readiness. These include: Validating your Incident Readiness - testing can confirm that you are as ready as you think you are, and that nothing has changed resulting in an end state which prevents you from initiating IR.  Assess Controls Coverage and Identify Gaps - testing can confirm your controls coverage is adequate as well as highlighting those gaps which you'd rather not have in the event of a real issue. Demonstrate value of investment - you've probably spent a lot of time and other people's money acquiring controls, attracting talent and preparing for the eventually of an incident. Internal stakeholders will likely already be looking for assurance that their investment has been worth while.  Demonstrate investment and commitment to interested parties - internal stakeholders considered, you'll lik
Read more