Don’t Overreact: 5 Steps for Responding to Vulnerability Disclosures

Heartbleed, Shellshock, FREAK, POODLE, VENOM – these are just some of the branded vulnerabilities that were disclosed in the past two years. With so many branded vulnerabilities coming out executives are paying more attention to application security. This is great, except that it also means security professionals are under increased pressure to react to vulnerability disclosures, rather than create comprehensive, strategic plans around securing the applications that run their businesses. 

You want your security programs to be more strategic in nature, yet they cannot ignore these potentially threatening vulnerabilities. They need a plan that can help them determine how urgent a vulnerability is, and how the team can respond.

A good place to start is to create a vulnerability response plan which helps you determine how your company should and can respond. Veracode was facing this very same dilemma. We wanted to ensure our company is secure and vulnerabilities are managed. Yet, the steady stream of vulnerability disclosures, both branded and non-branded, meant we were constantly putting out fires without any regard to how it impacted our production schedules or other strategic initiatives.

We pulled together a plan following these five steps:

Step 1: Identify a rapid-response team

When a vulnerability is disclosed, the rapid-response team meets and runs through the process to determine how the company should respond and at what level of urgency.

Step 2: Create protocols for the team to follow

In order for the rapid-response teams to operate effectively, each team should establish operating procedures. The rapid-response team’s first responsibility is identifying when a new vulnerability is disclosed. This alert will typically come from a press release announcing the vulnerability disclosure or from a vendor letting you know what it is doing to respond. Either way, an internal email distribution list should be created, and any employee hearing about a new vulnerability disclosure should communicate this to the rapid-response team.

Step 3: Define priority levels and corresponding responses

Every organization has its own appetite for risk, and, as such, each organization will have a different definition for what constitutes high and low urgency. Regardless of your organization’s appetite for risk, a programmatic approach with clearly defined patterns will help in teams keep a level head throughout the response process.

Step 4: Set up a framework for determining priority levels

Predetermining what constitutes a high-urgency vulnerability versus a low-urgency vulnerability will save time when an incident does occur. By explicitly outlining what actions will be taken given the priority level assigned to the vulnerability, enterprises can also justify their response to their customers and boards if asked. 

Step 5: Create clear procedures for responding to each level

Once the rapid-response team has determined what priority level the breach fits into, the incident response team will begin their mitigation efforts. It is important that there is a clear plan for how the team should respond depending on the level of urgency prescribed to the vulnerability.

Despite being a necessary part of security, responding to a zero-day vulnerability disclosure can be a costly effort if it pulls teams from their planned strategic or operational activities. Enterprises with pre-determined response plans and methods for prioritizing their remediation and patching efforts will be prepared to enact the appropriate response so that risk is properly mitigated with minimal cost.

Curious where vulnerabilities come from? Read the “how vulnerabilities get in software” pdf.