AGA Review - Part 3
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, and 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.
That’s it. No part 4. I’ll post the responses, contrary views and any other interesting feedback I get on this review in a week or two. What do you think of AGA-12?
Author: Dale Peterson
Posted: July 1st, 2005 under AGA 12.
Comments: 3
Comments
Comment from Andrew Wright
Time: July 18, 2005, 1:08 pm
These are some good comments. I’ll respond to them below, but first I would like to correct one error.
Dale says: if a unit needs to be added or replaced at the control center, you will need to generate and properly load a new key in each of the 50 field units. Clearly this would be a major operational problem. However, this is not true if symmetric keys are used, as the standard currently proposes. The original symmetric keys for the field units can be installed in the replacement control center unit, and this unit will be able to resume communication with the field units.
Now to addesss Dale’s comments.
There is general recognition by the committee that key management is required. However, there is some disagreement over how it should be done or even on what timescale agreement can be reached. Some people feel that reaching agreement on a key management system in a short time will be easy, while others are concerned that it will take too long to get an agreed-on system in place and this will delay deployment of the standard.
There is also general agreement that asymmetric methods should be incorporated in the standard for session key exchange. There are some benefits to using asymmetric keys over symmetric keys, but they come with a greater burden of key management. Again the problem is arriving at agreement on a solution without unduly delaying the standard.
Regarding configuration management in general, the AGA standard was never intended to describe a complete product - only to recommmend how the critical encryption aspects of a serial SCADA protection system should work. Cryptographic protocol design is tricky, as evidenced for example by the many vulnerabilities in 802.11 WEP, and proprietary designs are best avoided. Nor should the ScadaSafe open source implementation that uses INI-style configuration files be considered representative of what a product should do. We expect manufacturers to design suitable key- and configuration-management systems, but do not feel that these should be mandated as part of the standard, at least not yet. Let vendors experiment with management solutions, and let the market decide.
Finally, Dale suggests a cipher suite providing authentication only with no encryption. This is an entirely reasonable suggestion, but achievable only with holdback. I will suggest we consider this.
Andrew Wright, Cisco Systems
Comment from Dale Peterson
Time: July 18, 2005, 1:34 pm
Andrew,
I agree that replacing a unit in the control center would not require rekeying all field units if the key had been archived and could be loaded into the new unit. If the unit in the control center was lost, stolen or otherwise compromised it would require rekeying all field units.
A new unit in the control center would require generating and loading keys in all field units unless one is prepared to accept the risks of sharing the same keys in all units in the control center.
In your comment, “the AGA standard was never intended to describe a complete product - only to recommmend how the critical encryption aspects of a serial SCADA protection system should work” significantly diminishes the value of the effort in my eyes. It becomes more of an academic exercise rather than a standard that can be used in real world solutions to improve SCADA security.
For those who don’t follow AGA closely, Andrew is the author of the open source AGA 12 implementation that is available at:
Comment from Andrew Wright
Time: July 27, 2005, 1:57 pm
Perhaps I need to clarify my comment that AGA 12 was never intended to describe a complete product. AGA 12 is intended to describe a complete protocol, much as various RFCs describe TCP. The TCP RFCs describe how implementations of TCP should behave in terms of what bits they put on the wire, but do not prescribe how they must be implemented, nor how applications make use of TCP, etc. Similarly, AGA 12 Part 2 describes what bits a compliant SCM must put on the wire, but avoids prescribing how it must be implemented, or how a system should use it, etc. (Actually, because AGA 12 Part 2 requires FIPS compliance for cryptographic hardware, it does go a little further than the TCP RFCs in terms of putting some implementation requirements on SCMs.)
Dale is quite right to insist that key and configuration management is a significant issue, but in my opinion it would be best to get the protocol standard finished and address K&C management in a future recommendation, rather than hold up the current draft.
Andrew Wright, Cisco Systems
Write a comment