How do you know if you're ready to start a vulnerability disclosure program (VDP)? There are important assessments you should make before implementing a VDP. These assessments help identify gaps in your infrastructure and prepare the team for the stream of incoming bug reports. A properly implemented VDP brings in a steady flow of reports. If your team isn't ready for the additional workload, the new program could have a negative impact instead of improving security. Assessing your security program to identify and address gaps can go a long way towards increasing your ability to handle the throughput of a VDP. Promptly responding to reported vulnerabilities can improve your relationship with the hacking community, resulting in a healthier program.
Basic security hygiene
Regardless of the security maturity of your organization or the resources available, evaluating your current security hygiene is the best way to identify gaps. Below we discuss identifying potential gaps in key areas that are commonly overlooked including, finding bugs, fixing bugs, root cause analysis, detection and response, and security culture.
Finding bugs
When preparing to launch a VDP, it is important to assess the methods that your team uses to identify vulnerabilities in your environment. As part of your assessment and preparation for starting a VDP, an initial effort should be made to find and fix vulnerabilities.
Not doing so could result in a huge spike of vulnerability reports when your VDP launches, potentially overwhelming your team. Setting up a basic vulnerability scanning and security review process will enable your organization to establish solid processes for handling security issues. When you start your VDP, you'll be better prepared to handle incoming vulnerability reports.
Fixing bugs
In addition to finding vulnerabilities, you'll need well-defined processes and resources for ensuring vulnerabilities get fixed in a timely manner . Simply finding bugs is not enough, security only improves when bugs are fixed. Do you have processes and resources in place for vulnerability management? What's the culture like within your organization when it comes to security? Is the security team viewed as the naysayers, the blockers, the thorn in the side of engineering? Or are you viewed as a collaborative partner? How do you prioritize vulnerability remediation? Do you have common nomenclature and understanding around severity and remediation timelines? How easy or difficult is it to find an owner to fix an identified vulnerability? Do you track metrics around vulnerabilities identified, including time to fix? Does your organization have an asset inventory, or is it a distant dream of the future? Again, if you're feeling pretty good about this and have a good grasp of ensuring severe bugs get fixed promptly, have a solid relationship with the teams and individuals responsible for fixing vulnerabilities, and have resources in place to process incoming streams of security bugs smoothly, you're well on your way. If not, we'll provide guidance on how to implement a successful vulnerability management program in the next chapter. In either case, you'll want to have solid vulnerability management practices in place to be able to handle the new stream of bugs you'll receive from your VDP, ensuring you can respond to and address identified vulnerabilities in a timely manner.
Root cause analysis
Beyond the operational work of finding and fixing bugs as one-offs, are you performing root cause analysis (RCA) of issues and identifying systemic causes of the introduction of vulnerabilities into your environment? It's great to be able to find and fix bugs quickly. However, when it comes to running a successful VDP, you'll want to be able to determine how these bugs are appearing in the first place. This can come in different forms, such as:
- Identifying how an application security vulnerability was introduced.
- Are developers using common libraries and frameworks that reduce the risk of vulnerabilities being introduced?
- Analyzing data and identifying trends.
- Are you noticing infrastructure managed by a particular team is never patched with security updates?
- Security incidents or breaches.
- Perform a post-mortem with all related parties to dissect what happened, why, and learn from it so as not to make the same mistakes in the future.
Without performing RCA, a lot of effort can be wasted processing numerous similar bug reports from your VDP. If you start a vulnerability reward program in the future, lack of RCA also has a financial impact to your organization. We'll go into more specific advice on how to implement RCA processes and a post-mortem culture in the next chapter.
Detection and response
Inviting external researchers to hack on your assets will impact your detection and response mechanisms. If you have intrusion detection/prevention systems in place, you'll want to consider what types of testing you'd like security researchers to perform. Will you create exceptions for them to find vulnerabilities "behind" these automated defense systems? If ten researchers all start running vulnerability scans on your externally facing assets at 2:00AM on Saturday, will alarms go off waking up your security team? How do you identify legitimate testing traffic from security researchers versus a potential real attack against your systems? Do you know how to leverage data generated by security researchers testing against your systems? If a security researcher tries to brute force guessing usernames and passwords, could they lock out real users? Before you start a VDP, you'll want to consider all of these aspects. You need to ensure you've set clear expectations with security researchers in terms of what types of testing is and isn't okay, and determine how to configure your existing detection and response mechanisms. The next chapter will go into more detail on how to approach this.
Security culture
The culture within your organization has a huge impact on your ability to start and maintain a successful VDP. It's good to take a step back and understand who the key stakeholders are that will need to buy into this initiative, and what their existing relationship is with the information security team. Based on the various relevant stakeholders and how you anticipate them handling a proposal of starting up a vulnerability disclosure program, you'll need to identify methods and materials to persuade them to buy-in to this concept. One key stakeholder that isn't on board could potentially block a VDP from ever getting started.