I gave a talk titled “Working with Hackers: A (Brief) Look at Implementing Vulnerability Reporting Policies” at The Long Con 2018 on 03 November 2018.

Below you will find a copy of the slides and my speakers notes. The slides are also available as a PDF.

Working with Hackers: A (Brief) Look at Implementing Vulnerability Reporting Policies

Welcome to my talk; Working with hackers; A (brief) look at implementing vulnerability disclosure policies and bug bounties

Before we get started, just a quick note. Please respect my privacy and refrain from taking photos. You can find a copy of these slides along with an overview of my speakers notes on my blog @ glitchwitch.io/blog/

Okay, so who am I? I’m GlitchWitch, obviously that’s not my real name but rather a handle I’ve adopted to preserve my privacy

I currently work as a freelance information security researcher doing penetration testing, managing bug bounties and providing consulting services. You can learn more about that on my website.

Over the past decade have worked in a wide variety of roles in a number of different industries.

In my spare time I do my own auto repairs and other hands on work.

Fun fact: this is actually my first time speaking at a conference, so that’s cool!

Today we are talking about vulnerability disclosure policies and bug bounties.

By the end of this talk you should hopefully have a basic understanding of a few things

Including, Why you should have a vulnerability disclosure policy Some best practices to follow when implementing a policy And some resources to help get you started

We will also briefly touch on The differences between bug bounties and vulnerability disclosure policies Some benefits of running a bug bounty And how to prepare for launching a bug bounty

So what is a vulnerability disclosure policy? (or VDP for short)

“A vulnerability disclosure policy is intended to give hackers & researchers clear guidelines for submitting potentially unknown and harmful security vulnerabilities to organizations”

A good Vulnerability Disclosure Policy will provide a path for external parties -such as hackers and researchers - to report issues to you

In doing so it will give clear guidelines for things such as What your scope is - this is what can be tested and what should be avoided.

A good VDP will also ensure safe harbour for researchers and programs owners

And ultimately a successful VDP will improve the overall security posture of your product or organization

So why do you need a vulnerability disclosure policy?

If you have a publicly accessible website or product, you should probably have a disclosure policy for a number of reasons

First of, nothing is 100% secure, we all know this, people WILL find bugs whether you want them to or not.

When those bugs are found a Vulnerability Disclosure Policy provides a clear path on how to handle them, which ultimately will lead to those bugs getting patched faster.

A VDP will also encourage hackers to tell you about the bugs, rather then just ignore them, drop them has zero days, sell them or even exploit them for their own gain.

And of course, a VDP will help quell fears from researchers like myself who have faced legal threats when reporting issues.

This is a big one as often times without a Vulnerability Disclosure Policy researchers end up operating in a sort of legal grey area where they could potentially be violating laws like the Computer Fraud & Abuse Act

A good VDP should include some key elements First there should be guidelines around communication, such as where to report bugs.
This could be a contact form or an email like [email protected] If possible you should also include a PGP key or some other way to submit findings securely

Expected response time. Ideally you will want to communicate when researchers should expect a response from you and set yourself a deadline for when they should hear back about issues. Even with this you’ll generally want to send some sort of an acknowledgement that you have received the report within the first 48 hours.

You should also include expectations around what sort of information researchers should include in the report. For example you might ask them to include a proof of concept or applicable CVE numbers.

And Acknowledgement. This will layout how you will reward the researchers for reporting. Often times just having a bullet point credit can be enough incentive.

You’ll also want to define a scope, what domains, products, or assets you will accept reports for, and what’s is okay for researchers to test. This can be something as simple as everything we own is in scope, but please don’t disrupt services, limit your access to user data, and don’t try to phish or physically break in.

Your VDP should also set terms for disclosure and whether or not researchers can publicly disclose the findings they report to you and when. This can range from no disclosure at all to full disclosure after a patch. You can also handle this on a case by case basis.

And lastly you’ll want to have some sort of legal safe harbour that promises not to take legal action against researchers who are acting in good faith. This would typically include some sort of authorization aswell as a promise not to pursue CFAA violations

Now that we understand why it is we need a Vulnerability Disclosure Policy and what to include in our policy we can take a look at some resources to help get you started.

