If you run a business and have any sort of online presence, sooner or later you will get a call from a “security researcher” about some finding that they have found out about your site. The larger the organization, the more frequent this encounter may be. If you have a bug bounty program, then this is hardly unexpected and you already have a means for dealing with these reports.
But what if you don’t have a bug bounty program? What if you don’t have a full time security person on staff? What can you do? What should you do? Let’s dive into this a bit more in today’s blog post.
Defining a Security Researcher
I want to start off by defining what a security researcher is. A security researcher is any individual who claims to have information about a potential weakness within your website, application, service, infrastructure, or some other finding in a system that you use for your company. The individual may provide details around what they found, or they may also just say they have a finding and would like to inquire if you have a bug bounty program. If you’re lucky, some will just inform you and ask for nothing more than a thank you or a t-shirt as a reward.
So is this extortion? No, this is someone trying to make a name for themselves and going about it slightly awkwardly. In general, testing the security of a company’s systems without their permission can be considered illegal in many jurisdictions, but I’m not a lawyer so I won’t get too deep down that rabbit hole. The truth is a lot of these individuals reside in countries where even when this is the case, there is very little you can do about it. Nobody is going to go out of their way to extradite someone for checking that you have some outdated Wordpress plugins on your site, and threatening them with a lawsuit is likely going to cause more trouble than it’s worth.
I realize this is starting to sound rather negative here, and that’s not the intention. Over the years I’ve had to deal with more than a few of these researcher types, ranging from highly professional to those just fishing for a payday. There are quite a number of highly ethical, honest people out there who are trying to honestly help organizations along. Without knowing who you’re dealing with up front, it’s best to treat them all equally - that is with respect.
Initial Contact
Receiving The Message
How did the researcher get in touch with you? Do you have an email address for reporting incidents? A great start is having a security@company.com email address that goes to someone who can deal with these requests. The head of your IT department, your VP of software development, etc. I find it best if whoever is going to receive these emails can follow along with the initial report and offer some type of first-stage triage of the situation - i.e. is this a legitimate finding, is this a major concern, etc.
Having a generic security@company.com email address is the most common way people will reach out. Contact forms, Twitter/Facebook/Instagram accounts are another one, and some enterprising people may even email the CEO directly to get some attention. I’ve seen entire departments get spammed by a researcher when they honestly don’t know who to reach.
If you want to go further, take a look at this site: https://securitytxt.org/ for details on a proposed standard for providing contact information for security-related incidents regarding your organization. This is a nice way to centralize your security-related communication preferences for your organization, and a great way to re-direct researchers who may be using alternative channels to get in touch with you.
We have one for EliteSec, just in case you would like to see a real life example.
Regardless of how the message came in, you will want to respond from an account that will be the main contact point for the researcher moving forward. Put an individual in charge and continue communications that way.
Response Time
I normally recommend providing a response within the first 24 hours of receiving the message. This can be as simple as a message saying “Thank you for contacting us. We are currently reviewing the information you have provided and will get back to you once we’ve had an opportunity to review. Thank you for your patience.”
You want to ensure that they are acknowledged as it is less likely they will post about any weaknesses you have. Note also that we haven’t committed any reward for reporting anything yet either. This is also important since you don’t want to pay for every report that gets sent to you. Feel free to tweak this message based on the content. Here’s a standard response I share with clients when the researcher is claiming to have found something, but doesn’t actually provide any type of proof:
Hello <name>,
My name is <name>, and I’m a member of the security team here at <company>. Recently you reached out to us asking about bug bounty programs. Currently, <company> does not have a formal bug bounty program, nor do we have plans for one in the near future. Having said that, we do support responsible disclosure for vulnerabilities and security issues.
If you do find a vulnerability, we do encourage you to please let us know with as much detail as possible so that we can validate the findings.
Depending on the vulnerability, a reward may be offered. Factors that impact this include, but are not limited to:
- Whether the vulnerability is already known/reported by another party
- The severity of the issue (we will perform a CVSS calculation to determine severity)
- The ability to recreate and confirm the vulnerability
If you do know of a vulnerability within our product or our website, I do encourage you to let us know. Thanks for reaching out, and let us know if you have any other questions.
Most of the time, the individual will not respond back especially if they did not provide you with any sort of information on what they found.
Validate The Finding
Assuming you have received enough information about the finding, you need a technical resource to actually see if it’s true. Here’s a short list of what I recommend you start with:
Check to see if the content of the report was copy-and-pasted from a blog or article
I see this one more often than not. People will take the content from a blog article, edit the content to make it seem as if it affects your own website, and sends it off to you. The “researcher” has no idea what the blog is even saying, but they see similar output from your own site and so they try to report it to you. This is common if your website uses Wordpress, and the xml-rpc.php “vulnerability” is a common one that is reported.
Validate the finding with Open Source tools
If you are comfortable with doing some research and getting an understanding yourself of what’s being reported, using tools like OWASP ZAP or WPScan can go a long way to give you a second opinion on the finding. Checking in with the firm that did a penetration test is also a great way to get some extra eyes on these types of reports. Most reputable firms will often do this for free if the original software was in scope of the penetration test.
Use your own tools, never anything that is offered
If a researcher offers to provide you with a website, tool, etc, to verify their results, just say no. Just like taking candy from strangers, we do not want you to accept some random tool from a stranger over the Internet. Use your own tools first, or ask a trusted resource for help.
Determining Next Steps
If you do find that a result is indeed realistic, now you have a choice to make. Do you pay them for their efforts, or ignore them? Force them into signing an NDA, or threaten legal action?
My advice is to be honest with them. If they have discovered a bug, offer them a small reward. Check for similar bugs reported on Bugcrowd or HackerOne and see what they have paid out. Let them know you don’t have a dedicated bug bounty program and you can’t provide a massive payout. See if they would be okay with a t-shirt or some other marketing swag if you honestly don’t have a budget. But if the finding was legitimate, pay them a fair reward. Even a few hundred dollars can go a long way to building some good faith.
Normally I recommend keeping a budget of around $2,000 - $3,000 per year for unexpected bug reports. Chances are you will not come close to spending this, but it can come in handy when something serious comes across your desk.
In Summary
Dealing with an unexpected security report from someone claiming to be a researcher can be a stressful experience. Having some key processes in place cna help make things a lot easier for yourself and your organization. There’s obviously a lot more detail I can go into, and every experience is different, but hopefully this is a good starting point.
– John
At EliteSec, we would be more than happy to discuss this topic further and help build out your own processes for dealing with security researchers, including setting up a bug bounty program. Contact us today!