-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Meta] Expand support for populating event.ingested #20073
Comments
Pinging @elastic/siem (Team:SIEM) |
In my opinion an optimal solution would be to have Filebeat install an Elasticsearch pipeline that adds So I think the easiest way to address this would be to update the modules in bulk and add a |
Would this be available to all beats, if implemented, or would it be just filebeat? |
The event.ingested field defines time at which the event was ingested to Elasticsearch and it added by the Ingest Node pipeline. This field is important when trying to build alerts for activities that may have been reported long after they occurred (@timestamp is much older than event.ingested). This might happen if an agent was offline for a period of time or the processing was delayed. This adds a test to ensure all modules create event.ingested. Closes elastic#20073
The event.ingested field defines time at which the event was ingested to Elasticsearch and it added by the Ingest Node pipeline. This field is important when trying to build alerts for activities that may have been reported long after they occurred (@timestamp is much older than event.ingested). This might happen if an agent was offline for a period of time or the processing was delayed. This adds a test to ensure all modules create event.ingested. Use Filebeat read time instead of ingest time as event.created in Zeek. Closes #20073
The event.ingested field defines time at which the event was ingested to Elasticsearch and it added by the Ingest Node pipeline. This field is important when trying to build alerts for activities that may have been reported long after they occurred (@timestamp is much older than event.ingested). This might happen if an agent was offline for a period of time or the processing was delayed. This adds a test to ensure all modules create event.ingested. Use Filebeat read time instead of ingest time as event.created in Zeek. Closes elastic#20073 (cherry picked from commit 829c3b7)
The event.ingested field defines time at which the event was ingested to Elasticsearch and it added by the Ingest Node pipeline. This field is important when trying to build alerts for activities that may have been reported long after they occurred (@timestamp is much older than event.ingested). This might happen if an agent was offline for a period of time or the processing was delayed. This adds a test to ensure all modules create event.ingested. Use Filebeat read time instead of ingest time as event.created in Zeek. Closes #20073 (cherry picked from commit 829c3b7)
The event.ingested field defines time at which the event was ingested to Elasticsearch and it added by the Ingest Node pipeline. This field is important when trying to build alerts for activities that may have been reported long after they occurred (@timestamp is much older than event.ingested). This might happen if an agent was offline for a period of time or the processing was delayed. This adds a test to ensure all modules create event.ingested. Use Filebeat read time instead of ingest time as event.created in Zeek. Closes elastic#20073
Within Elastic Security we've recently exposed the ability for users to specify the timestamp field used when a Detection Rule runs in effort to minimize any gaps in alerts from delayed events. The ECS field most useful here would be
event.ingested
(elastic/ecs#453, elastic/ecs#582), and so ensuring that this field is populated whenever possible would greatly benefit any downstream use-cases where the system must determine if an event is stale or has been delayed.Currently it looks like only two modules are setting
event.ingested
(thanks @leehinman!):In discussions it looks like we can add the following to relevant pipelines:
And also update the test modules here:
Let's use this as a meta issue for tracking the support of
event.ingested
across modules -- feel free to update this description as things progress.Currently supported:
Yet to be supported:
The text was updated successfully, but these errors were encountered: