Protocol for SCADA field communications

Again, this is not a new problem. Frame relay and X.25 encryptors dealt with this exact problem in the past. However, these systems had a management system where changes were entered in a central location and automatically and securely distributed to all encryptors in the network. We would not recommend deploying a system of AGA 12 encryptors without a central address table management solution.

Market Demand
The second major question is . . .  Is there a market for a $500, bump-in-the line encryptor for serial SCADA communications? The market will ultimately decide this question, but for now I’m skeptical.

In our experience, the risks associated with serial communications are substantially lower than many other risks. We are seeing the need for better patching, strong authentication, IDS and security monitoring, protecting the control center from the field, secure remote access . . .  well ahead of protecting serial communications. NERC would seem to agree with this assessment since they have specifically excluded non TCP/IP communications.

Actually, it is interesting that most of the field site security solutions, firewalls and encryptors, are targeting a $500 price point. 

While the need for management and question of market demand are by far the most important issues, there were a few other issues worthy of comment.

The mode we would most likely recommend, a strong authentication-only mode, is not defined. Most control systems prioritize the security goals as

1. Availability
2. Integrity
3. Confidentiality

In many cases, confidentiality is a distant third. We would recommend a HMACSHA256 mode if it were available.

I was told that the committee felt that the processing power required to perform the public key calculations in a HMACSHA256 would support encryption. So the committee decided to include encryption. This is one of the ways that security professionals get labeled as unrealistic or paranoid by implementing protection that does not reduce a risk to the organization. There definitely should be encryption modes, but there should be authentication-only modes for asset owners where confidentiality is not required.

The standard wisely defines a mixed mode with both protected and unprotected communication going through a Secure Communication Module (SCM). An asset owner may not want to protect communications to all field sites. Also, mixed mode will support a phased implementation of the AGA-12 boxes.

The serial field communication is typically at a low data rate and may be very time sensitive. Waiting until the entire command is received and the security fields processed prior to sending to a PLC may introduce an unacceptable delay. The AGA 12 standard recognizes this and has holdback and non-holdback modes. Holdback processes the security fields and passes the commands if the signature and HMAC are valid. Non-holdback modes pass the data to the PLC as fast as possible and post processes the signature and HMAC. 

Responses to this article will be posted on the DitalBond.com SCADA Blog, along with contrary views and any other interesting feedback I get on this review. What do you think of AGA-12?

About the Author

Dale Peterson leads the SCADA Security Consulting Practice at Digital Bond, Inc. Contact Dale at Peterson@digitalbond.com.