Indicator of Compromise by Kool-Aid Man
Mandiant recently announced OpenIOC, “an extensible XML schema that enables you to describe the technical characteristics that identify a known threat, an attacker’s methodology, or other evidence of compromise.” For example, you might have an IOC listing something as simple as a set of MD5 hashes and file names, or as complex as descriptors of the structure of a particular executable (PE file. The schema includes terms for network indicators as well, like URIs, IP addresses, and strings in network traffic.
Those of us who react to threats every day already know we need to get better at sharing threat intel and acting on it quickly. A number of industry and other organizations exist that help get these data out to folks who can use it, but often the intel comes in the form of a human-written. This means that systems can’t parse the data easily, and in fact the communication sometimes has significant ambiguity on it. When systems and tools can’t parse the data, not only does that introduce delays into the detection process, it also makes validation difficult. So sometimes we get notified of malware with the MD5 sum “d41d8cd98f00b204e9800998ecf8427e” (the hash of the zero or null string), or of “http://google.com?webhp&hl=en”. Both of these have happened to me in the last few months, and while that’s simple human error, allowing tools to do some basic sanity checks would help with this.
This, of course, shows up the weakness with OpenIOC: a classic chicken and egg problem. The XML files don’t serve much purpose until tools can read them, but at the moment the only tools that can read them come from Mandiant: their enterprise commercial product MIR and the free no-cost IOC Finder. (Note that, while OpenIOC is released under the Apache 2 license and therefore qualifies as ‘free software‘, the same does not hold true for IOC Finder.)
For OpenIOC to work well, we need more tools and responders to support it. That could start with truly free tools like Splunk, Sleuthkit, and Snort, but I’d like to see large commercial tools like Arcsight, EnCase, and Sourcefire incorporate it as well. This applies as much to producing IOCs as it does to consuming them, by the way: if FireEye’s malware detection and analysis tools could export an IOC, detection across the network would become much more straightforward. But Mandiant, as much as I love many of the people who work there, has sort of a NIH problem: they like to blaze new trails and do cool new stuff, but working with other vendors has always seemed to stymie them as far as I can tell. Hopefully Doug Wilson, the new point man on OpenIOC, can turn that around.
OpenIOC can solve a key problem, but we will see whether anybody actually uses it to do so.
