In the current threat environment, rapid communication of pertinent threat information is the key to quickly detecting, responding and containing targeted attacks. Traditionally, threat information is harvested from hosts and networks, and then encoded in technology-specific configurations (e.g. Snort rules) or compiled into written reports that are passed on to humans for sharing. Even inside the same organization, the ability to share threat information may depend on overburdened staff reading paper reports and passing them on to others in the organization, with each transition increasing the time from when an attacker first strikes to when the organization reacts. By the time that many organizations begin to react, the information is outdated and the attackers have had plenty of time to infiltrate broadly across the network.
The key to increasing your ability to detect, respond and contain targeted attacks is a workflow and set of tools that allow threat information to be communicated across your enterprise at machine speed. OpenIOC is a format for recording, defining, and sharing information that allows your organization to accomplish this by sharing many different types of threat information both internally and externally in a machine-digestible format. OpenIOC is an open and flexible standard that can be modified on the fly as additional intelligence is gathered so that you can capture input from human subject matter experts and translate it into a format that can be used by various technologies to sweep your enterprise for signs that it has been compromised or is currently under attack to combat advanced targeted attacks in a manner that makes real remediation a realizable goal and enhances your security posture to combat future intrusions.
IOCs & OpenIOC
Indicators of Compromise (IOCs) are forensic artifacts of an intrusion that can be identified on a host or network. OpenIOC is a threat information sharing standard that allows you to logically group forensic artifacts, and communicate this information in a machine-readable format. The terms are sometimes used interchangeably, but an IOC (also sometimes just called an Indicator) is a logically grouped set of descriptive terms (each called an “Indicator Term”) about a specific threat while OpenIOC is the language used to describe those specific sets (e.g. an incident response team would use the OpenIOC format to write multiple IOCs during the course of responding to an incident).
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.
First, while the base schema used for OpenIOC is fairly small and lightweight, it can also be extended with indicator sets (also written in XML) that are supplied with the base schema. Additionally, custom indicators that suit a particular environment or threat that are not already described can be created and added if an organization needs them. Since OpenIOC is written in XML, it is also easy to create utilities to convert or parse OpenIOC to other formats that might contain information that could feed into or benefit from the threat information contained in an IOC.
Indicator Terms are the name of the specific types of data elements that are included in IOCs. Indicator Terms are usually organized in Indicator Term Documents, which are groupings of indicators inside an XML document. When creating an IOC, an investigator can use as many or as few terms from as many or as few sources as they like. An organization desiring to extend OpenIOC to include new types of elements that are unique to their enterprise or circumstances would create and host an Indicator Term Document that contained the new Indicator Terms they wished to make available for others to use.
The indicator terms that John Snow Labs currently provides for OpenIOC detail over 500 different types of evidence that can be gathered in an enterprise. These definitions are derived from years of practical experience in industry-leading incident response conducted by John Snow Labs. This combined with the flexible nature of OpenIOC, with nested logical structures, has led to much greater functionality than standard static signature-based technologies.
Indicators start with simply looking for signatures of specific artifacts. These can be the traditional forensic artifacts such as MD5 checksums, compile times, file size, name, path locations, registry keys, and so on. But they can also include items from more advanced forensic techniques, such as memory forensics, looking for artifacts that are much harder for attackers to change, or artifacts that attackers are more likely to recycle, such as running process components (including process handle names), the imports and exports used by an executable, and more. These can all be combined together in different logically grouped combinations, which are refined as the investigator learns more about the intrusion they are working on. Many different types of specific indicators can be combined together in one IOC, so that any of several sets of signatures of differing types of complexity could apply within one particular IOC. Going beyond making logically complex indicators, there are also additional ways to use IOCs than just a straight query against a host. IOCs can also be used with logical operators to exclude entire classes of the hosts or network being examined when querying against harvested data sets. Instead of looking for a specific file using terms that have to precisely match, IOCs can also be used to match all of the files that should be on a particular part of a system. An investigator would collect unfiltered data from systems, and then run an IOC against the collection to look for the files that stand out.
Simple use cases allow querying for forensic artifacts such as:
- Looking for a specific file by MD5 sum (hash), file name, size, create date, or other file attributes
- Looking for a specific entity in Memory (process information, running service information)
- Looking for a specific entry or set of entries in the Windows Registry
- Combining these together in various combinations to provide better matching and less false positives than searches for individual artifacts.
More complex use cases and techniques combine these together and allow even more depth:
- Instead of just looking for specific file artifacts in one part of the operating system or network, groups of artifacts can be combined together using the logic of OpenIOC to create a match on artifact groups that are common across families of malware or other intrusion tools (such as from the same authors or threat actor groups).
- Instead of hunting down a specific known bad file, an incident responder could make a whitelist of the files that were known to be in a directory, and then catch all the files that were NOT on that list, assuming the investigator had a full collection of what was on the system.