<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear Marius,</p>
<div class="moz-cite-prefix">On 2/22/21 9:46 PM, Marius Urkis wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e4c9ff1c-9e1e-c378-33fa-9aec4a689715@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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>
</blockquote>
In IntelMQ most usages of "malware" were actually
"malware-distribution", e.g. websites spreading malware files. Some
other usages were <span class="blob-code-inner blob-code-marker"
data-code-marker="+"><span class="pl-s"><span class="x x-first
x-last">infected-system. </span></span></span><br>
<span class="blob-code-inner blob-code-marker" data-code-marker="+"><span
class="pl-s"><span class="x x-first x-last">For a full diff
<a class="moz-txt-link-freetext" href="https://github.com/certtools/intelmq/compare/650a450...2588a284e31582e6cbfa72aac483dd17198527ce">https://github.com/certtools/intelmq/compare/650a450...2588a284e31582e6cbfa72aac483dd17198527ce</a>
should give a good but very long overview.<br>
</span></span></span>
<blockquote type="cite"
cite="mid:e4c9ff1c-9e1e-c378-33fa-9aec4a689715@gmail.com">
<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>
</blockquote>
<p>Yes. The question is, how much do we want to support such
use-cases in IntelMQ. AFAIK the primary use-case of IntelMQ is
incident handling, not processing malware files/hashes. The RSIT
does not give us the means to classify malware, independent of
which tool is used. But this does not mean, that processing
malware files/hashes is not possible or allowed with IntelMQ. IMO
it's totally legit to process that data with IntelMQ, but it's not
the the tool's primary intent. A quick view over IntelMQ's bots
and feeds shows, that only the two cases I mentioned in my first
mail are not related to incidents (the GitHub feed and FireEye).</p>
<p>best regards<br>
Sebastian<br>
</p>
<blockquote type="cite"
cite="mid:e4c9ff1c-9e1e-c378-33fa-9aec4a689715@gmail.com">
<p> </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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<pre class="moz-signature" cols="72">--
// Sebastian Wagner <a class="moz-txt-link-rfc2396E" href="mailto:wagner@cert.at"><wagner@cert.at></a> - T: +43 1 5056416 7201
// CERT Austria - <a class="moz-txt-link-freetext" href="https://www.cert.at/">https://www.cert.at/</a>
// Eine Initiative der nic.at GmbH - <a class="moz-txt-link-freetext" href="https://www.nic.at/">https://www.nic.at/</a>
// Firmenbuchnummer 172568b, LG Salzburg</pre>
</body>
</html>