[IntelMQ-dev] Classification of malware itself in IntelMQ

Sebastian Wagner wagner at cert.at
Mon Feb 22 11:24:25 CET 2021


Dear IntelMQ community,

sorry for cross-posting, but I think this topic should be discussed in a
wider group.

IntelMQ always followed the Reference Security Incident Taxonomy (short:
RSIT)[0] and its predecessor for its 'classification.taxonomy/type'
fields. The Classification column in the RSIT corresponds to our
"classification.taxonomy" field, and the RSIT's second column (currently
called Incident examples) corresponds to our "classification.type"
field. "classification.identifier" is an optional third level free-text
field to give more specific context.[1]

Due to historical reasons and changes on both sides - IntelMQ as well as
the RSIT -, IntelMQ's classification scheme deviated a bit from the RSIT
over time. I'm working on aligning them again for 3.0, which works
straightforward in most cases. But for one case, I need your input.

The predecessor of the RSIT (the eCSIRT.net taxonomy)[2] used the
malicious code taxonomy differently: To classify malware itself into
categories, like virus, worm, trojan, etc. The RSIT never did that, as
classifying malware is never unambiguous and there are plenty of
existing classification scheme out there, which do this already. Also,
the focus of the RSIT is different, as it classifies the
incidents/events, not malware samples.

And for this reason, IntelMQ had (until < 3.0.0) the classification.type
"malware" in IntelMQ. Most of the usages were wrong anyway, and should
have been infected-device, malware-distribution or something else
anyway. There is only one usage in IntelMQ, which can not be changed.
And that one is really about malware itself (or: the hashes of samples)
as used in the GitHub Feed parser[3] and the FireEye Parser[4]. But the
issue is more generic, as we need to decide anyway, how we want to deal
with such malware-IoCs.

A malware (hash) does not fit into the RSIT. It's neither an Infected
System, a C2 Server, Malware Distribution nor Malware Configuration.
It's just a malware (hash). I see four options:

1) Deviate from the RSIT and just use 'classification.taxonomy' =
'Malicious Code' and 'classification.type' = 'malware'
2) Deviate slightly less from the RSIT and use 'classification.taxonomy'
= 'other' and 'classification.type' = 'malware'
3) Adhere strictly to the RSIT and use 'classification.taxonomy' =
'other' and 'classification.type' = 'other' and
"classification.identifier" = 'malware'
4) IntelMQ does not support this use case

In cases 1) and 2) "classification.identifier" could be used to specify
what the event is about, e.g. "hash", or the malware family.

I'm currently in favor of option 2), as we can keep the meaning of
"Malicious Code" in sync with the RSIT and still support the use-case
sufficiently. But my opinion could change during the discussion :)

Do you see any more options than I listed above? What do you favor?

best regards
Sebastian

[0]:
https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/blob/5479e71/working_copy/humanv1.md
[1]:
https://intelmq.readthedocs.io/en/latest/dev/data-harmonization.html#classification
[2]: https://www.trusted-introducer.org/Incident-Classification-Taxonomy.pdf
[3]:
https://github.com/certtools/intelmq/blob/f7507ca2643fe8ddb3817c9be1209504ef8cc1f9/intelmq/bots/parsers/github_feed/parser.py
[4]: https://github.com/certtools/intelmq/pull/1745


-- 
// Sebastian Wagner <wagner at cert.at> - T: +43 1 5056416 7201
// CERT Austria - https://www.cert.at/
// Eine Initiative der nic.at GmbH - https://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20210222/34f77501/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20210222/34f77501/attachment-0001.sig>


More information about the IntelMQ-dev mailing list