[IntelMQ-dev] IEP04 use-cases (Was: Re: Decision on IEP04: IntelMQ Data Format - Meta-Information)

[Pavel Kácha]

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] https://idea.cesnet.cz/en/definition
-------------- 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/20210429/b0474268/attachment.sig>