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
How Attackers Could Use Azure Apps to Sneak into Microsoft 365
Kelly Sheridan, Staff Editor, Dark Reading,  3/24/2020
Malicious USB Drive Hides Behind Gift Card Lure
Dark Reading Staff 3/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-10940
PUBLISHED: 2020-03-27
Local Privilege Escalation can occur in PHOENIX CONTACT PORTICO SERVER through 3.0.7 when installed to run as a service.
CVE-2020-10939
PUBLISHED: 2020-03-27
Insecure, default path permissions in PHOENIX CONTACT PC WORX SRT through 1.14 allow for local privilege escalation.
CVE-2020-6095
PUBLISHED: 2020-03-27
An exploitable denial of service vulnerability exists in the GstRTSPAuth functionality of GStreamer/gst-rtsp-server 1.14.5. A specially crafted RTSP setup request can cause a null pointer deference resulting in denial-of-service. An attacker can send a malicious packet to trigger this vulnerability.
CVE-2020-10817
PUBLISHED: 2020-03-27
The custom-searchable-data-entry-system (aka Custom Searchable Data Entry System) plugin through 1.7.1 for WordPress allows SQL Injection. NOTE: this product is discontinued.
CVE-2020-10952
PUBLISHED: 2020-03-27
GitLab EE/CE 8.11 through 12.9.1 allows blocked users to pull/push docker images.