Security Basics: One-way Diodes

(This article was originally published on the Findings From the Field blog.)

The Owl Computing Technologies presentation at the ICSJWG 2010 Fall Conference caught my eye. Owl has been showing up at more conferences lately, providing some competition for the incumbent industrial diode leader Waterfall Security Solutions. The question I had when I first heard of this kind of technology is “when would you use that?” The concept behind the diodes is simple: the diode hardware allows communication in only one direction. A diode can push data from one place to another, but it is incapable of sending any information back. How can this be useful in a world full of two-way communications protocols?

The answer is complicated, so let’s tackle an easier question first: when would you need this? Answer: You consider a diode any time you have a serious security problem. For example, Waterfall reports that their biggest markets are nuclear sites and sites in war zones.

When you have a serious security problem, you quickly conclude that you need an “air gap.” That is: you need to completely disconnect your enterprise network from your control network. A firewall is just not secure enough for some sites; a determined and resource-rich attacker can find zero-day vulnerabilities in your firewall and take it over. Once the firewall is controlled by the attacker, your control system can be compromised.

Air-gapping a control system is almost never a safety risk. Control systems, as a rule, are designed to run safely, indefinitely, without contact with other networks or business applications. However, while you can almost always run an air-gapped control system safely, you generally cannot run it profitably. Most modern enterprises rely on access to real-time data like current inventories, equipment runtime statistics and batch records. Communicating this information across an air gap manually – by voice over the phone, or on pieces of paper – tends to be unacceptably slow, costly and error-prone.

Enter diodes: having decided you must air-gap your control system, you find that you have valuable information which must be communicated across the air gap. A diode is a tool for communicating this information out of a very secure network.

How it works

This brings us back to the question of how diodes work. Almost all modern communications protocols are two-way – how can you run a two-way protocol over a one-way medium? Well, it turns out that diode hardware is pretty simple, but diode software is more interesting — each end of a diode hosts one or more proxy servers.

For example, consider the “OPC Classic” protocol. Let’s imagine we have a number of PLCs on an industrial network, and we want to make information in those PLCs available to an enterprise application, say a web server serving high level information to users on the enterprise network. For this information to pass through a diode, you need an opc server proxy on the enterprise side of the diode, and an opc client proxy on the industrial side.

OPC Classic Communications via a Diode

OPC Classic Communications via a Diode
The client proxy is configured to emulate the enterprise web server that is the real OPC client. The proxy needs to be configured to poll the PLCs in the same way that the web server client would poll them. The client then pushes the polled information across the one-way link to the OPC server proxy. The real OPC client connects to the OPC server proxy as if it were the server for the real PLCs and pulls information from the server, as if it had just arrived from the PLCs. Both the server and client proxies use the two-way OPC protocol to talk to the real client and the real OPC server, but the client proxy uses the one-way protocol to send information to the server proxy, and receive nothing back from that server proxy.


How does the OPC client proxy know the OPC server proxy successfully received the information transmitted across the one-way medium? In short, it can’t. Nothing about the transmitted information can be returned to the industrial network from the enterprise side. Now, no communications medium is perfect – how do you deal with data that is lost or corrupted as it passes across the diode hardware? In the OPC example, it may not matter – the web site is likely more interested in current information than in a missing piece of historical information.

There are times, however, when the loss of a piece of information may be critical. In these cases, the enterprise / receiving side of the diode can detect data loss or corruption with the usual checksums and sequence numbers. The receiving proxy can also raise alerts and notify people when such losses are detected. Waterfall Security reports that, depending on the configuration, the sending side of their diodes keeps between several hours and several days of already-transmitted data buffered and ready to retransmit if necessary. When network administrators are notified of data loss, they can walk over to the sending side of the diode and manually trigger a retransmission of the lost data. That said, the diode vendors select communications hardware which is extremely reliable and so you tend not to see data loss or manual retransmissions in practice.


