Open platramos opened 8 years ago
There are a few different formats. STIX and OpenIOC are both XML based (which is very verbose, and wasteful for a blockchain.
http://www.forensicswiki.org/wiki/Cyber_Threat_Intelligence Should we consider own own data format and provide STIX/OpenIOC transforms within the client?
https://www.fireeye.com/blog/threat-research/2013/10/openioc-basics.html is a nice intro to IOC's in general (Fireeye is owned by Mandiant, the OpenIOC maintainer) They have also published a IOC writer module in python https://github.com/mandiant/ioc_writer
I am thinking we should really go with a native blockchain format, as the standards appear to be based on XML which adds a lot of overhead for the space conscious.
An IOC is made up of three main parts: IOC metadata, references and the definition.
- Metadata:
- * Name: Must be free text, consider UTF8 with a max size. Compressed?
- * * Author: public key reference, or on-chain registration TX
- * * #ID: maybe some hash of some fields
- * * Create Date: 64-bit date integer. I would suggest we look at the bitcoin encoding method here as it provides both 'chain length' and 'unix date' in the same integer range. Should this be per TX or per block (bitcoin uses per block).
- * * Expiry Date: 64-bit date integer. Could be block height or unix date.
- * Description: Brotli compressed UTF-8 text of n letters.
- Ref+href (all references can have a type, references and an href).
- * Category:
- * * Grade:
- * * ThreatGroup:
- * * Report:
- * * Comment:
I would consider rolling a json encoded dictionary into a brotli compressed blob for this.
OR
OR AND
DestIP(c) = 8.8.8.8 DestIP(c) = 8.8.8.4 SHA256(f) = xy FileSize(f) = 123 bytes
Would indicate that a valid IOC detection would occur if:
The file made a connection or 8.8.8.8 or 8.8.8.4, or its file hash was zy and size was 123 bytes
http://www.openioc.org/