Management
Management has been the downfall of many encryption systems. What works in a prototype deployment of four units becomes completely impractical in a system with 100's of units. The AGA 12 standard actually has two major managment challenges that are unspecified in the standard and not addressed yet by the handful of vendors developing products.
In a typical scenario a control center will have a few encryptors and each protected field site will have an encryptor. Any pair of encryptors that communicate require a unique key pair for a "static session" per the AGA 12 standard. The static sessions are then used to securely set up dynamic sessions, and this setup includes the crypto key parameters in the ciphersuite field.
Take a simple example with two encryptors in the control center and an encryptor at each of the 50 field sites. There would be a requirement to generate and load 100 unique key pairs, 50 in each control center encryptor and two in each field encryptor. As the standard exists today this is would all happen manually. Now imagine there is a small change in the network. 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. And remember, each field unit would have a unique key and these keys are random 256-bit values, which are not the easiest things to type in manually.
This is very similar to the ANSI X9.17 key management standard that was widely used in banking in the '80s and early '90s. The key pair in the static session is similar to the X9.17 key encryption key that was used to exchange data encryption keys similar to the dynamic session keys. It was completely unworkable with manual entry, so a management system was required. Having worked for two companies that had X9.17 management systems, I can tell you that after many man years of engineering the management systems worked but not well. The level of complexity made the management systems very expensive and the end users unhappy.
Fortunately, with the advent of public key technology this is all unnecessary. The concept of manually loaded unique key pairs is out. Encryption units are issued pubic key certificates from a trusted certificate authority. The units then use these certificates to perform a public key exchange to negotiate a key, such as the static session key, often using the Diffie Hellman algorithm.
If a new encryption unit is added, the unit is issued a certificate and no re-keying is required in any other encryption unit. SCADA networks have the added implementation advantage that they are closed networks. Every unit that will communicate securely on the SCADA network is approved by an entity in advance and will be issued a certificate, unlike in e-commerce where you never know who will hit your website.
In discussions with GTI I learned that they been thinking about adding this type of layer on top of the static sessions. Practically speaking, this added layer will either be designed in the standard to facillitate interoperability or left to the vendors to accomplish. In any case, we would never recommend moving past a prototype test into a production deployment of the encryptors without this key management.
To be fair, this management has been unnecessary since there have been no encryptors to manage. The contract with Mykrotronx to develop a product along with other vendors efforts to develop AGA products requires an urgent effort to develop appropriate key management.
While key management has technical solutions to eliminate the requirement for a sophisticated management solution, there is no simple technical solution for managing the address table.
The address table maps SCADA addresses to a SCADA Cryptographic Module (SCM), or encryptor, that protects the address. When a poll or some other SCADA protocol message is sent, the originating SCM must look at the message and extract the SCADA address from the message. The originating SCM looks at its address table and determines what destination SCM protects that address. It then establishes a dynamic session with the destination SCM and sends the message securely, most likely through an encrypted and authenticated tunnel.
Each SCM will have an address table. Each control center SCM will need to know the SCADA addresses behind each of the 50 field site SCM’s. Each of the field site SCM’s will need to know the SCADA addresses behind the two control center SCM’s. And if any field site SCM’s communicate with each other, and this happens in larger SCADA systems, they will need to know the SCM / SCADA address mappings for all communicating field sites.
Entering the address table once is a lot of work in even a medium size SCADA network, but management becomes even more important when changes occur. What if a new HMI or control server is added in the control center? The address table for each of the 50 field sites would need to be updated. What if a new PLC is deployed? A SCM loses the address table? A new field site is deployed? While the networks don’t change frequently, even infrequent changes can require a number of address table changes.
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
- Availability
- Integrity
- 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 |
