search

elastic / ecs

Elastic Common Schema
https://www.elastic.co/what-is/ecs
Apache License 2.0
1.01k stars 418 forks source link

Add New Vulnerability ECS Fields #2127

Open mr1716 opened 1 year ago

mr1716 commented 1 year ago

Summary Please let me know if this requires a new RFC, but the request is to add new vulnerability ECS fields to help ensure that ECS is more complete and provide information about the vulnerabilities.

Motivation: The goal is to add vulnerability fields to ensure that adding details around vulnerability information to add in about fixes, discovery, information, and other information about the vulnerability. It would be very useful to be

Detailed Design:

Add the following fields: Proposed Field Description Example Type
vulnerability.last_observed Date when vulnerability was last observed Nov 25 2022 02:40:39 EST date
vulnerability.publication Date when vulnerability was published Jan 1 1995 12:00:00 EST date
vulnerability.solution Vulnerability Solution Filter out the ICMP timestamp requests (13) and the outgoing ICMP timestamp replies (14) keyword
vulnerability.repository Vulnerability Repository Individual Scan keyword
vulnerability.synopsis Synopsis of vulnerability This vulnerabiilty allows an attacker to execute remote code keyword
vulnerability.first_discovered Date when vulnerability was first observed Oct 25 2022 02:40:39 EST date
vulnerability.publish.date Vulnerability Publish Date Sept 25 2022 02:40:39 EST keyword
vulnerability.Fix.Date When Vulnerability Was Fixed Nov 25 2022 02:40:39 EST keyword
vulnerability.Fix.Status Was The Vulnerability Fixed True keyword
mr1716 commented 1 year ago

@kgeller if I wanted to create new fields in an existing base field, is this the right path to take?? (alternative would be to submit an RFC) If not, please let me know. Trying to follow the best practices

kgeller commented 1 year ago

@mr1716 since there's a number of fields being proposed and they aren't necessarily standard fields, I'd recommend to move forward with an RFC.

mr1716 commented 1 year ago

@kgeller Thanks for the heads up. Is there a difference between when an RFC is required for extending an existing base field and when one is not required??

kgeller commented 1 year ago

Nope, totally same RFC process

mr1716 commented 1 year ago

@kgeller but for these cases, I dont see an RFC for these changes, so maybe this doesnt require an RFC: https://github.com/elastic/ecs/pull/2083/files https://github.com/elastic/ecs/pull/2121/files

kgeller commented 1 year ago

@mr1716 those are both different scenarios than this. For what you've described above, I think that we should go through the RFC process.

epicsilence99 commented 1 year ago

Just a curious observer looking into similar, were you basing this off of tenable/nessus fields @mr1716 ? That is what it seems like at first glance. I also have an interest in improving the Vulnerability ECS fields, maybe we can agree on a bit cut down list that doesn't require RFC and could be considered "standard" while we could work on submitting something for RFC for a more inclusive list? I know it's been stale for a bit so not sure on the activity, so didn't want to duplicate any work

mr1716 commented 1 year ago

Just a curious observer looking into similar, were you basing this off of tenable/nessus fields @mr1716 ? That is what it seems like at first glance. I also have an interest in improving the Vulnerability ECS fields, maybe we can agree on a bit cut down list that doesn't require RFC and could be considered "standard" while we could work on submitting something for RFC for a more inclusive list? I know it's been stale for a bit so not sure on the activity, so didn't want to duplicate any work

You’re correct

epicsilence99 commented 1 year ago

Just a curious observer looking into similar, were you basing this off of tenable/nessus fields @mr1716 ? That is what it seems like at first glance. I also have an interest in improving the Vulnerability ECS fields, maybe we can agree on a bit cut down list that doesn't require RFC and could be considered "standard" while we could work on submitting something for RFC for a more inclusive list? I know it's been stale for a bit so not sure on the activity, so didn't want to duplicate any work

You’re correct

I think that is @kgeller concern, some of those fields might be too specific like vulnerability.repository since this is tenable specific terminology and ECS is meant to be as general as possible and platform agnostic as much as possible. Hence why I believe she suggested the RFC process, maybe there's an in between here where we could agree on standardized ones in your list that don't require RFC, and then have a further discussion about what could potentially make it to RFC process