The real value of an IOC?

Published: 2018-04-24
Last Updated: 2018-04-24 06:42:38 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

When a new malware sample is analysed by a security researcher, details are usually posted online with details of the behaviour and, based on this, a list of IOCs or “Indicators of Compromise” is published. Those indicators are pieces of technical information that, if detected on your network or hosts, may indicate that it has been compromised or at least something suspicious occurred. Classic IOCs are domain names, IP addresses, hashes (MD5, SHA1, SHA256), email addresses, ports, URLs, filenames, processes, muteness, services, etc… But they can also be non-IT related stuff like a bank account, a Bitcoin wallet or a phone number even… the name of a person.

I would like to insist on the verb “may indicate” in the sentence above. Indeed, for some time, we are facing what I'm calling a race of IOCs. For many commercial organizations, it became mandatory to have a presence online and to communicate about new threats as much as possible. This lead to an increase in the amount of (good) IOCs generated. Let’s take an example with my own MISP[1] instance (“Malware Information Sharing Platform”) which is a tool dedicated to the processing of indicators of compromise. I had a quick look at the amount of IOCs stored in my database.

The total of IOCs is 1.052.922. Here is an overview of IOCs received for the last 12 months. Even, if there is a decrease of IOCs for a few months, I'm still getting thousands of new records monthly:

The goal of such database is to be used to perform searches (or better, retro-searches) operations with other tools like an IDS or a SIEM. For example, I’m exporting IOCs from my MISP into my OSSEC[2], my IDS[3] and Splunk. How to handle a still growing number of IOCs? The best situation is always to process all of them but, from a technical point of view, it is impossible. How to optimise them?

The first idea is to process IOCs relevant to your infrastructure. Like an IDS where some rules can be disabled (example: why to enable FTP rules if you don’t use the FTP protocol?), you can disable IOCs related to technologies that you don’t use. Always a little bit risky though. Basically, an IOC out of its context is less useful and today most of them are. Do you need IOCs related to JAVA RaT if you don’t have JAVA installed on your endpoints?

You can also work with "tags" or "label" to increase the value of IOCs. Here is an idea how they are handled by one of my customers. IOCs are exported from MISCP if:

  • They are tagged as TLP:RED (IOCs tagged TLP:RED by peers are very important in the business context of my customer)
  • They have been created during the last 30 days (to cover recent threats)
  • They are tagged as relevant by the on-duty Security Analyst (an example of a business targeted attack)

The last point implies a manual review of the newly received events in MISP. The Security Analyst, based on his/her knowledge, the current threats and his understanding of the organization business decides if a new event and its IOCs are relevant or now.

I like the approach of the incident handling tool TheHive[4] that uses two different names: When a security analyst is working on a case, he/she creates “observables” (the name speaks by itself) and, when investigations are completed, some observables can be converted to “IOC” and exported to a MISP event. Keep in mind, an IP address alone does not mean a lot but if you can link it to a domain or a hash, you increase your chances to detect malicious activities or compromisations.

And you? How do you optimise your IOCs? Feel free to share your thoughts.

[1] http://www.misp-project.org/
[2] https://isc.sans.edu/forums/diary/Hunting+for+Malicious+Files+with+MISP+OSSEC/21251/
[3] https://isc.sans.edu/forums/diary/Automatic+Hunting+for+Malicious+Files+Crossing+your+Network/23473/
[4] https://thehive-project.org/

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

Keywords:
0 comment(s)

Comments


Diary Archives