Why nobody actually segments the plant network

Ask anyone who runs a plant whether the network should be divided up — office here, control systems there, a controlled gate between them — and they will say yes. It has been the standard advice for twenty years. Every audit recommends it. Every incident report concludes with it.

Now ask how many plants have actually done it.

The gap between those two answers is not budget, and it is not ignorance. It is much simpler than that, and once you see it the whole problem changes shape.

The real reason it never happens#

Whoever turns on the rule owns whatever stops working.

That is the entire obstacle. If you block something that turned out to be important, the plant has a bad day and everyone knows whose change caused it. If you do nothing, the risk stays theoretical and nobody's name is on it. Faced with that trade, any sensible person finds something else to work on. So the project gets planned, discussed, quoted, and quietly deferred — often for years.

Notice that this is not a security problem. It is a confidence problem. People are not refusing to build the wall; they are refusing to guess where the doors go.

Why the usual starting point makes it worse#

The normal way to begin is with a reference diagram — the layered picture, plant at the bottom, business at the top, tidy arrows in between. It is a genuinely good teaching tool and most of us learned from it.

But it is a picture of a plant in general. You are being asked to apply it to yours, and yours has fifteen years of history in it: the system somebody added to watch the pumps, the report that runs at 4am, the connection an integrator set up in 2019 that nobody has touched since.

None of that is on the diagram. All of it is on your network.

So you end up writing rules from a map of somewhere else, which is exactly the situation that makes people nervous — and they are right to be.

The cheap thing almost nobody does#

Before drawing any boundary, watch the network and write down who actually talks to whom.

That is it. No product, no project, no consultant. A machine that can see the traffic and a day of patience. You end up with a list: this system talks to that one, in this direction, for this purpose. Then you write your rules from the list instead of from the diagram, and the fear mostly evaporates, because you are no longer guessing.

I had been telling people this for a while without ever having done it properly myself, which is a bad look for advice. So I did it on my own plant — three sites, a control room pair, a database, the usual — and watched everything for a day.

Three things came out of it that I did not expect.

One: a quick look is worse than useless#

I first watched for three minutes, which is roughly what "I've had a look at the traffic" means in practice. It showed 48 conversations.

Watching for a day showed 261.

The four-fifths I would have missed were not exotic. They were the things that happen every hour, or once a night, or only when something fails — the backup, the certificate renewal, the scheduled report. Which means they are precisely the conversations a new rule would block silently, with the damage showing up days later, long after anyone would connect it to the firewall change.

If you take one practical thing from this piece: whatever period you were planning to watch for, it is too short.

Two: the textbook had one thing backwards#

I wrote down what the standard diagram said my plant should be allowed to do, and compared it to what my plant actually did.

It got one rule confidently right in a way that would have broken my plant.

The diagram says the sites report up to the control room. Mine never does that — not once in a day. It works the other way round: the control room reaches out to the sites, and that is the single busiest conversation I have.

Here is why, without the networking vocabulary. When two systems connect, one of them dials and the other answers. It feels like it should not matter which. But I run two control room servers, a main one and a standby, and configuration only copies from the main one outward. If each site dials in to the main server, the standby never learns those numbers. It sits there looking healthy, with no way to reach anything.

I found that out the unglamorous way: I switched the main server off. The screens moved to the standby in eight seconds, exactly as advertised. Nobody watching the control room would have noticed anything. Meanwhile the plant recorded nothing at all for six and a half minutes, because the standby had no relationship with any site and nothing said so.

So the direction is not a style preference. It is the difference between a backup that works and one that only looks like it does — and the textbook, followed faithfully, would have pointed it the wrong way.

That is the part worth sitting with. A rule that is correct while everything is healthy and wrong at the exact moment something fails is worse than having no rule, because you will trust it.

Three: one machine was in two places at once#

The last finding is the one I would look for first in anyone else's plant.

One of my machines does several important jobs deep inside the plant. It also quietly serves something completely unrelated, to a different group of people, and accepts connections from the public internet.

There is no zone for that machine. By what it does it belongs inside the wall; by what it is exposed to it belongs outside. No amount of drawing solves it. The only real fix is to split it into two machines, which means an outage, a migration and a conversation about who pays.

Almost every plant has one of these. It is usually a machine that picked up a second job years ago because it happened to be there and had capacity. Finding it is worth more than the policy you were trying to write.

What the diagram forbade#

Worth saying what the twenty-two disagreements actually were, because they sound alarming and are not. A system that checks every machine is still alive. A site writing its own records directly into the central database, because that is the one path that survives the link going down. The two control room servers keeping each other in step. Announcement messages that are not addressed to anybody in particular, which no rule written as this one may talk to that one will ever account for.

None of that is bad practice. It is what a working plant is made of, and it is invisible to a diagram drawn before most of it existed.

What I would actually do#

Watch before you draw. A day, not an hour. You are making a list, not a report.

Write the rules from your list, then compare that to the textbook diagram. Where they disagree, treat it as a question about your plant rather than a mistake. Some disagreements will be things to fix. Twenty-two of mine were simply things the diagram did not know about.

Check what each rule does during a failure, not just on a normal day. Turn something off and watch what stops.

Expect to find a machine doing two jobs, and treat that discovery as the real result.

None of this needs a purchase. It needs a day of watching and the willingness to write down what is actually there — which is the part nobody does, including, until recently, me.

The full method, the numbers, the complete list, and the four mistakes I made in my own measurements are in the lab notes. The failover that explains the direction problem is written up here, and the piece where I gave this advice without evidence is here.

Once the list exists, the next question is what to build from it: the wall between office and plant, and the rules inside each room that most plants never write — one firewall is not segmentation.