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

[Pavel Kácha]

   Sure! Use as you wish/need.

-- Pavel

> From: Sebastian Wagner <wagner at cert.at>, Date: kvě 03, 2021
>
>    Dear Pavel,
> 
>    Thank you very much for this great composition of possible use-cases. May I integrate them into the current IEP04 text?
> 
>    Sebastian
> 
>    On 4/29/21 3:40 PM, Pavel Kácha wrote:
> 
>  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] [1]https://idea.cesnet.cz/en/definition
> 
>  _______________________________________________
>  IntelMQ-dev mailing list
>  [2]https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
>  [3]https://intelmq.readthedocs.io/
> 
>  --
>  // Sebastian Wagner [4]<wagner at cert.at> - T: +43 676 898 298 7201
>  // CERT Austria - [5]https://www.cert.at/
>  // Eine Initiative der nic.at GmbH - [6]https://www.nic.at/
>  // Firmenbuchnummer 172568b, LG Salzburg
> 
> References
> 
>    Visible links
>    1. https://idea.cesnet.cz/en/definition
>    2. https://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
>    3. https://intelmq.readthedocs.io/
>    4. mailto:wagner at cert.at
>    5. https://www.cert.at/
>    6. https://www.nic.at/



-------------- 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/20210503/f51e5e42/attachment.sig>