Recently, I have began producing the SANS ICS Concept video series to outline some basic concepts for individuals moving towards the Industrial Control Systems (ICS) / Operational Technology (OT) security field. The first three installments focused on using the Modbus protocol to explain and re-enforce several basic considerations about industrial protocols.

The Modbus protocol has a wide distribution across many sectors in the industrial field. It also has characteristics that are useful for explaining many concepts that are implemented within ICS / OT environments. The following are a few of the things I tried to achieve during these videos and why I selected Modbus over other protocols.

Server to Device Interactions

Modbus exposes students to communications exchanges that are found in many industrial protocols. The original, industry standard, wording for this was a master and slave relationship. In recent documentation these references have been modified to Director / Producer, Client / Server, Server / Field Device, and others. The SANS ICS410 courseware has been updated to use these new references as they make sense for the situation being described. This is important to clarify because vendor documentation is slower to change, and stored documentation will always lag online resources. For reference, directors / clients are management servers, controllers, and other systems that are making Modbus requests. The destination of that request is considered a producer / server. Producers can be controllers, smart end points (sensors / actuators), or other systems that are running the Modbus server, typically on port 502. The producer does not initiate traffic itself. It waits for a request from a director and then takes action on that request. Other industrial protocols leverage similar functionality to the Modbus protocol. The director / producer relationship is seen in Distributed Network Protocol 3 (DNP3), Manufacturing Message Specification (MMS), and other protocols.

Modbus requests can read or write values associated with the function code selected. Values are associated with information that the device has been configured to track. Input values are device inputs that are read-only, and they are referred to as a Discrete Input (a one bit value) or an Input Register (a 16 bit value). Values that are read and writable are Coils (a one-bit value) and Holding Registers (a 16-bit value). Every device has a specific mapping for how these values are configured. These mappings are usually found in the products documentation, but they can also be customized by the device's programmer for the specific function it performs in the process. Other industrial protocols leverage similar functionality for interacting, storing, and accessing with data. This functionality is outlined in the protocol and device documentation, as well.

Insecure Communications

Modbus is an "insecure" protocol, by design. Confidentiality and integrity were not a consideration during its design. This is a difficult concept for many information security professionals and even some administrators to accept. Industrial protocols are selected because of the capabilities they provide to achieve specific production requirements. In the case of Modbus, it is simple to implement, the information exchanged is easy to process, and the transmission of the data is reliable on multiple mediums. The protocol is typically selected for these characteristics because of hardware and communications mediums selected.

Other industrial protocols do provide security features that provide confidentiality and integrity to the communications. However, these are implemented on a case-by-case basis. Often, when its security features are not selected, it is because of specific process requirements. Other times, it is because the OT team does not know about the configuration, the process cannot be updated without significant, and costly, modifications, or concern about latency. In all cases, security teams need to understand the capabilities and limitations of the protocol and why it was selected and implemented before taking a stand for secure communications.

Protocol Formatting

Understanding the data exchanged between two endpoints on the control network is important for protocol analysis. The Modbus protocol formatting, like other protocols, is detailed in the protocol specification. The specification details the organization of each byte of a communication in a manner that is consistent for the applications to parse and operate on. The specifications also outline the order of communications between the end points. Modbus is often selected for education because the data formatting is easy to understand and even build simple tools for communicating with end points. Other industrial protocols, while easy to understand with education and implementation, are more complex and thereby more difficult to introduce.

In all instances of industrial protocols, there are multiple ways to interact with the data. For Modbus, tools like mbtget, rodbus-client, and pyModbus provide non-commercial means to format data appropriately for sending requests to the producers. Some of these tools can also be used act as the producers themselves to simulate the end point and allow student interactions. While there are tools that generate requests for other industrial protocols, the complexity of their specifications makes it more difficult to develop non-commercial simulators. Even those more complex protocols, like Distributed Network Protocol 3 (DNP3), do have simulators, but they are more difficult to configure end points that mimic devices that would be found on the control network.

Protocol Analysis

Understanding the data exchanged between two endpoints on the control network is important for protocol analysis. Process engineers, operators, and implementers use many tools to capture and review these exchanges when they are troubleshooting issues. Many vendors provide tools to assist with these activities. Unfortunately, these commercial tools are generally expensive. The Wireshark network protocol analysis tool is commonly used as a communication analysis tool when commercial tools are not available. Wireshark provides many dissectors for industrial protocols and it is an excellent means for helping to educate students to new protocols.

The Wireshark toolkit, and other network protocol analysis tools, provides additional methods for understanding the exchange of information between two end points and within the control network. Tools like Tshark and Scapy are useful for automating, using scripts, the extraction of specific data from a collection of network packets. Scripting makes complicated and repetitive activities easy to implement and ensure consistent outputs. These skills are useful for many types of activities including asset identification.

Attacking Protocols

Understanding how threat actors will interact with a process is extremely valuable. Vendor tools provide the best methods for interacting with their products and with specific protocols. However, these tools are generally limited in flexibility that is necessary for causing unexpected conditions. Thus, threat actors are known to develop their own tools to accomplish their goals. These tools are typically based on open-source software that was developed to provide interoperability to vendors or as a part of educational / research projects. Modbus tools are a good starting point for learning this concept and developing scripts and other tools to interact with end points. Modbus isn't the only protocol with open-source software. EtherNet/IP (ENIP) and Common Industrial Protocol (CIP) has the Python-based CPPPO and pycomm3 projects. DNP3 has the extremely successful and secure OpenDNP3 project. OPC-UA has the Python-based opcua project and OPC-DA has the Golang-based OPC project. IEC 61850, which includes MMS and Goose, has the C-based libiec61850 libraries with easily compiled examples. The only limitation of these tools is the supporting infrastructure to run devices that implement use that protocol for control and data acquisition.

The primary similarity between network-based protocols is the network. Attackers have been known to use techniques that intercept these communications and make modifications on the fly. This technique is not new. It has been demonstrated many times for protocols commonly used in corporate environments. It has also been demonstrated in control network. However, with all techniques, it is a new concept to those that have not seen it before. Since Modbus is a simple protocol, demonstrating how to modify network traffic is easily demonstrated and understood. However, these techniques are just as effective on other protocols because the data can be easily analyzed and modified by the same tools.

Summary

Ultimately, my goal with the three Modbus videos is to provide an understanding of all of these concepts. Hopefully, people watching the videos can make the logical leap to using the same techniques across other, potentially more complex, industrial protocols. It might be a leap of faith, but one I know most people can handle.

Future videos will cover other ICS Concepts that are not related to industrial protocols. There is no limit to the number of things that require an introduction in this field. At some point, I am hoping to have guests from throughout the ICS / OT industry to cover some of the other protocols and how they are used within control environments. These three videos should provide a good protocol primer and allow those videos to jump directly into more interesting aspects of the implementation and analysis of that industrial protocol.

If you have any questions about this or other topics, join the SANS ICS Forum and post them there. If you tag me, I'll respond as soon as I can. Else, someone from the community will respond with useful information and suggestions.

Go forth and do good things,

Don C. Weber (@cutaway)

SANS Instructor Profile

Cutaway Security, LLC