Industrial cybersecurity: Protecting OT from IT

A powerful technique for protecting OT from IT, or to enforce whatever separation is required to ensure the integrity of industrial control infrastructure, involves controlling the direction of traffic into or out of an ICS enclave. At first glance, it might seem counterintuitive to restrict bidirectional traffic between OT devices and management systems, but closer inspection reveals that across IT/OT interfaces, almost all data flows are from OT to IT systems, and hardware unidirectional flow assurance provides strong risk reduction for OT.

Most information flow in OT/ICS environments involves communications from control systems to IT systems. This enables continuous and effective monitoring of critical industrial control functions and equipment status. Modern industrial enterprises have long since learned to profit from real-time access to operations data, through programs ranging from predictive maintenance to comparing details of operation across facilities to enable enterprise-wide optimization and operations best practices.

A primary cyber security OT risk involves malware or remote attackers finding their way into the ICS infrastructure to degrade operations, block telemetry flow, or alter configuration settings. Assuming the devices are manufactured correctly (i.e., no malware inserted by developers), this risk can only be realized only in the presence of an information flow channel into ICS devices from the network infrastructure hosting the IT systems.

This information flow channel may be physical, for example a USB drive carried past physical security, or via online IP or other messaging. Modern industrial sites generally eliminate as much as possible physical information flows, by banning removable media and transient devices such as vendor laptops, and implementing security controls that make it impossible to mount such media on control equipment, or connect unauthorized devices to control networks. What remains is to control the online attack channel.

A paradigm thus emerges for data flow management through designated unidirectional gateways that can assure such control in all cases. The operational objective is that upon deployment, telemetry from ICS devices to the external network is permitted to support industrial control monitoring, but that reverse flow from the external network to the ICS devices would be prevented to prevent malware infections.

Unidirectional gateway protection of ICS devices from malware

The implication of such flow management is profound, because if the underlying unidirectional device design is sound, then one can make the physical argument that malware cannot flow toward the control system network. For many years, air gap arguments were weakened by end-around paths in complex networks because IT monitoring of OT systems had so much value. Unidirectional Gateways enable this very valuable monitoring function, while physically preventing any potentially compromising information from reaching the protected ICS system.

The physics of unidirectional gateway design supports transmit and receive flows using the optical characteristics of light. Without getting too much into the physics, security experts can take comfort in the fact that a so-called TX (transmit) laser sends data across a gap medium to an RX (receiver) in a manner that ensures that information can physically flow in only one direction, but not in the reverse.

This type of strong flow direction management allows for security policies to be written and enforced on OT/ICS infrastructure regarding malware. For example, an OT infrastructure could have the following operational requirement imposed on its operation in the presence of a unidirectional gateway: “The organization shall ensure that malware cannot flow into the OT/ICS infrastructure.” This is a powerful cyber security requirement for SCADA protection.

Unidirectional gateway design

An apparent challenge in the presence of a unidirectional gateway is modern communications protocols – almost all such protocols are query/response. How can response data reach IT consumers who can profit so much from the data, if no queries can reach the ICS data sources? The solution lies in the unidirectional gateway software, which replicates database servers and other servers. The software in the control-system source network queries control servers, sends data and updates through the unidirectional hardware, and on the receiving network, inserts the data into identical / replica servers. IT users and applications send their queries to the IT replicas, and get the same answer from the replicas as the live ICS servers would have given.

Another challenge is the apparent requirement for commands to flow from the external environment to the ICS devices. Reconfigurations, patching, updates, and other control commands, for example, might need to be issued from IT servers to the deployed OT/ICS servers and devices. Unidirectional gateways would disallow such functionality.

Most often, this need is an illusion. For example, automatic security updates might seem to warrant an inbound communications channel, but the engineering change control discipline demands extensive testing of such updates over a long period of time. An automatic inbound channel makes sense when security updates enter a network daily – such a channel reduces manual labor, errors and omissions in copying updates daily to removable media and carrying them across the perimeter. But in a system where security updates cross the perimeter in batches, only every 3-6 months, an automatic inbound channel introduces more risk than it alleviates.

