# Assessment

![Basic security hygiene](https://developers.google.com/static/android/play-protect/starting-a-vdp/images/vdp-security-hygiene.svg)

How do you know if you're ready to start a (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 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](https://landing.google.com/sre/sre-book/chapters/postmortem-culture/) 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.