I am a long time user of ELK and recently switched to 7.9 to experiment with Security and SIEM functions.
After much trouble shooting to get my test Detection to show up in the "Detection Alerts" area, I discovered by expanding my search time parameter into the future that Detections was adding ~20 minutes to my detection signal @timestamp. There are no underlying changes to the data (i.e. the correct @timestamp for a particular UID in the ES index) but the wrong @timestamp does push over into a Timeline.
All other similar timestamp type data in the detection signal such as event.created and even signal.original_event.created are unchanged (i.e. the correct time).
Note: All my zeek data renders fine in the "Network" tab WITH the correct @timestamp.
I am aware that Kibana will parse time zones into browser or other set timezone but can't find references to it adding minutes.
I would appreciate ideas on how to correct this or even how to debug it.
Thanks for reaching out. If it's ok, I'd love to get a bit more info to try to recreate what you're observing.
I want to make sure I understand your expectations of the different timestamps. When you say that the @timestamp on the signal is wrong - you are expecting the signal @timestamp to equal the originating event @timestamp? Currently, when we generate signals, we assign the signal a new @timestamp at it's generation. What is the interval the rule is set to run at? For example, if your rule is set to run every 20 minutes, the signal @timestamp could then be 20 minutes after the corresponding event.
If you are wanting to adjust the time field the rule uses to query indices - you can use the rule's timestamp_override field, documented here. In the UI, you can find this option under a rule's About --> Advanced settings section:
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
