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

[Sebastian Wagner]

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.

I also noticed that the AIL format itself doesn't provide a timestamp, I
wonder why. Alex, why is that the case?

Sebastian

-- 
// Sebastian Wagner <wagner at cert.at> - T: +43 676 898 298 7201
// CERT Austria - https://www.cert.at/
// Eine Initiative der nic.at GmbH - https://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20210908/8a1f0b03/attachment.sig>