OT security for control systems — protecting a plant that cannot be rebooted

Control systems were designed when they were isolated, and they are not isolated now. They were connected to the business network for production data, to the vendor for support, to a historian, to a maintenance management system, and each of those connections was individually sensible.

The difficulty is that the equipment at the end of them was designed on the assumption that anything talking to it was authorised. A controller that accepts a command does not generally ask who sent it.

Why the IT answer does not transfer

In an IT environment the usual priority order puts confidentiality first. In a control system it is close to reversed, and for a defensible reason: a plant that cannot be seen or operated is a hazard, not an inconvenience.

Three consequences follow, and they shape everything else.

It cannot be rebooted at will. A patch that requires a restart requires a process outage, or a redundancy changeover that carries its own risk.

The patch may not exist, or may not be allowed. Control system suppliers validate operating system patches against their product, often slowly and sometimes not at all. Applying an unvalidated patch is an uncontrolled change to a system the plant depends on.

The equipment lasts twenty years. A controller commissioned in 2006 is still running the process, has no vendor support, and will not be replaced this year or next.

Zones and conduits, in plain terms

IEC 62443 is the reference standard, and its central idea is simple enough to use without adopting the whole framework.

A zone is a group of assets that share a security requirement — the safety system, the control system, the DMZ, the enterprise network. A conduit is the managed pathway between two zones: an enumerated, restricted, inspected connection carrying only the traffic the design intends.

The value of the model is that it turns a vague question into a specific one. Instead of asking whether the control system is secure, you ask: what are the zones, what crosses between them, who authorised each crossing, and is that still the configuration today.

The three routes that go around the architecture

The maintenance laptop. On the office network in the morning, email and browsing, plugged into a controller in the afternoon. It bypasses every boundary because it is carried through them. The control is dedicated machines that never leave the control zone, kept patched and checked, and an explicit rule that general purpose laptops do not connect.

Vendor remote access. Opened during commissioning, left enabled, credentials shared among the vendor’s engineers and sometimes across their customers, with no record of when it was used or by whom. The control is not to refuse remote support, which is often genuinely necessary, but to make each session requested, approved, time-limited, supervised from the plant end and logged.

Removable media. A drive carrying a configuration backup, a vendor patch, a report. It crosses every boundary at once, by hand, and leaves no trace. The controls are a scanning kiosk, issued and controlled drives, and disabling the ports that are not needed — which is what the red block in the photograph above is.

Patching what cannot be patched

The honest position on most operating plants is that a substantial part of the control system cannot be patched to current, and will not be replaced soon. Pretending otherwise produces a risk register entry that is restated annually and never closed.

The workable approach has four parts.

1. Know what you have. An inventory of every device, its firmware or operating system version, its support status and its network connections. Most plants cannot produce this, and producing it is the single most useful thing a security programme does first.
2. Patch what can be patched, on the vendor’s validated list, during planned outages, with a tested rollback.
3. Compensate for the rest. Tighten the zone around the unpatchable asset, restrict what can reach it to the minimum, and monitor that boundary rather than the asset.
4. Fund the replacement. Obsolescence is an engineering programme with a date and a budget. A security finding that depends on a replacement nobody has funded is not a finding that will be closed.

Detection, which is what is usually missing

Most plants have some separation and almost no visibility. The question “has anything unusual happened on the control network” cannot be answered, because nothing is recording.

Passive network monitoring on a control network is well suited to the environment: traffic is repetitive and predictable, so a new device appearing, an unexpected protocol, or an engineering command outside a work window is genuinely anomalous in a way it never is on an office network. It is also entirely passive, which matters where active scanning can knock over an old controller.

Alongside that sits the simplest detection of all, which is a controller configuration compared periodically against its approved baseline. A change nobody can account for is the finding.

Where this starts

For a plant beginning from nothing, the order that produces most benefit soonest:

1. An asset inventory, including network connections.
2. A network diagram that matches reality, produced by looking rather than by asking.
3. Removable media control and port blocking.
4. Vendor remote access brought under per-session approval.
5. Backups, offline, tested.
6. Dedicated maintenance machines for the control zone.
7. Segmentation improvements and monitoring.
8. A funded obsolescence plan.

The first two are not security measures and they cost almost nothing. Everything after them depends on having done them.

Where this goes next

• Control system architecture — the zones this topic is securing.
• Safety instrumented systems — the layer whose independence has to be preserved.
• Proof testing and partial stroke — change control and bypass discipline in the safety system.
• Alarm management — the other place where configuration drifts away from the approved design.