Vulnerability Scoring 102

In my last post, I talked about the basics of vulnerability scoring in vulnerability management and the disparity that can exist when you score the subjective elements of a vulnerability. We looked at the variance that can exist within CVSSv2 and how a properly developed score can show a clear difference between two unique issues.

This time, I want to talk about vulnerability versus risk. This is an important topic that isn’t discussed nearly as often as it should. If you recall the last post, risk is a component of the IP360 vulnerability score, however, vulnerability score is a component of risk.

Wait? How can we have a circular definition?

That one is pretty easy to explain but since we’re using the same word here, I’m going to use risk to refer to the component of the IP360 vulnerability score and RISK to refer to the end result.

When we talk about risk, we’re talking about the outcome when a vulnerability is successfully exploited. With IP360, we always look at the worst-case scenario… well, sort of. We make one exception, which is the user the victim is logged in as. Since anything involving user interaction COULD result in a larger and more dangerous breach if the user is an Administrator and almost any client-side vulnerability could see the user logged in as Administrator, we remove that from the equation.

The argument is often made, “But what if the administrator is logged in?” The answer is yes, the outcome could be worse but we want to differentiate between vulnerabilities that could lead to privileged access and vulnerabilities that will lead to privileged access. As a result, we consider a vulnerability to affect the user if the resulting exploit code runs in the context of the logged in user. If the vulnerability escalates privileges, then we look at it as a privileged attack.

This differs greatly from RISK with regard to your network and your systems. The risk is the same for every instance of a vulnerability, regardless of the system. The RISK, however, is variable based on network controls and configuration. An exploit that targets a remote service and leads to privileged access is, in Tripwire’s scoring system, as bad as it gets.

The RISK to a system that is firewalled with access coming in via a single bastion host may be a lot lower. That said, the RISK to two systems with the same vulnerability might differ based on the data stored. That is to say that a customer database with credit card information is likely to rank a higher RISK score than a system used for ordering the office’s lunch.

This is an important distinction to make and can be even harder to understand. Hopefully, this clears up the difference in risk vs. RISK and how it affects you and your systems.