When I led incident response operations at Los Alamos National Laboratory, we subscribed to several ‘threat intelligence’ feeds: big commercial providers, secret-squirrel (theoretically) government only information, and other miscellaneous items. Almost without exception, if the feed did not provide reports that detailed how an attack or intrusion took place and oriented this within the broader scope of malicious activity, I took one simple action: I extracted whatever indicators existed in the report, retrieved samples, and did the work myself. As far as I’m concerned, this is the only ‘intelligence’ value to atomic, stand-alone ‘indicators of compromise’ (IOCs) – stepping stones that can be used to determine overall adversary tactics, techniques, and procedures (TTPs). Intelligence reporting should provide overarching behavioral information that covers not just observed attacks, but future activity – IOCs are just individual building blocks toward arriving at such a picture, and even then not necessarily the best building blocks, either. In the absence of the former, one can use the latter to build some sort of picture of malicious activity – but ultimately, intelligence must focus on the ‘big’ picture.
Presently, I find myself in another discussion over the value of IOCs – or more seriously, the value of threat intelligence work when IOCs are not provided (or simply do not effectively exist). To adequately address the concern, an overview of just what IOCs are and how they should be used is necessary.
IOCs at their simplest are just what the name implies: individual observables that indicate a known type of compromise. As such, they are atomic in nature (one piece of data in isolation), typically a hash value, domain name, or IP address. Occasionally IOCs will branch out into more ‘exotic’ territory and cover registry keys, mutex values, or user agent strings – but lack of standardization across security products, logs, and appliances makes these less useful (and less widely supported) than the three mentioned initially. Furthermore, the very name signifies a sign of compromise: observing the indicator within the environment is a sign that the environment is compromised by a known threat vector. In that respect, IOCs are very effective backward-looking tools to determine if a network was compromised by a known attack. But this implementation assumes a breach already occurred – as such, IOCs essentially ‘expire’ (in most cases) for future activity the very moment they are discovered, unless one is dealing with especially lazy actors.
Toward this end, IOCs can be invaluable triage items for incident response and forensic analysis. Identifying a known-bad hash value or network artifact in historical data allows responders to orient their activity to the perceived threat – so long as the IOC is actually ‘fleshed out’ with amplifying information about the specific threat, its behavior, and other pertinent details. Otherwise, an IOC simply communicates ‘something bad happened’.
IOCs are essentially information security ‘junk food’ – they make us think we’ve done something meaningful and satisfied our appetites, while leaving us malnourished and fundamentally needing more.
From the standpoint of threat intelligence work supporting network defense operations, IOCs are effectively useless and may even be harmful by building a false sense of security. Adopting the US Department of Defense Joint Publication 2-0 definition of intelligence, intelligence is “the product resulting from the collection, processing, integration, evaluation, analysis, and interpretation of available information concerning foreign nations, hostile or potentially hostile forces or elements, or areas of actual or potential operations.” A ‘product’ in this case is more than a single data point – in other words, an IOC. Instead, the product represents the distillation of raw data through structured information to complete, finalized intelligence: a holistic view of the activities or entities under consideration that provides context, nuance, and background to the events observed. One must build a picture of activity by analyzing data, sorting the resulting information, then orienting all of these observables to formulate actionable intelligence.
From the standpoint of network defense, intelligence fuels defensive planning and orients response. IOCs may provide a ‘jumping off’ point or a very quick and easy means of indicating (known) compromise – but such an approach fails with minimum change in operations on the part of the adversary. A defensive approach focusing on atomic observables of malicious activity will find itself forever fighting the ‘last war’ – this approach may work for low-level, commodity events where adversaries are expending minimum effort to achieve monetization. But even minimally-sophisticated threat actors can easily and cheaply defeat an IOC-based defense approach through packers, dynamic DNS or domain generation algorithms, or any number of other easily-implemented approaches.
Rather than focusing on atomic observables from infection events, intelligence professionals must identify and define the overall adversary behaviors and TTPs leveraged in the intrusion. While not providing something easily incorporated into (most) security tools as simple binary alerts, such in-depth reporting of adversary activity informs defenders on the actual methods employed in intrusion events – IOCs simply represent individual, specific instantiations of an attack methodology. Instead of targeting these specific instances, defenders must orient themselves to the underlying behaviors that give birth to these atomic observables. Although not ‘easy’ in the sense of ‘block this IP’ or ‘alert on this hash’, such an approach is far more robust in identifying adversary activities over time as fundamental adversary methodologies are more resistant to change than individual manifestations thereof. (On this, simply see David Bianco’s Pyramid of Pain.)
Ultimately, the goal of threat intelligence must be to prepare network defenders for the next attack. To adequately perform this task, threat intelligence must delve into the fundamental activities and TTPs displayed by threat actors to arrive at conceptions for how an adversary will act in future engagements. While this approach unfortunately does not lend itself well to the vast majority of current automated security solutions that act on atomic, IOC-like information, this approach is necessary to keep moving network defense forward against ever-evolving adversaries.
For those especially curious, I will present an in-depth discussion of this topic with respect to ICS environments at CS3STHLM in October. My purpose and intent is to move the industry beyond IOC ‘whack-a-mole’ and toward more robust, behavior-based detection and defense. While the latter is easily implemented in most environments, the latter – after sufficient effort is expended to create the proper logging and alerting frameworks – enables far more robust and sustainable network security monitoring and defense.
