Closed ph closed 3 years ago
Pinging @elastic/security-external-integrations (Team:Security-External Integrations)
@ruflin I saw your message later in the benchmark discussion, I see quite a few usage of wildcards in the integration packages, I agree we are not affected as drastically as beats but we should probably audit the above, there is a lot of reference of wildcards especially on the zeek integration. Are we using it correctly ?
@ph -- these fields were changed to bring the packages to parity with the beats modules. We're using them "correctly" in the sense that these fields are all marked as wildcard
fields in the experimental/1.8 ECS schema.
Personally I'd be fine keeping these as wildcard since the changes are slightly more constrained than beats, as @ruflin mentioned, but if we want to revert them in the same way the 7.11 beats modules are getting reverted, I'm fine with that too.
WRT zeek
the reason the integration has so many fields that are wildcard is because the package itself is huge--both the filebeat module and the package contain ~30 data streams IIRC, so they have a lot of fields in general.
Thanks for the details @andrewstucki I am fine with keeping them as is and will be closing this.
We are going to revert the wildcard changes in packages to be consistent with Beats for the time being. We'll swap over to using on the non-experimental fields for ECS 1.7. After ECS promotes the wildcard fields to non-experimental status we'll adopt them.
quoted from https://github.com/elastic/beats/issues/23671:
Looking at the integration fields we seems to have a few
wildcard
reference.