Wishlist for IntelMQ 4.x

[aaronkaplan]

• all CLI components could highly benefit from using typer
• support redis streams
• LDAP enrichment bot (which must also be compatible with AD)
• Full Splunk support: interface the Splunk API
• VT API enrichtment bot
• Support Jira as ticket system
• Support OTRS as ticket system
• TheHive interface
• new data format (see IEP04)

For potential new hard requirements in the core I usually look at how widespread and common that dependency is. For typer, I see that it's available in Debian sid and Fedora and openSUSE Tumbleweed. So it doesn't look like the package is bleeding edge and is starting to be picked up by distros. For the older ones, we'd still to package it ourselves. To put it in a nutshell, from that point of view, that's not a blocker.

[aaronkaplan]

okay, but it should not be a big problem to bring it and package it for bullseye for example. So, yeah... not a blocker.
The question is - did you read the docs and would it make sense ? It looks really good for me, make the code very clean and lean and simple.

It also supports shell completion (https://typer.tiangolo.com/typer-cli/), which is a big pro (our current solutions some some issues, e.g. #1240 #1561 #2094 ).
Still, before going for typer I'd like to see a comparison of different solution to check if it matches our requirements best (could even also be an IEP). E.g. one other (even more) widespread cli-library is click.

[aaronkaplan]

+1 for IEP. But I am collecting ideas first in this issue :)

maybe it makes sense to first define the problem(s) that should be solved

[gethvi]

Extending format based on classification.type.

Example 1:
classification.type: "phishing"

Optional additional fields:
phishing.brand: "Big-Bank-Name"
phishing.screenshot (maybe base64 data?)
phishing.sector: "banking"
phishing.language: EN
etc

Example 2:
classification.type: "system-compromise"

Optional additional fields:
system-compromise.commands: ["wget evil-url", "./evil-file"]
system-compromise.vector: "ssh" (or maybe "web-attacks", "sqli", etc)
etc.

Add destination.password

When an event describes unauthorized login attempt, it would be nice to officialy "recognize" the password (for example honeypots provide this information).

Add TLS info

If some service is running using TLS, we could accomodate info about certificate serial number or perhaps an issuer of the cert.

All of the above are half-baked ideas, but they come from real experience when I found it really hard/impossible to map relevant information to the intelmq data format without adding custom fields.

[aaronkaplan]

@gethvi good additions, thanks! Agree, they could be elaborated but this list is there to collect ideas :) so, spot on. No idea is too half-baked for this issue :)