Interested in linking to "Securing IP control protocols"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
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:
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.
ControlGlobal.com is exclusively dedicated to the global process automation market. We report on developing industry trends, illustrate successful industry applications, and update the basic skills and knowledge base that provide the profession's foundation.