Understanding Indicators of Compromise (IOC) Part II


In the first installment of this blog series we discussed several principle ideas and concepts necessary for security analysts as they seek to master an understanding of indicators of compromise (IOC).  We discussed how IOCs relate to observables and how observables tie or relate to measurable events or stateful properties on a host.  We also discussed the importance of being able to identify, collect, record and note in a detailed manner IOCs as they are encountered in host and network based forensic investigations.  We also began discussing standards or taxonomic models that are making waves in the industry (rightly so) and left off preparing to discuss the three leading contenders in detail: CyBox, the OpenIOC initiative and IODEF (RFC5070) respectively.  We concluded the first installment in the series with a dialogue on CyBox and today we’ll discuss the OpenIOC initiative.

What is the OpenIOC Inititiative?

Like the CyBox program sponsored by MITRE, the OpenIOC initiative is a program designed to bring a degree of maturity, repeatability and order in a taxonomic fashion to the world of the security analyst and incident responder.  Its architects designed it in such a way so as to guarantee expeditious communication of information germane to quickly detecting, responding and containing targeted attacks.  Additionally, it ought to be noted that this is a vendor sponsored emerging standard.   The goal of which is to address current holes existing within enterprise organizations’ operational and threat mitigation models; specifically where threat intelligence sharing (in a machine readable format) is nonexistent.  This is not necessarily a bad thing.  This is neither the first nor will it be the last time that a standard has emerged from a vendor rather than a collective standards body such as the IETF for example.  For some organizations, vendor standards such as this one will be looked at with a quizzical eye.  For others, adoption will occur rapidly.  In many cases adoption or the lack thereof, will be dependent upon whether or not the organization in question has already made an investment in the underlying architecture that the standard was designed to compliment.  Either way, if one is investigation standards that address IOCs one must investigate the OpenIOC initiative.


The OpenIOC is an extensible XML schema that empowers analysts with the capability to achieve the following:

  1. Definition of the descriptive elements of a given threat – technical; non-technical, methodology or evidence of compromise

The standard was originally developed by a vendor to enhance and enable their products platform from a intelligence codification perspective during breach investigations.  This ‘standardization’ led to requests of the vendor through its user community to make the schema open and available to all who use the vendor’s platform and technology.  The vendor’s assertion is that traditional methods and means of identifying security breaches (and by proxy IOCs) is no longer effective and thus requires a new approach.  So far, I agree there are things that need to change and change for the better but let’s continue and see what else they say prior to commenting more on the merits or shortcomings of the proposed standard. They further assert that simple signatures are too easy for aggressors to evade and circumvent (something I agree with and that most of more savvy anti-malware / intrusion prevention organizations agree with as well).  Furthermore, they go on to assert that through the use of the framework described in the standard an organization will have the most advanced threat detection capability available.  A bold claim if I may so myself.   Not surprising given that this is a vendor sponsored standard (I can’t blame them in all honesty).

In order to gain access to the tools and schema written in XML as we described above, an potentially interested organization must download them from the vendor site.  At which point, providing the schema and the standard meet the needs of the organization, they are free to use them at their discretion.  The schema will enable the user to describe in detail, approximately 500 attributes that can be used to sleuth out attackers that have been vetted through the vendor’s experiences in incident response.

Net Effect

The OpenIOC is intriguing due to its highly extensible, well vetted for IOC development and customization of IOCs for organizations of varying size and industry vertical.  Potential downside being that it is a vendor sponsored and largely driven though it endorses a “community” driven look and feel.  For some organizations, this will be the ‘achilles heal’ in the selection process.

Coming Soon!

In the next installment we’ll discuss the IETF IODEF (aka RFC 5070) standard and what it offers in comparison to CyBox and the OpenIOC initiative.


No Comments