Extend Vulnerability Fieldset

[jamiehynds]

Based on user feedback, we're missing some fields in our ECS vulnerability fields and suggest the following additions.

• Mitigations and Solutions
  • This is a free-text field that explains to users how to fix or mitigate the problem, suggest vulnerability.mitigation?
• CWE
  • This should be an array to help future proof itself. There are reasons to use multiple CWE names. Right now the ECS definition of reference is a string, an array should be considered.
• id
  • We specify one id in ECS, which makes sense, but it's common for a CVE ID to also be mapped to various scanner IDs, I need another field, maybe alternate_id or secondary_id
• statement
  • This is different than the description. There are some CVE IDs that we will want to publish details about that include a statement such as "This library is not exposed to the external network in the container image"
• status
  • This is part of the statement data, so something could be a false positive, or future update, or whatever. It can have multiple statuses (is statuses a word?). For example something can be a false positive and also be getting a future update. Suggest vulnerability.status: open/fixed/ignored
• patch
  • does a patch exist to resolve the vulnerability and is there a patch code associated. e.g. vulnerability.patch.exists (yes/no), vulnerability.patch.code (ESA-2020-13), vulnerrability.patch.name
• Dates
  • vulnerability.discovered (first time detected), vulnerability.disclosed, vulnerability.closed
• Affected components: link to CPE ?
• Decomposition of vulnerability.score.temporal to include exploitability. It could be interesting to automatically calculate it based on entered elements, and share the script.
• Ownership - Might be through another field like service
• **vulnerability.category**

[jamiehynds]

FYI @clement-fouque

[clement-fouque]

Thanks @jamiehynds. Here are some comments on the properties you were mentioning:

• Mitigations and Solutions
  • Pretty useful to store resolution from the scanner vendor or document mitigation in place
• CWE
  • Might be good to have an array of items with properties name, id & description
  • Details can be found here https://nvd.nist.gov/vuln/categories
• id
  • A vulnerability doesn't have necessary a CVE associated with it. I don't know if it makes sense to seperate vulnerability ID (like CVEs) to the vendor/detection IDs. Using alternate_id or secondary_id might be good option.
• status
  • Values could also be: false_positive, risk_accepted, reopened, ...
• patch
  • I really like the idea to have 3 properties associated (exists, code and name) as it'll be easier to exclude vulnerabilities that have no patch and also group remediation by patch
• dates
  • I would also add last time found.
• Affected components
  • Yep, CPE will probably be the way to go
• Decomposition of vulnerability.score.temporal to include exploitability
  • Excellent idea to have a script and share it. We can also extend it to vulnerability.score.environmental
  • It could give ideas/exemple to implement First EPSS scoring.
• Ownership
  • As you said, it might not be the best place to store it. Having guidance where to store it would definitely help.

I would also add

• title, name or short description as it's easier to use in dashboards
• Exploitability
  • CVSS is the prioritisation model that is the most often used. More mature vulnerability management program will use exploitability (end then environmental).
  • It does not necessarly fit in vulnerability.temporal as we need to describe if exploit exists, maturity, last time it was found, ...
  • We might just adapt the threat field
• Severity which could be based on First Qualitative Severity Rating Scale

The following are ideas that might not be interesting to add in ECS:

• Scan details
  • Timing (Start/stop)
  • Method (IP/agent based)
• Asset type
  • VM
  • Web
  • Container

[clement-fouque]

It might be interesting to align with the Open Source Vulnerability format.

[dainperkins]

The addition of event.category vulnerability is definitely a critical add for easily creating dashboards from multiple vulnerability scanners.

a vulnerability.(hash || fingerprint || uid) would be really useful as well (tenable includes one) to identify the same vulnerability over multiple scans

status (open, patched, mitigated, accepted, etc.) is another one that would be extremely useful

for the vulnerability.id, maybe vulnerability.vendor

on the asset front - is there consideration of moving asset type records into an "asset" field set &&|| using existing fieldsets to populate that data? (e.g. host, container, etc.). would also be relevant in terms of e.g. network info for remote assessments (e.g. populating destination.port for a vulnerability, or potentially adding e.g. network.port as a more general descriptor or keeping it under vulnerability w/ vulnerability.port / vulnerability.network port...)

[nicpenning]

Including CVSS 4.0 would also be a good add if Elastic ever wants to get into the vulnerability management game.

[norrietaylor]

Linking this RFC here: https://github.com/elastic/ecs/pull/2331

It looks like it will complete a fair number of the requests on this issue.

[nicpenning]

Tenable Nessus (10.8.0) is now (as of this month) including CVSS 4.0 and EPSS scoring into their datasets. This increases the need for these additional ECS fields for sure!