The Challenges of Industrial Device Detection

Background

Nessus® Network Monitor (NNM) provides continuous visibility into the systems and services running on enterprise networks, offering unmatched asset insight. From legacy assets to the latest technologies, and from IT to OT, it illuminates blind spots across the entire network environment. As the underlying sensor for Industrial Security (IS), NNM offers enhanced OT support — including asset discovery and protocol detection — for passively monitoring industrial control systems (ICS), SCADA systems and other operational technology. This gives security teams a safe and non-intrusive way to discover and monitor sensitive critical infrastructure systems and the industrial devices they rely on.

Challenges

Industrial networks are different from IT networks — the devices are more sensitive and the protocols they speak are more complex. ICS devices tend to behave in unexpected ways when actively scanned with regular IT security tools, so NNM elicits detection information simply by listening to the traffic moving across industrial networks (passive detection). To do so, it has to understand the protocols OT devices speak, and they present additional complexity. Specifically, there are a wide variety of ICS protocols used in industrial networks, some sharing open standards across different industries and others specific to a single industry, vendor or application. For example, the proprietary S7 protocol is used only by Siemens devices. Similarly, the DNP3 protocol is typically used in electrical distribution plants. In addition to contextual challenges, differences in the implementation of a given protocol are often seen from device to device, or from manufacturer to manufacturer. And complexity arises as protocols and standards evolve. Some protocols originated with a specific vendor and evolved into a protocol standard, adapted for use by a large number of vendors, for a range of applications. These are some of the most interesting protocols to work with. We’ll look at one such example — Modbus/TCP protocol — and I’ll describe in greater detail how the NNM team makes sense of it for Industrial Security customers.

Modbus Basics

Modbus is a communication protocol used to control, monitor, and program devices used in ICS environments. Modbus/TCP is the Modbus protocol used in TCP/IP Ethernet networks. It is a request/response protocol that was designed for use by the Modicon line of PLC (Programmable Logic Controllers). Schneider Electric designs and builds Modicon ICS devices, and Modbus is now an open standard, and the protocol specifications are available at www.modbus.org.

The way Modbus/TCP works is fairly straightforward. Each message has a function code, and there are 19 functions defined with requirements for purpose, format, field meanings, and allowed values defined in the standard, per Table 1 below:

Table 1

The NNM team typically researches a protocol from its specification, if publicly available. From the Modbus/TCP spec, we find that its messages have a 7 byte header, followed by a data section that begins with the function code, which tells us which type of message we’re looking at. A typical request sent by a client also specifies a transaction identifier in the header that is used to identify the server’s response. If the server is able to process the request, the response includes the transaction identifier, the function code and any sub code, and the requested data. If the server is unable to process the request, the high bit of the function code byte is set in the response, followed by a 1 byte exception code.

How We Implement Industrial Device Detections

Typically we focus on message types that provide device identification information that can be used for detections — since Modbus/TCP has a function code/subfunction code (43/14) set aside for this specific purpose, knowing where to look appears fairly straight forward at the outset.

What can make Modbus/TCP particularly complex is that the set of function codes implemented varies by vendor and device. For example, most Schneider devices have default, built-in Modbus/TCP capabilities we would expect. These typically implement function code 43 and sub code 14, which contains device identification information, and also a Schneider specific function code 90 (the Unity message, which can be used to program and configure a Programmable Logic Controller). Siemens and Rockwell PLCs that speak Modbus/TCP, however, don’t respond to these requests as implemented — they need custom programming by the user to respond to Modbus/TCP requests. Similarly, Siemens and Schneider Electric devices may use a server port other than the standard port 502. Moreover, Siemens and Rockwell devices typically do not implement the Device Identification Message. So knowing how a manufacturer treats a given protocol is important to understanding whether and how we can detect specific devices.

For implementations that do allow for detection, there are 5 forms of device identification messages which can be used reliably by NNM for detection. Of these, the reliable messages are Basic Device Identification, Regular Device Identification, Extended Device Identification, and Individual Device Identification — the less reliable message is the Report Server ID response. We’ll discuss the first two of these different identification messages and show how NNM uses the data within them to detect OT devices.

Basic Device Identification Messages — The Basic Device Identification response contains 3 objects in type length value (TLV) format, which are the VendorName, the Product Code, and the Major Minor Revision. These are text strings that provide high-reliability for detections — not only in identifying the device itself, but for cross-referencing device attributes (from research the team conducts on individual devices so that NNM can report them when detected) and associated vulnerabilities (drawn from known vulnerability data, which NNM cross-references with the device and firmware version information found in these fields).

Regular Device Identification Messages — The Regular Device Identification response may contain the additional objects VendorUrl, ProductName, ModelName, and UserApplicationName. Making protocol dissection more complicated, some devices include even more additional objects in the response than these. The Regular Device Identification response from the Schneider Electric SCU HMI, for example, contains all of these additional objects plus Object ID 8 (see below). And in some cases, a Regular Device Identification response may only contain the 3 objects of the Basic Device Identification message, yet with a specific flag set (Conformity Level) to reflect that only Basic Device Identification is being sent. And as if these variations aren’t challenging enough, some Schneider devices use the ProductCode field to hold a barcode value, which NNM can look up from a table to identify the device.

Conclusion

Modbus/TCP is but a single ICS protocol, and we’ve only discussed two of the message types that can be used for detection, but doing so demonstrates the complexity of the work the NNM team does in building industrial device detections. NNM supports over a dozen well-known industrial protocols (as well as several legacy and less well-known protocols as well) and over 5,000 individual devices, and adds new protocol and device support on a regular basis. If you’d like to learn more about NNM or Industrial Security, or have experience in dissecting industrial protocols and have an interest in joining the Tenable team, please don’t hesitate to reach out to us!