AGA 12 recommends how to protect SCADA communications from cyber attack.
The fundamental goal is to make it easy for SCADA operators to specify good communication security without having to delve into complicated topics like cryptography and digital certificates. Pipelines and utilities can confidently protect their systems from cyber attack if they simply specify AGA 12 compliance for SCADA equipment and follow the recommendations in the documents. Believing that competition is the best way to assure low-cost products, AGA 12 requires that SCADA cyber security equipment can interoperate, independent of manufacturer or age.
By themselves, the AGA 12 documents protect nothing. It is only effective when manufacturers incorporate the standard into cost-effective products and utilities deploy that equipment to protect SCADA systems from potential attackers. We are pleased to see that commercial products are now available.
The AGA, the AWWA Research Foundation (AwwaRF), the Department of Energy (DOE), the Gas Technology Institute (GTI), the Technical Support Working Group (TSWG), and more than a dozen private companies combined resources to develop the AGA 12 set of recommended practices.
Initial feedback from the gas and electric industries recommended that the first AGA 12 efforts address the need for retrofit protection of serial communications for installed (legacy) SCADA systems. The reason is that such systems have lifetimes between seven and 20 years and are too expensive to be replaced for the sole purpose of incorporating security. Accordingly, the AGA 12 Working Group began development on a series of four documents, structured as follows:
* AGA Report No. 12, Part 1--"Cryptographic Protection of SCADA Communications: General Recommendations" contains the background, security policy fundamentals, and a test plan that apply generally to all areas of cryptographic protection of SCADA systems.
* AGA Report No. 12, Part2--"Cryptographic Protection of SCADA Communications: Retrofit Applications" focuses on protecting already installed, generally low-speed, serial equipment. This document contains the functional requirements and detailed technical specifications for AGA 12-compliant retrofit devices.
* AGA Report No. 12, Part 3--"Cryptographic Protection of SCADA Communications: Protection of Networked Systems" will focus on high-speed communication systems, including the Interact.
* AGA Report No. 12, Part 4--"Cryptographic Protection of SCADA Communications: Embedded Protection of SCADA Components" will specify how to protect SCADA systems by incorporating cryptography into the system components at the time of manufacture; this will greatly reduce the cost of protection while improving its performance.
More convenient key management for large-scale operations, protection of data at rest, forensics and intrusion detection, certification, and security policy models are among the issues we hope to address in future extensions of AGA 12.
AGA 12, Part 1
On March 16, 2006, the AGA Managing Committee completed the final balloting on AGA 12, Part 1, making it a gas industry recommended practice. It is available at AGA 12 Web site www.aga.org/Content/ContentGroups/ Operations_and_Engineering2/Infrastructure_ Security 1/AGA 12.pdf
AGA has also offered this as a recommended practice to the water industry and it is posted on the American Water Works Association Research Foundation Web site.
AGA 12, Part 1 is the foundation for the series of four reports and sets forth the general requirements to which the subsequent documents in the series will comply. It begins with a discussion of the cyber threats SCADA systems face. It also includes a collection of background material that specialists in one area need to understand and evaluate the work of specialists in another area. In particular, it explains the basics of cryptography for SCADA experts and the basics of SCADA for cryptographers.
AGA 12, Part 1 recommends adopting a corporate security posture that is based on deploying protection for SCADA communications only where the risks justify doing so. Because SCADA systems differ from one another, the AGA 12 Committee opted to recommend a systematic procedure each system owner can implement to assess its risks, rather than to recommend using a checklist.
The essence of the AGA 12, Part 1 policy recommendation is "determine the possible consequences of an attack on your system and protect only against those attacks that represent unacceptable risks." The report stresses that if the cost of protecting a part of the SCADA system is higher than the risk of an attack, then it makes no sense to deploy protection.
The final general set of recommendations in AGA 12, Part 1 is a process for testing cryptographic equipment for its suitability for SCADA operations. Because cryptography is such an arcane subject, we believe SCADA operators will require a "seal-of-approval" certification that assures them the equipment they purchase really does comply with the AGA 12 recommendations. This requirement means that a testing program is established that determines whether products really perform as they are supposed to perform and Part 1 lays out the basic testing requirements.
AGA 12, Part 2
Rather than mandating cryptographic protection for all SCADA systems, AGA 12, Part 1 recommends it only for those portions of the system where it makes business sense. However, once a company determines that cryptographic protection is required, the remaining AGA 12 documents recommend how it should be done to provide reliable security. Based on industry input, the AGA 12 Working Group first completed Part 1, then focused its efforts on Part 2, the specification for retrofit applications.
A three-step approach was adopted to develop the retrofit specifications. The first step was to list the characteristics of a SCADA system that impact cyber security. The next step was to develop a list of functional requirements and constraints that these real-world characteristics impose on any cryptographic solution. Finally, existing standards that would meet the functional requirements were identified. The list of SCADA characteristics and the resulting functional requirements are posted on the AGA 12 Web site www.gtiservices. org/security/AGA 12-1RFC.pdf
The functional requirements that resulted from the process described in the last paragraph were tight constraints. The most stringent requirements were that the SCADA cryptographic modules (SCMs) had to:
* Be very simple to install,
* Support approximately 100 existing SCADA protocols,
* Be reliable,
* Slow communications by a very small amount.
* Be convenient to operate,
* Require no changes in host computer software or RTUs,
* Cost no more than about $500, and
* Pass a security evaluation by cryptographic experts.
Despite this tight set of constraints, the AGA 12 Working Group was able to develop a specification that meets these requirements. The AGA 12. Part 2 specification is now posted on the AGA 12 Web site at www.gtiservices.org/security/aga-12p2-draft-20060331.pdf
For anyone wishing to install the AGA 12. Part 2 capabilities on their own machines or to develop products that comply with the Part 2 specification, Cisco Systems has made available, at no cost, a JAVA implementation at http://scadasafe. sourceforge.net/
The status of the AGA 2, Part 2 document is a bit difficult to understand. On the one hand, we believe it is technically correct and complete. The evidence for this opinion is that manufacturers have used the existing specification to build CMs that interoperate with CMs built by others and that function when deployed in the field. In addition, cryptographers at the Sandia National Laboratories have understood and evaluated the AGA 12, Part 2 specification.
However, while the specification is correct and complete, it is not ready for submission to AGA for a formal ballot because funding ran out before the Working Group could complete the final review and edit. Thus, AGA 12, Part 2 is being used as a de facto standard, but is stalled at the stage of being effectively a set of notes that can be used to build SCMs.
Part 2 Carefully Tested
Before the AGA 12 Working Group presented Part 2 to AGA for ballot to become an industry recommended practice, it was critical to establish that the specification is technically sound and that it meets the requirements that were identified. We addressed these needs with laboratory and field tests and an evaluation by cryptographers at Sandia.
The first set of tests was conducted in the GTI laboratories and began with the construction of the "Gold Standard" version of the AGA 12, Part 2 module. The term Gold Standard indicates that--at least for now--the most reliable way for manufacturers to establish that their units inter-operate with other AGA 12-compliant products is to test them against this lab unit, shown in the accompanying photograph.
This laboratory prototype can be installed in minutes. For example, to protect an installed modem and RTU in the field, the modem is disconnected from the RTU. The RTU is plugged into the "Plaintext" port. The modem is connected to the "Ciphertext" port and the mechanical installation is complete.
In operation, the original SCADA message leaves the RTU and enters the SCM through the Plaintext port. Inside the unit, the message is encrypted and delivered to the Ciphertext port, from which it goes out to the modem. The process is reversed when an encrypted message arrives at the Ciphertext port and is returned to the RTU as the original message.
We tested the laboratory unit to be certain that the cryptographic system of AGA 12, Part 2 works, that it does not slow messages down to the point of significantly interfering with SCADA operation, and that messages and commands can be encrypted and decrypted. We also tested for a wide variety of other situations that would occur in the field. As an example, we tested the ability of the unit to recover from the loss of power, loss of communication link, and switch from the primary to the back-up host during an emergency.
Once we had confidence in the unit's ability to function in the laboratory, we tested it in a gas utility. The next step was to send it to several manufacturers which built prototypes of commercial products and tested them for speed functionality and interoperability with the Gold Standard. We also sent Gold Standard units to Pacific Northwest National Laboratories (as part of the DOE National SCADA Test Bed Program) for a series of tests as one step in determining whether the units can meet the needs of the electric industry's SCADA systems. Testing continues and no problems have been uncovered to date.
The next step was to test commercial prototypes in the field. Although we lacked funding to complete the field tests in a gas utility, a water utility that uses the Modbus protocol (typical of many gas utilities) funded a field test that began in January 2006. The cryptographic units functioned well in the field. The final analysis of the field test data is expected to be completed shortly.
Although the final results are not yet available, commercial versions of AGA 12, Part 2 products (based on various releases of the protocol) are now available at a cost of approximately $550 per unit. However, the decision on the final step--deployment of the protective equipment--remains in the hands of utilities.
Speed and functionality alone, however, are not enough. It is also important that the AGA 12, Part 2 cryptographic specification is secure. The Department of Energy arranged for cryptographers at Sandia to evaluate the security of the cryptographic system as part of the DOE National SCADA Test Bed Program. The details of the evaluation have been classified as Official Use Only, but are available to those who will need this information to make balloting decisions: this includes AGA members on the Gas Control Committee as well as the key decision makers in the water and electric industries.
Sandia cryptographers are not aware of any attack that will break the cryptographic system. However, the analysis may have to be updated as the AGA 12, Part 2 specification changes in response to field experience.
Our decision to recommend a cryptographic standard, rather than to develop a secret method to encrypt messages, is often puzzling to people with little cryptographic experience. The concept of publishing the details of how messages are encrypted seems to make the attackers' job easy since the encryption system is available on the Internet.
A simple analogy may set the stage for a better understanding. Consider the combination lock. Anyone can find out how the lock mechanism works. The description is on the Internet, in any good encyclopedia, or from the patent office. Sawing one open also allows for "reverse engineering" of the lock.
However, knowing the mechanism does not let you open a single lock. The security comes from knowing the secret number called the "combination." Thus, a standard, well-publicized security mechanism like a combination lock can protect something because the security lies in knowing a secret number, not in the obscurity of the mechanism. In the case of cryptographic algorithms, the secret number that opens the message is called the key.
Cryptographic algorithms are similar. The mechanism is well known and thoroughly evaluated by the cryptographic community. In fact, counter-intuitive as it is, the history of secret cryptographic systems or those developed in isolation is not encouraging. Because systems developed by cryptographers are often broken by other cryptographers once they are published and subjected to exhaustive testing, the AGA 12 Working Group decided early on to require that any cryptographic algorithms we recommended would have to be standard algorithms that have been approved for use through the Federal Information Process Standards system.
Additional Work Remains
Despite the fact that AGA 12 has made great progress, significant work remains. The improvements AGA 12 needs include the following:
* Complete the balloting of AGA 12, Part 2 so that it can join Part 1 as an industry-recommended practice.
* Evaluate the performance of full deployments of AGA 12 compliant equipment to assure utilities that it can be scaled up to large-scale operations and will perform reliably in the field.
* Reduce the cost and increase the performance of cryptographic protection by incorporating it into SCADA products at the time of manufacture.
* Complete the specification of AGA 12 to include high-speed networks, including the Internet.
* Incorporate forensic capabilities into the specification to enable detection of attacks, notify the operator, and gather information to help identify, locate, and prosecute attackers.
* Improve on the currently defined prototype key management process to enable it to be deployed on a utility-wide scale.
* Specify a compliance test procedure so that SCADA operators can be confident that the equipment they are installing does really comply with the AGA 2 specification.
Those of us who served on the AGA 12 Working Group are proud of the fact that AGA's private sector effort has produced a recommendation for protecting SCADA systems without the need for government regulations. Because the team that developed these recommendations was from the affected industries, we are confident that these recommendations will provide low-cost security, reliable protection that is easy to install and designed to support more than 100 existing SCADA protocols. We are particularly pleased to see products that are designed to the AGA 12 recommendations entering the market place. Our hope remains that we will be able to complete the work that we believe has been so well begun.
While work remains, the AGA 12 Working Group has advanced its work to the point that SCADA operators can begin using it to protect their communication links from cyber attacks. AGA's acceptance of AGA 12, Part 1 as a recommended practice indicates confidence that this is a sound methodology for developing a cyber-security posture and a sound general approach to this area.
The Part 2 specification is now sufficiently complete and stable to the point that the commercially available products that are designed to this specification can be deployed today and will provide reliable protection to SCADA systems. The next step of actually deploying these protective systems can only be taken by the SCADA system owners themselves.
William F. Rush is an Institute Scientist in the Distribution and Pipeline Technology Group at GTI. His contributions include the areas of integrated automation, cryptography to protect SCADA .systems, and having served as Chair of the AGA 12 Committee.
John A. Kinast is Senior Engineer at Distribution and Pipeline Technology Group at GTI. His primary activities include automating field operations and applied cryptography. He is a primary contributor in developing AGA 12 Parts 1 & 2 and serves as the editor of Part 2.
Aakash Shah was an engineer at GTI. He conducted critical infrastructure (SCADA) security research for over two years and was responsible for testing the prototype AGA 12 compliant cryptographic modules. He has a B.S. in Computer Engineering from the University of Illinois at Urbana-Champaign and is currently, working on an M.S. in Information Security at Carnegie Mellon University.
By William F. Rush, John A Kinast, and Aakash B. Shah, Gas Technology Institute, Des Plaines, IL
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||supervisory control and data acquisition systems, American Gas Association|
|Comment:||AGA 12 recommends how to protect SCADA communications from cyber attack.(supervisory control and data acquisition systems, American Gas Association)|
|Author:||Rush, William F.; Kinast, John A.; Shah, Aakash B.|
|Publication:||Pipeline & Gas Journal|
|Date:||Nov 1, 2006|
|Previous Article:||Leading liquids pipelines.|
|Next Article:||Predictions of disaster: is the sky really falling?|