Throughout the years, the Industrial Control Systems (ICS) domain has drastically changed from disconnected or “closed” systems using proprietary protocols, to more “open” and standardized protocols. These standardized Local Area Network (LAN) protocols are built upon common computing platforms, and integrated with Internet Protocol (IP) based IT solutions. This interconnection of IT and ICS components has significant business value as it promotes corporate business connectivity and remote access capabilities increasing efficiency and reducing costs associated with operations. However, it also introduces an attack surface that did not previously exist in these isolated environments creating a greater need to secure these systems from both intentional and unintentional threats from both inside and outside the organization.
The technologies and techniques involved in securing ICS are not entirely different from IT. In fact, many of the strategies are derived from the more mature IT discipline, however there are some differences to consider. Many cybersecurity guidelines and policies are driven by the well-known CIA triad model, which stands for confidentiality, integrity, and availability. These three foundational principles form the cornerstone of any organization’s security infrastructure. Understanding your organization’s security goals based on industry, business, and regulatory requirements can indicate a need to prioritize one principle over the others. Generally speaking, in IT systems confidentiality takes precedence followed by integrity while in ICS environments availability is considered most important closely followed by integrity. Furthermore, ICS environments sometimes also add safety to the CIA as shown below.
Figure 1. CIA in IT vs. ICS
Consequently, many IT security control can be applied to ICS. However, these controls must be based on the risks. Unsurprisingly, the risks associated with ICS are distinct from IT risks. In particular, many ICS components such as PLCs are executing logic that have a direct impact on the physical world and if compromised could endanger the health and safety of human lives as well as have serious national security concerns. In short, the integration of IT solutions has blurred the boundary between what is considered IT and operational technology (OT). As a result, applying standard IT countermeasures to ICS environments while prioritizing availability has proven difficult, if not impossible.
According to the Cybersecurity and Infrastructure Security Agency (CISA), there are three areas in which ICS differs from traditional IT: Communication, Operation, and Support. However, the recommended strategy for securing ICS/OT environments is the same as that of IT systems. The Department of Homeland Security recommends Defense in Depth (DiD). DiD is considered a holistic approach to securing an organization’s security infrastructure through multiple layers of defense, specifically five layers as shown in Figure 2. It is important to note that DiD is a dynamic process involving people, technology and operations that are constantly improving to keep up with new attack vectors.
Figure 2. DHS Defense in Depth
First, ICS communications involve host applications that are usually limited to monitoring and controlling. Furthermore, these applications are designed to perform a specific task. In contrast, most business systems are used for many different purposes leading to dynamic and on-demand network traffic. Therefore, the network traffic for ICS is usually considered deterministic while traditional IT is considered more sporadic. On one hand, this makes it somewhat easier to set up intrusion detection systems (IDS). On the other hand, however, many components are highly specialized where the underlying IT solution is customized adding a layer of complexity in which traditional countermeasures used to protect IT systems may negatively affect the operational requirements of the OT system. For instance, PLCs are low-memory embedded devices that cannot handle environments with high network traffic. Additionally, many do not require authentication and don’t support encrypted communication. Although having an IDS is better than nothing, it is also helpful to scan the network regularly to ensure there has not been any unauthorized access to any devices on the network. However, performing network scans with tools such as nmap may cause high/irregular traffic that the PLC may not be able to handle. Additionally, the fieldbus which is a real-time distributed control network on which the PLCs communicate with sensors cannot be monitored with well-known networking tools such as Wireshark. Instead, protocol-specific and oftentimes vendor-specific monitoring tools must be incorporated into the security architecture resulting in increased overhead and reduced synergy amongst threat management software.
Second, many IT and ICS operations are driven by regulatory agencies and their compliance requirements. ICS is invaluable to the proper and safe operation of critical infrastructure and key resource (CIKR) sectors. These are assets, systems, and networks considered so vital to the security, economy, and public health and safety of the United States that many government directives and agencies were created to properly secure them. It is important to note, that not all sectors have clear compliance requirements and some of them function under recommended guidance. However, the guidance does not have the same consequences as compliance because compliance directives can be audited and usually have fines associated with any non-compliance.
Nevertheless, with the increase in cyber awareness among government agencies, asset owners, and down to the operators, the implementation of ICS security controls has improved. For example, one of the most common differences between IT and ICS was the policy for usernames and passwords. Due to the high availability and high capacity requirements, there were safety-related restrictions involved in securing ICS components and networks. In an emergency, the operator cannot be expected to memorize a complex randomly generated password to log in to an HMI to stop an out of control system. However, with an increasing focus on security for ICS, more ICS organizations are using individual usernames and passwords effectively without impeding the operator functionality. Although it may sound trivial, proper user authentication policies are an important facet of an organization’s security infrastructure. The figure below from CISA demonstrates the time to brute force a 96 character combination (a-z, A-Z,0-9, & special characters) password with varying password lengths from 4 to 9 with different hardware. The 10 million per second can be achieved with a modern quad-core processor while 76 billion per second can be achieved with a botnet. In other words, it is important to find the right balance between security and functionality.
Figure 3. Brute Force Password Capabilities [2].
Lastly, there are some major support differences between IT and ICS. IT being the fairly more mature discipline, security personnel and vendors have a vast number of sources from standards to best practices to manage and support the technologies and processes that protect their IT systems and networks. In contrast, ICS security is not as mature and due to its critical nature, it is difficult to implement many of the standard IT solutions directly. There are several reasons as to why many core ICS components are incompatible with traditional IT security strategies. As mentioned previously, many ICS components are resource restrained. This, for instance, may prevent a vendor or manufacturer from implementing encryption. Furthermore, legacy systems introduce a host of problems due to their age and fragility. This, in turn, may lead to continued inferior practices as they are not easily updated and the cost associated with retrofitting legacy systems with contemporary controls is high.
Another challenge ICS environments face is network related restrictions. Many devices in an ICS environment require real-time data and connection that can have consequences if delayed down to the millisecond level. Even a small disruption in this connection or process could cause unrecoverable damage. Therefore, even when implementing network firewalls or IDSs, one of the most standard IT solutions, special care must be taken to not cause any delays that could bring down a crucial process. Furthermore, as previously shown with the password example, there are also safety-related restrictions. Many of these restrictions also affect each other. A classic example would be that of a valid command to shut down a process, due to safety requirements, cannot be prevented from going through the network by a firewall or IDS or Intrusion Preventions System (IPS). Attackers may take advantage of this to send unauthorized valid commands on the network to cause disruption. Most importantly, all of these restrictions are closely tied to the high-availability requirements. Most ICS run systems with high runtime and uptime requirements. Consequently, typical security controls such as change management, patch management, IDS/IPS, and anti-virus/anti-malware updates will need to be specifically tailored for OT needs.
A detailed walkthrough of the entire Defense in Depth (DiD) process is out of scope for this article. However, we will focus on one of the main security controls and delineate some key differences. In order to have proper DiD, it is crucial to have visibility into the ICS architecture. However, the convergence of IT and OT systems, the boundary between these two technologies has blurred. Nevertheless, a good place to start is with the industry adopted Perdue Enterprise Reference Architecture (PERA) model shown in Figure 4. The model facilitates network engineers and architects to understand the interconnection and interdependencies of all the main ICS components [3]. As the PERA model illustrates, it is important to control the flow of information to and from the different security domains. Such isolations reduce the risks of unauthorized information flow among system components and provide opportunities to implement greater security controls over selected components that require them [4]. Furthermore, similar to how corporate networks consider the Internet as a threat, ICS networks should consider the corporate network as a threat. Many malware and viruses leverage the connection between corporate IT systems, known as IT conduits, and ICS components to deliver attacks. It is critical that network and ICS security architects cooperate in order to design an architecture that is both secure and functional with policies and procedures to mitigate risks where certain communications must be allowed to flow from different security domains.
Figure 4. Purdue Enterprise Architecture Reference Model
As technology progresses and industries such as IT and OT start to converge, it becomes ever more present that in order to securely integrate the two a more meticulous approach has to be taken. Over the past 5 years, Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) has noted that there is an increase in vulnerabilities discovered in the ICS arena and that it is likely to continue to grow as research continues. Also, notably, there has been an increase in ransomware targeting ICS specific functionality such as EKANS, which seeks out and stops ICS related process like Honeywell’s HMIWeb application and other remote monitoring and licensing related software. In all, this is a never-ending game of cat and mouse and harps back to the obligation of developing security architectures that are specific for OT needs. As was stated earlier security is governed by the CIA triad, however for OT availability is the most important aspect. In order for DiD to be effective in OT, the software and architecture must be tailored to the needs of OT environments. As cyber-awareness increases and people become more aware of the special needs of ICS, security solutions, standards, and best practices will improve leading to a more mature ICS security discipline.
