Securing IP control protocols

 have a dream that all IP-based SCADA field communications are protected by a common security protocol. The security protocol authenticates the source and data integrity of each packet and offers optional encryption. In my dream, process control vendors of applications, field systems and communication equipment all implement the secure protocol because it is inexpensive and ubiquitous. It is found in almost every process control Ethernet card or chip set. In fact, the vendors are happy to do this because they no longer need to worry about different security requirements for Modbus TCP, ProfiNet, DNP3 and the myriad of different protocols encapsulated in IP. The system users are thrilled because they don’t have to analyze a variety of proprietary solutions or conflicting security standards.

Is it impossible for all SCADA IP control protocols to implement a common security protocol? The answer is in the question. When the serial protocols wanted to transit over IP networks they all found a way to encapsulate their individual serial protocol formats into the same IP protocol. So there is no technical reason why a common security wrapper could not protect the various IP-based SCADA protocols.

IPsec is a practical demonstration that the dream can be realized. Routers, VPN products, firewalls and other IP products all protect a wide variety of protocols at a higher layer using IPsec. In fact, IPsec would be a viable option if it were not so verbose as to affect performance in the many segments of the process control world. Some of the problems with IPsec include overhead of 50-bytes per packet in the most common mode, five roundtrip packet communication to establish a security association (SA) and two roundtrips for a re-key, and a larger than necessary impact on CPU and memory.

The task at hand for the industry is to create an IPsec-like protocol that meets SCADA and DCS system performance requirements. Creating this protocol is not a difficult technical problem and would likely include some of the following features:

• A brief field, probably a control byte, prior to the control message.  The control byte would indicate what protection is provided, field lengths, post processing and other security settings.
• A longer security field that includes the secure hash (a secure check sum) occurring at the end of the packet to allow for post processing in demanding environments.
• A variable length security field for the secure hash that allows the system to provide the appropriate level of security and address strict performance requirements.
• Support for standard crypto algorithms that are commonly found in chipsets and crypto API’s, such as Microsoft’s Crypto API or the Intel chipsets.  
• Require no handshaking to process a protected message. While this may be difficult in an open environment, SCADA and DCS networks are typically closed and do not have unknown and unassociated devices.

The harder issue is gaining the support from all of the parties who would need to cooperate.  Even identifying an organization that would lead this effort is a challenge. Is it the IETF, the organization that developed IPsec? IETF is not a significant player in the SCADA and DCS arenas. Is it an industry organization like ISA or IEC? Do these organizations cover enough of the SCADA and DCS markets, and can any of these organizations get support from other organizations that are often viewed as competitors? What about a U.S. Government-led effort under the auspices of DHS or the Department of Energy? Would the world accept a US based solution? 

Whoever is going to potentially save the industry from a plethora of incompatible security algorithms better get started soon. The window is beginning to close as a number of disparate SCADA protocol security standards are under development. The American Gas Association is looking at IP security in AGA 12-3; IEC is writing standards for securing the IP layer; and there are probably efforts under consideration in most of the protocol organizations.

If the industry can come together on a standard it could see a highly secure, high performance security protocol integrated into Ethernet cards and available at an affordable price. Dare to dream.