This first one is an Open Source Vulnerability Disclosure Framework Developed by BugCrowd and CipherLaw. It was designed to help prepare organizations to work with independent security researchers. It offers a set of templates that you can use to quickly write out and publish your disclosure policy

There’s also dislose.io which expands on the aforementioned work by BugCrowd and CipherLaw. Again this project attempts to standardize best practices around safe harbour for good-faith security research.

There is also a free ISO #29147 that gives guidelines for disclosure of vulnerabilities. It’s about 42 pages and goes into great detail on how to properly manage vulnerabilities reports from external parties.

And of course you can always look at other companies disclosure policies to see how they’ve already been implemented. Some good examples would be those from Google, CloudFlare and DropBox

Now that you have an understanding of what you need to successfully implement a vulnerability disclosure policy, we take a look at some common pitfalls to avoid.

The first set are around communication. Things like not having a timely response can be detrimental to your program. Typically you will want to have an initial response within 24-48 hours if possible along with a timeline for further communication. There have been cases where not responded quickly enough can leader hackers to publicly disclose the findings before you’ve had a chance to fix them.

You’ll also want to have a clear internal communication and documentation path. This will include making sure all the applicable teams are on the same page and that you are properly triaging findings and documenting when you don’t. In cases where you make a business decision to not fix an issue right away, it is very important to document why that happened to avoid potential legal and regulatory issues.

This ties in with resources and staffing. Ideally the team that is receiving the reports will be one with strong customer services skills. You have to remember that you are building relationships with people and in some cases the person on the other end of the screen makes their living from stuff like this. Have empathy and be accountable.

Another common pitfall is the inability for your team to properly validate and prioritize the findings. Again having the right people taking these reports can be very important. You’ll want them to be have a strong technical knowledge so that they can independently validate findings as they come in This will also include having a strong communication pipeline with your development and management teams in order properly prioritize fixes and effectively communicate with researchers.

And of course there’s the inability to fix the bugs that are reported to you. This can have several consequences, not just for the obvious reasons of having unpatched vulnerabilities, but also legal problems too.

For example if an incident occurs that leads to regulatory investigation or a lawsuit, it could be very bad if during discovery they find that you had a few hundred unpatched issues.

At this point you should have a good baseline for setting up a vulnerability disclosure policy, and you’re probably wondering, what about bug bounties?

Bug bounties typically differ from vulnerability disclosure policies in a few ways

Bug bounties expand on your existing your existing Vulnerability Disclosure Policy by offering incentives and financial rewards to researchers who discover vulnerabilities within a defined scope.

Bug bounties are typically set up when your organization already has a good security posture and practices in place.

And of course, bug bounties aren’t for everyone. Just because all the cool kids are doing them, doesn’t necessarily mean they are right for your organization.

Before you start preparing to launch a successful bug bounty program, you’re going to want to have a few things.

First you will want to have an existing Vulnerability Disclosure Policy and a strong grasp on handling researcher submissions. Ideally you’ll have had this in place for sometime and will have worked out the kinks in properly handling and triaging issues.

You’ll also want to have a healthy budget for rewarding researchers and paying staff. Having an existing disclosure policy can also help you with estimating the budget that you will need for paying researchers.

And of course you’ll want a good security posture. As you hopefully know, a bug bounty is not a pentest. Having proper security testing by an external team before launching a bounty program will save you a lot of time and money

Before you launch a bug bounty you’ll also want to consider a few things

Rewards How much will you reward researchers? Will you offer cash or swag such as conference tickets or software licenses. If you are paying cash rewards, how much are you willing to pay, and what bugs are worth the most to you? Typically at the very least, if you’ve made a change then you’ll want to reward. However some bugs that have higher business impact might be worth more to you.

Platform: Where will you host your bug bounty? Will you run it yourself or on a platform like HackerOne or BugCrowd And will it be public or invite only?

Pros: International financial and tax paperwork is handled for you Managed bounties reduce internal workload Recognition and immediate response from hacker community

Cons: Expensive (upwards of 20% of bounty payout) Third-party responsible for keeping vulnerability information secure Lots of submissions, often low quality ones.

In Conclusion

Vulnerability Disclosure Policies help improve overall security.

VDP’s encourage researchers to report findings they might not have.

VDP’s take a lot of work to implement, but often are worth it.

Bug Bounties are not for everyone.

Communication is key.