From: Chris Horsley chris.horsley@csirtfoundry.com, Date: zář 08, 2021
Not specifically for IntelMQ, but I tend to break an event message into at least three timestamps (but possibly more depending on event type):
- actual occurrence time of reported security event (time.source as I'd
understand it)
- event package original creation time (the suggested meta.intelmq:timestamp
here, which I'd possibly rename to meta.intelmq:creation_timestamp or similar)
- event package system ingestion time (time.observation?)
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.
And I second the opinion that if timestamp is already in the metadata, UUID4 is fine.
-- Pavel Kácha