Adversaries across the capability spectrum are increasingly targeting Industrial Control System (ICS) environments. Malware such as BlackEnergy2, Havex, and Stuxnet have been developed with specific capabilities against different control system targets. As exemplified by BlackEnergy2 and Havex even today's advanced adversaries typically target the commodity IT hardware, software, and communications protocols in use as part of our ICS systems. While this is the common tactic today, as the ICS community improves its cybersecurity posture adversaries will have to change their tactics and may turn to harder to access but more insecure communications mechanisms such as serial communications.
Why does serial data matter?
Serial data is critical to the functionality of most ICS environments. Even more modern installations rely heavily in serial data communications for critical operational communications. While technologies built on IP protocol stacks are becoming more common, even in these environments serial is the prevalent communication mechanism for the "last mile" to field devices. The criticality of the operational data sent via serial makes it an opportune target for an adversary who is interested in having physical consequences.
What is the issue?
While many ICS facilities have begun to adopt Network Security Monitoring (NSM) techniques on their corporate and control networks, few facilities are monitoring serial communications. Part of the challenge is that there are few open source or commercially available options that will allow for basic serial communication logging or forwarding. The tools that are available typically convert serial to IP and vice versa permitting two-way communications (not ideal for NSM). These tools are often protocol or vendor specific and centered around attempting to allow serial communications over an IP infrastructure and are not engineered to be a monitoring solution. Monitoring tools that allow passive tapping of serial communications with one-way forwarding into security analysis tools are needed.
How can you tap it?
When planning to physically intercept, or tap, serial communications it is important to keep in mind any impacts the tap may have to the primary communications path. When selecting a tap, it is preferable to use a physical tap that isolates the monitoring port from the main communications line and that "fails open" allowing communications even if the device has a failure. You want to ensure that a malfunction or compromise of your monitoring will not have an impact to your operations. There are a number of products on the market such as the B+B SmartWorx's serial data taps or the Frontline ComProbe II that will allow you to duplicate serial communications in this manner.
Should an isolated solution not be practical in your environment, a serial Y-Cable (an example can be seen here) tap can be purchased for relatively low cost to create a monitoring port. Serial Y-Cables can even be manufactured with relatively basic soldering skills however unreliable connections or interference from serial Y-Cables could have adverse impacts operations and should only be used when an isolated solution is not available. Additionally, since serial Y-Cables are generally wired as straight through you can only practically monitor the RX side of the serial communications without constructing an external circuit and adding complexity to your solution that is built into the professional data taps.
Setting taps in an production environment can become incredibly complex depending on the configuration of the serial communications network you are attempting to tap. In my example implementation below I will demonstrate a very basic setup for monitoring a simplex connection suitable for monitoring a single endpoint device that can be helpful in an incident response or detection context. When adding in multiple protocols, multiplexers, and other serial communications equipment monitoring serial communications becomes significantly more complex. While the principles outlined here apply to more complex environments, significant planning and coordination with communications engineers at the facility will be required to implement monitoring at scale.
How can you integrate with existing tools?
Traditional IT network security monitoring has significantly matured over the last decade. There are now a variety of open source and commercial tools that can process and analyze IP based network data for security monitoring. In order to integrate with these existing tools, serial data could be "wrapped" with an IP packet structure so this data can be ingested. Below is a simple python tool I made called Serial IP Forwarder that leverages pySerial to forward serial data from a serial tap and forward it via UDP to an IP based NSM sensor for processing.
The tool does not attempt to process the data or convert it to a IP equivalent ICS protocols (such as Modbus to ModbusTCP) but it does represent a starting point for forwarding serial captured data into more common IT NSM tools. This tool can be deployed on a simple laptop or a Raspberry Pi (RPi) with a serial interface to forward traffic for processing.
Example Raspberry Pi Implementation
To demonstrate the concept, I set up a Raspberry Pi in my lab using a Modbus serial simulation. If you've taken SANS ICS515: ICS Active Defense and Incident Response, you can use the Raspberry Pi you are provided as part of the class to build your own serial data forwarder. While a stock RPi does not have a DB9 or other serial connector, the header pins are automatically configured for a serial interface. You can access the device as ?/dev/ttyAMA0', this is the RPi's Linux operating system name for the default serial port similar to a COM port you may be familiar with in Windows. You can acquire a serial port connector as I did above, or wire one yourself as it only requires four connections.
If you install the default version of Rasbian, you will need to make two modifications to your RPi before you can reliably use the built in serial port. By default the RPi initializes the serial port as system console access for applications without monitors or keyboards. To disable this function, you will need to edit your /boot/cmdline.txt and /etc/initab to remove any references to "ttyAMA0". Elinux.org has a helpful description of the RPi serial port that outlines the processes for making these modifications. Once complete, restart the RPi and connect it to your serial tap or Y-Cable.
In this example I have a Modbus Master station in RTU mode polling a Modbus slave with slave ID 10 for 10 registers. The resulting request should present in hexadecimal as "0A 03 00 00 00 0A C4 B6" and be assembled as shown below.
On the RPi, simply navigate to the directory where you saved the python script and run the script as root being sure to specify at least the IP address or HOSTNAME you'd like the data to be forwarded to and the serial interface name. There are a variety of other options you can set, including the UDP port to forward to (default is 7777) that are displayed by running ?serial_forwarder.py -help?.
In my lab setup the my NSM sensor is located at 10.10.10.100 and the RPi serial port is named ?/dev/ttyAMA0'?so the command would be ?sudo python serial_forwarder.py 10.10.10.100 /dev/ttyAMA0'. The script will start up and wait for serial data to be transmitted. Once serial data is detected on the bus, the hexadecimal representation of the serial data will be displayed in the terminal window.
To verify that the data was actually transmitted to the NSM monitor for ingest, I had Wireshark running to verify.
Since I was using a serial Y-Cable in the configuration above, I was only able to monitor the master station's transmissions. Additionally the Raspberry Pi could be active on the serial bus and could interfere with the regular communications between the master and slaves. This limitation can be overcome by using a purpose built isolated serial tap that merges both the TX and RX lines into the RX line of the tap port or by building a tap that ties the TX and RX lines together and adding diodes and other circuitry to ensure the tap remains completely passive. The configuration used here was to demonstrate the method and is not recommended for production environments.
Mark Bristow is an instructor for the SANS ICS515: Active Defense and Incident Response course. Mark currently serves as the Chief of Incident Response for the ICS-CERT and has a background in ICS assessments, incident response, and penetration testing.
.jpg "ICS_Blog_Building a Better OT Ransomware Response Plan_340 x 340(1).jpg")
