66a93156e0c7504ad83968ac Crowdstrike Solarwinds And Stuxnet Demonstrated Th

CrowdStrike, SolarWinds and Stuxnet demonstrated the cyber fragility of IT and OT systems

July 30, 2024
Three cyber incidents that affected multiple sectors and demonstrated cyber fragility
Whether targeted attacks such as Stuxnet or unintentional incidents like the recent CrowdStrike global event, the fragility of IT and OT systems has been demonstrated time and time again over the past 20 years. SolarWinds (a malicious attack) and CrowdStrike and McAfee “corrupt” cyber security upgrades (unintentional but damaging events) were cyber incidents that affected multiple sectors and demonstrated cyber fragility.
 

CrowdStrike

 
The recent CrowdStrike cyber incident caused global chaos throughout the IT and even OT community (although the effects on OT were less noticeable). IT systems operating in the OT process control environment such as Windows-based HMIs, Windows-based historians and Windows-based engineering workstations (e.g, FactoryTalk, Inductive Automation Ignition, etc.,) running CrowdStrike endpoint protection also experienced impacts due to the CrowdStrike event.
 
It’s generally recognized that a CrowdStrike testing failure was the root of the incident, but it’s worth remembering the importance of users as well as vendor testing. Where was the testing and validation of updates and change to the OT environment? If change management testing of the updates in a non-production environment were carried out as identified in ISA Technical Report ISA 62443-2-3 and ISA 62443-2-1, the issue would have been identified prior to release to the production environment.
 
The widespread nature of the event indicates that adequate testing in the OT environment was not being performed. OT organizations should have waited at least several days to ensure the update did not affect IT systems before implementing the upgrade in an OT environment. If the OT (and IT) community intends to utilize zero trust, the user can’t just trust the auto updates from the vendor like the recent one from CrowdStrike without doing confirmatory testing in a non-production environment. This is not the first time that inadequate testing of OT patches have impacted OT/control systems in production environments.
 

OT issues

 
Interdependencies are how one sector can affect other sectors, and they can lead to cyber fragility. For critical infrastructure, the classic interdependency is that all sectors depend on the electric power sector. Yet the electric power sector itself depends on water and telecommunications. But interdependencies extend to more than just sectors: they also include the vendors that provide products to many sectors. 
 
There are only a limited number of control system suppliers, and they supply all sectors globally. A control system cyber incident affecting any of these control system vendors could cause physical impacts cascading throughout multiple sectors with enduring, long-lasting effects, since equipment or facilities could be damaged. 
 

Stuxnet

 
Stuxnet (still not conclusively attributed to any specific actor) was the first cyberattack on a specific control system supplier that damaged equipment – in this case control system equipment made by Siemens. The second major control system cyberattack (this one attributed to Russia) targeted Triconex safety controllers – a Schneider product. Siemens provides a significant percentage of control systems globally, including in the U.S. Schneider (Triconex) supplies a significant percentage of safety controllers (as well as other control systems) globally, including in the U.S.
 
Stuxnet effectively was an attack against industrial infrastructures. The same Siemens PCS 7 PLCs were, and still are, used in electric, water, all forms of manufacturing, land and sea-based transportation, amusement park rides, defense, etc. Other than the “warhead” that was specifically targeting centrifuges, the rest of the Stuxnet attack could affect Siemens PCS7 PLCs used in every sector. In fact, Stuxnet did affect Siemens PLCs in other industries, but without damage. Stuxnet infections were found in Iran, Indonesia, India and elsewhere. (I was involved in the investigation of a Stuxnet case in the San Francisco Bay Area.)
 
The threat wasn’t confined to just one vendor’s products, either. Some of the techniques used against the Siemens PLCs apply to PLCs from other PLC vendors. As the president of ABB stated at an ABB Users Group meeting after Stuxnet was discovered, Stuxnet could have targeted ABB or any of the major control system suppliers.
 
In August 2008, Siemens held the Siemens Automation Summit in Chicago. The Idaho National Laboratory (INL) and Siemens delivered a presentation, “Control Systems Security Assessments.” The slides appropriately represented control systems used in every sector. (Unfortunately, the 2008 slides still represent the general state of control system cyber security today.) Control system security is not sector specific. Their connectivity also crosses geographic boundaries, and sectors are not operationally isolated. Interdependency of critical sectors can increase the overall appeal to a threat actor of using cyber as an attack tool. 
 
According to the 2008 Siemens/INL presentation, the complex nature of network-based control systems makes it very hard to distinguish between normal operational incidents and cyberattacks. This is why so few control system cyberattacks or incidents are identified as being cyber-related. 
 
Specifically, the INL/Siemens PCS 7 vulnerability assessment identified the following:
 
  • Passwords were hardcoded and couldn’t be changed. (The Siemens hardcoded passwords were found on a Russian website. Yet CISA stated the Iranian Unitronics hacks occurred because of user-configurable passwords.)
  • DMZ servers were found vulnerable – the goal is for the attacker to gain control of the servers inside the DMZ. Gaining control of servers inside the DMZ is a steppingstone for getting into the control systems. (Current recommendations are to have DMZs without necessarily assuring they are not cyber vulnerable.)
  • Attackers could gain unauthorized access to the Engineering Workstation – the goal is to gain interactive login to the PCS 7 Engineering Workstation. (Gaining access to any control system supplier’s Engineer Workstation provides this access.)
  • Attackers during their reconnaissance performed protocol fuzzing to find vulnerabilities – goal is to cause a communication disruption/overload. Creating a communication overload scenario is a common hacker method for attempting to take down a control system. (Protocol fuzzing is a common cyber security procedure used by control system vendors and security researchers.)
  • Attackers could obtain unauthorized configuration database access – goal is to modify configuration from the PCS 7 Engineering Workstation. The objectives would be to infiltrate the PCS 7 Engineering Workstation and modify the configuration. Modifying a controller configuration in the basic process control system (BPCS) and the Safety Integrated System (SIS) would be a significant security and safety breach yet, not be detected by the operator. (This also applies to other control system vendor’s systems.)
 
Russia, China and Iran learned from Stuxnet. Moreover, China and Iran use Siemens controllers in their own infrastructures. They’re familiar with these controllers and well-equipped to study them for exploitable vulnerabilities.
 

More than Siemens

 
Like the Siemens PCS 7’s, Unitronics controllers are “general purpose” PLCs. They’re used in multiple sectors, as are the other hardware-based PLC suppliers. Specifically, the Iranian cyberattacks against Unitronics controllers affected, water, food, and other industries. China has installed hardware backdoors in critical electric, port cranes, and other operational equipment used in infrastructures globally. 
 

Conclusions

 
Fifteen years ago, Stuxnet demonstrated that getting to the Engineers’ Workstations can cause devastating damage. Three years ago, SolarWinds showed that malware could be inserted into the update cycle. Two weeks ago, CrowdStrike demonstrated that Engineers’ Workstations are still cyber vulnerable to automatic updates that are fully trusted. It was evident that OT (and IT) didn’t follow their own change management policies by not testing the update before installing the automatic update. OT should have waited at least several days to ensure the update did not affect IT systems before implementing the upgrade in an OT environment.
 
If the OT and IT community want to utilize zero trust, you can’t automatically trust auto updates like CrowdStrike. The significant concentration of few IT and control system vendors increases cyber fragility whether from unintentional incidents or malicious cyberattacks. OT issues continue to receive less attention than IT. The recent CrowdStrike event has continued to place the focus on IT systems, and OT risks continue to be overlooked by the cyber defenders.

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.