CISO Forum and the problems of Vulnerability Databases

Last Tuesday, April 24,  I was at “CISO FORUM 2020: glance to the future“. I presented there my report “Vulnerability Databases: sifting thousands tons of verbal ore”. In this post, I’ll briefly talk about this report and about the event itself.

CISO Forum 2020

My speech was the last in the program. At the same time, in a parallel stream, there was another interesting presentation by the most famous Russian information security blogger. Thus, there was a real danger of speaking in an empty room. 🙂 But everything went well. There were about 30 spectators and we had an active QA session afterwards.

As I wrote earlier, I started preparing my CyberCentral presentation several months before the event. I did not want to tell the same story again at CISO Forum and PHDays. So I prepared 2 different presentations. At CyberCentral, I was talking about Vulnerability Scanners. And at CISO Forum I was talking mainly about Vulnerable Databases. Of course, I reused some materials, but the accents were different.

The problems of Vulnerability Databases

For the sake of a single word
you waste
a thousand tons
of verbal ore.

Vladimir Mayakovsky, “Conversation With A Tax Collector About Poetry”, 1926

CISO Forum 2020 my photo

So, the plan of my presentation:

  1. My attempt to classify Vulnerability Databases
  2. Balance between Trash and Completeness for Databases of Individual Vulnerabilities
  3. Vulnerability workflow: everything is linked by CVE
  4. Does product statistics in NVD mean anything?
  5. Vulnerability data in NVD
  6. How to evaluate automatically that vulnerability is critical?
  7. Common Vulnerability Scoring System usage in NVD: pros and cons
  8. Common Weakness Enumeration usage in NVD: pros and cons
  9. From Vulnerability Database to Vulnerability Scanner
  10. Version-based vulnerability detection (on Vulchain example)
  11. “Exploitation”-based vulnerability detection
  12. Knowledge Base comparison for Vulnerability Scanners (Nessus and OpenVAS)
  13. Exploitability flags in Vulnerability Scanners (on Nessus example)
  14. Ideal Continuous Monitoring and real life processes
  15. Tragicomedy of Chip Apocalypse
  16. Certificate cancellation because of not patched vulnerabilities: pros and cons

I will probably share my slides after PHDays, May 15–16. I need to change them a little and translate into English. upd. Here it is: “PHDays8: Digital Bet and thousands tons of verbal ore

I wanted to talk about Vulnerability Database, because this topic seems to be very promising and important. Ok, Vulnerability Management vendors make some products that detect vulnerabilities on the hosts using some criteria. But in most cases they do not analyze founded vulnerabilities in any way. They simply tell a client, that some vulnerability seems to exist somewhere. And they take description of this vulnerability from some open Vulnerability Database, for example NVD. It’s a pretty formal approach.

Why is this happening? Well, Vulnerability Management vendors need to process enormous amounts of data to keep their knowledge bases up to date. In this race it is easy to forget about the real needs of the client.

After all, a client purchases a Vulnerability Scanner not for receiving thousands of poorly described vulnerabilities and false positives. He wants to find something truly exploitable in his particular infrastructure. And the VM vendors do not really know how to exploit detected vulnerabilities or know it for a very small part of their Knowledge Bases.

If there is no public exploit, almost all the information that we can get about vulnerability will come from the software vendor or an independent researcher (less often). In fact, the Software Vendor advisories is the only practically usable source of information about vulnerability and vulnerable software versions. We dependent on the completeness and reliability of this information, since it is extremely difficult to check it.

Often regulators do not motivate vendors to be responsible. For example, they can get information about some vulnerability from the vendor and use it to cancel the certificate for this software. It’s ironic, because this information could not be obtained in any other way. 🙂

The facts about vulnerabilities are, as a rule, described badly and it become extremely difficult to analyze them automatically. For example, for NVD CVEs: CVSS is subjective, CWE identifiers are not informative. In fact, the most valuable parts are text description and links to related security objects. I already wrote about the analysis of the links in the posts about Vulnerability Quadrants. I’ve been analyzing text descriptions of vulnerabilities as well and it’s pretty promising.

QA session

After my speech, there was an interesting QA session. I will mention some questions:

  1. What should we do with this all? Given the problems of vulnerability description in vulnerability databases, the incompleteness of vulnerability scanner’s knowledge bases and the imperfection of detection mechanisms.
    Use multiple vulnerability scanners even so they are expensive. Try to use various methods of detecting vulnerabilities, including the development of your own tools.
  2. How do the Vulnerability Databases intersect?
    All Vulnerability Databases partially overlap. This is normal, given that they are supported by independent teams.
  3. How do you patch your Windows systems?
    We have good IT team. My task is to control and show that something is going wrong. And of course it is necessary to check all the patches carefully. Or it will end like in the situation with Meltdown/Spectre patches for Windows 7.
  4. Could you name a solution that could report new vulnerabilities for different kinds of software (Vulnerability Intelligence services)?
    Well, Vulners, Flexera/Secunia. But anyway in practice we will need a vulnerability scanner to place this vulnerabilities in a context of particular infrastructure.

Other reports

Now a few words about other reports at CISO Forum. Unfortunately, I was very busy at work and attended only the second day of the forum. I watched presentations mainly in hackers stream, moderated by Dmitry Gadar, Head of Information Security Department at

I really liked the report “Automating processes in SOC / CSIRT teams” by Sergey Serov, CSIRT Team Lead at QIWI. He described the ways to automate all routine activities for Live Response, Threat Hunting, Recon, Search for anomalies, etc. It was very nice that he mentioned service, which now supports IOCs (Indicator of Compromise).

CISO FORUM 2020 Serov Vulners

The second interesting report was “Safety of Telegram’s bots” by Maxim Mosharov, Application Security Adept at He described the process of creating a bot for office automation and described common problems with authorization, some types of attacks and typical development errors.

CISO_FORUM 2020 Mosharov Telegram

At the exhibition, I was very pleased to talk with guys from Skybox Security. It was interesting how they import raw scan results, for example from Nessus and can also detect vulnerabilities by themselves (I think they do it with cpe-based detection, like Vulchain, but I do not know for sure).

CISO FORUM 2020 Skybox

In conclusion

I really liked this conference. Thanks to the organizers!  It is very pleasant when the organizers are interested in you as a speaker, invite you to the event, offer a wide range of topics to speak, make the schedule carefully, trying to do event interesting for all participants. This is very different from the huge conferences, where you have to send something to CFP and you don’t know until the very last moment whether your report will be approved or not.

During the conference, everything were very well organized. No problems with timing, there were more than enough time for the performance (I had a whole hour!). After the conference, all materials were shared very quickly. All photos and slides were available in 3 days.

That’s why I was speaking for the second time at the CISO Forum and I hope to participate next year as well.

One thought on “CISO Forum and the problems of Vulnerability Databases

  1. Pingback: Vulchain scan workflow and search queries | Alexander V. Leonov

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.