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