[IntelMQ-dev] [IntelMQ-users] IEP03: IntelMQ Data Format - Multiple Values

[Pavel Kácha]

Hello Sebastian,

> From: Sebastian Waldbauer <waldbauer at cert.at>, Date: dub 06, 2021
>
> IMHO, I wouldn't use multiple values in source fields as intelmq data gets
> more complex and will break the KISS principle. Using the parent uuid would
> solve this problem of nesting, as you can use uuids to connect similar
> events to each other. I'd propose to use multiple values in fields where it
> doenst get too complex like `tags`. Tags can be used to add specified tags
> like campaigns.

   Sure, then you'll have to embrace IEP04, however with its own set of
problems (M:N alias difficult to describe DDoS, data completeness problem
alias "how long should I wait to be reasonably sure I have complete set of
events?").
   We wanted to take the analysis/assembly/complexity burden out of readers
(cause we have our experience with IDMEF, IODEF and MISP, which seem to me
as writer friendly, not reader friendly :) ), so we went for (hopefully
reasonably) increased complexity and against dropping (too much) features -
and trying to solve most of the problems on our side. Real world is usually
not KISS. :)

> > > ### Classification
> > ...
> > > ## Format
> > > {"classification.taxonomy": ["information-content-security", "fraud"],
> > > "classification.type": ["unauthorised-modification-of-information",
> > > "phishing"]
> >     I believe (feel free to correct me) that RSIT does not preclude usage of
> > just first level category in cases where second level is ambiguous or
> > unknown, so in two array format you could solve it for example like:
> > 
> >     {
> >        "classification.taxonomy": ["information-content-security", "fraud"],
> >        "classification.type": [null, "phishing"]
> > 
> >     In Idea we went for "merged" field, here it might look like:
> > 
> >     classification: [
> >        "information-content-security.unauthorised-modification-of-information",
> >        "fraud.phishing"
> >     ]
> > 
> >     or considering missing second level:
> > 
> >     classification: [
> >        "information-content-security",
> >        "fraud.phishing"
> >     ]
> 
> Agree with the "tagging" style, as it can contain a lot of information & can
> be set per event.

   Just a note that came to my mind - on RSIT, second level implies first
level (all second level labels are unique and belong to exactly one first
level labels), so (as for completeness of information, not necessarily for
clarity) "unauthorised-modification-of-information" is in fact enough,
instead of "information-content-security.unauthorised-modification-of-information".
   However, explicit is usually better than implicit. :)

-- 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/20210406/64595bca/attachment.sig>