Equipment gateway security and critical infrastructure

A page for the information security team and OT engineers. In short: the gateway sits inside the site network, only reads equipment, and reaches the cloud itself over outbound HTTPS to 443. It accepts no inbound connections from the internet.

Network connections

The intake address is built into the build: a release gateway sends data only there, and an activation line with another address does not redirect it. The gateway checks the intake server against the system's certificate store. Cloud commands reach the gateway by long polling over the same outbound connection.

The way out to the cloud goes through a proxy if there is one: explicit in the settings file, or the machine's proxy (environment variables, on Windows also WinHTTP, PAC and WPAD). The gateway reaches equipment directly. OPC DA on another machine works through DCOM: TCP 135 and a dynamic port range. The recommended place for a gateway reading OPC DA is the OPC DA server's own machine; then no DCOM is needed.

Read only

This gateway build has no equipment write at all: the drivers have neither value writes nor method calls. Over OPC UA the gateway's session can read, subscribe and refresh the alarm list, and nothing else. There is no write switch in the settings, because there is nothing to write with.

What the site sets, not the cloud

• The address allowlist (equipment_hosts): a connection to an address outside the list does not start. The cloud cannot widen the list.
• Updates (auto_update = false): turns automatic updates off, and the cloud cannot turn them back on.
• The proxy and OPC UA certificate trust: the gateway does not trust an unknown server certificate until it is put into the trusted list at the site.

How to set these: the gateway settings file.

The gateway key

The gateway connects with a one-time code issued by someone who manages the organization's integrations: issuing the code is the approval of that gateway. The code works for a limited time. The key received for the code is kept in the system's secret store, together with the connection credentials the cloud sends. Revoking in the app ends the key at once, and the gateway erases the buffer of the revoked activation. One organization's data never leaves with another organization's key.

Running and updates

• Windows: a LocalSystem service with automatic start. The gateway closes its settings folder under %ProgramData% to the system and administrators, so a planted settings file cannot change the service's proxy or updates. An update package is checked by its signature, and if the new version does not come online, the service returns to the previous one.
• Linux, systemd: a dedicated system user, no privilege escalation, a read-only file system except the data directory.
• Linux, container: the process inside does not run as root. A Linux gateway does not update itself; the operator installs a new version.

For a source whose version has a known vulnerability, the connection row shows Source version vulnerability: … with the CVE number.

When the link drops

While there is no link to the cloud, the gateway keeps reading equipment and buffers data on its disk. Once the link is back it sends what piled up, and a repeat of the same batch creates no duplicates. The site sets the disk ceiling (buffer_max_mb). When space runs out, the oldest data is evicted, and the screen shows how many samples were evicted: a hole in the history shows as a number. After the link to an OPC UA server drops, the gateway reads what it missed from the server's history, if the server keeps one.

Critical infrastructure

The question is asked only of someone who marked the site as a Critical infrastructure object when adding it or under Site category. An ordinary site fills in nothing. The significance category is assigned by the site owner's commission; the cloud does not infer it.

Why a significant object is closed: FSTEC Order No. 239 does not allow remote software updates on it by people who are not the owner's employees, nor passing process information to the developer without the owner's control. The gateway keeps an outbound channel to the cloud and updates on the cloud's command, so such objects connect only through a separate setup: everything in Russia, and the owner installs updates. Until it exists, the site is closed. Safety systems cannot be told apart from the rest by protocol (the same Modbus and OPC UA), so the site owner answers.

Closure is worked out from the answer and deletes nothing. On a closed site the cloud sends the gateway no connections, installs no updates, takes no camera frames and issues no new codes. Gateways are not revoked, and connections and the data already collected stay. If the answer changes and the site opens, the cloud gives the gateway its connections back with the next configuration.

Checklist for the security team

• No inbound rules are needed. Allow outbound HTTPS to 443 from the gateway server to ingest.samreshuuu.ru, and for Windows with automatic updates also to the release storage.
• Put the gateway in the DMZ or on the SCADA server and limit its access to the plant network to the ports of the protocols you need.
• Write the addresses and networks the gateway may read into equipment_hosts.
• Decide whether updates install themselves. If not, set auto_update = false, and the operator installs updates.
• For OPC UA use secured endpoints and put the server certificate into the gateway's trusted list.
• Mark a critical infrastructure site and its category before assigning connections.
• The organization's data exports as an archive at any time, without gateway secrets and connection credentials. General storage and access rules: security.