OT Network Security Monitoring Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does an inventory project expand into a full security programme?

The funded requirement is usually one sentence: tell us what is on the process network. Then segmentation comes up, because once you can see the network you can see how flat it is. Then remote access control, because the machine builder paths are now visible and someone senior is unhappy about them. Then identity, then a whole architecture programme. Each step is correct and each step pushes the inventory further away.

It happens here more than in information technology projects because visibility exposes so much at once. The first honest asset list in fifteen years generates a queue of legitimate work, and the queue arrives before the tool that produced it is even stable.

The fix is to hold the first release to one representative site: passive collection, parsers for the protocols actually present there, the asset inventory with process context, and the core engineering integrity detections. That is the $120,000 to $240,000, 16 to 24 week release, and it stays inside that band because it refuses the architecture work. Segmentation and remote access control are then better projects, because they are informed by a real inventory rather than a drawing from a 2016 upgrade.

What goes wrong with the asset data you start from?

You start with three artefacts and none of them are true: a network drawing from the last major upgrade, a spreadsheet a contractor left behind, and roughly fifteen years of undocumented additions that exist only in the memory of a maintenance supervisor who is two years from retirement.

Passive discovery then produces a second list, and the two do not agree. Devices appear that nobody expected. Devices on the drawing never speak, because they were removed, or because they are quiet, and passive collection cannot distinguish between those two states. That ambiguity is the real data problem in this category and it is routinely glossed over.

The fix is reconciliation as scope, not as an afterthought. Pair the discovered inventory with a physical walkdown, and record for every discrepancy whether it was resolved as removed, quiet or unknown. Anything still unknown after the walkdown is a candidate for a targeted, approved, read only query in a maintenance window, and the approval gets recorded per device. A developer or product that claims complete passive coverage with no caveats is overselling, and the caveat is exactly where your risk sits.

Why do the security operations centre and asset system integrations break after launch?

Sending industrial alerts into an information technology queue is the integration that fails most predictably. It does not fail technically, it fails socially. Analysts receive alerts naming a controller address with no idea what it does, cannot action them, start closing them, and within two months the feed is muted and both teams have learned to distrust the other.

The maintenance and asset system link fails differently. Two systems now hold device records, nobody agreed which is authoritative, and the security inventory starts overwriting a maintenance identifier that plant engineering depends on.

The fixes are translation and authority. Enrich every alert before it leaves the plant: which line, what it produces, the operational consequence of the affected controller, and the named plant engineering contact. Agree field level authority in writing before build, so the security system owns network observations and the maintenance system owns asset identity, with no writes across the boundary. And make the aggregation path strictly one way out of the plant, confirmed by the people who own the network, because the alternative is that your monitoring becomes a route into the process network.

What happens when detection stays generic and vulnerabilities are shown as a patch queue?

Generic detections and statistical baselining produce noise in a plant, because normal here means something specific: the expected sequence of operations, the expected value ranges, and the fact that a setpoint write from an engineering workstation at two in the morning means something different from the same write at ten during a scheduled changeover. A baseline learns the pattern without understanding the intent, so it alerts on the changeover and stays silent on the anomaly.

Vulnerability data fails in the same way. A prioritised patch list ignores that patching is scheduled against production outages that may be annual and often requires machine builder approval to preserve warranty. A list nobody can act on gets ignored, and once one report is ignored the next one is too.

The fixes: write detections jointly with your plant engineers, starting with engineering integrity events such as logic downloads, firmware changes, controller mode changes, new devices and new cross cell communication relationships. Most of those catch an unapproved contractor change long before they catch an attacker, which is exactly how the system earns credibility. Present vulnerabilities as exposure and compensating control: which vulnerable devices are reachable from where, what would have to be true for exploitation here, and what mitigation exists short of patching.

Should you build custom or configure what you already own?

Many organisations reading this should buy. One site, a modern and reasonably uniform control system, mainstream protocols and no restriction on sending telemetry off site: deploy Nozomi Networks or Claroty and you will have an inventory in weeks rather than months, and the remaining money is better spent on segmentation. Dragos has genuine depth in industrial threat intelligence, Armis and Forescout come at it from device visibility across the whole estate, and Tenable OT Security suits organisations already standardised there.

If you are an electric utility whose main driver is evidence for NERC CIP obligations, evaluate the products against your specific requirements before assuming a build, because several have invested in that reporting. Configure what you have properly first: protocol coverage settings and detection tuning are frequently left at defaults, which makes any product look noisier than it is.

Build when the constraints are structural rather than cosmetic: your most critical lines run protocols the products parse poorly, so the inventory is silent exactly where the risk is; detection must encode process knowledge only your engineers hold; process telemetry cannot leave the plant for contractual or commercial reasons; you run enough sites that per site licensing is a large recurring number; or you need this joined to your own asset and maintenance systems rather than sitting in a separate console.

How do hidden costs get into the quote?

Protocol parser work is the largest and the hardest to estimate in advance. Mainstream protocols are well understood. A proprietary or older protocol with no public documentation is genuinely expensive and sometimes requires the vendor's cooperation, which is a commercial negotiation rather than an engineering task. Survey what is actually on your networks before anyone quotes a number.

Site count and topology are second. In a layered control architecture the interesting traffic often does not cross a single point, so sensor placement is a survey exercise per plant rather than a repeatable installation.

Third are physical and safety constraints: hazardous area requirements for hardware, and safety instrumented systems, which carry additional restrictions and frequently a hard prohibition on any active interaction whatsoever.

Fourth, and the one nobody budgets, is the availability of your own engineers. You enter the plant when the plant lets you, validation waits for maintenance windows, and the schedule constraint is almost never the software. That is why 16 to 24 weeks is realistic even when the engineering itself is straightforward.

What separates a build that works from one that fails here?

Safety raised first, by them and not by you. A developer who does not immediately flag the risk of active scanning on a control network, or who proposes an agent on an engineering workstation without asking about vendor support agreements and warranty implications, should not be near your plant regardless of their security credentials.

Second, plant engineering treated as the client. The engineers control access, they define what normal means, and if they do not trust the project it will not be deployed no matter who signed the budget. Ask whether the developer has sat through a plant walkdown. The answer tells you a great deal.

Third, sensor health as a first class feature. A monitoring system that quietly stops collecting is worse than none, because it produces confidence without coverage. Absence of traffic from a sensor must be an alert, and the inventory should show its own freshness.

Fourth, the inventory built as an engineering record rather than a security artefact, carrying vendor, model, firmware, segment, the process area and line it serves, and the criticality of the process it controls. That last field turns a list into a decision tool, and it is why the plant will keep using the system long after the security programme moves on. Then settle ownership in writing before kickoff, because a complete map of your control networks belongs to you and not to a supplier.