The secret to diodes is, therefore, in the proxies. You can send many kinds of two-way protocols over a diode if you have a pair of proxies for those protocols. This is where diode vendors differ. There are a number of diode vendors in the military/defense market with proxies designed for that market. Waterfall Security is currently the leader in the control systems diodes market, with the broadest selection of industrial-focused protocol proxies available.

The most frequently-deployed proxies in industrial markets appear to be data historian redundancy proxies. That is – proxies which let you replicate a data historian inside a critical network to a historian outside a critical network. You air-gap the industrial network and set up a diode to connect the two historians. Each historian thinks the diode is another historian. The historian on the enterprise network gets a copy of all of the data from the control historian, and your end users and enterprise applications use the copy of the data on the enterprise network because they have no access to the control historian. Waterfall has these proxies for major data historians, and Owl supports major historians as well.

Deciding to use a Diode

Diodes generally cost more than a firewall costs to install because both of the diode’s proxies need to be configured, which tends to be more complex than configuring a firewall rule. On the other hand, once your proxies are configured they tend to need less stringent reviewing than do firewall rules, because no matter how the proxies are configured, they cannot allow intruders into the more secure network from the less secure network.  And of course you will still need to pay to communicate information manually in the “other” direction across the air-gap, though to be fair, that cost is really a consequence of your decision to use an air-gap, not your decision to use a diode.

Note: If you decide to use a diode, you will be tempted to use removable media like USB flash sticks when you need to communicate information from less-critical networks to diode-protected, more-critical networks. As the Stuxnet worm just demonstrated, using USB flash sticks can be very dangerous. Any information or media carried across a diode in “the other direction” must be considered suspect. At many sites, an imperfect, but practical, way around the problem is to set up a second diode serving a very limited set of file types across a proxy like an FTP server.
In practice, it is still possible to transmit malware across such a diode – for example you could transmit a Siemens S7 project file across a file transfer diode, a project file containing the Stuxnet worm. To prevent such compromise of your critical network, you will need to be very diligent as to what kinds of files are permitted across this second diode.

We are starting to see diodes used at NERC-CIP sites, because of the reduced cost of compliance. Time will tell if we see increased use of diodes to improve control system security due to the threat of sophisticated malware like the Stuxnet worm, targeting industrial control systems.

1 comment:

  1. I have received feedback on this posting and would like to clarify a couple of things for the record:

    - When I said "diode hardware is pretty simple" I meant "simple in concept." In fact, the hardware tends to represent a significant engineering effort, reflecting the requirements for extreme reliability to make retransmissions extremely unlikely, high speed, hardware redundancy, and elimination of hardware-based covert channels.

    - In the redundant control / enterprise historian scenario, readers should understand that enterprise clients do not see a "copy of the data from the control historian," rather, enterprise clients interact with the enterprise historian. Data from the control historian has been sent via a diode to the enterprise historian, and enterprise clients have the full power of the historian instance on the enterprise network at their disposal to analyze the historical data.

    - My use of the term "proxy" seems confusing as well. I meant the term in a more abstract sense than readers seem to be interpreting it. I used "proxy" to mean "any piece of software which emulates another server for the purposes of streamlining or securing communications." If you are familiar with web proxies or email proxies or other security technologies called "proxies" which typically run on advanced firewall / unified threat managers, you will know that those proxies are bidirectional. The "proxy" components which I describe as part of diode solutions emulate bidirectionality, but in fact transmit information only in one direction through the diode hardware.

    For example an OPC proxy on the enterprise end of a diode will accept commands from an enterprise OPC client to poll a device on a regular basis. The proxy however, clearly cannot poll the device on the protected network, because the diode prevents any such commands from reaching the protected network. Instead, the enterprise proxy acknowledges the polling instructions from the OPC client and behaves as if the proxy had polled the device regularly. In fact though, the proxy provides to the enterprise OPC client whatever device data the protected end of the diode sends to the enterprise side of the diode, on whatever schedule the protected end of the diode sends the data.

    Different vendors have different names for the various components of their solutions. I don't know if any of them use the "proxy" term the way I have tried to use it here to simplify descriptions.

    As always, feedback like the above is welcome, either as comments here, or in email or voice-to-voice.