[VulnWhisperer] Create Vulnerability standard for all scanner modules

[qmontal]

Create a VulnWhisperer Vulnerability Standard template for all scanner results to follow when being stored locally. This will unify all the differences from the scanners into a single structure, which will make VulnWhisperer easier to integrate with new modules and less prone to errors and failures.

This change will mean:

• creating a new Vulnerability standard from the scan results of the different modules
• refactoring the scanner modules to adapt to the new template
• refactoring the logstash config file (as there would be a single one for all scanner modules)
• refactoring the Kibana dashboards in order to follow the new standard.

Also, ideally the new standard Logstash config would follow ECS already (#97).

Resources:
elastic/ecs#113
https://github.com/DefectDojo/sample-scan-files
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html#securityhub-findings-format-syntax

[qmontal]

Implementation started at #177.

[pemontto]

To keep track, my understanding is

• risk the vendors risk level as a string
  • none, low, medium, high, critical
  • Nessus supplies this
  • for Qualys we derive from the risk_number (severity)
• risk_number the vendors risk number
  • A value from 0-4 representing the risk
  • Qualys supplies this as severity from 1-5, we subtract 1
  • for Nessus we derive this from the risk string
• risk_score the CVSS score
• risk_score_name a string representing the risk based on the CVSS value

Currently risk_score_name has been renamed to cvss_severity and risk_score is just cvss. With additional data sources we now also have cvss3 and cvss3_severity.

cvss and cvss3 are calculated as the cvss_temporal or the cvss_base in that order.

risk -> risk
risk_number -> risk_number
risk_score -> cvss
risk_score_name -> cvss_severity

[qmontal]

@pemontto that is indeed how it should be, thanks for the confirmation!

[elvarb]

Would a risk_source be valuable? or is it something that already exists as a field

The thought behind it it if you are using both Nessus and Qualys and want to see the source of the risk value or the risk_number value because both use their own reasoning for the risk. For when you have both scanners scanning the same endpoint finding the same vulnerability but each setting a different risk value.

[pemontto]

@elvarb yes, in beta-2.0 we export a scan_source field which is set to the name of the config section (tenable, nessus, qualys_vm, qualys_was, openvas). We also export a vendor field that looks like the below for the various sources

tenable -> Tenable
nessus -> Tenable
qualys_vm -> Qualys
qualys_was -> Qualys
openvas -> Greenbone

[qmontal]

The vulnerability index of ECS was released on December 2019 with version 1.3, so we will be working on using it as the official Vulnerability Standard on which VulnWhisperer relies. We will be working on the mapping as soon as we get resources to continue with the whole refactoring.