Vulnerability Quadrants. Hi everyone! Today I would like talk about software vulnerabilities. How to find really interesting vulnerabilities in the overall CVE flow. And how to do it automatically.

First of all, let’s talk why we may ever need to analyze software vulnerabilities? How people usually do their Vulnerability Management and Vulnerability Intelligence?

• Some people have a Vulnerability scanner, scan infrastructure with it, patch founded vulnerabilities and think that this will be enough.
• Some people pay attention to the vulnerabilities that are widely covered by media.
• Some people use vulnerability databases and search for the most critical vulnerabilities by some criteria.

Each of these ways have some advantages and some disadvantages.

Vulnerability Scanners

Huge part of detection plugins were written manually. Especially plugins that work remotely without authorization. It takes time to make them and so they may appear in scanner with a huge latency. It also might be economically impractical for VM vendors to deal with vulnerabilities in some rare software.

Vulnerabilities, that are widely covered in media

From the one hand it’s really great. Even Top managers might ask you if we have, for example, GHOST in our infrastructure or other popular vulnerability. They begin to see that you are doing something important!

On the other hand, vulnerability researchers are also people. And they are interested in making more hype around the vulnerabilities they have discovered. It’s just a part of their self-promotion. It’s relatively easy to come with a name, register a domain and make a beautiful logo for the vulnerability. And it’s hard to understand how critical this vulnerability really is. Especially when there are no so much details.

Here you can see some well-known vulnerabilities that made a lot of noise in the past.

Most of them were really critical. But, I have seen plenty of publications about BadLock saying that this vulnerability was overvalued.

Vulnerability databases and feeds

Most people use CVSS vector and the CVSS Base Score for vulnerability filtering and vulnerability prioritization. They may also take into consideration the existence of exploits, for example. But the CVSS is still a basis.

What is the Common Vulnerability Scoring System? In fact, there is a framework, a questionnaire, in which some person manually describes the vulnerability.

I do not know who fills CVSS for National Vulnerability Database. But, imagine some people in US military uniform.

The final result is a score, number from 0 to 10, and a vector containing all the answers in a compact form.

What’s wrong with CVSS?

• Filling the questionnaire is highly subjective procedure. You can easily make a mistake or just think differently during the classification.Or you may just have a controversial information about the vulnerability.
• It  takes time. That’s why CVSS for the vulnerability appears in database much later than a human-readable description.
• In NVD, for example, you can see only Base Score and Base Vector. And there is no Temporal Vector available.
• CVSS model works well when we talk about desktops and servers and doesn’t really fit for Internet of Things, for example.
• CVSS is not well suited for confidentiality threats.  A good example is the well-known Heartbleed.

Heartbleed was rated as a medium-level vulnerability by NVD. But on the other hand, Tenable Network Security, the well-known Vulnerability Management vendor, believes that this vulnerability should have different CVSS vector.

So this is a controversial issue:

• Confidentiality Impact is Complete or Partial?
• Integrity Impact is None or Complete?

And the final result depends on this.

It was the 2nd version of the CVSS standard, now the actual version is 3rd. But in 3rd versions problems with confidentiality threats were not solved either.

Vulnerability Quadrants

So, my idea was to evaluate vulnerabilities using the data that we currently have. Of course, it would be great to work with some highly formalized descriptions of vulnerabilities. However, as a rule, we do not have such information. We have only different objects linked with each other and stored in some vulnerability database.

If we open, for example, Heartbleed page at vulners.com (read more about this service at “Vulners – Google for hacker“) we can see all the objects linked to this vulnerability and the timestamps when objects were created.

Using this data I can calculate two integrated characteristics of vulnerability: “Danger” and “Relevance”. And I can do it for any moment of time.

“Danger” is about technical criticality and exploitability. It shows how interesting this vulnerability may be for an attacker.

It depends on:

• CVSS Base Score ↑
• Potential exploitability ↑
• Exploits ↑
• Malware* ↑
• Patches ↓
• Detection plugins ↓
• Age ↓

“Relevance” shows the attention paid to the vulnerability by media, vulnerability management vendors, and users of vulnerability databases.

It depends on:

• Media coverage ↑
• Descriptions ↑
• Detection plugins ↑
• Search queries* ↑
• Search results* ↑
  
• Clicks* ↑
  
• Age ↓

* haven’t used it in PoC

To show the current state of vulnerability I use “quadrants”. Like consulting and research companies do it for comparing software vendors.

So, for products “Ability to execute” and “Completeness of vision” are important, for vulnerabilities it will be “Danger” and “Relevance”.

I gave this names to quadrants:

• Leading Threats
• Local Disaster
• Well-known Issue
• Daily Routine

Here is, for example, Vulnerability Quadrant for Heartbleed:

And this one is for Badlock:

As you can see, unlike Heartbleed, Badlock was never a Leading Threat.

We can visualize more than one vulnerability at the same time.  For example, here I took last year CVEs and showed dynamics of their state since this beginning of the year (from 2017-01-01 till 2017-04-15).

To limit amount of the vulnerabilities in the lower left corner I made a “rule for disappearing”: vulnerability may stay in Daily Routine quadrant only for 10 days with value of Danger and Relevance <3.5 or they will disappear.

Here you can see different types of vulnerabilities. These ones are about race condition that allows attackers to execute arbitrary code in a privileged context via a crafted app. (iOS, macOS, tvOS, watchOS):

And these vulnerabilities in Microsoft Edge and WordPress are also dangerous and exploitable, but never get the same level of media attention. Researchers find vulnerabilities in this products on a regular basis and therefore it’s not a news. Vulnerabilities of such kind are slowly drifting from Local Disaster quadrant to Daily Routine.

Of course, “rule for disappearing” doesn’t work in real life and all vulnerabilities will exist in your infrastructure until you install the updates. If I switch off this rule and switch off all the captions, we will see something like this:

So, don’t forget to fix vulnerabilities in your systems until it’s too late:

Vulnerability Quadrant is a simple and universal way to show the current state for any vulnerability and dynamics of this state. it’s possible to highlight most critical vulnerabilities and to identify trends. And it’s just fun to watch vulnerabilities crawling on the screen. 😉

Problems and limitations
– It’s all about CVEs. And we all know, that some vulnerabilities may have multiple CVEs and some may don’t have CVEs at all, for example vulnerabilities in SAP products. And they are out of scope right now.
– Formulas for Danger and Relevance are very subjective. Basically, what factors you choose, such values you will get. However, when you use the same formulas for all vulnerabilities the overall picture remains the same.
– We can make this instrument much more effective, but we need more information about exploits, malware, statistics and search history from vulnerability databases and so on.

Q: Can we use Vulnerability Quadrants to decide which of vulnerabilities are really dangerous for your organization and should be discovered and patched immediately?

Well, yes, but not in the form we have seen earlier. First of all, we should switch off gravity. Vulnerability Danger will not become smaller until you patch the software in your organization. As well as Relevance. And you should consider only vulnerabilities in the software products that are currently in use in your organization.