William T. (Tim) Shaw
PhD, CISSP / CIEH / CPT

Serial communications have been used in industrial automation for many decades, particularly starting in the early 1960s with the invention of integrated circuits and accelerating when (relatively) low-cost 16-bit ‘minicomputers’ with RS-232 communication boards became available. All long-distance communications (e.g. telemetry applications) relied on serial communications but even in-plant applications abounded once we had a lot of smart devices that needed to exchange data and commands. ‘Serial’ communications eventually morphed into LAN/WAN communications with the invention of Ethernet. And today we understand that LAN/WAN connectivity poses a cyber threat to our automation systems. But what about old-style serial communications? Are they a cyber threat?

I am constantly amazed at how conventional industrial ‘serial’ communications are misunderstood by IT and cyber security experts. Let me clarify; by ‘serial’ communications I mean low speed (300 bits/sec to 128 kilobits/sec), asynchronous, message exchanges based on bit/byte-oriented industrial protocols devised long before the invention of modern LAN/ WAN technology and TCP/IP networking. I am talking about the kinds of communications used in prior generations of SCADA systems to communicate with field-based RTUs (remote terminal units) and even in early PLC factory-automation applications. A common theme among most such serial communication schemes was the need for low overhead (percentage of bits being transmitted that were ‘data’ versus the percentage of bits that were used to deliver the ‘data’), a small population of participating devices (between two and sixteen) and reliable operation over low quality communication channels. Such communications were usually of a point-to-point or a point-to-multipoint configuration, with no need for message passing or routing due to the ‘flat’ architecture of the communication channel.

As there were no standards for industrial communications in the 1960s and 1970s each manufacturer of smart devices, PLCs and SCADA systems tended to devise their own, proprietary protocol(s). Between the invention of the IC and their use in building low(er)-cost computers there was a period of time where digital devices such as MTUs (master terminal units) and ‘dumb’ RTUs were designed and built, with their communication protocol logic actually hard-coded in digital circuitry. Those devices tended to use isonchronous (bit-oriented) communications where the messages were composed of a potentially large number of bits (not always a multiple of 8) and transmitted sequentially without breaking the message into octets and appending start/stop bits (as in asynchronous transmission). When computers came along and had to communicate with those ‘dumb’ (digital but not computer-based) RTUs special communication hardware had to be developed to send and receive the isonchronous messages. Legacy protocols such as CDC type I/II, Conitel, TRW and Getac were of this bit-oriented design (and named after the companies that devised them) and, surprisingly, most are still found being used in electrical substation and SCADA/EMS applications today.

As a former SCADA system developer I can attest to the major pain in the posterior that resulted when a customer required us to support any of these legacy protocols. You can’t ‘speak’ to them using a conventional UART circuit (so forget the COM: ports on your PC). We had to develop special hardware circuitry to transmit/receive the entire isonchronous messages and then break them into octets that could subsequently be delivered using a UART circuit into a COM: port. This is a consideration when assessing the cyber vulnerability of such communications as no off-the-shelf computer hardware can be successfully used to eavesdrop on (or inject falsified) message traffic.

In the 1970s the UART chip and RS-232 electrical standard, combined with early telephone MODEMS, provided a means for dumb computer terminals (remember those?) to communicate asynchronously (character by character) with mainframe computers and form ‘timesharing’ computer systems. The industrial world picked up on the same technologies and thereafter most (but not all) subsequent industrial protocols used asynchronous message transmission. In that timeframe several new protocols were devised, both for early PLC applications and for electrical, pipeline, transportation and water SCADA applications. The Modbus and DNP protocols are good examples of asynchronous, serial protocols that could operate on low-speed channels (such as a radio link or analog phone line) and support both point-to-point and multipoint operations. Both of those protocols have been widely accepted and are in common use today in a wide range of industrial applications. In fact Modbus protocol is found in more smart devices (devices that support asynchronous serial communications) than any other industrial protocol.

Those protocols, and even the earlier bit-oriented ones, are not of the same sophistication as modern LAN/WAN protocols that use TCP/IP and use a layered design such as is described by the ISO/OSI (open systems interconnect) model. These serial industrial protocols consist of essentially just three (3) layers as compared to the seven (7) layers of the OSI model and the five (5) layers of the IP model. Those three layers are (using the OSI terminology) the ‘physical’ layer, the ‘data link’ layer and the ‘application’ layer. The layers that are missing involve functions such as routing and session persistence and data format compatibility. None of those functions were required by these industrial protocols. Another major difference between these industrial protocols and a general-purpose message delivery service like TCP/IP (or even UDP/IP) is that all of the allowable/supported commands and data types are pre-defined in the industrial protocol specification and anything else should/would be treated as a bad/invalid message and ignored.

