[IntelMQ-dev] IEP04: The choice of the UUID-format

[Pavel Kácha]

> From: Chris Horsley <chris.horsley at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20210908/bbc0d422/attachment.sig>