A more common requirement is for anti-virus updates to enter protected control systems reasonably regularly, and batch instructions in the form of XML production orders to enter frequently as well. These information transfers are more disciplined than the arbitrary “access” connections, and can be inspected in much more detail to determine that the transfers are safe.

This need can be met by replicating servers, or subsets of servers, from untrusted IT networks into control networks. This can be accomplished by deploying a reversible “FLIP” device – a unidirectional gateway whose orientation reverses on a schedule.

Unidirectional gateway FLIP

The FLIP provides a disciplined method for inspecting and periodically permitting select content into unidirectionally-protected networks, in the rare cases where such content is deemed desirable. Given the unidirectional and scheduled nature of the FLIP, it is impossible to sustain an interactive TCP-like session through the device, even the most cleverly, stego-graphically hidden session.

For environments where the OT/ICS devices exist in a tangled web of local network infrastructure, perhaps with information flowing in many different directions from a variety of IT and OT devices, the security engineer might find a unidirectional gateway to be an awkward solution. It might be viewed as adding a motion sensor into the middle of a busy cocktail party, where the detection would trip constantly.

In such cases, it might be wise to rethink the overall OT/ICS architectural set-up. The decision to segregate SCADA controlled devices from IT support infrastructure such as DNS, Active Directory and anti-virus servers is a reasonable one, and would be recommended for any industrial network the enterprise deems important enough to protect thoroughly. One might say that the degree to which a unidirectional gateway, perhaps with flip capability, can be supported, is directly proportional to the segregation properties of that OT/ICS infrastructure.

Another apparent challenge to any unidirectional gateway integration involves existing or new ICS devices and management systems with intensely-bidirectional interfaces that cannot be interrupted by unidirectional flow. Most of the ICS ecosystems one can imagine would certainly have this requirement. The device might, for example, send telemetry to a system that is designed to provide back an expected heartbeat. This would seem fatal to the unidirectional concept.

A clever solution, however – one that greatly reduces the challenge of inserting unidirectional flow management devices into the existing device-to-control ecosystem involves functions resident on either end of the gateway, serving essentially like proxy capabilities, to emulate the function of the corresponding remote participant. Local devices, for example, would communicate with a local system proxy, and vice versa, so that the bi-directional protocol is properly supported on each network.

Support for ICS and control system bidirectional protocol

Solutions such as from Waterfall Security offer all these and other clever capabilities, which create impression that information producers are communicating bidirectionally with the corresponding information consumers, but with the Waterfall gateway communicating across the unidirectional connection. This set-up provides the malware flow protection advantages of a unidirectional gateway while still satisfying integration requirements for existing protocols and servers.

Interested readers should contact Waterfall Security directly to better understand the various configuration options. In most cases, the platform involves what amounts to a client on both sides of the IT/OT gateway. Specific configuration requirements will vary between different OT/ICS environments, and the cyber security experts at Waterfall Security can help match the platform to the local OT/ICS requirements.

Articles in this series

• Article One Provides an overview of the OT landscape, including an outline of the influential Purdue model
• Article Two offers an insight into how hackers have had success to date breaking into operational systems
• Article Three outlines the SCADA vulnerabilities associated with typical industrial control system architectures
• Article Four covers how innovations such as unidirectional gateways can be used to separate industrial networks from Internet-exposed IT networks
• Article Five provides a glimpse into the future of OT and SCADA systems in critical infrastructure.

The insights offered in these articles are intended to provide guidance for both traditional IT security experts, as well as OT engineers who might be new to cyber protection solutions. The optimal staff arrangement in any OT/ICS environment would optimize the OT experience and expertise of the engineers with the cyber security insights of the traditional enterprise IT security expert. These articles are intended to help both types of expert.

Contributing author: Andrew Ginter, Vice President of Industrial Security at Waterfall Security.