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

[Pavel Kácha]

> From: Sebastian Wagner <wagner at 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
-------------- 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/20210909/a41ce611/attachment-0001.sig>