A previous post on indicators and network defense generated quite a bit of attention, as well as some requests for follow-up items. One item in particular was very interesting to me: comparing an actionable, effective threat intelligence report not relying on indicators with a “bad” example. I think this idea is interesting, but somewhat dangerous simply because I don’t want to be the person to crap on another’s work, which is almost certainly how such an exercise will play out. Instead of this requested approach, instead I would like to address a practical, relevant example of the behavioral vs. indicator argument playing out in real time in light of recent work I’ve done at Dragos on the XENOTIME activity group.
In this specific case, and going back to the original public reporting I co-authored, I’ve heard that an “IOC-less” approach for TRISIS and XENOTIME in general represents one of several factors: failing to adequately document or support work; potentially masking a lack of information in public reporting; and leaving defenders in the lurch by not providing all relevant, potentially actionable information.
I will spend most of our remaining time on the last point, but I’d like to quickly address the other two before moving on. The first, in terms of “showing one’s work”, has some merit – but only depending on the audience. If your intention is to inform operations personnel, and not the community of threat intelligence researchers and reverse engineers, providing sample hashes seems irrelevant and unnecessary, especially if you already think such IOCs are effectively useless for other organizations from the start. The second is just a waste of time, and I’ll let my colleagues Jimmy Wylie and Reid Wightman dispel this with their in-depth walk-through of the TRISIS framework at RECON.
Getting back on track, as a professional in this field one of the most damning and hurtful comments that I can hear is that I am doing less than my absolute best in arming and equipping defenders to respond to malicious events. Toward that end, the notion that omitting IOCs from a report – whether public or private – may actively harm or disadvantage defenders really hits home, but in responding to this assertion I feel we can arrive at an even better understanding of the limitations of an IOC approach especially in an environment such as ICS defense.
First, some preliminaries to ground our discussion. ICS environments, although generally limited to a handful of common vendors and general operational purposes (refine oil, generate power, manufacture widgets, etc.) are ultimately very unique and beautiful snowflakes. Whereas any corporate network will exhibit the same Windows monoculture with a smattering of Linux and maybe OSX/macOS, an ICS environment will feature some generic Windows gear (of varying vintages) as well as a host of specialized devices (the true and ultimate target of any disruptive attack) that feature far less commonality. Even equipment from the same vendor – and Schneider Electric’s Triconex system, the target of TRISIS, is an excellent example with its switch from a PowerPC to an ARM platform – can be drastically different across versions or even firmware for the same product line. Coupled with vendor-proprietary protocols and site-specific installation features, and ICS attacks begin to look fairly unique. While the general, broad brush-strokes of an attack will be similar (a very important point that we will return to), the very specific technical details – including information that would pass through as a file hash for a piece of malware – are in many cases not relevant to environments outside of the original target.
Thus, in the case of TRISIS, the malware in question – while featuring many items that could be re-used in a new attack provided one were able and willing to reverse and analyze a different variant of the target system – simply was not scalable or even relevant beyond the specific target equipment in the event. As a result, unless your organization was running the same Triconex equipment targeted in the original TRISIS event, the hashes themselves (and similar IOCs) are meaningless as the malware simply isn’t applicable.
A more important point worth emphasizing is that any code running on a safety instrumented system (SIS) in an ICS environment should be alarming and potentially devastating unless part of a known, planned activity. By focusing defense at this “last line” – code execution on the SIS device – defenders have yielded much in the way of key terrain and initiative to the adversary. However, by adopting a more strategic, holistic approach to ICS intrusions in general and SIS compromise specifically, defenders can move “ahead of the curve” to detect or curtail attacks before reaching this final, critical stage.
At this point, we’ve moved well beyond the realm of atomic IOCs and reached the terrain of adversary behaviors discussed previously. Rather than attempting to focus on the “last line of defense” – immediate communications to the SIS or similarly vital devices – by looking for signs of malicious activity in communication or strange binaries in transit direct to the final target, defenders must focus on all prior stages to successful attack execution. In this manner, defenders can regain initiative normally ceded to the adversary and potentially reshape the intrusion scenario to match defender advantages. Of the latter, those that stand out the most are knowledge of the network’s design, architecture, functional necessities, and most importantly physical and logical choke points. The latter especially become incredibly important as critical gateways where proper sensing and monitoring combined with an understanding of likely or required adversary actions yields the potential to detect or block attacks long before the final stage of ICS impact.
From the perspective of a SIS intrusion, the following items must all be met for an interactive, operator-controlled intrusion:
- IT network compromised.
- Pivot point from IT to ICS identified and compromised.
- Beach head created in ICS environment.
- ICS environment enumerated and critical system locations and system types (vendor, hardware, firmware, software) identified.
- Adversary tools or attack package brought into the ICS network from adversary-owned infrastructure.
- Attack package maneuvered to delivery point against critical system components.
- Attack executed.
At any of the above stages, defenders have an opportunity to identify malicious activity and initiate appropriate response procedures. By identifying the necessary prerequisites to the truly frightening scenario – all the way down at number 7 – defenders can push out potential disruptive effects away from operational pain points to areas more amenable to recovery. Simply grasping what movement between the broadly-defined stages articulated above, 1-7, provides defenders with a list of pivot points between different activity types, whether distinguished by network location or behavior type.
Essentially, each transition between logical attack stages becomes a logical “choke point” for identifying and potentially mitigating an intrusion scenario. Articulating what “malicious” looks like in activity moving between these stages is a vital task, and understanding fundamental attacker methodologies and adversary operational necessities will enable defenders to accurately perform this task. In doing so, entire categories of malicious activity can be identified: data thieves and ICS attackers may have ultimately different goals, but both need to pivot through the target network, ensure persistence on at least some nodes, and maintain some degree of command and control. Focusing on these dependencies, how they manifest themselves at different layers of network activity, and differentiating from merely “normal” or “anomalous” arms defenders with the capability to respond to early-stage intrusions for maximal effect.
One drawback to this approach as outlined above is clarity in adversary purpose. In the case of a SIS attack, if defenders are able to identify and mitigate an intrusion at the IT-ICS pivot point, the defenders will never know that the attack was designed to produce a disruptive, safety-impacting event. Essentially, the earlier an attack is mitigated, the less detail defenders have on what potential future stages or targets of the attack would be. While as a threat intelligence specialist this does concern me to a degree, putting on my incident response hat such considerations are ultimately irrelevant. The goal is to identify the attacker as soon as possible, kick them out, and ensure rapid recovery to safe, secure system operations. Anything after that is a bonus, and not a priority.
ICS network defense provides a number of distinct advantages to defenders, primarily by introducing additional stages to any attack where defenders have the option to implement more robust monitoring and detection schema. Of course, to truly take advantage of this conceptual benefit, many decisions are most effective when made at the very start of a network’s existence: designing network choke points at the architectural stage then ensuring continued adherence throughout the network’s lifecycle. But even in already-existing environments, simply identifying critical resources and shaping defense around them – knowing full well that such items must be compromised or otherwise interacted with by an adversary – still provides some benefit and the opportunity to add additional defensive mechanisms.
Adopting a strategic approach focusing on adversary behaviors and, more importantly, adversary requirements enables defenders to shift the narrative of intrusion scenarios in their favor. By implementing network design, monitoring schema, and overall visibility to focus on critical adversary requirements, defenders can ensnare attackers in the course of operations, and ensure detection by layering these “choke points” throughout the network.
For those interested, this approach of applying an adversary-focused, behavior-dependent, strategic approach to ICS network defense will be the focus of my class at CS3STHLM in Stockholm, Sweden in October 2018.