Industrial protocols were/are, in general, designed to allow the exchange of data/status values and the issuance of control requests. In other words to allow for remote access to analog/ pulse/status inputs (values) and remote manipulation (control) of analog/pulse/contact outputs. Different protocols use different means for specifying which inputs and outputs they are accessing and some support more data types than others (e.g. only discrete bits and 16-bit integers versus floating-point values). Different protocols offer a different variety of possible commands (e.g. merely read/write registers versus supporting accumulator freeze, setting the time/date, etc.). It is important to note that most smart devices that ‘support’ a given industrial protocol actually only support the minimum subset of defined commands necessary. For example, if a smart device has no control outputs why would the vendor waste time programming it to process output manipulation commands? Much less costly just to program-in the one or two commands needed by the device and treat all other commands as invalid (even if they are defined by the protocol specification.)

I have overheard long-winded arguments between so-called experts about how a Modbus serial communication connection between an RTU and a SCADA ‘host’ could be usurped by an adversary to launch a cyber attack on a SCADA system. It is quite feasible that an attacker could tap into a communication channel and inject falsified message traffic (Google Vitek Boden if you want to read about a real-world example of doing this.) If done as falsified responses to a SCADA host the result would be invalid measurement/status indications to the operators. If done as falsified commands to the RTUs then this could result in field equipment being put into unsafe conditions. Neither of those results are, in my humble opinion, a ‘cyber attack’ on the SCADA host. Neither effort will result in injecting malicious executable code into the host or provide the attacker with the ability to remotely control/manipulate the host. This is not to say that bad things might not happen, but it is still not a cyber attack in the traditional sense.

Of course with a SCADA system, unless the communications between the host and RTU were left broken by the attacker, at the next poll the invalid data would be replaced with fresh valid data and operators could issue commands to restore field equipment to its valid state. Also note that major SCADA systems usually have numerous communication channels out to the field and the RTUs, so disrupting just one channel would have a limited scope of impact. And really big SCADA systems often have backup sites with separate communication channels to the field in order to ensure that operations can be maintained.

Not too long ago a researcher claimed that there was a ‘special message’ they had devised that could crash any SCADA system that used Modbus protocol. In cyber security speak they were claiming to have devised an exploit and payload that if transmitted to the SCADA master as a response to a poll would result in killing the Modbus communication task at the host end (would result in a buffer overflow that mangled the Modbus driver instructions). They failed to take into account how real SCADA systems operate: most run a separate process for each communication channel and a separate background (‘watchdog’) process that watches over running processes and will reload/restart any that crash or get hung. Thus the results of the attack would be short-lived (actually since most SCADA systems are designed with redundancy it is possible that an automatic switch to the backup would occur to restore Modbus polling operations.)

Also, that particular exploit and payload might be viable for a very specific version of a Modbus driver from a given vendor, but many SCADA system vendors have written their own protocol libraries and it is unlikely that the exploit and payload would work against a different vendor’s software. Certainly, if a vulnerability is discovered in a commercial protocol library (and many have been) then any SCADA system using that particular library/version would be potentially susceptible to attack and exploitation.

To date I have not been made aware of any cyber attack on an asynchronous serial communication polling channel that resulted in injecting malware or hacker-ware into a SCADA host. In theory it should be possible, and I would be very interested in learning about any successes in this regard. But so far the jury is out.

Now this is not to say that all serial communications are ‘safe’ and don’t provide a potential cyber attack pathway. Any form of TCP/IP networking can potentially be abused through cyber manipulation. We should all remember that prior to the widespread availability of broadband networking most of us got to the Internet by using a dial-up phone line and a MODEM to connect to AOL (or some other ISP). So obviously a TCP/IP connection and session can be established over a low-speed, asynchronous, serial communication channel.

Also, serial communications have often been used for remote maintenance and technical support activities. If a technician is remotely accessing a protective relay in a substation using a dial-in phone line then it may be possible for an attacker to discover the same phone line and attempt to gain access to substation IEDs using a brute-force password cracking attack. That is something that an electric utility would definitely wish to prevent from happening, but that will have to be the subject matter for a future column.

About the Author

Dr. Shaw is a Certified Information Systems Security Professional (CISSP), a Certified Ethical Hacker (CEH) a Certified Penetration Tester (CPT) and has been active in designing and installing industrial automation for more than 35 years. He is the author of Computer Control of BATCH Processes and CYBERSECURITY for SCADA Systems and co-author of the latest revision of Industrial Data Communications. Shaw is a prolific writer of papers and articles on a wide range of technical topics and has also contributed to several other books. Shaw has also developed, and is also an instructor for, a number of ISA courses and he also teaches on-line courses for the University of Kansas continuing education program. He is currently Principal & Senior Consultant for Cyber SECurity Consulting, a consultancy practice focused on industrial automation cyber security and technologies. Inquiries, comments or questions regarding the contents of this column and/or other security-related topics can be emailed to timshaw4@verizon.net.