In many, if not most plants with industrial control systems (ICS), ICS engineers and their internal information technology (IT) counterparts have very different perspectives on cybersecurity. Not surprisingly, these different perspectives often lead to conflicts when connecting an ICS to the plant’s IT system.
In the past, because industrial control systems used proprietary hardware and software, this interconnection focused primarily on just being able to communicate. The introduction of Ethernet and Microsoft Windows into industrial control systems in the mid-1990s, followed by the development of OPC interfaces, greatly simplified this problem, but at the cost of exposing the ICS to security threats previously known only to IT systems.
Further, with the rapid increase of attacks on industrial systems in the past few years, chief information officers are often held responsible for cybersecurity for the entire plant, including their industrial control systems. Unfortunately, not all IT security solutions are suitable for industrial control systems because of fundamental differences between ICS and IT systems. In addition, plants often have multiple production processes and industrial control systems, and some are naturally more critical than others. As a result, it is not uncommon for security to be handled differently among the various industrial control systems in a plant.
This article discusses how industrial control systems differ from IT systems as they relate to cybersecurity. It is important that IT and ICS professionals jointly understand the following top ten differences and develop workable security solutions that benefit the whole organization.
Difference #1: Security objectives
One of the biggest differences between ICS and plant IT security is the main security objective of each. Plant IT systems are business systems whose primary cybersecurity objective is to protect data (confidentiality). In contrast, the main cybersecurity objective of an ICS is to maintain the integrity of its production process and the availability of its components. Protection of information is still important, but loss of production translates into an immediate loss of income. Examples of threats to production integrity include those that degrade production, cause loss of view/control, damage production equipment, or result in possible safety issues.
One of the consequences of industrial control systems focusing on the production process is that ICS security is implemented using a comprehensive set of defense-in-depth layers to isolate the ICS and the physical process from the plant IT system. This isolation is the topic of difference #2.
Difference #2: Network segmentation
The first difference encountered when connecting ICS and IT systems is how they are segmented and protected. IT systems are usually composed of interconnected subnets (short for “subnetworks”) with some level of Internet connectivity. As a result, access controls and protection from the Internet is a primary focus of IT network security. It is not uncommon to see sophisticated firewalls, proxy servers, intrusion detection/prevention devices, and other protective mechanisms at the boundary with the Internet.
Inside this boundary, the remainder of the IT network is segmented into subnets that are generally aligned with organizational and geographical boundaries. Because access between these subnets is usually required, security between them is typically limited. However, all traffic from them must pass through the Internet security boundary to access the Internet. ICS networks, on the other hand, can be viewed as industrial intranets with two overriding security requirements. First, no access to the Internet or to email should be allowed from ICS networks. Second, ICS networks should be rigorously defended from other plant networks, especially those with Internet access.
To meet these requirements, industrial control systems usually employ network security devices (e.g., firewalls) for isolation from the plant IT system. Only workstations and servers within the ICS that act as gateways should allow ICS access through these ICS perimeter security devices. This prevents other devices on the ICS control network from being directly accessible from the plant network. These gateways should have an additional network card that allows them to connect the ICS control network. In general, only devices authorized to access the ICS from the plant network should be aware of these ICS network security devices and therefore be able to send messages through them to ICS gateways.
Industrial control systems should be further insulated from the plant IT system by a demilitarized zone (DMZ) that sits between the plant network and the ICS. The DMZ is an intranet that should be hidden from the plant network by an undiscoverable network security device. All external access to the ICS should first pass through this device and then be terminated in DMZ servers. DMZ servers provide clients on the plant network with ICS data and events that these servers independently obtain through separate and isolated communications with the ICS. The network security device that connects the DMZ to the ICS should be configured to allow only these isolated communications to ensure that all ICS access goes through the DMZ servers.
As a further precaution, the DMZ should use private subnet addresses that are independent of subnet addresses used in the plant network to prevent plant network messages from being erroneously routed to the DMZ. Similarly, the ICS should use private subnet addresses that are independent of DMZ addresses.
ICS networks often have remote input/output (I/O) systems, whereas IT networks do not. In these systems, I/O devices are installed in remote geographical locations and are often connected to the ICS via modems over public networks, virtual public networks (VPNs), and satellite links. Care must be taken, because these connections can give rise to security issues.
Difference #3: Network topology
Closely related to network segmentation differences are network topology differences. Many IT systems are large when compared to a typical ICS and contain data centers, intranets, and Wi-Fi networks. Industrial control systems, on the other hand, are often small and have only a configuration database and data/event historians.
It is not uncommon for an IT system to have hundreds if not thousands of nodes whose numbers change daily as employees come and go, as applications evolve, and as mobile devices are connected and disconnected. In contrast, most industrial control systems are an order of magnitude smaller, and generally have statically defined configurations.
IT network configurations, including VPNs, and network security devices have to keep up with these changes. As a result, IT systems extensively use many automated tools, such as dynamic host configuration protocol (DHCP), to manage their network topologies. These and other tools are cost effective only in large-scale systems and are considered expensive and complex by ICS standards.
Industrial control systems typically remain relatively static for years. A rigorous change management process is normally mandatory to ensure all changes are approved and tested. In addition, the use of DHCP and Wi-Fi segments are discouraged in the ICS for security reasons. In addition, ICS networks that connect ICS workstations with controller-level devices are normally redundant to prevent a network failure from affecting the operation of the control system. This network redundancy is typically proprietary to the ICS vendor with custom addressing models and switchover logic. As a result, the tools and techniques IT uses to maintain its dynamic network topologies are often not suitable or applicable to statically defined ICS networks.
About the Authors
Lee Neitzel, senior engineer at Emerson Automation Solutions in Austin, Tex., has been involved in security and network standards for more than 30 years. He has worked on IEEE 802, FDDI, Fieldbus Foundation, and OPC standards. He is currently the IEC project leader for integrating the WIB "Process Control Domain - Security Requirements for Vendors" specification into the IEC 62443 and the ISA-99 security standard.
Bob Huba, system security architect, has been with Emerson Automation Solutions for 36 years. He is active in the development of the ISA-99/IEC 62443 standards.
A version of this article also was published at InTech magazine.