<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello Sebastian,</p>
<p>Could you give some real-life examples of incorrect usage? I
think quite a lot of cases can be covered by infected-system when
hash taken from infected device, or malware-distribution
otherwise. <br>
</p>
<p>From other hand, RIST stands exclusively for Incident taxonomy
and classification attributes helps only with Incident
classification. However Incident management is not the only
service/activity of CSIRTs, so if malicious code analysis is
related not to the some incident, RSIT taxonomy would not help
here, and probably such a case should be handled not as an
incident?<br>
</p>
<p><br>
</p>
<p>Best regards<br>
</p>
<div class="moz-cite-prefix">On 22/02/2021 12:24, Sebastian Wagner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c2ecabf0-0261-846d-83eb-e6a54582128c@cert.at">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Dear IntelMQ community,</p>
<p>sorry for cross-posting, but I think this topic should be
discussed in a wider group.</p>
<p>IntelMQ always followed the <span class="reference external">Reference
Security Incident Taxonomy</span> (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]</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<p>1) Deviate from the RSIT and just use 'classification.taxonomy'
= 'Malicious Code' and 'classification.type' = 'malware'<br>
2) Deviate slightly less from the RSIT and use
'classification.taxonomy' = 'other' and 'classification.type' =
'malware'<br>
3) Adhere strictly to the RSIT and use 'classification.taxonomy'
= 'other' and 'classification.type' = 'other' and
"classification.identifier" = 'malware'<br>
4) IntelMQ does not support this use case<br>
</p>
<p>In cases 1) and 2) "classification.identifier" could be used to
specify what the event is about, e.g. "hash", or the malware
family.</p>
<p>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 :)</p>
<p>Do you see any more options than I listed above? What do you
favor?</p>
<p>best regards<br>
Sebastian<br>
</p>
<p>[0]:
<a class="moz-txt-link-freetext"
href="https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/blob/5479e71/working_copy/humanv1.md"
moz-do-not-send="true">https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/blob/5479e71/working_copy/humanv1.md</a><br>
[1]:
<a class="moz-txt-link-freetext"
href="https://intelmq.readthedocs.io/en/latest/dev/data-harmonization.html#classification"
moz-do-not-send="true">https://intelmq.readthedocs.io/en/latest/dev/data-harmonization.html#classification</a><br>
[2]: <a class="moz-txt-link-freetext"
href="https://www.trusted-introducer.org/Incident-Classification-Taxonomy.pdf"
moz-do-not-send="true">https://www.trusted-introducer.org/Incident-Classification-Taxonomy.pdf</a><br>
[3]:
<a class="moz-txt-link-freetext"
href="https://github.com/certtools/intelmq/blob/f7507ca2643fe8ddb3817c9be1209504ef8cc1f9/intelmq/bots/parsers/github_feed/parser.py"
moz-do-not-send="true">https://github.com/certtools/intelmq/blob/f7507ca2643fe8ddb3817c9be1209504ef8cc1f9/intelmq/bots/parsers/github_feed/parser.py</a><br>
[4]: <a class="moz-txt-link-freetext"
href="https://github.com/certtools/intelmq/pull/1745"
moz-do-not-send="true">https://github.com/certtools/intelmq/pull/1745</a><br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
// Sebastian Wagner <a class="moz-txt-link-rfc2396E" href="mailto:wagner@cert.at" moz-do-not-send="true"><wagner@cert.at></a> - T: +43 1 5056416 7201
// CERT Austria - <a class="moz-txt-link-freetext" href="https://www.cert.at/" moz-do-not-send="true">https://www.cert.at/</a>
// Eine Initiative der nic.at GmbH - <a class="moz-txt-link-freetext" href="https://www.nic.at/" moz-do-not-send="true">https://www.nic.at/</a>
// Firmenbuchnummer 172568b, LG Salzburg</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
</body>
</html>