Tec Nikan
فارسی
Talk to us
All posts

Why Your Network Diagram Is Wrong

Every plant has a network drawing, and every plant that has actually measured its network has found the drawing incomplete. What discovery turns up, and how to survive the result.

OT networksasset inventorynetwork discoveryIEC 62443industrial ethernet

Every plant has a network diagram. It is on a wall, in a drive, or attached to the last audit report, and it shows a tidy hierarchy of switches, a firewall, a handful of controllers and a supervisory layer. It is also, in essentially every plant where somebody has since measured the network, wrong. Not maliciously wrong and not carelessly wrong — wrong in the ordinary way that a document describing a living system becomes wrong, one undocumented change at a time.

The first reason is that the diagram records an intention rather than an installation. It was drawn during the project, approved before commissioning, and describes the network as designed. What got built differed in small ways — a port was already occupied so the cable went to the other switch, a device would not negotiate so a media converter was added, the contractor ran out of fibre and used a copper link nobody expected to be permanent. None of those are errors worth a change notice at the time, and all of them are still there years later.

The second reason is accretion. A network diagram is produced once and modified rarely, while the network changes every time someone adds a camera, a printer, an energy meter, a vendor's remote-access box, a wireless bridge to the warehouse, or a laptop that quietly became a permanent historian. Each addition was reasonable, most were made by people who never saw the drawing, and there is no natural moment at which anyone is obliged to update it.

The third and most consequential reason is that the diagram shows physical topology while the interesting questions are about reachability. Which devices can talk to which? A drawing of switches and cables does not answer that. VLAN assignments, access control lists, routes that exist because someone needed them for a week in 2021, a firewall rule with a permissive destination, a dual-homed engineering workstation bridging two zones that the drawing shows as separate — these determine what an intruder or a broadcast storm can actually reach, and none of them appear in the picture.

So the honest starting point for any segmentation, monitoring, or security programme is not the drawing. It is measurement. Passive discovery is the right first instrument: a span or mirror port feeding a tool that reads traffic without transmitting anything gives you an inventory of what is actually speaking, what protocols they use, and which pairs actually exchange data. It is safe on production networks precisely because it emits nothing, and it finds things nobody expected — a spare controller still powered and still polling, a supplier's cellular router, a duplicate IP address that has been causing the intermittent fault for two years.

Active scanning has a place, but a smaller and later one. Some industrial devices respond badly to port scans and unexpected traffic, and a scan that resets a controller during production will end the programme rather than the vulnerability. If active discovery is needed, it belongs in a planned window, on a known device population, with the vendor's guidance on what its equipment tolerates, and with someone in the control room who knows what is happening.

What to do with the result is where most of this work is either won or wasted. The instinct is to redraw the diagram accurately and file it, which reproduces the original problem on a shorter timescale. The better outcome is a live inventory — a system that keeps looking, flags new devices when they appear, and records a change rather than requiring a person to remember one. The drawing then becomes a rendering of the inventory rather than an independent artefact, and it can be wrong for hours instead of years.

Two practical cautions. Expect the first discovery run to find more devices than anyone predicted; a factor of two is common and is not evidence that the plant is badly run. And expect some of what it finds to be politically awkward — the remote access that a vendor uses and nobody formally approved, the network that the quality department built themselves. Deciding in advance that discovery is a fact-finding exercise rather than a fault-finding one is what determines whether people help you or route around you the second time.

The diagram is not useless. It is the design intent, and design intent is worth knowing. But it is a hypothesis about the network, and the network is the thing that will be attacked, will fail, and will have to be segmented. Treat the drawing as the question and the measurement as the answer.

Want to work with us?

Tell us what you're building and we'll help you scope the first deployment.