One of IntelMQ's core use-cases is to distribute warnings and IoC data to responsible parties like network or domain owners. The distribution of data requires information of the delivery and recipient's address.
https://github.com/Intevation/intelmq-fody/ https://github.com/Intevation/intelmq-certbund-contact/
https://gitlab.com/Intevation/tuency/tuency certtools/intelmq#1857
https://github.com/Intevation/intelmq-mailgen/tree/master/docs https://github.com/certat/intelmq/blob/master/docs/user/intelmqcli.rst
For mail transfer, the following data fields are required:
- one or multiple destination email addresses
- optionally a PGP public key or fingerprint per address
- optionally an S/MIME certificate per address
- optionally a flag indicating, that the mail should be sent as Cc: to the recipient per address
- data format, e.g. CSV, JSON, IDEA, X-ARF, STIX etc.
Option 1: encryption information could be stored in a separate component, queried/used by the sending program.
If the information is to be pushed to a foreign API, the following data fields are necessary:
- API endpoint, as URI, optionally containing username and password information
- optionally a client certificate
- optionally an authentication token
- Hostname https://www.rabbitmq.com/uri-spec.html Does not support exchanges or queues, only vhost
https://xmpp.org/rfcs/rfc5122.html#use-form
Timing interval information
| Delivery method | URI | Specific parameters | Authentication | PGP + S/MIME | Client Cert | Cc | Data format |
|---|---|---|---|---|---|---|---|
| One or more addresses | No | Yes | No | Yes | Yes | ||
| XMPP | Yes | Yes | Yes | No | ? | No | Yes |
| HTTP/REST API | Yes | No | Yes | No | Yes | No | Yes |
| AMQP | Yes | Yes | Yes | No | Yes | No | Yes |
Instead of replicating all information for every event, the events could as well hold only references. For PGP or S/MIME this could be the fingerprint, for AMQP/XMPP etc this could cover only connection parameters (authentication etc) without the host URI, or the host information as well.