Skip to content ↓ | Skip to navigation ↓

I’ve been involved in vulnerability scoring discussions more times than I can count. Colleagues, customers, conference-goers, and complete strangers all want to discuss the topic and I can’t say I blame them… the topic is interesting.

So after numerous blog posts on other subjects, it’s probably time to tackle the issue in an open forum where we can discuss and debate as a group.

Let’s start with my feelings on scores since I should probably be upfront about it. The current state of vulnerability scoring is useless. With the frequency of vulnerability disclosure and the number of vulnerabilities patched in products, a bucket consisting of High, Medium, and Low tells me nothing.

The solution to our scoring problems was supposed to be CVSS. It provides more buckets and looks, at least initially, as though it distributes the scores quite well. In reality, the 100 buckets of CVSS is really more like 15-20 as certain scores become commonplace and others are never seen.

Let’s take two vulnerabilities, A and B. Vulnerability A has public exploit code and targets a popular operating system. It is a remote unauthenticated attack against the network stack and leads to a total compromise of the system.

  • CVSS Score: 10.0
  • CVSS Vector: (AV:N/AC:L/Au:N/C:C/I:C/A:C)

Vulnerability B has no public exploit code and targets a popular web technology. It requires that a user browse to a website and, if an exploit existed, successful exploitation would lead to code running in the context of the user, not the system.

  • CVSS Score: 10.0
  • CVSS Vector: (AV:N/AC:L/Au:N/C:C/I:C/A:C)

As you can see both of these have CVSS Scores of 10.0. This is why I see these system as useless. When you read the details, it’s very easy to identify a priority but if you were to rank these by CVSS, that priority would disappear.

So what is the solution? In my mind it’s risk scoring. When you’re talking about a vulnerability, the risk score is what you should care about. What we really need is CVRSS but it doesn’t exist (hrm… maybe an upcoming blog idea).

When you look at public systems, no one is really doing this. Microsoft has come close but they still aren’t there. If they could find a way to marry their severity score with their exploitability index into a single value, I think they’d provide a useful way to truly prioritize Microsoft bulletins.

I think this is something that everyone in the vulnerability management space is currently dealing with as well. Helping customers prioritize vulnerabilities is a large part of our job and no one has figured out the perfect way to do it yet. Some companies are still scoring vulnerabilities, other companies are just using CVSS, and others still, Tripwire included (via the nCircle acquisition), have worked at risk scoring but still haven’t perfected it.

At Tripwire, we look to score the risk using three factors: age of the vulnerability, exploit availability, and resulting level of access to the system. If I do a follow-up blog post on a proposed CVRSS, I would leave these in but I would likely improve the process with a few additional factors. When you look at the elements used by Tripwire, they all make sense, especially exploit availability and level of system access.

If an exploit is available, a vulnerability should score higher, and if that exploit is in malware or a known exploit framework it should score even higher. The same is true when you look at the level of access… a vulnerability that leads to user level access should not score the same as a vulnerability that leads to system level access.  These factors make a world of difference when you’re looking at a list of 10,000 vulnerabilities trying to decide which ones to patch first.

If you look at the above Vulnerability A and Vulnerability B examples, using Tripwire ’s scoring system, Vulnerability A would receive a score of 24,203 and Vulnerability B would receive a score of 1. From this difference, it is quite easy to determine a priority for applying patches.

In an effort to further improve our scoring, Tripwire (again, via the nCircle acquisition) released a number of ASPL-Based scoring changes last year. These are flags that the customer can set to further prioritize their vulnerability scan results.

These flags can be thought of as the environmental portion of a proposed CVRSS, allowing more control over the results that are important to you. Customers interested in learning more about this can contact Tripwire for details or sign up for The State of Security publication.

After this much writing, I’ll probably have to do a follow-up post on risk scoring… but I wanted to get something posted simply to start the discussion. So… discuss!

Note: CVSS examples are based on NVD’s use of the scoring system since NVD is considered by many to be the standard for CVSS scores.


Image courtesy of ShutterStock

Tripwire University
  • These concerns have been brought up multiple times before. Anyone performing VA or PenTesting has had this issue for years. Is Tripwire or you involved in the CVSSv3 working group?

  • Amir Budi Cecep

    It's been 1.5 years ago but I see that the author isn't bothered to post any reply.. even when he invited the readers to discuss!

    Anyway, while CVSSv2 doesn't have enough granularity, the example he posted is over-simplified.

    Anyone who has been using CVSSv2 for quite a while will know that a Complete impact on all the 3 C/I/A tangents will result on the High spectrum (7.5 – 10.0). There are 2 flaws in the example:

    1) Even though the availability of public exploit code is known, the example didn't put it in the CVSSv2 vector: Exploitability: Unproven that exploit exists (E:U). This alone will bring B score down to 8.5 — not by much, but if prioritization is all you want, there you have it: A = 10.0 > B = 8.5.

    2) I don't know how Tripwire's scoring system work but if they put so much emphasize like this article on the "successful exploitation would lead to code running in the context of the user, not the system" in vulnerability B, then he should adjust the Impact metrics to be more suitable in the overall outlook, especially if you're comparing things. Seting all 3 C/I/A impacts as Partial will bring the score further down to 7.5 (base score) or 6.4 (+temporal metrics with E:U). Is it as dramatic as Tripwire's 24203 vs. 1? Nope, and this is indeed acknolwedge as the challenge of using the not-so-granular CVSSv2. But a vulnerability with score of 1, who wants to bother fixing it? Is it the correct "prioritization"? The answer is yours.