OT and Industrial Network Security Monitoring: How Do You Inventory a Plant Network You Are Not Allowed to Scan?

The question the plant cannot answer

An IT security manager asks a reasonable question: what is on the process network at the Ohio site? The plant engineering lead's honest answer is that there is a drawing from a 2016 upgrade, a spreadsheet a contractor left behind, and about fifteen years of undocumented additions. There are controllers from at least four vendors, several engineering workstations running an operating system that has been out of support for years because the licensed programming software will not run on anything newer, a couple of remote access paths a machine builder set up for support, and an unknown number of drives, sensors and gateways.

The IT team's normal answer to that question is a scan. On this network the answer is no. Older controllers can and do fault when they receive traffic they do not expect, and a fault on a controller running a process is not an inconvenience, it is a production stop or a safety event. So the standard IT playbook is unavailable, the plant team has no security tooling of its own, and the firewall between the two worlds has become a place where visibility stops rather than a boundary that is monitored.

That gap is why this gets funded. Regulators are increasingly explicit about asset visibility for critical infrastructure: electric utilities under NERC CIP have to identify and manage their cyber assets, and water systems in the United States operate under risk assessment obligations introduced by the America's Water Infrastructure Act. You cannot meet an obligation to know what you have with a spreadsheet from 2016.

Passive first, and why that constrains everything

The foundational design decision is that discovery must be passive. Instead of asking devices what they are, you watch them talk to each other and infer it. A network tap or a switch mirror port feeds a sensor that parses industrial protocol traffic and builds an inventory from what it observes: this address speaks Modbus TCP as a server, this one initiates DNP3 reads on a schedule, this station downloaded logic to a controller at 14:20 on Tuesday, this device announced itself with a vendor specific identity string that tells you the model and firmware.

Passive discovery has a real limitation: a device that never talks is invisible, and quiet devices exist. The honest answer is layered. Passive collection as the default. Selective active queries only for protocols and device families where the vendor documents a safe read only query, only during a maintenance window, and only with plant engineering approval recorded per device. Any product or developer who is relaxed about active querying on a process network has not been in a control room during a fault.

Sensor placement is the other constraint that shapes cost. In a Purdue style architecture the interesting traffic between the supervisory layer and the control layer often does not cross a single point, so you need sensors at several places per plant, then aggregation upward without letting the aggregation path become a route into the process network. In practice this means the data flows one way, out of the plant, through a mechanism your plant engineers will accept.

Where Claroty, Nozomi, Dragos and Armis fit, and where they do not

These are strong products built by people who understand this environment, and for many sites they are the right purchase. Dragos has genuine depth in threat intelligence specific to industrial control systems. Nozomi and Claroty have broad protocol coverage and mature interfaces. Armis and Forescout come at it from device visibility across the whole estate. Tenable OT Security suits organisations already standardised on Tenable. If your plant is modern and reasonably uniform, deploy one and you will have visibility far faster than any build.

Three situations push organisations past them. Protocol coverage is the first: every vendor supports the mainstream protocols well and then coverage thins for the proprietary or older ones, and it is usually a legacy line running something obscure that carries the most risk because it cannot be patched. If a sensor cannot parse the traffic on your most fragile line, its inventory is silent exactly where you needed it.

The second is detection quality. Products ship generic detections plus baselining, and both produce noise in a plant, because normal in a process network means something specific: the sequence of operations, the expected value ranges, the fact that a setpoint write from an engineering workstation at 02:00 is unusual while the same write at 10:00 during a changeover is routine. Encoding that requires your process knowledge, which is why the useful detections are always the ones written with your plant engineers rather than the ones in the box.

The third is data handling. Many industrial operators will not send process telemetry to a vendor cloud, sometimes for contractual reasons with customers, sometimes because the traffic reveals production rates and recipes that are commercially sensitive. Products offer on premise deployments with varying degrees of enthusiasm, and the licensing frequently assumes a connected model.

The inventory is the deliverable, and it must be an engineering record

Whatever else you build, the asset inventory is what the plant will actually use, and it will be used far more for engineering purposes than for security. Make it worth that. Each device should carry vendor, model, firmware version, address, the network segment and cell it sits in, the process area and line it serves, its communication relationships, and the criticality of the process it controls. That last field is what turns a list into a decision tool, and it comes from plant engineering rather than from the network.

