How ICS and OT targeted attacks became a serious threat
Industrial Control Systems (ICS) and Operation Technology (OT) form the foundation of critical infrastructure and are part of our everyday life. The technology behind ICS/OT was designed to last for 30 years, so let your mind wander back to the 1990s: it is hard to imagine that engineers of the time were thinking that ransomware could pose a serious threat to industrial systems. Thinking about industrial malware, such as Stuxnet that later destroyed nuclear centrifuges, was considered more of a science fiction topic than engineering. In fact, if we look at the timeline of computer viruses and worms from before the 1970s, we can only find one article from the genius polymath John von Neumann on the “Theory of self-reproducing automata”. Then, in the 1990s, we could count significant computer viruses using our fingers. The same is true today for tailored ICS malware.
Fast forward to 2007, when the Idaho National Laboratory researchers simulated a cyber-attack involving a diesel generator, protective relays, and circuit breakers as targets. The goal of the simulation was to prove that a cyber-attack could have a significant physical impact on components of the national electrical grid. Researchers assumed that an attacker could gain access to protective relays that control the circuit breakers of the generator, and by reprograming its protective relays, the researchers pushed the generator into an unstable state. The final result of their simulation was serious physical damage to the generator, finally destroying the generator itself, thus proving the frightening fragility of complex, digitally-interfaced industrial systems. View the simulation on youtube HERE.
Where there are challenges and opportunities, there is also an evil mind. It’s no wonder that we later witnessed Stuxnet incidents in 2010, the Ukraine blackout saga in 2015 and 2016, and later a targeted Triton malware attack against Saudi safety instrumented systems of petrochemical plants.
There were also numerous examples of classic IT malware/worm threats – such as WannaCry and NotPetya – finding their way into industrial control systems. These threats, however, were designed to infect as many systems as possible, without specific knowledge or techniques native to ICS environments. Even though they have caused significant financial cost, they had lower potential of apocalyptic damage: contrast this to ICS-tailored malware, which has profound knowledge of the industrial process and operations, and can cause specific disruption and destruction of equipment, and in the worst case, endanger human life.
In the “Mr. Robot” series, Elliot explains to blackmailers that hacking a prison isn’t as easy as many people think. Although a prison can be controlled by a vulnerable SCADA system, having physical access to parts of the system is often necessary to launch an attack. In the case of Mr. Robot, Elliot succeeds in opening prison doors and causes the disruption of the prison’s ICS for a short amount of time. However, the execution of a successful, repeatable, high-assurance attack is far more difficult to achieve. Stuxnet malware, for example, could be described as one of the most complex pieces of malware ever found. Ralf Langer, the author of “To Kill a Centrifuge, A Technical Analysis of What Stuxnet’s Creators Tried to Achieve” described Stuxnet in his TED talk in 2011 using the words: “The dropper of Stuxnet is complex and high-tech, and let me tell you this, its payload is rocket science”.
Even though hacking ICS components beyond repair is not technically easy, attacks are now quickly transitioning from Hollywood to reality, forcing ICS operators to address this transition and trends with the importance it deserves.
First steps towards ICS and OT security
The big challenge today is therefore to design and build ICS/OT defenses against current and upcoming malware, ransomware, and exploitation attacks tailored to and targeting our ICS/OT systems. One can start with an (easier) bottom-up approach, using a security framework such as the CIS’s Implementation Guide for Industrial Control Systems, and NIST’s Guide to Industrial Control Systems (ICS) Security. The CIS guide provides 20 basic security controls, and NIST includes guidance with 19 security controls, with a significant overlap between the two guides. While these security controls are common-sense, they still require a dedicated engineering team to implement and operate them: backing-up data, having an incident response team, controlling removable media, and so forth.
It is however best to take a top-down approach first: creating a proper system architecture (or migrating to one) that includes system segmentation. All miraculous security solutions, using current buzzwords of machine learning and AI, cannot help us if we have a flat OT network with several entry points from the Internet.
From architecture to specific controls
A popular model used to start building a reasonable ICS/OT architecture is the Purdue Model for Control Hierarchy, which promotes a logical segmentation framework with 5 zones. Zones between 0 and 2 are cell/area zones, zone 3 is the manufacturing zone, and beyond that, and including zone 4 is the enterprise zone. Often, organizations use the best practice of implementing a buffer demilitarized zone (DMZ) between the corporate network and the OT environment (i.e. between zones 3 and 4), similarly to what has been the best practice between the corporate IT environment and the Internet.
While the Purdue model gives structure and guidance to move towards a proper architecture, this is not an easy job for existing distributed systems with a lot of devices. A working architecture in place, however, allows for the implementation of many useful boundary controls, such as OT firewalls, which can significantly help in the prevention and containment, such as that of malware that spreads using an SMB vulnerability (read the related blog HERE) or script-kiddies targeting whatever happens to be vulnerable and exposed.
As the implementation of internal granular segmentation and access control (firewalls) is often difficult in existing ICS/OT systems, one can use an alternative approach and immensely improve the overall security posture using continuous network security monitoring. With continuous network security monitoring, one focuses efforts on the detection of suspicious activity, but with limited or no automatic prevention, which could prevent the normal flow of operations and stop the production process. After having mastered network security monitoring, the next logical step is to create an incident response capability, with a clearly defined incident response process using process flowcharts and playbooks, tested using real and tabletop exercises. Incident response, like any other complex human task, requires many repetitions to master to the point of automatic execution, such as the process of driving a car to work. The same should be true for incident response.
Early in the risk management and design process, you will also need to work on the topics of asset discovery, asset management, and asset analysis. If one doesn’t know what to protect, what is most valuable, and where it is located, building a cost-optimal solution in a timely manner is impossible. Using intrusive, IT-standard tools, such as active asset and vulnerability scanners, is typically frowned upon in ICS/OT environments, due to the significant risk of accidental denial-of-service. Fortunately, network monitoring approaches provide us with a reasonably simple and scalable method of dynamic asset discovery inside network-communicating ICS/OT systems.
A holy trinity for risk reduction
Building a proper architecture, identifying assets, and continuous network security monitoring, therefore, go hand in hand, and we would consider these three concepts as an excellent starting point for initial security operations to reduce risk. With proper network segmentation and equipment, network security monitoring is relatively easy to establish at network choke points where the majority of our network traffic flows.
On such chokepoints, one can create SPAN/mirror ports on a managed industrial switch to start monitoring ICS/OT traffic. The monitoring technology can then, in the initial observation, dynamically identify all assets seen inside network traffic. If your goal is just identifying your assets, a simple tool like Wireshark is enough. We should, however, have a more ambitious goal of continuous security monitoring: open-source tools, such as Snort, have a good set network traffic signatures to identify malicious traffic even in an ICS environment. Then, tuning those signatures to our environment to get the right balance of false-positive and true positive alerts is hard engineering work, that requires collaboration between OT and IT specialists. To extend the capability of monitoring even further, we can benefit from commercial tools that add the possibility of network behavior monitoring and anomaly-based detection, in addition to asset discovery, management, protocol dissection, and flow visualization.
People and process add to technology controls
As with IT security, ICS/OT risk management does not, and cannot only rely on technology, but also on people and security-focused processes. Today, building a dedicated ICS/OT security team can be a challenge, as there is a significant shortage of knowledgeable ICS/OT security experts. Organizations can currently address this by outsourcing the design, implementation, and partly the security operations process to a specialist, boutique vendors.
To create a reliable, transparent, and objective process, one can today incorporate threat modeling in the design, implementation, and operations process. Currently, the most notable is the MITRE ATT&CK framework and its cyber kill chain concept. Initially developed for IT environments, the MITRE ATT&CK was not applicable to industrial systems, which saw the development of the MITRE ATT&CK framework for ICS in 2019.
The MITRE ATT&CK framework for the ICS framework follows an attacker from initial access to the final goal of the attack and can be effectively used as a tool for predicting the next steps of the attackers. For example, MITRE ATT&CK for ICS focuses on tactics, techniques, and procedures (TTP) as seen in the wild. These TTPs are similar to bad behaviors, such as smoking or drinking, and the assumption behind the framework is that adversaries are having a hard time abandoning their behaviors. In this sense, monitoring for known techniques gives great value to our defense process. To give an example, the Program Download technique that is part of the “Persistence”, “Inhibit Response Function” and “Impair Process Control” tactics of MITRE ATT&CK for ICS is a worthy candidate to monitor using continuous network security monitoring. A program download can indicate a malicious change in the logic of a PLC, and if this change happens outside of known maintenance windows, we should seriously investigate this activity and respond to a potential incident.
In conclusion
Examining the ATT&CK for the ICS framework we can observe that the number of known adversaries, malware, and exploits is relatively low compared to the comparable IT framework. This observation confirms our statement that ICS hacking is not trivial, and not as widespread as IT-focused threats. However, ICS attacks are becoming a frightening reality that can impact our daily lives beyond financial cost. The attackers are getting bolder, and the attacks we have observed have displayed extremely advanced domain-knowledge. Our industrial technology won’t adapt to this new reality as fast as the attackers will. It’s high time that we put our attention on this matter.
