Safe Interrogation in Fragile Systems: The Art of Touching Without Breaking

There is a competency in OT security work that rarely appears in job descriptions or certification curricula, but that separates practitioners who can actually operate in industrial environments from those who have studied them. It is the ability to extract information from control systems without perturbing the systems in the process. Call it safe interrogation. It is part engineering judgment, part protocol knowledge, part operational discipline, and it is learned primarily through experience, often uncomfortable experience.

The starting point is understanding that OT devices are not general-purpose computers. A PLC running a reactor control sequence has its scan time managed to microsecond precision. Every clock cycle is accounted for. When something unexpected arrives on the network, whether a packet the device was not programmed to handle or a query rate higher than the application was designed to service, the control system does not gracefully degrade. It faults, it drops communications, or it responds in ways that affect process output. The device is doing exactly what it was programmed to do; it just was not programmed to handle what you sent it.

Protocol selection is the first variable under the interrogator's control. Passive collection of EtherNet/IP traffic, for example, can be supplemented with CIP Unconnected Message Manager requests to enumerate device identity, including the device class, product name, serial number, and firmware revision. These are Class 1 identity attributes that every CIP-compliant device supports, and the query is structurally benign: it asks for information the device is explicitly designed to provide. Contrast this with attempting to read process data registers on a device you do not have a program map for, using a generic Modbus function code scan. You will get responses, but some percentage of devices will respond poorly, and in a production environment, poorly is not acceptable.

Low-and-slow interrogation is not a security best practice transplanted from penetration testing methodology. It is a direct consequence of how industrial communication stacks are implemented. A field device sized for a 250-millisecond scan rate was not designed to absorb queries at ten times that rate.

Rate is the second variable. Industrial devices are often sized for their specific communication requirements, not for general load. Sending queries at ten times the device's designed scan rate may not crash it immediately, but it will consume resources that the device was not sized to spend. One query per device per minute or less is the appropriate starting point, not the cautious exception.

Timing matters beyond rate. Industrial processes run in cycles, and within those cycles there are windows where the control system is more and less tolerant of external stimulus. Querying a PLC during its I/O scan cycle is structurally different from querying it during an idle window, even if the underlying packet structure is identical. Understanding the scan cycle behavior of a specific platform, which comes from engineering documentation and vendor knowledge rather than network analysis alone, allows interrogation to be scheduled appropriately. This is the kind of knowledge that lives in operations teams rather than security teams, which is another reason why the two functions cannot operate independently.

Vendor coordination changes the risk profile significantly. Most major OT vendors, including Rockwell, Siemens, Schneider, Honeywell, and Emerson, have documented positions on which diagnostic queries their platforms support and under what conditions. Some have developed security-specific tooling that performs asset discovery using the same communication mechanisms their engineering workstations use, which is the safest interrogation method available: the device has been tested against this query pattern by the people who built it. Working with vendor documentation before sending anything to a production network should be a standard step, not an afterthought.

The organizational implication is procedural. Safe interrogation in OT environments should follow a change management process, even if the interrogation itself does not modify any device configuration. The operations team should know what is being sent, when, and to which assets. The control room should be informed. There should be someone available to respond if a device behaves unexpectedly. This is not bureaucratic overhead. It is the same discipline applied to any other activity that could affect process operation. Security practitioners who resist this structure are importing IT assumptions about what constitutes a non-impacting action into environments where that framing does not hold.