VPN Design

What a VPN is and is not

A VPN builds an encrypted tunnel between two points across a network that neither trusts, and it authenticates the points before it does so. That protects the traffic from being read or altered on the way, and it ensures the remote party is who they claim. It does nothing about what they do next: a VPN that lands an engineer on the control network gives that engineer, and whatever is on their laptop, the same access as a cable in the control room. The design therefore separates transport from authorization: the VPN carries the connection to a place in the DMZ, and the jump host, the firewall rules, and the SCADA roles decide what happens from there.

User access

1. 1

   Concentrator in the DMZ

   The VPN terminates on a device or a service in the DMZ, on the firewall or a dedicated appliance, with the internet on one side and the DMZ on the other. Nothing terminates on the control network.

2. 2

   Individual accounts and multi-factor

   Each user, staff or vendor, has their own account tied to the directory, with multi-factor authentication required for every connection, and the account disabled when not needed for vendors.

3. 3

   No split tunneling

   While connected, the laptop routes everything through the utility; it cannot be on the internet and the utility at once, which is how a compromised laptop bridges the two.

4. 4

   Posture and restriction

   Where the concentrator supports it, a check that the laptop is a managed device with current protection, and a restriction to the jump host address and port only.

5. 5

   Land on the jump host

   The only thing a VPN user can reach is the jump host. From it, with a second authentication and the jump host tools, they reach what their role allows, and every action is logged.

6. 6

   Expire

   Sessions time out; accounts expire; vendor accounts are enabled for a window.

Site-to-site

Cellular remote sites, a second plant, and an operations center connect to the main plant through site-to-site tunnels: each end has a router or a firewall that builds a tunnel with the other, authenticated by a certificate or a strong unique pre-shared key per site, over the carrier network or the internet. The tunnel makes the site part of the private address space; it does not make the site trusted. The firewall rules at each end still permit only the polling conduit and the engineering path, so that a compromised site reaches only what it is allowed to reach. Tunnels are monitored for status and rebuilt automatically, and a site whose tunnel is down runs on local control like any lost link.

The concentrator

• It faces the internet, so it is in the emergency patch tier: vulnerabilities in VPN appliances are exploited within days of publication, and utilities have been entered that way.
• Logging of every connection, authentication success and failure, source address, duration, and the account, to the collector.
• Monitoring for failed logins, logins from unexpected countries or at unexpected hours, and concurrent sessions on one account.
• Administration only from the engineering zone or the console, with its own strong credentials and multi-factor authentication.
• The certificate and key material in the vault; expiry tracked.
• A review each quarter of who has VPN accounts and whether they still need them.

Alternatives and additions

Some utilities use a remote access service that reverses the connection: an agent in the DMZ connects outward to a broker, and remote users connect to the broker, so that no inbound port is open on the utility firewall. The principle is the same: the user lands in the DMZ on a jump host, with multi-factor authentication, logging, and role-based access, and the broker is a service the utility has evaluated. Whatever the transport, the tests are whether an outside scan shows an open port, whether a connected user can reach anything but the jump host, and whether the session appears in the log.