Heartbleed and the Vulnerability Management Lifecycle

Heartbleed is remembered as one of the worst vulnerabilities ever found. On paper, NVD scores it a 7.5 out of 10 under CVSS 3.1. That's High, not Critical. (Under the older CVSS v2 it gets a 5.0, Medium.) That gap between the number and the reputation is the most useful thing about it, so let's start with how severity gets scored in the first place.

Triage starts with CVSS

Security professionals are often tasked with addressing many vulnerabilities at one time. Some are highly critical and need immediate attention. Others are less severe and can wait until the critical ones are mitigated. So how do you accurately judge severity, so you can triage?

A good place to start is the CVSS, the Common Vulnerability Scoring System. CVSS is a ranking system that uses several metrics to determine severity, including (but not limited to) ease of exploitation and whether the attack needs privileges or user interaction (malware, phishing) to work. It turns those metrics into a standard scale:

It's a great way to assess a threat quickly and in a standardized way as part of vulnerability analysis. Keep that Heartbleed score in mind, though. We'll come back to it.

The vulnerability management lifecycle

The vulnerability management lifecycle is a standardized, repeatable method for discovering, mitigating, and managing the response to threats, start to finish. It means defining your risk posture and policies, building a complete asset list, scanning for and assessing vulnerabilities, and acting on what you find. Done right, it gives an organization a strategic view of its threats and hardens it against attack.

The model I learned breaks it into three main phases:

• Pre-assessment: Define policies and standards, identify critical assets, set a baseline, and define risk based on criticality. This is also where you gather information on approved ports, software, drivers, and basic configuration for each system.
• Vulnerability assessment: The heavy scanning phase. You hunt for vulnerabilities across the operating systems, web applications, and web servers, and you can use compliance guidelines to steer the scans. It can also include penetration testing, a look at the network architecture, and a review of physical and operational security.
• Post-assessment: Four sub-phases. Risk assessment prioritizes what you found and plans the fix. Remediation is the specific, measurable, time-bound work of mitigating it. Verification is re-scanning to see if the fix actually worked. Monitoring is continuous watching for new threats and new vulnerabilities, and best practice says all of these phases get repeated regularly.

Walking Heartbleed through it

In April 2014, two teams independently found a flaw in OpenSSL's implementation of the heartbeat extension for TLS and DTLS: researchers at Codenomicon and Neel Mehta of Google. Here's the gist. A client could ask a server to echo back a piece of data and lie about how long it was, and the server would answer with up to 64 KB of whatever happened to be sitting next to it in memory. Attackers could repeat the request as many times as they liked. What lives in a web server's memory? Passwords, session data, and the server's private keys. OpenSSL 1.0.1 through 1.0.1f were affected, and 1.0.1g fixed it.

Classification. Heartbleed's potential to expose critical data made everyone treat it as critical, even though the formal score says High. The reason is in the math. The CVSS vector counts a total loss of confidentiality but nothing for integrity or availability, and that caps the score at 7.5. A number can't capture what was in memory when the leak happened. Treat the score as a place to start the conversation, not the end of it.

Assessment. Security teams had to work out which systems were affected and how exposed they were. That was hard, because OpenSSL isn't just a web server thing. Apache and nginx alone accounted for over two-thirds of active sites, and OpenSSL also sits behind email servers, VPNs, and network appliances. Penetration testing and risk analysis helped organizations understand what they were exposed to.

Remediation. The patch was the easy part: upgrade OpenSSL to 1.0.1g or newer. The hard part is that exploitation leaves no trace in server logs, so nobody could prove their keys hadn't been stolen. That's why many organizations also issued new SSL/TLS certificates, even if patching alone would have closed the technical hole. If your private key was exposed, a new key is the only way to make sure a stolen one doesn't show up later.