From: Sebastian Wagner wagner@cert.at, Date: zář 08, 2021
On 9/8/21 4:15 PM, Pavel Kácha wrote:
Exactly, came to my mind also. Not to forget that timestamps are not exact - portscan or DDoS have their start and end timestamps, not just one.
If we want to have some type of timestamp within UUID, or at least within metadata, there should be deterministic definition of what is should be, and taking into account that some of that info would not be available (precise start or end of the attack, etc.), for example one of:
- use always detection time
- use always creation time
- use first available: event start, detection window start, event end, detection window end, detection time, event creation time
I think that timestamp within metadata is important even if there are (possibly duplicate) timestamps within event data (payload) itself, if support for other formats (n6, Idea) is considered - some tools within the chain would not need to actually understand all of the formats, but only metadata.
I think the third option best describes a useful behavior in IntelMQ (we have no fields for detection window and events start == time.source, creation time ~= time.observation) which is already used in some code parts.
Putting six different timestamps in the metadata while not providing that data in the payload itself seems a bit awkward to me.
Definitely. To make myself clearer - I didn't mean to put all the timestamps into metadata, just the one, which would make best sense for the tools, which do not need to look into payload, and which would be clearly defined. My examples are just (some of the) possibilities of how to define it.
-- Pavel