In the security management of Industrial Control Systems (ICS), security management is typically divided into three main areas: the security of physical devices, IT security, and operational security (factory safety and system integrity).
Nowadays, in the security management of Industrial Control Systems (ICS), information technology (IT) security testing has become increasingly automated. Although we are still far from accomplishing all security tasks through this automation, this trend is inevitable. However, it has also brought about a problem: security management is becoming increasingly complex. For example, many proprietary terms have been invented, such as SCADA, ICS, OT, DCS… This plethora of terminology often leads to confusion, making it more difficult for facility operators to detect and respond to security incidents.
Moreover, modern operations often span complex IT (Information Technology) and OT (Operational Technology) infrastructures, typically covering thousands of devices, which are increasingly interconnected through the Industrial Internet of Things (IIoT). This presents new challenges for industrial environment security: making security threats to industrial control systems harder to detect, investigate, and remediate.
In some existing industrial operations, the two are often segregated, with IT security being the responsibility of the network operations team, while OT security is managed by operators or business personnel. Furthermore, security threats aimed at OT systems are often overlooked. This is not only due to the significant differences in security procedures and technical applications between OT and IT systems but also because each vertical industry has considerable variations in business characteristics. In reality, the issues faced by OT systems are equally severe as those faced by IT systems.
The following are important terms commonly mentioned in Industrial Control Systems:
· IT: Information Technology, the hardware and software used for storing, retrieving, or transmitting information;
· OT: Operational Technology, the hardware and software that monitor or trigger changes in physical devices, referring to components of ICS systems in this article;
· WAN: Wide Area Network; this is a network primarily used for computer networks that extends over large geographical areas;
· CNI: Critical National Infrastructure, systems (including IT and OT) and assets vital to societal functions;
· ICS: Industrial Control Systems, which are computer systems that control complex and often hazardous physical processes, subdivided into two distinct categories—Supervisory Control and Data Acquisition (SCADA) systems and Distributed Control Systems (DCS);
· SCADA: Supervisory Control and Data Acquisition systems, which are types of ICS that span wide area networks (WAN), often mistakenly used as a term to refer to all types of ICS;
· DCS: Distributed Control Systems, which are types of ICS that do not involve WAN;
· HMI: Human-Machine Interface, a user interface that allows people to interact with devices or systems, a commonly used term for ICS interfaces;
· PLC: Programmable Logic Controller, these are small computers used in OT that utilize highly specialized operating systems to process events in real time;
· IIoT: Industrial Internet of Things, a term often used to refer to the trend of connecting OT to the Internet;
Currently, the OT involved in all ICS systems is often quite old, and traditional IT-based network security methods do not ensure the security of OT.
As a result, there is growing attention to protecting these OT systems, but this is often done by simply adjusting or repurposing IT-based security testing tools, techniques, and methods. This article will discuss the problems inherent in this approach and the changes that need to be made.
History of OT Security Incidents
Security incidents affecting OT (mainly in ICS systems), whether intentional or accidental, can occur, albeit not very frequently. However, when they do happen, the losses to businesses can be substantial. For example, Kaspersky Lab’s white paper “2017 Industrial Cybersecurity Status” estimated the average cumulative cost for businesses at $347,603 (approximately £265,881), which includes the consequences of incidents and the necessary remediation measures. Over half of the surveyed companies admitted to experiencing at least one attack incident in the past twelve months. In contrast, a follow-up survey in 2018 found that less than half of the participating companies acknowledged having experienced security incidents, indicating that the security of OT systems is improving. However, the cost of losses remains high, and these costs are not solely financial.
The security incidents referred to in this article include the following three major categories:
1. Actions taken by external attackers to deliberately circumvent security measures or disrupt the normal operation of systems;
2. Malicious actions by employees intended to circumvent security measures or disrupt the normal operation of systems;
3. Incidents caused by accidental actions of employees that disrupt the normal operation of systems;
It is worth noting that it is currently challenging to determine the exact number of attacks on ICS systems. This is because only 30% of companies are mandated to report security incidents to regulatory authorities, although this number is expected to increase with the implementation of GDPR regulations. Even with limited data, we can list some significant security incidents:
The 2004 Sterigenics International Company medical device sterilization incident, where an explosion occurred when maintenance personnel bypassed computer-controlled safeguards by entering a password, leading to the sterilization cabinet door opening prematurely. This caused an explosive mixture containing Ethylene Oxide (EO) to be released into the catalytic oxidizer (which had an open flame), igniting the EO and resulting in a violent explosion. The aftermath resulted in over $27 million in property damage.
The 2010 Stuxnet worm incident in Iran, where in September 2010, Iran reported that some employees’ computers at the Bushehr nuclear power plant were infected with a supercomputer worm called “Stuxnet.” This worm could silently lurk and propagate, damaging specific Siemens industrial computers.
The worm was designed to target specific ICS systems and disrupt PLCs. Initially, Stuxnet quietly lurked on ordinary personal computers, silently infecting USB drives until one day an infected USB drive was plugged into a highly confidential, internet-isolated computer at the nuclear facility, at which point it suddenly activated and quickly infected the entire local area network.
Stuxnet exploited previously undiscovered Microsoft Windows software vulnerabilities, known as “0 day” vulnerabilities, with destructive power that astonished antivirus researchers. According to The New York Times, the Stuxnet worm was developed in 2008 through a collaboration between U.S. and Israeli intelligence agencies and was officially deployed in Iran in 2010, ultimately causing about 1,000 of the 8,000 centrifuges at Iran’s Natanz nuclear facility to malfunction. The International Atomic Energy Agency stated that Iran suspended its uranium enrichment activities in mid-November 2010.
In 2014, a steel mill in Germany suffered a sophisticated persistent threat (APT) attack. Attackers used spear-phishing emails and social engineering techniques to gain access to the mill’s office network. They then used this network to infiltrate the production network of the steel mill. The attackers’ actions forced the control components of the industrial control system and the entire production line to stop operating, resulting in significant damage due to the abnormal shutdown of the steel furnace. Security researchers indicated that the attackers might have directly connected through the human-machine interface or other control systems to cause damage to the factory.
The 2015 Ukraine blackout incident, where an attack on Ukraine’s SCADA system resulted in approximately 230,000 people losing power for several hours.
The 2017 WannaCry incident, although no reports were released regarding the impact on ICS systems, some ICS systems appeared to have gone offline due to incompatibility with Windows systems connected to OT.
The aforementioned incidents illustrate the severe consequences of attacks on OT systems and highlight the importance of protecting OT systems more than other systems.
However, IT and OT are indeed different.
IT and OT are fundamentally different!
IT environments are dynamic; for instance, IT systems require frequent repairs, upgrades, and replacements. IT staff are very concerned about data confidentiality, integrity, and availability (known as the CIA triad). They are well aware of the latest IT trends and threats. However, IT personnel are often not familiar with OT networks or industrial control systems (ICS), and very few of them venture into factory environments.
In contrast, OT personnel work in an operational environment focused on stability, safety, and reliability. Their work involves maintaining the stability of complex sensitive environments, such as refineries, chemical plants, and water treatment facilities, which are filled with legacy systems from decades ago that have not been updated for years. Their motto is: “If it works, don’t touch it.”
IT and OT use different technologies
Essentially, IT personnel are accustomed to using the latest and greatest hardware and software, including the best security technologies to protect their networks. They tend to spend most of their time fixing, upgrading, and replacing systems.
Meanwhile, OT personnel are accustomed to working with legacy technologies, many of which predate the internet era. These systems often use proprietary network protocols and lack basic security controls such as authentication or encryption, and there are often no event logs or audit trails. Consequently, event detection and response in OT environments are vastly different from those in IT environments.
What are the differences between IT and OT?
A common approach to assessing IT system security is to acknowledge that it is data-centric, with the critical requirements being the confidentiality, integrity, and availability of the data being processed (C, I, and A).
In addition to these key fundamental concepts, the presentation by Byres, Lissimore, and Kube also lists the differences between IT and OT from a security testing perspective:
1. Different performance requirements;
2. Different reliability requirements;
3. “Anomalous” operating systems (OS) and applications;
4. Different security architectures;
5. Different risk management objectives;
This difference in priorities between IT and OT systems is the core reason why IT security testing methods, common findings, and common recommendations cannot simply be adjusted and reused in the OT space. This results from a lack of understanding of OT in the entire network industry beyond the product assessment realm. The increasingly close connection between IT and OT has led to a perception that OT is an extension of IT, but this is not the case. Furthermore, despite a recent trend to enhance the security of such systems, many IT security professionals have had little or no exposure to OT systems.
To further illustrate the complexity of the issues surrounding traditional IT security measures and testing methods, let us look at some examples of IT security testing and consider their implications for OT systems.
Network Scanning
Using tools like NMAP and Nessus for automated scanning is a common activity in the infrastructure testing process of IT systems, typically involving sending packets to identify the logical network layout or check if individual computers have known vulnerabilities. Sometimes such scanning may be restricted as it can lead to unexpected behaviors, such as causing computers to shut down, but this is very rare in IT.
In contrast, such activities are more likely to lead to unexpected results in OT and can have far worse consequences. The most common outcome is that the scanned device may shut down or become unresponsive due to some unexpected input. Such activities can lead to unintended mechanical reactions, such as a robotic arm suddenly moving in a manufacturing plant causing physical damage to surrounding machinery or injuring personnel working in that area.
Patching
Patching is one of the most common remediation methods on IT systems undergoing security reviews and is a hot topic in the security industry. Operating systems and applications installed on them often become targets for attackers and security experts alike, with attackers seeking ways to gain access to systems while security experts look for vulnerabilities that need to be fixed. When a vulnerability is discovered and reported, the developers of the operating system or software typically issue patches for that vulnerability, which then need to be installed on the affected computers to ensure their security.
It is commonly assumed that systems should have security patches and updates installed in a short period and should only use vendor-supported operating systems.
Even in IT systems, this is not as straightforward as it sounds, as patches can cause problems with the interaction between different software. Therefore, organizations with larger networks tend to first install patches on a single device to check for issues before rolling them out to other parts of the network.
These issues are even more complex in OT networks, where devices are often designed to run continuously for years. This means:
1. They may rely on outdated software versions that no longer receive security updates but cannot be upgraded;
2. They have very short maintenance windows;
3. The cost of downtime caused by patches leading to unexpected behavior is too great;
Therefore, patching is not a priority for most ICS systems, as it may impact the core principles of safety and reliability.
Encryption and Authentication
Another security mechanism we examine in every IT security assessment is the use of encryption. Without encryption, any data can potentially be read or modified by someone monitoring your network. It is used to protect financial transactions, login pages, emails, etc., to the extent that systems without encryption are considered high-risk targets. Encryption is often closely related to authentication, which is the mechanism that ensures you are the only person who can access the data.
However, security mechanisms applicable in IT do not necessarily apply to OT. First, we have pointed out that data confidentiality on these systems is not a priority, although it may apply to connected IT systems. While using encryption and authentication can help mitigate malicious attacks to some extent, they also consume computational resources, which may lead to delayed responses, severely impacting reliability and safety. Imagine a reactor overheating in a power plant; if the transmission of readings is delayed, the activation of cooling or shutdown mechanisms will be delayed, potentially leading to physical damage or destruction of the reactor.
Additionally, authentication mechanisms in OT systems are sometimes viewed by employees as stumbling blocks to security management, as they do not want to waste time remembering and entering complex passwords in response to urgent alarms while trying to diagnose problems and take appropriate action. In fact, such security measures (authentication mechanisms) are more likely to lead employees to share login details and write them on sticky notes at the control console to save time, which completely contradicts the initial intent of setting passwords.
This could be more severe than the consequences of an attacker gaining access to the system. Therefore, from a security perspective, accepting the consequences of a single intrusion by an attacker may be less detrimental than hindering those responsible for maintaining the security and reliability of the system.
Conclusion
This article primarily discusses that the security measures commonly seen in IT do not apply to OT systems used in ICS. This requires us to transform our mindset regarding security protection, no longer viewing OT security as a part of IT security, but as a separate type with different security requirements.
This means that in the mindset of deploying OT security, security professionals need to reflect on at least two distinct areas:
1. Security testing methods in OT systems: this means a comprehensive change in the current approach, tools, and techniques used to assess the security status of OT systems, rather than simply adjusting existing IT security testing methods.
2. Identifying security vulnerabilities and corresponding solutions, which are currently primarily based on IT systems. In OT systems, the principles of security and reliability need to be the core principles for identifying vulnerabilities.
In addition to the aforementioned, consideration must also be given to the profiles of attackers used in every practical environment of OT system security reviews, which differ from typical IT systems.
Security professionals assessing OT systems need to consider whether the system is critical to security, and if testing leads to system disruptions (not just financial costs, but also physical damage, environmental impact, and threats), what the worst-case scenario would be? What are the security guarantees for the system, and what are the most realistic threats to the system?
Therefore, the assessment of each OT system should be tailored, and any OT testing method should be flexible enough to accommodate each unique system.
We hope that after reading this article, you understand why IT and OT security need to be viewed separately and why OT security testing differs from IT security testing.
