<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi,</p>
    <p>I fully agree that use-cases 1-4 can be solved by adding linking
      information to IntelMQ messages.<br>
    </p>
    <p>Regarding the use-cases 5+:<br>
    </p>
    <p>Use-case 5 is of course very interesting, but I'd like to not
      discuss that one as part of IEP04. Defining such an algorithm/hash
      for identifying similar or almost-identical events would take some
      time and deserves its own proper discussion and IEP.</p>
    <p>6 (internal identifier) is just a freeform text, so easy to
      implement it needed.<br>
    </p>
    <p>7 (Meta-events) and 9 (Modification or deletion/withdrawal of
      information) would introduce a different type of message, and I
      think it is - in the first place - not related to Meta-information
      of events.</p>
    <p>8 (Correlated events) is either a meta-event or a simple link
      (1-4)</p>
    <p>Cheers,<br>
      Sebastian<br>
    </p>
    <div class="moz-cite-prefix">On 4/29/21 3:40 PM, Pavel Kácha wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:20210429134058.GE8626@cesnet.cz">
      <pre class="moz-quote-pre" wrap="">Hello,

   at the hackaton we decided to try to document some real use-cases that
might be covered by IntelMQ. I guess this is still bit of a design phase and
does not fit into one of the issues at GitHub, so I'll try to kick it off
here for discussion (and decisions of what IntelMQ does and does not want to
support, or what to consider and what to scratch).

 1, Events with multiple target IPs/hostnames/ports

  - Horizontal portscan (multiple machines, one port)
  - SSH bruteforce (multiple machines, one port/service)
  - Vertical portscan (one machine, multiple ports)

 2, Events with multiple source IPs/hostames/ports

  - Targeted DDoS (mutiple machines/reflectors shoot at one target)

 3, Events with both multiple sources and targets

  - Wider DDoS (multiple machines/reflectors shoot at mutiple machines,
    whole subnet, etc.)

 4, Events with one or more both sources and targets, where exact pattern is
    not known

  - Aka one of [1, 2, 3], but we do not have complete information about
    specific connections made, possibly because the event/detection came
    from the statistical detector or from some form of aggregation (where
    original full information from for example netflow is already lost).


   I guess these (1-4) initiated creation of IEP03 and IEP04 and probably
are the only ones worth considering now.


   Taking into account the possibility of linking of events, there might be
other orthogonal use-cases:

 5, Identification of identical events from possibly the same source to
    avoid duplication/circles

  - aka some form of stable identifier

 6, When target organisation contacts source organisation for more info,
    identification of where event came from internally

  - aka possibility to put there the internal (opaque) identifier, like
    CESNET-RT#2235 (Request tracker), or Idea:UUID (what Idea event was
    converted into this IntelMQ event)

 7, Meta-events

  - event, linking together multiple completely different events as one
    incident (email address of spammer from spam email, IPs of spamming
    mailservers, phishing URL from spam email)

 8, Correlated events

  - aka different events, but identified as related/part of other events
    (like ongoing attack)

 9, Modification or deletion/withdrawal of information

  - aka "this event replaces that event with new info", or "that event was
    wrong, sent by error, forget it"


   All above are ones we considered in Idea (see ID, AltNames, CorrelID,
AggrID, PredID, RelID at [1], and not yet implemented GroupID), and I
personally consider:

  - 1-4, maybe 5 quite important, 
  - 6 handy (nice to have)
  - 7-9 - we incorporated possibility of these, but in fact never used


   I believe pretty much all are solvable by linking of events (IEP04):

 1, 2, 3 as bunch of linked events with source-target relation in each of them
 4 as two linked events - one with all the sources, one with all the targets

 5 as additional calculated identifier, hard part is not storage, but
   standardization/calculation
 6 as additional opaque (freehand, non UUID) identifiers
 7, 8 as bunch of linked events, with possibility of some meta-event maybe
 9 as additional type of link 

-- Pavel

[1] <a class="moz-txt-link-freetext" href="https://idea.cesnet.cz/en/definition">https://idea.cesnet.cz/en/definition</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
IntelMQ-dev mailing list
<a class="moz-txt-link-freetext" href="https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev">https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev</a>
<a class="moz-txt-link-freetext" href="https://intelmq.readthedocs.io/">https://intelmq.readthedocs.io/</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
// Sebastian Wagner <a class="moz-txt-link-rfc2396E" href="mailto:wagner@cert.at"><wagner@cert.at></a> - T: +43 676 898 298 7201
// CERT Austria - <a class="moz-txt-link-freetext" href="https://www.cert.at/">https://www.cert.at/</a>
// Eine Initiative der nic.at GmbH - <a class="moz-txt-link-freetext" href="https://www.nic.at/">https://www.nic.at/</a>
// Firmenbuchnummer 172568b, LG Salzburg</pre>
  </body>
</html>