Pinhole communication with air gapped network

Question

A long time ago ago I worked for a small bank. We used a physically separated network to host our internal servers that handled all the transactions, as well as the workstations accessing the system.

One day someone came along and wanted to build a perl-based web interface for it, and basically tried putting an internet-connected server in our secure server area and plug it directly into the bank server with cat5. This was, of course, promptly denied.

But that made me think; and now, many years later I'm still thinking about it. How can you efficiently "air gap" a network and yet provide services to an outside world?

My idea was as follows.

• Set up an physically separated network with a server hosting critical data (bank accounts, transactions, electrical grid services, voting records, etc). Ensure all normal security procedures for air gapped networks, etc, etc.
• Set up a slightly less sensitive (but still highly secure) internet-connected network for hosting application servers, and beyond that somewhere towards the perimeter, the actual web servers, load balancers, firewalls and so on.
• Run a serial cable between two hosts on the two networks.
• Any communication between the networks, say for inquiring about a balance, posting a transaction, and so on, needs to happen over the serial cable. Any request should also be properly cryptographically signed, so the ultimate authorization lies with the secure servers on the air gapped network - they don't trust anything coming in over the serial wire unless it's cryptographically validated and authorized.

My reasoning here is that once you connect a cat5 cable to a server, there's so many different kinds of traffic potentially occurring on that cable (even with proper firewalls). You can have intruders moving laterally through the network, misconfigured firewalls, there are 65000 possible ports on it and you're using 1 of them - by using a serial cable you're drastically minimizing attack vectors. Of course you still need to secure the software stack behind the serial cable, and there are several other attacks possible here, but I just kind of feel good about limiting the traffic to a custom protocol over a dumb serial cable - kind of like the bridge over Khazad-dûm, if you know.

The downside is that a serial cable is not particularly effective. At 115 kbit/s, it's going to struggle compared to a regular 1 Gbit/s link. I suppose you could use multiple serial cables...

So...

1. Is this a good idea?
2. Are there better ideas?
3. Is there a practical alternative to a serial cable that still doesn't bring a whole network stack with it?

Answer 1

An air-gap is used as a complete separation between networks with different security requirements. You don't want this kind of full separation since it makes data exchange impossible. Instead you want to have as much separation as possible. Especially you want to make sure that no data from the maybe already compromised lower security network might harm the higher security network.

In the easiest case data should never flow from the low security network to the higher security network at all, but only in the other direction. A use case for this is for example the transfer of log and status data from an industry network into the monitoring network for log aggregation, display and analysis. Technologies in this area are data diodes which guarantee that data can only flow in one direction, sometimes guaranteed by hardware and sometimes by minimal and easy to audit software stacks like microkernels.

The more complex case is restricted bidirectional communication. In this case attacks from the lower security network might happen at various layers: from network layer up to the application layer. Your idea of using a serial line tries to reduce attacks at the network layer by replacing the large attack surface of a full and complex network stack with the hopefully smaller attack surface of a more simple serial line interface.

You also try to deal with attacks at the higher layers by accepting only signed packets from the lower security network. But since the lower security network might have been compromised, the attacker might also have access to the secrets needed for the signature and is thus able to sign any kind of payload he wants. This means you should not trust anything coming from the low security network, even if it is signed.

Instead you need to make sure that only payloads gets send from low to high security network, which are fully expected at the high security network and thus will not cause harm there. In the easiest form this might be a fixed set of messages which are allowed. More complex are a fixed set of messages which can be slightly parameterized, in which case you need to validate that the parameters match the expectations. Depending on the actual requirements regarding data transfer and the costs of failure such validation and maybe sanitization or transformation of the payload can be really complex. And of course, it might contain exploitable bugs too, so you also need to protect the validation itself. In higher security environments (like government, banks or energy sector) one might opt for dedicated gateway devices with a hardened and minimal OS which only have this one task of validating, sanitizing and transferring payloads in specific protocols and which can be more easily audited because of the lower complexity.