A controller cannot run a security agent, and no plant manager will let you put a new box in the path of the line. That leaves exactly one safe place to watch from, which is beside the traffic.
MITRE ATT&CK techniques covered: T0842 Network Sniffing · T0846 Remote System Discovery · T0861 Point and Tag Identification · T0883 Internet Accessible Device · T0886 Remote Services
OT stands for operational technology: the systems that run a physical process. Pumps, valves, boilers, conveyors, turbines, building plant. Searched on its own the abbreviation returns occupational therapy and overtime, so it is usually written OT security or industrial control security to be unambiguous.
The surrounding terms are used interchangeably by people who are not certain which is which, and the differences matter when deciding what you need to monitor:
The priorities are inverted. In IT, confidentiality usually comes first and a reboot is an inconvenience. In OT, availability and safety come first and an unplanned stop can be expensive, dangerous or both. That single difference rules out most of the IT toolkit:
In an IT network you can install something. In a plant you usually cannot. The controllers, drives, relays, sensors and human-machine interfaces that matter most were not designed to host software, are often long out of vendor support, and cannot be patched on your schedule because the process cannot stop.
So the question is not which agent to deploy. It is what can be learned from a copy of the traffic, without adding a single device to the control path. The answer turns out to be a great deal, because industrial protocols are far more descriptive than general network traffic.
Industrial protocols carry function codes, register addresses and device identity in the clear. Reading them properly turns a flow record into a description of what was actually asked of a machine.
A list of protocols is not a promise about your plant, so ask us before you assume. Protocol variants differ, newer engineering traffic can be integrity-protected, and serial links, PROFINET and an OEM's proprietary line protocol are each their own question. We will tell you what we parse on your estate and what we do not, in writing, before you buy anything.
Because these protocols answer identity requests honestly, a passive listener can build an inventory without scanning anything: vendor, model, serial number and firmware revision, read from the devices' own replies rather than from a spreadsheet somebody last updated three years ago.
Because it is built only from what the equipment volunteers, coverage is whatever your estate reveals rather than everything you own, and the report names the devices it could not identify instead of quietly leaving them out.
That inventory is then matched against published vulnerability data, prioritised by what is known to be exploited in the wild. We are realistic about this one: you already know your controllers carry unpatched issues you cannot patch on your own schedule. So the useful output is not a list of a thousand findings, it is the short list that changes what you would isolate, monitor or raise with your OEM. A report you cannot act on is worse than no report, because it exists.
Scanning an OT network to build an inventory is exactly the kind of activity that has knocked controllers offline in the past. Nothing described on this page involves sending a single packet to a single device.
The most useful OT signal is often not a known-bad indicator, because there may not be one. It is a change in the character of a relationship. A link between an engineering workstation and a controller that has only ever carried reads for months, and then one day carries a write, is worth a human look regardless of whether any signature matched.
The same applies to remote access reaching into the control network, and to control equipment that turns out to be reachable from the internet. Both are profile problems rather than malware problems, and both are visible from a mirror port.
Operational technology: the systems that run a physical process, as distinct from the information technology that runs the business. Written on its own the abbreviation is ambiguous, so OT security is the usual phrasing.
Protecting the systems that control physical equipment, where an outage or an unsafe state matters more than data confidentiality. In practice that means monitoring without touching: no agents on controllers, no active scanning, and no assumption that anything can be patched promptly.
OT is the broad category of every system that affects something physical. ICS, industrial control systems, is the part of it that actively controls a process. All ICS is OT; a building-management sensor that only reports a temperature is OT but not ICS.
SCADA is an architecture for supervising equipment spread over distance - a pipeline, a grid, a water network - usually with intermittent links and local autonomy. A DCS controls a single site as one tightly coupled system, typically a plant or refinery. The distinction is geography and coupling, not vendor.
A programmable logic controller: the device that reads sensors, drives outputs and runs the logic deciding when something physical happens. It is the thing at the bottom of the stack that an attack on OT is ultimately trying to reach.
Because the priorities are inverted and the constraints are different. OT ranks availability and safety first, controllers cannot run agents, active scanning can knock older equipment offline, and patching may need a maintenance window measured in months. Passive observation is the only method that is safe by construction.
No, and we would rather say so. Purdue is a useful way to think about segmentation, but passive observation cannot reliably tell a level-2 device from a level-3 one without knowing your design intent. We report what each device is and who it talks to; assigning levels is a judgement you and your integrator make.
No. The sensor receives a copy of traffic and never transmits. It is not inline, so it cannot add latency, drop a packet or interrupt a control loop. If it fails, nothing on the process network notices.
Most managed switches can mirror a port. Where they cannot, or where the switch is unmanaged, a passive network tap achieves the same thing without any switch configuration at all.
No. Identifying the equipment from its own traffic is part of what the sensor does, and in practice the list it produces is usually compared against the existing inventory rather than the other way round. Some devices stay unnamed because their protocol carries no identity to read - we show those as unnamed rather than guessing.
It would not be, which is why vulnerability context is matched at model level and ranked by what the device actually does and what it can reach, not listed exhaustively. A known weakness on an isolated device is a different problem from the same weakness on one reachable from the business network.
Then the industrial parsers stay quiet and you get the general network detection, which is the right answer. A tool that found OT findings in a network with no OT would be telling you something false.
Tell us whether you suspect something is already inside, or whether you want to measure what your current tools would catch. Either way you get a concrete next step.
Contact us