Hello,
my few cents - in Idea we adopted URN syntax (as hash is basically content based resource identifier, so the hash name can denote the namespace). Which happens to be the same, just with the colon separator:
sha256:79e18f...
Cheers -- Pavel Kácha
From: Thomas Hungenberg th@cert-bund.de, Date: Jan 02, 2017
Hi all,
SHA256 hashes are quite common today, so I'd suggest adding malware.hash.sha256 to the DHO in addition to md5 and sha1.
For other hashes that might be used, I like Dustins suggestion for the malware.hash.other rule.
- ThomasCERT-Bund Incident Response & Malware Analysis Team
On 02.01.2017 13:05, Dustin Demuth wrote:
Dear all,
happy new year!
Tomás, thanks for your E-Mail.
*Approaches**:*
- Rename the key 'malware.hash' to something like 'malware.hash.other' for
situations where we see a feed providing a different type of hash 2. Remove the key 'malware.hash' and keep with the other two ones 3. Remove the keys 'malware.hash.md5' and 'malware.hash.sha1' and only use the key 'malware.hash' for all types of hash. With this approach, if the feed provides a md5 and sha1 hashes in the same event, we will not be able to store both.
The chosen approach is the first one. If you have chance, please take some minutes to give your feedback in order to understand if everyone is comfortable with that.
I also prefer the first approach. Does anyone see a necessity or possibility how a "type annotation" could be added?
For instance as a "rule": "When writing to the 'malware.hash.other' field, the type of the hash must be written first, followed by one space and the hash"
Example: malware.hash.other = "SHA256 79e18f00a39f45ca2b87c9d2f27efaa08ef68701d01b2729450900a4651f81b9"
Best Regards Dustin
Intelmq-dev mailing list Intelmq-dev@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev
Intelmq-dev mailing list Intelmq-dev@lists.cert.at http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev