Industrial control system communication media and protocols

How do all these parts of an ICS communicate? Traditionally, ICS systems used several distinct and proprietary communication media and protocols. The recent trend has been to adopt many of these proprietary protocols to work on a common medium, Ethernet, and a common communications protocol suite, Internet Protocol (IP). Therefore, you will find technologies such as PROFIBUS, traditionally run over serial cables, converted into PROFINET, which runs on Ethernet and IP. Modbus, which traditionally runs on serial lines, got converted into Modbus TCP/IP, which supports Ethernet and IP. The Common Industrial Protocol (CIP), traditionally run on coax medium via the ControlNet protocol or Controller Area Network (CAN) medium via the DeviceNet protocol now runs on the Industrial Protocol with Ethernet/IP (IP stands for Industrial Protocol in this case).

Chapter 2, Insecure by Inheritance, will provide a detailed explanation on all the aforementioned protocols and point out security concerns for them. For now, we are sticking to the explanation of how these individual protocols and media are used to connect all the parts and systems of a modern-day ICS.

The communication protocols found in a typical Industrial control system can be divided into the following categories; keep in mind that these run within the IP suite.

Regular information technology network protocols

Regular information technology or IT protocols are are the protocols that are in use on everyday IT networks. Some examples of those protocols include HTTP, HTTPS, SMTP, FTP, TFTP, SMB, and SNMP. This doesn't mean these protocols are used exclusively for IT purposes. Many OT devices, for example, will incorporate a diagnostic web page or use FTP to receive an application or firmware updates:

Traditionally, these protocols were used only outside of the plant floor and ICS networks in levels 4 and 5 of the Purdue model. With the trend of converging OT and IT networks technologies, many of these protocols can now be found all the way down to level 1 and with them their vulnerabilities too, which have plagued regular IT networks for years.

Process automation protocols

Process automation protocols include PROFIBUS, DeviceNet, ControlNet, Modbus, and CIP. These protocols are used to connect control devices together, be it a PLC to a sensor, a PLC to a PLC, or an engineering workstation to a control device to configure or program the device:

These protocols tend to be found mostly in levels 3 and lower of the Purdue model. A properly configured IDMZ should block any process automation protocol from leaving the Industrial zone.

From a security perspective, these protocols were never designed with security in mind. They forgo using encryption or implementing integrity checks to provide higher performance, stability, or compatibility. This opens them up to replay attacks, modification of the payload, and others. Chapter 2, Insecure by Inheritance, will expose the vulnerabilities per protocol in more depth.

Industrial control system protocols

Industrial control system protocols are mainly used for interconnecting devices and systems in different vendors, such as using a generic HMI solution to connect to a Siemens or Rockwell Automation PLC:

The main protocol in this category is OLE for Process Control or OPC. OPC is a series of standards and applications for industrial communications based on OLE, COM, and DCOM technologies developed by Microsoft.

From a security perspective, OPC is a nightmare. The protocol is easy to implement, flexible, and forgiving and provides the programmer with direct access to data registers from a large array of devices from all major vendors, all without any regard for authentication, data confidentiality, or integrity. Even more, the areas where OPC services are implemented ensure that this unprotected data needs to traverse from level 1 all the way to level 4. Someone once told me this joke: only two things can survive a nuclear bomb, cockroaches and OPC servers. The joke refers to the fact that OPC servers can be found anywhere and even though you can kill a bunch in a sweep, you can't kill them all.

The OPC foundation has made great efforts in addressing many security concerns and has developed a more security-oriented architecture, OPC Unified Architecture (OPC UA). The highlights of the OPC Unified Architecture are as follows:

• Functional equivalence, all COM OPC classic specifications are mapped to UA
• Platform independence, from an embedded micro-controller to a cloud-based infrastructure
• Secure encryption, authentication, and auditing
• Extensible, the ability to add new features without affecting existing applications
• Comprehensive information modeling for defining complex information

Building automation protocols

Building automation protocols allow communication between the parts of the control systems that run applications such as heating, ventilation, and air-conditioning. Protocols in use in this category include BACnet, C-Bus, Modbus, ZigBee, and Z-Wave.

From a security perspective, these protocols tend to be unencrypted and without integrity checking applied, which leaves them open to replay and manipulation attacks. What makes things particularly dangerous is that fact that most of the installed systems are connected to the internet or at least accessible via a modem for the vendor to supply remote support. Oftentimes, the authentication isn't very solid on the boundary of the system and breaking into it is a simple exercise. No other than tech giant Google had its building automation network breached by researchers back in 2013 (https://www.wired.com/2013/05/googles-control-system-hacked/). A breach of the building network system can be a direct entry into the rest of the network if the two are linked or they can give an attacker a means to enter the facility by providing the ability to open doors or disable alarm systems:

Automatic meter reading protocols

Can you remember when the last time the meter guy stopped at your home to take your meter reading? Lots of research and development have been put into creating more convenient ways of getting customer's meter readings from gas, electricity, cooling, and so on. The solutions range from a Radio Frequency (RF)-enabled meter that can be read by proximity to a city block covering radio mesh of smart meters, each solution with its own security challenges:

Protocols typically used for automatic meter reading include AMR, AMI, WiSmart (Wi-Fi), GSM, and Power Line Communication (PLC).

The following diagram shows where these protocols are typically found within the ICS architecture:

Communication protocols in the enterprise zone

The enterprise zone network will see web traffic using the HTTP or HTTPS protocols, email in the form of IMAP, POP3, and SMTP, file transfer and sharing protocols such as FTP and SMB, and many others. All these protocols come with their own security challenges and vulnerabilities. If your ICS network (Industrial zone) and the business network (enterprise zone) use the same physical network, these vulnerabilities can directly affect your production system. Having a common network for business systems and production systems is an insecure practice that is seen all too often still. More on this topic will be discussed in a later chapter.

The enterprise zone is where a plant or facility is connected to the Internet, typically via a setup such as the one shown in the following figure:

• The enterprise network is typically connected to the internet via an Edge Router and some form of a modem that converts an ISP provided service such as a T1 or optical carrier (OC1) medium into an Ethernet that is used throughout the rest of the enterprise network. Dedicated firewalls will securely connect the business network to the ISP network by use of port blocking and traffic monitoring. A common practice for enterprise internet policies is to use a proxy firewall for outbound traffic while highly restricting incoming traffic. Any necessary publicly facing services would be guarded off with a Demilitarized Zone or DMZ.
• Typical services in the Enterprise DMZ are publicly facing web servers, the company's public DNS servers, and the like. The DMZ allows a landing area of public traffic. If a service in the DMZ where to get compromised, the compromise would be contained in the DMZ. Further pivoting attempts would be caught by the enterprise DMZ firewalls.
• The enterprise internal network consists of switches, routers, Layer 3 switches, and end devices such as servers and client computers. Most companies will segment their internal network by means of VLANs. Inter VLAN traffic needs to go through some sort of routing device, such as a Layer 3 switch, a firewall, or a router, at which point, there are Access Control Lists (ACLs) or firewall rules.

Communication protocols in the Industrial zone

In recent years, the Industrial zone has seen a shift from using proprietary OT protocols such as PROFIBUS, DeviceNet, ControlNet, and Modbus to using common IT technologies such as Ethernet and the IP suite protocols. However, a few proprietary protocols and network media can still be found in the lower levels of the ICS systems. The figure below shows where some of these can be found in the ICS architecture, followed with a short description:

 

• A - Hardwired devices: These are the sensors, actuators, and other devices that use a discrete signal, such as 24 VDC or an analog signal such as 4-20 mA or 0-10 VDC, to operate. These devices are wired directly into a PLC add-on IO card or a remote communication rack with IO cards.
• B - Fieldbus protocols: These are mainly proprietary protocols such as DeviceNet, ControlNet, PROFIBUS, and Modbus and deliver real-time control and monitoring. These protocols can connect end devices such as sensors and actuators directly to a PLC without the need for an IO module. They can also be used to connect PLCs or connect a remote rack to a PLC. Most, if not all, fieldbus protocols are adopted to work on Ethernet and on top of IP.
• C - Nested Ethernet: Though it's not technically a different protocol, nesting Ethernet is a way to hide or obfuscate parts of the control network. They will only be visible by or through the device that they are connected to.