Indicator of Compromise is something that we often hear in these days. I think it is a buzz word like a cloud computing terminology in IT industry. In Incident Response area, IOC is already introduced in 2007. Based on Lenny Zeltser blog http://blog.zeltser.com/post/44795789779/indicators-of-compromise-entering-the-mainstream IOC first introduced by Mandiant. Kriss Kendall paper http://www.blackhat.com/presentations/bh-dc-07/Kendall_McMillan/Paper/bh-dc-07-Kendall_McMillan-WP.pdf mention about IOC in part of his reversing malware paper. Now, IOC terminology is well known in IT security area, especially in DFIR (Digital Forensic and Incident Response).
An easy way to understand about IOC is like this : you know that there is an incident, you know the behavior, how they act, what change being made, and then you make a simple standard to detect their presence. As simple like that. In a technical area, IOC is a forensic artifact from an intrusion that can be identified on a host or a network. The attribute that can be used in IOC document is : AP Address / Domain Name, URL, hash, File Mutex, HTTP User Agent, X-Mailer, etc.
In this APT-era (I know this is bullshit), intelligence threat sharing become a serious thing that should be implemented in each environment / organization. IOC is one important component in intelligence threat sharing. Why do we care about intelligence threat sharing? Because it is faster and easier way to detect and respond immediately the intrusion in our organization. It is also important for every individual or organization to build a trust relationship.
Unfortunately, there is no standard format to describe IOCs attribute. There are several organization / company that create their IOCs standard. It is naive, that in this intelligence threat sharing era, we dont even have a clear standard. And how do we share our IOCs if there is no clear standard format data?
The most common standard that being used in large organization is OpenIOC http://openioc.org/. OpenIOC is a framework to describe the IOC that was developed by Mandiant. OpenIOC is written in XML (Extensible Markup Language). XML provides a well-recognized standard format of encoding data into a machine readable format that is used in many different standardized methods of communicating data. The use of XML provides several benefits for consumers of OpenIOC.
The second IOC standard is come from MITRE. They develop a IOC standard that called as CyBox http://cybox.mitre.org/. From the website : CybOX is a standardized schema for the specification, capture, characterization, and communication of events or stateful properties that are observable in the operational domain. A wide variety of high-level cyber security use cases rely on such information including: event management/logging, malware characterization, intrusion detection, incident response/management, attack pattern characterization, etc. CybOX provides a common mechanism (structure and content) for addressing cyber observables across and among this full range of use cases improving consistency, efficiency, interoperability, and overall situational awareness. CyBox allows the incident responder use this standard in these following area :
- Threat assessment and characterization (detailed attack patterns)
- Malware characterization
- Operational event management Logging
- Cyber situational awareness
- Incident response
- Forensics
- ETC.
In my opinion, CyBox can not stand alone. CyBox need help from another MITRE standard (STIX, TAXII, CAPEC, MAEC) to describe a threat security assesment in identifying the incident and intrusion. It is lookalike there is some overlap attribute in MITRE standard. It is difficult for me to determine wheteher this attribute belongs to CyBOX, STIX, TAXII, CAPEC or MAEC.
Another IOC standard format is IODEF. https://www.ietf.org/rfc/rfc5070.txt. The IODEF is a standing IETF RFC (RFC 5070) that is designed to address and define a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. The basic premise is that organizations need help from third parties to mitigate malicious or nefarious activity targeting their hosts and networks. The architects of the Incident Object Description Exchange Format (IODEF) are a format that offers the users a means by which to represent computer security information as described above. It is communicated via an XML schema that conveys incident information across administrative domains amongst parties that have an operational responsibility for both remediation and notification of their user population.
The conclusion about Indicator of Compromise : there are several standard that may applied in your organization. You can choose wisely which one is the best to be implemented. In my personal opinion, it is difficult to apply the intelligence threat sharing, if everyone has a different standard. OpenIOC, CyBox, and IODEF, is just the big three standard format for IOC. When you talk about spesific vendor, they may use their own IOC standard. Maybe law of the jungle will prevail, who is the most widely used, then they will be the winner.
PS : If you want to compare one by one, about the pros and the cons about the big three IOC standard (OpenIOC, CyBox, and IODEF), you can read the detail in this RSA Conference slide : http://www.rsaconference.com/writable/presentations/file_upload/dsp-w25a.pdf
Edit :
If you want to create a sample of IoC, here is the recommended reading list for you:
http://www.darkreading.com/attacks-breaches/top-15-indicators-of-compromise/240162469
Source :
https://blogs.rsa.com/understanding-indicators-of-compromise-ioc-part-i/
https://blogs.rsa.com/understanding-indicators-of-compromise-ioc-part-ii/
https://blogs.rsa.com/understanding-indicators-of-compromise-ioc-part-iii/
]]>
