Detecting and preventing potential cyberattack moves
Before most "final" attack success or failures, there is a whole series of often forgotten or unseen steps or plays that took place and users can take steps to prevent them from happening or, at the very least, slow them down.
Casual observers of sporting news can be forgiven for thinking that all sporting events are comprised of a handful of plays that result in a score. Similarly, security practitioners could be forgiven for thinking the same when it comes to news of industrial control system (ICS) security. In the spirit of ESPN, Trisis/Triton/Hatman (T/T/H) should be nominated as the play of the month.
This offensive event has been brilliantly dissected by experts and commented upon with frequency. Make no mistake, the work done by Mandiant and Dragos are quality efforts and the understanding of the incident critical to industrial defenders, it is indeed most newsworthy. But like Alabama’s wide left field goal attempt at 00:00 in the College Football National Championship regulation time, we should not forget there were nine other plays in that final drive resulting in varying success, and there was more of the game to come.
Before most "final" attack success or failures, there is a whole series of often forgotten or unseen steps or plays that took place. Reviews of attack campaigns normally reflect steps which can be roughly mapped to a process commonly called the Kill Chain, originally a military concept, applied to cyber intrusions by groups at Lockheed-Martin. A key lesson to take from the Kill Chain concept is attacks can be described as serial processes whose success is determined by the ability to progress through the seven phases to the final act on a targeted system.
The direct impact on the Triconex safety system would be the penultimate stage of the kill chain concept. The attacker had left evidence of a set of attack tools. Those tools had very specific targets, a class of Schneider Triconex models.
Ready for attack
Further evidence shows the attacker was able to execute preparation of the targeted Triconex successfully and thus ready for the final "attack" payload. What they were not successful at however was performing these final steps without detection—assuming detection was undesired.
Unlike our widely-reported college football game, however, there are a great many steps that are not widely known to the public. The lack of knowledge opens the possibility of potentially damaging or helpful speculation.
It may be obvious, but still worth stating, safety instrumentation systems (SIS) exist to protect other process systems. With that end in mind, I will propose that at some point up-stream, the attackers may have executed or planned to execute similar activity on the process systems which this SIS was meant to protect. Should similar situations arise within your environment, it would be be good to investigate the surrounding systems as well.
Kill chain evidence
Moving further up the kill chain there is likely to be evidence of outbound communications with external control sources, manipulated systems, and horizontal and vertical movement. This assumes this stage and prior stages required such activity. An internal and trusted source could bypass those steps depending on their knowledge of the targeted systems. Both an internal and external attack source is likely to leave artifacts associated with their activities. The necessary steps to investigate are not dissimilar in either case. In the case of T/T/H the workstation upstream was found to be compromised (as expected).
Working backward from that workstation, a diligent security forensics investigator can hopefully detect and recreate the rest of the kill chain and any potential branches to ancillary targets.
As a defender, finding this path represents a chance to learn the weaknesses of the system and apply the right defenses.
Remember, each step the attacker must take represents an opportunity for the defender to slow and perhaps stop the next attacker’s progress. These steps and plays are likely to be more generic and not nearly as exciting, but the opportunity to learn from them is equal to the ESPN play of the month.
Robert Albach is the senior product manager for security at Cisco. This content originally appeared on ISSSource.com. ISSSource is a CFE Media content partner. Edited by Chris Vavra, production editor, CFE Media, firstname.lastname@example.org.
See related stories from ISSSource linked below.
Original content can be found at www.isssource.com.