On-premise and air-gapped analytics for operational technology

Air-gapped, used strictly, means no network path exists to the system at all. Data moves by physical media and nothing else. Very few industrial analytics deployments are air-gapped in that sense, and the ones that are pay for it in update friction.

What most sites have, and what most people mean, is a segmented network with controlled paths between zones. Traffic is permitted in specific directions, between specific hosts, for specific protocols, and everything else is denied. That is a different security argument and usually the correct one.

The distinction is worth insisting on early, because a proposal described as air-gapped that turns out to have a remote support tunnel is the kind of discrepancy that ends a security review badly. Describe what is actually there.

The Purdue reference model, which most industrial cyber standards assume, separates field devices and control at the lower levels from site operations above, with a demilitarised zone between plant and enterprise. IEC 62443 describes the same idea as zones and conduits: group assets by risk and define and control every path between groups.

An on-premise analytics host generally belongs at the site operations level. It reads upward from control through a defined conduit and never writes back down. Placing it lower puts a general-purpose computer next to the process; placing it higher usually means the data has to leave the plant to reach it.

The conduit is the part worth specifying rather than assuming. Which protocol, in which direction, initiated by which side, through which enforcement point, and what happens to the process side if the analytics host disappears. A host that fails and takes a plant function with it has been placed wrongly, whatever the diagram says.

Egress of process data. Process data does not leave the site, which narrows the question of where data is stored, under whose jurisdiction, and who at the vendor can see it, to whatever remote support, update and backup paths the deployment keeps. Those paths are the ones to document.

Data residency and sovereignty questions. For assets with public or sovereign participation this is frequently a procurement condition rather than a preference, and it is easier to satisfy by architecture than by contract.

Dependence on an external service for plant-facing function. A cloud analytics service that becomes unavailable takes its output with it. An on-premise host has failure modes but they are the site's own and the site can act on them.

Third-party subprocessor exposure. Process data that stays on site does not traverse anyone else's infrastructure, which shortens the due diligence conversation to the vendor's own support and update arrangements.

Credentials. The host has accounts, the accounts have privileges, and how those are issued, rotated and revoked is the same problem it would be anywhere. On-premise moves the credential store; it does not eliminate it.

Patching. Software on site still needs updates, and an isolated host is harder to patch, not easier. Sites that treat isolation as a substitute for patching accumulate known vulnerabilities on a machine nobody can reach to fix.

Removable media. The classic route into an isolated system is a USB device, and the more isolated the system the more people reach for one. Media control has to be part of the design rather than a policy statement.

Remote support. Vendor assistance is wanted at some point on most deployments, and the mechanism for it is the real security boundary. A permanently open tunnel described as occasional access is the most common gap found in these reviews.

Supply chain. The software arrived from somewhere, built from components sourced from elsewhere. Isolation does not tell you what is inside the artefact you installed.

This is the practical difficulty in a genuinely isolated deployment and the one to design first, because it is where isolation is usually abandoned quietly. Models change: they are re-tuned, corrected, extended to new equipment.

The workable patterns are a controlled one-way import through a reviewed staging point, a scheduled maintenance window with a temporary supervised path, or a physical media procedure with signature verification and a documented chain of custody. All three are more work than a cloud update and all three are auditable, which is the point.

What matters more than the mechanism is that the update path is designed, documented and rehearsed. An undesigned path becomes an undocumented one, and an undocumented path is the thing an assessor finds.

It also argues for a model architecture that does not need frequent updating. A physics-based layer changes when the plant changes; a purely statistical model needs re-fitting whenever the operating distribution moves, which on a renewable-coupled asset is constantly. That is a security argument for physical constraints as well as an accuracy one, and the accuracy side is covered in physics-driven AI against generic industrial analytics.

A data flow diagram naming every path, its direction, the initiating side and the enforcement point. Not a marketing architecture diagram: the actual paths, including the support one.

The privilege model. Which accounts exist on the host, what each can do, who holds them, and how they are revoked when someone leaves.

The egress statement. What leaves the site, if anything, including telemetry, licence checks and crash reports, which are the three that surface late and embarrass a vendor who said nothing leaves.

The patching and update procedure, including the model update path and who approves it.

The support model. How assistance is requested, what is opened, by whom, for how long, and what is logged.

The failure behaviour. What happens on the plant side if the host stops, which should be nothing, and how that is demonstrated rather than asserted.