Why OT Incident Response is really different?
It’s not a secret. There are thousands of companies providing IT incident response, but handful of companies capable of handling OT incident response.
Some IT folks believe it’s mission impossible and they are not far from the truth, but the first step is to admit that OT incident response is quite a different animal.
IT solutions put in place in response to cybersecurity incidents don’t fit the industrial operational technology (OT) environment. It’s clear to the engineers involved in operations and production, but the IT crowd with a cybersecurity mindset often struggles to understand why. Running a response in OT requires dedicated skill sets. Classic models don’t fit, nor does taking a traditional forensic approach to the emergency. And all the fancy host-based IT technology for detecting and containing advanced threats is a dangerous stretch; it’s not suitable for an industrial environment – period.
There’s a host of differences to consider before writing a plan, building internal incident response (IR) capabilities, or hiring an external IR team during the contingency. A lesson you learn in the field running a threat management consulting business in a country with a manufacturing sector bombarded with cyber attacks for months.
There are plenty of good reasons; if you’re used to cybersecurity response concepts, the following points may provide useful insights, even if at first they may sound awkward.
01.
Different impact
Unfortunately, the consequences of a compromised OT network might be far worse than just the breach of the IT system in which it originated. A system shutdown can have a drastic impact on physical elements, with possible repercussions for safety and/or damage to the installation and environment.
There is good news: apart from sporadic cases of targeted attacks on a specific industry and technology, today’s attacks are often an amplification of IT breaches. A dedicated piece of malware to control operational aspects in critical infrastructure would be more devastating – as was the case for renowned attacks like the Stuxnet malware, the Sandworms campaign or the Ukrainian power grid attack.
Often a hacker barely realises that the domain or the host just compromised is part of the OT environment. He spreads malware and moves laterally using known techniques, easily leveraging poor segmentation and protection, weak and old operating systems and poorly managed access privileges.
02.
Different level of visibility
Cyber threat visibility during IR is the enabler of the many workarounds. It helps control the risks linked to going back into production in a contingency, often with the infected systems isolated.
Visibility and the ability to detect cyber-related threats is something that a cybersecurity-mature environment has permanently in place. If not there, OT responders should make it immediately available, part of the IR toolset, to give the team some level of comfort in ring-fencing networks. We really must monitor the OT for anomalies – new or known malicious activity (e.g. malware that keeps trying to beacon out, ransomware, any other form of existing or new compromise, a lateral move, etc.) but also identify deviations from the usual network behaviour. Communications and protocols in the ICS/SCADA environment tend to follow recurring patterns. That’s the principle used by industrial security systems based on AI learning and k-clustering for anomaly detection.
03.
Different threats & different tooling
The threats to an OT environment are different to those in an IT environment. The risks are much higher and the consequences of a successful compromise much more significant. The environments themselves are rife with older vulnerabilities which are for the most part long gone in stock standard IT environments.
OT environments use, besides things such as ‘normal’ computers, a lot of specialised equipment such as PLCs and HMIs. Collection tooling on this sort of equipment differs too, assuming it even exists. Collection off a PLC might be done with for instance the snap7 library, but requires the development of specialised collection tools to grab and analyse the ‘code blocks’ on the PLCs. The blocks that are recovered off the PLC will not have basic details such as variable names or other indications of what they do or are supposed to do. Analysis and reverse engineering of this sort of artefact is an altogether different proposition to what IT incident responders are used to.
04.
Different attackers
Attackers are different too, especially when it comes to their objectives. The ‘kill chain’ is likely to move from IT through to OT. Like in IT, attackers come in sophisticated and unsophisticated varieties.
In OT, even an unsophisticated attacker can do a lot of damage quickly. OT environments are typically vulnerable to relatively unsophisticated attacks, due to the immaturity of protocols, the use of old and outdated operating systems in the IT parts of the environment, a number of known vulnerabilities in the standard components of the operational environment, and the widespread use of insecure practices.
Sophisticated OT threat actors tend to focus on lasting physical damage, which, given the complexity of a typical OT environment, is the most achievable goal. The stuff of spy novels and movies, remote control of, say, a power station, is still somewhere in the future, but causing significant damage by, say, repeatedly and swiftly turning equipment on and off is not.
Conclusion
OT cyber incident response is something that you want to run with an experienced partner who genuinely understands your environment, and who won’t blindly start a trial-and-error approach based “classic” IT response – regardless of leading-edge technology and proven excellence. It’s something that requires proper tooling, processes, preparation, and coordination. And a long list of lessons learned on the basis of blood, sweat and tears in the OT field.