Firmware and vulnerability context needs care. Knowing that a controller runs a firmware version with published advisories is useful. Presenting that as a patch queue is not, because in this environment patching is scheduled against production outages that may be annual and requires the machine builder's approval to preserve warranty. The useful output is exposure and compensating control: which vulnerable devices are reachable from where, what would have to be true for the vulnerability to be exploitable here, and what mitigation exists short of patching. A prioritised list that ignores the reality of outage windows gets ignored in return.

Detections worth having in a plant

• New device appearing on the process network, which is the highest value alert in the entire system and is close to trivial to generate once the inventory is stable.
• Engineering activity: logic downloads, firmware changes, controller mode changes such as run to program, with the source station and the time.
• Communication relationships that did not previously exist, particularly anything crossing between cells or reaching toward the enterprise network.
• Remote access sessions from machine builders and integrators, correlated with whether an approved support request exists.
• Setpoint and parameter writes outside expected ranges or outside expected windows, defined with your process engineers.
• Protocol behaviour that is technically valid but operationally wrong, such as a write function to a device that should only ever be read.

Notice how many of these are engineering integrity rather than intrusion detection. That is deliberate. In practice the same detections catch a contractor making an unapproved change and an attacker making a malicious one, and the first happens far more often, which means the system earns credibility with the plant before it is ever needed for the second.

What it costs and how long it takes

From the projects Digital Heroes has delivered, a first release covering passive collection at one site, parsers for the protocols actually present there, the asset inventory with process context, and the core engineering integrity detections runs $120,000 to $240,000 and ships in 16 to 24 weeks. The longer timeline compared with an equivalent IT project is not engineering complexity, it is access: you get into the plant when the plant lets you, and validating anything means waiting for a window.

The full platform adding multi site aggregation, process aware detection developed with your engineers, vulnerability and exposure context, integration into your security operations centre, and reporting for regulatory obligations runs $300,000 to $700,000 phased over 9 to 18 months.

Cost drivers specific to this domain: the number of protocols requiring parser work, since a proprietary protocol with no public documentation is genuinely expensive and sometimes needs the vendor's cooperation. Site count and network topology, because sensor placement per plant is a survey exercise. Safety instrumented systems, which carry additional constraints and often a hard prohibition on any active interaction. Hazardous area requirements for physical hardware. And the availability of your own engineers, which is the schedule constraint nobody budgets for.

What keeps it down: pick one representative site, cover the protocols present there, and prove the model before industrialising. Sites are more similar than they look once the framework exists.

When to buy instead

One site, a modern and reasonably uniform control system, mainstream protocols, and no restriction on sending telemetry off site: deploy Nozomi or Claroty. You will have an inventory within weeks and the money is better spent on segmentation.

If you are an electric utility whose main driver is NERC CIP evidence, evaluate the products against your specific obligations before assuming a build, because several have invested in exactly that reporting.

Build when your most critical lines use protocols the products parse poorly, when detection has to encode process knowledge that only your engineers hold, when process data cannot leave the plant, when you operate enough sites that per site licensing becomes a large recurring number, or when you need OT visibility joined to your own asset and maintenance systems rather than sitting in a separate console.

How to choose a developer

Ask about safety first. A developer who does not immediately raise the risk of active scanning on a control network, or who proposes an agent on an engineering workstation without asking about vendor support agreements, should not be near your plant.

Ask what industrial protocols they have parsed and at what depth, naming them. Reading Modbus function codes is not the same as understanding a vendor's proprietary logic download sequence, and the second is where the valuable detections live.

Ask how they will work with plant engineering rather than around it. The engineers control access, they know what normal means, and if they do not trust the project it will not be deployed. Ask whether the developer has ever sat through a plant walkdown, because the answer tells you a lot.

Ask how data leaves the plant and confirm the path is one way. Then ask what happens when the sensor fails: a monitoring system that quietly stops collecting is worse than none, because it produces confidence without coverage.

Get code and infrastructure ownership written into the contract before kickoff. At Digital Heroes the client owns the code from the first commit. A system holding the complete map of your control networks belongs to you, not to a supplier.