Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

9/12/2019
02:00 PM
David Baker
David Baker
Commentary
Connect Directly
LinkedIn
Twitter
RSS
E-Mail vvv
100%
0%

A Definitive Guide to Crowdsourced Vulnerability Management

Knowing about a bug and actually securing it are very different things. These six steps will get you from "oh, sh*t" to fixed.

There is no shortage of vulnerabilities to find. According to a new report from Bugcrowd, the total number of vulnerabilities reported over the past year has nearly doubled. (Disclaimer: I am the chief security officer at Bugcrowd). Crowdsourced security programs have emerged as an effective way to help organizations find and fix these unknown vulnerabilities faster. But knowing about a bug and actually fixing it are very different things.

What's needed is a clear and demonstrable intake channel to receive and process vulnerability submissions from external security researchers, plus consistent and repeatable processes and procedures to respond to the surfaced vulnerabilities.

So, what should that workflow look like? Here is a helpful checklist to guide your organization:

1. Take all submissions seriously. It's easy to get wrapped up in just focusing on critical-level (P1 and P2) submissions. But it's often the P3s and P4s that are chained together that lead to another critical exposure. Keep in mind that a person took his or her own time to identify a security issue and report it. Researchers are showing you a measure of respect, so do the same for them and review every report. Ignoring researcher submissions wastes their time and only prolongs your company's exposure. The researchers may be wrong about the submission's overall risk of impact. And that's OK! They will appreciate your acknowledgement of their work.

2. Know the risk, get it fixed. After a critical issue has been identified, it's important to think beyond just filing a ticket and waiting for engineering to fix it. While this might be out of your immediate scope, it's now your responsibility to make sure the vulnerability gets remediated in a timely manner. Follow an agreed upon security development life cycle (SDLC): track down all the relevant parties, explain the risk, and escalate as needed. Critical findings should never get lost in the backlog, and security is no place for politics to endanger the trust of your end users. If the entire organization is aware of the risk and is onboard with security being a priority, then it makes a lot easier to get things fixed more quickly.

3. Thank the reporting researcher and have an open dialogue. Communication here is key. Make sure researchers know they are valued and welcome to continue hacking on your program. This is done by putting in the time, effort, and dollars. Be sure to tip if it's a particularly valuable finding! Even if the submission is invalid, taking the time to understand the submission from the researcher's perspective. Coaching them on true impact or how to better find vulnerabilities on your platform will earn their loyalty, which can pay off for future submissions. It's not difficult to orchestrate these narratives with a managed vulnerability disclosure or bug bounty program. To avoid misunderstandings, be open and willing to have a conversation to completely appreciate what's being reported and why.

4. Validate the fix. Often engineers may not fully understand what they're fixing, or why. Or, maybe the problem was outsourced to someone who is three levels abstracted from where it was found, and they're just looking to make the proof of concept go away. The fix may be partial (blacklisting one or two offending characters), uninformed, or ineffective altogether. Be sure the fix is sufficient; try to break it, review the code, and send it back if it's incomplete.

5. Keep in touch. Once remediated, go back to the researcher and tell him or her what you've done to see if they can find a way around that hasn't been considered by your team. Remember to thank them again for their work, and that you look forward to future findings.

6. Increase your scope and rewards. Having avoided disaster, now more than ever it's important to double down on the reality that having a crowdsourced program can (and does) help you identify issues before they're otherwise exploited in the wild. Make sure researchers are testing your full attack surface and are incentivized to do so.

Over the last few years, we saw mega-bugs like Meltdown, Spectre, ETERNALBLUE, Double Kill, and the notorious vulnerability in Apache Struts2 — which was responsible for the Equifax breach. These are just a few examples of bugs that were exploited in ways that made headlines and left many systems, users, and companies devastated.

Crowdsourced security programs are changing how we find and fix these software vulnerabilities, as well as helping companies avoid becoming tomorrow's headline. With a strong crowdsourced vulnerability management program in place, organizations can easily take any bug from "oh, sh*t" to fixed.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Community Projects Highlight Need for Security Volunteers."

David Baker brings over 20 years of experience in enterprise data security, information security and government computer research to his role as CSO. Prior to Bugcrowd, David served as the Chief Security Officer at Okta. As CSO, David was responsible for the security of ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19619
PUBLISHED: 2019-12-06
domain/section/markdown/markdown.go in Documize before 3.5.1 mishandles untrusted Markdown content. This was addressed by adding the bluemonday HTML sanitizer to defend against XSS.
CVE-2019-19616
PUBLISHED: 2019-12-06
An Insecure Direct Object Reference (IDOR) vulnerability in the Xtivia Web Time and Expense (WebTE) interface used for Microsoft Dynamics NAV before 2017 allows an attacker to download arbitrary files by specifying arbitrary values for the recId and filename parameters of the /Home/GetAttachment fun...
CVE-2019-19617
PUBLISHED: 2019-12-06
phpMyAdmin before 4.9.2 does not escape certain Git information, related to libraries/classes/Display/GitRevision.php and libraries/classes/Footer.php.
CVE-2012-1114
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the filter parameter to cmd.php in an export and exporter_id action. and the filteruid parameter to list.php.
CVE-2012-1115
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the export, add_value_form, and dn parameters to cmd.php.