We are attempting to map Tenable (Nessus) scan report items to the ECS vulnerability field set. The Tenable scan report may include multiple vulnerability identifiers related to the detected vulnerability where each vulnerability identifier is assigned by one or more vulnerability information providers. A Tenable (Nessus) reported vulnerability “event” can include multiple vulnerability identifiers assigned by one or more vulnerability information providers related to the detected vulnerabile. For example, a Tenable vulnerability "event" can include multiple CVEs, CERT, Microsoft, and other vendor and community specific vulnerability identifiers. The ECS Vulnerability field set supports a single vulnerability identifier, “vulnerability.id”. Because vulnerability IDs are not unique across vulnerability information providers the type of identifier stipulated in the “vulnerability.enumeration” field.
We have considered a few approaches towards extending the ECS Vulnerability field set to include all vulnerability identifiers reported by Tenable and would appreciate feedback and recommendations from Elastic based on best practices. The simple use case is to support search and analytics via a common field for any vulnerability identifier, for example:
- find all hosts that have a vulnerability attributed to CVE-2020-12334
- find all hosts that have a vulnerability attributed to Bugtraq ID 20180711
- count of hosts affected by vulnerability attributed to Microsoft Bulletin MS21-5003203
The approaches considered are:
-
Extend the ECS Vulnerabilty field set such that there is an array of “id” and “enumeration” pairs for each vulnerability identifier found in the Tenable record. The existing ECS “vulnerability.id” and “vulnerability.enumeration” field are populated with a primary vulnerability identifier for the record based on the Tenable reported vulnerability ID that is the CVSS score source.
-
Extend the ECS Vulnerability field set such that there is an explicitly named field for each type of vulnerability, e.g. “vulnerability.bid” and “vulnerability.iavm” for Exploit Database reported identifiers and Information Assurance Vulnerability Management alerts respectively. Populating a “related.id” with all reported vulnerability identifiers to support single field search. The existing ECS “vulnerability.id” and “vulnerability.enumeration” fields are populated with a primary vulnerability identifier for the record based on the Tenable reported vulnerability ID that is the CVSS score source.
Assuming a Tenable scan report below representing a vulnerability “event” (edited to include only key fields) A scan report that contains a CVSS score is considered to be a vulnerability event.
<ReportItem port="445" svc_name="cifs" protocol="tcp" severity="2" pluginID="132101" pluginName="WindowsSpeculative Execution Configuration Check" pluginFamily="Windows">
<bid>20180711</bid>
<cpe>cpe:/o:microsoft:windows</cpe>
<cve>CVE-2018-3615</cve>
<cve>CVE-2017-5753</cve>
<cvss_base_score>5.4</cvss_base_score>
<cvss_score_source>CVE-2018-3615</cvss_score_source>
<cvss_temporal_score>4.7</cvss_temporal_score>
<cvss_temporal_vector>CVSS2#E:H/RL:OF/RC:C</cvss_temporal_vector>
<cvss_vector>CVSS2#AV:L/AC:M/Au:N/C:C/I:P/A:N</cvss_vector>
<description>The remote host has not properly mitigated a series of known speculative execution vulnerabilities....</description>
<fname>microsoft_windows_spec_execution.nbin</fname>
<msft>MS21-5003203</msft>
<plugin_modification_date>2021/04/20</plugin_modification_date>
<plugin_name>WindowsSpeculative Execution Configuration Check</plugin_name>
<plugin_publication_date>2019/12/18</plugin_publication_date>
<plugin_type>local</plugin_type>
<risk_factor>Medium</risk_factor>
<script_version>1.14</script_version>
<see_also>http://www.nessus.org/u?8902cebb
http://www.nessus.org/u?6a005ed4</see_also>
<solution>Applyvendor recommended settings.</solution>
<synopsis>The remote host has not properly mitigated a series of speculative execution vulnerabilities.</synopsis>
<vuln_publication_date>2018/01/04</vuln_publication_date>
<plugin_output>....</plugin_output>
</ReportItem>
Following the mapping approaches described above the generated ECS records would be as follows (only showing vulnerability field set):
- Extending ECS Vulnerability field set definition to include an array of identifier and enumeration values for each vulnerability ID in the Tenable report.
{ "vulnerability" : {
"id" : "CVE-2017-5715",
"enumeration" : "CVE",
"related.ids" : [{"id" : "CVE-2017-5715", "enumeration" : "CVE" },
{"id" : "CVE-2017-5753", "enumeration" : "CVE" },
{"id" : "20180711", "enumeration" : "BID" },
{"id" : "MS21-5003203", "enumeration" : "MSFT" }],
"category" : ["windows"],
"classification" : "CVSS",
"description" : "The remote host has not properly mitigated a series of known speculative execution vulnerabilities ...",
"reference": ["http://www.nessus.org/u?8902cebb", "http://www.nessus.org/u?6a005ed4"],
"scanner.vendor": "Tenable",
"score.base":6.4,
"score.version": 2,
"score.temporal": 4.7,
"severity": "Medium"
}
}
- Extending ECS Vulnerability field set definition to include a uniquely named field for each vulnerability identifier and an array of related ids to contain all vulnerability IDs in the Tenable report:
{ "vulnerability" : {
"id" : "CVE-2017-5715",
"enumeration" : "CVE",
"related.ids" : [ "CVE-2017-5715","CVE-2017-5753","20180711","MS21-5003203"],
"cve": ["CVE-2017-5715","CVE-2017-5753"],
"bid": ["20180711"],
"msft": ["MS21-5003203"],
"category" : ["windows"],
"classification" : "CVSS",
"description" : "The remote host has not properly mitigated a series of known speculative execution vulnerabilities ...",
"reference": [ "http://www.nessus.org/u?8902cebb", "http://www.nessus.org/u?6a005ed4"],
"scanner.vendor": "Tenable",
"score.base":6.4,
"score.version": 2,
"score.temporal": 4.7,
"severity": "Medium"
}
}
Are either of these approaches consistent with ECS best practices?
Is there an advantage of either approach?
Is there an alternative recommendation?