Research and Advances
Architecture and Hardware Virtual extension

Improving the Cyber Security of SCADA Communication Networks

Posted
  1. Introduction
  2. SCADA Architectures
  3. Proposed Solutions to SCADA-Communication Security
  4. Test-Bed Evaluation
  5. Conclusion
  6. References
  7. Authors
  8. Footnotes
  9. Figures
  10. Tables

Supervisory control and data acquisition (SCADA) networks are used to control and monitor field devices from a central station and have been commonly used by utility and infrastructure companies for administration of railroads and mass transit systems, and the generation and transmission of products such as electric power, oil, gas, chemicals, and water. SCADA networks enable operating many devices remotely such as track switches, traffic signals, electric circuit breakers, valves, relays, sensors, and water and gas pumps. Since SCADA networks were initially designed with little attention to security, they can be easy targets of attacks by terrorist groups.

With the advancements in the Internet and wireless technologies, and the increased need to monitor industrial production facilities remotely and automatically, SCADA networks have gained much popularity. However, modern SCADA networks, integrated with corporate networks and the Internet, have become far more vulnerable to unauthorized cyber attacks. By sending a false control message from a computer connected to the Internet, an unauthorized intruder, for example, can manipulate traffic signals, electric-power switching stations, chemical process-control systems, or sewage-water valves, creating major concerns to public safety and health. For example, in January 2003, the Slammer worm attacked a private computer network at Ohio’s Davis-Besse nuclear power plant and disabled a safety monitoring system for nearly five hours.2

Threats against SCADA networks are ranked high in the list of government concerns, since terrorists have threatened to attack several SCADA networks.7 A computer belonging to an individual with indirect links to Osama bin Laden contained programs that suggested that the individual was interested in learning about dams and other water-retaining structures of the nation.3 This public report also stated that the U.S. law enforcement and intelligence agencies had received indications that Al Qaeda members had sought information about control systems from multiple Web sites, specifically on water supply and wastewater management practices in the United States.3 In this article, we present several options to secure SCADA communication networks that we have successfully implemented and tested to monitor and control a chemical-process test-bed at the University of Louisville, KY.6

Back to Top

SCADA Architectures

As shown in Figure 1, a SCADA architecture consists of one or more master terminal units (MTUs) used for supervising personnel, monitoring, and controlling a large number of remote terminal units (RTUs) or intelligent electronic devices (IEDs) installed in field.

An MTU is a general purpose computer, running SCADA management software. RTUs and IEDs are generally small dedicated devices designed for rough field or industrial environment. MTUs retrieve real-time analog and binary status data from RTUs or IEDs, analyze these data, and send control commands to RTUs and/or IEDs automatically or manually by the supervisors.

The transmission of data and control commands between an MTU and an RTU, designated as SCADA communications, are carried over a variety of media, including Ethernet, corporate frame relay, fiber channel, CDPD cellular systems, microwave signals, direct satellite broadcast and many licensed or unlicensed radio systems. Common open communication-protocols include International Electrotechnical Commission 60870-5-101, Distributed Network Protocol Version 3 (DNP3), and Modbus, in addition to several other private protocols. Most of these protocols include application layer, link layer, and transport layer in their specifications. They also allow messages to be transported using TCP/IP specifications to facilitate communication over the Internet.

How secure are today’s SCADA systems? Typical SCADA security measures consist of physically securing MTUs, RTUs, and transmission media, and employing common cyber security defenses such as password protection and anti-virus utilities. Communication security measures generally include private or leased telephone lines with a “secret” phone number and “secret” proprietary protocols. However, such measures are weak since it is not difficult to identify the secret phone number, tap a telephone line and decode proprietary protocols through reverse engineering. Some firms install firewalls and gateways but they fail to provide end-to-end security. Only a few private SCADA protocols have advanced level of built-in security features, such as message authentication, since most of these protocols were designed primarily to maximize performance, reliability, robustness, and functionality. Hardly any open protocol has built-in security feature since open protocols were designed much before the 9/11 attacks in New York. Here, we analyze various security approaches to reduce some of the cyber threats to SCADA communications.

Back to Top

Proposed Solutions to SCADA-Communication Security

We propose two methods of securing SCADA communication, “wrap” SCADA protocols with external cryptographic protocols, and enhance SCADA protocols with cryptography techniques.

Wrap SCADA protocols. We suggest two options, use Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocol and use IPsec protocol. SSL/TLS protocol was designed to protect against an intruder who may modify, delete, or replay the data in transit. This protocol is commonly used to protect client/server communication over the Internet from threats of eavesdropping, tampering, and message forgery. The protocol allows authentication of sending and receiving devices and provides integrity by using digital signatures and privacy using encryption. SSL/TLS is administered by an international standards organization (IETF) and is well established in areas of Web browsers, Web servers, and other Internet systems.

Any kind of enhancement done via securing TCP/IP, such as SSL/TLS, would secure more than one SCADA protocols, for example, Utility Communications Architecture / Manufacturing Message Specification protocol, and DNP3 protocol, since two or more SCADA protocols can coexist on the same physical network. However, the SSL/TLS solution has some limitations as it can run only a reliable transport protocol such as TCP. Second, this protocol relies on other components such as encryption and signature algorithms; therefore, SSL/TLS implementation cannot be stronger than the cryptographic or signature tools on which this implementation is based.8

The other “wrapper” option is using IPsec (secure IP). SSL/TLS operates above the Transport Layer (OSI Layer 4) but IPsec operates at the Network Layer (OSI Layer 3). IPsec can prevent attacks launched by repeatedly breaking connections because these connections are established at the IP level. However, IPsec cannot provide application-specific security or advanced security features such as nonrepudiation where the sender is provided with proof of the delivery and the recipient is provided with a proof of the sender’s identity. Moreover, IPsec is more sensitive than SSL/TLS to interference by intermediaries in the communication channel. So it would be cumbersome to send encrypted or authenticated data to a computer behind a firewall when IPsec is used.

Enhance SCADA protocols with selected cryptography techniques. SSL/TLS and IPsec provide generic security features and protect only a part of the communication channel, but selective cryptography techniques can provide end-to-end security that protects an entire channel between a sender and the receiver. Based on early works of the DNP3 User Group, we suggest the following two cryptography techniques that we have tested on a prototype at the University of Louisville.

Authentication Octets. This technique is based on digital-signature algorithm. In this technique, additional bytes of information, referred here as Authentication Octets, are appended to each message from an MTU to an RTU for the authentication. First, hash is performed on selected bytes of a message, resulting in a hash digest. This digest is encrypted by using the MTU’s private key (see Figure 2) and then the encrypted digest is sent along with the message. In our test-bed implementation, keys are stored locally, eliminating the need of the Certificate Authority. The message itself is not encrypted to save the processing time during the encryption and the decryption. Other data that vary with time are time stamped for additional checks. For example, with the timestamp, the RTU verifies that the time of reception does not vary from the time of transmission beyond a specified range to eliminate an intruder from resending a valid message multiple times. The RTU decrypts the hash digest by using the MTU’s public key and compares it with hash digest independently calculated by the RTU. The RTU would conclude that the message came from an authentic source if it can decrypt the digest using the MTU’s public key. The RTU would also conclude that the message contents are unaltered if the digest values match.

The Authentication Octets technique may also be applied to the messages send from an RTU to an MTU to prevent an intruder from making an MTU send inappropriate messages. For example, an intruder can send valid looking RTU values, indicating a high voltage surge to prompt an MTU to send a control message to turn-on the circuit breaker.

The Authentication Octets technique protects spoofing and modification attacks. Because the entire message is not encrypted, this technique does not protect from the threat of eavesdropping. However, for SCADA networks, eavesdropping is not a major concern. The more significant concern is to block the unauthorized commands to the RTU.

Authentication via Challenge Response. This technique verifies the identity of an RTU or an MTU by using the challenge-response cryptography to protect against the man-in-the-middle attack. Either of the devices (MTU or RTU) initiates a challenge to authenticate the other device that shares a secret. The authenticator device sends a random challenge to the other device. Using the secret and the challenge the other device calculates a hash digest and then sends this digest as a response. The authenticator checks the response against its own calculation of the expected hash digest. If the values match, the authentication is acknowledged, otherwise the authenticator terminates the connection.

There are four types of occasions when a challenge response method is used for an authentication: In establishing a connection, an RTU sends a challenge to verify the authenticity of the MTU; An RTU also sends a challenge in specific circumstances, such as when it receives a critical command to shut the power switch off from MTU; An MTU sends a challenge to an RTU to verify the validity of data that are out of the typical range; and MTUs and RTUs also randomly send challenges to each other to verify the authenticity of the other device.

Correctness Proofs for Cryptography Techniques Formal methods provide the advantages of mathematical proof process, but they are often ignored during the development of secure software, because mathematical proofs can be several-fold longer than the security specification.5 However, we used formal methods to prove the soundness of the proposed security techniques for SCADA communications, which we have published.4,6

Software tools that perform a formal analysis are helpful, because a manual proof can be laborious as well as error-prone. Most of the software tools require exact and detailed specifications on message communications as a part of their input, but the advantage is that these specifications can later be used during coding. After investigating a number of tools, we selected On-the-Fly Model-Checker (OFMC),1 and Security Protocol Engineering and Analysis Resources (SPEAR) version II,9 to perform formal security analysis of the proposed techniques. OFMC was found to be appropriate because it succeeded in finding intruder attacks. On the other hand, SPEAR II, which uses Prolog-based analyzer, was found to be appropriate in verifying that the protocols functioned as intended. For example, SPEAR II provided the proof that the message-receiving device was able to ensure the authenticity of the message origin.

Back to Top

Test-Bed Evaluation

The proposed security techniques were implemented at the SCADA test-bed at the University of Louisville, in Intelligent Systems and Process Control Laboratories. As shown in Figure 3, the test-bed consists of one MTU and five RTUs. The MTU uses DNP3 protocol to communicate with RTUs, human-machine-interface software to simulate real-life remote-monitoring environment, and MySQL database to store information obtained from intrusion detection sensors. Four RTUs are locally installed in the University of Louisville, and connected to the MTU with Ethernet LAN. One remote RTU is located about 100 miles away from the MTU which is connected to the MTU via the Internet. Each RTU includes intrusion detection software—Snort—to monitor the communication between the RTU and the MTU. Snort intrusion detection sensors analyze the communication to extract relevant information to alert the administrator of unauthorized intrusions. The sensors log their data to the database residing on the MTU.

The test-bed implementation of SSL/TLS was done using Java Secure Socket Extension (JSSE), which provides Java APIs for the SSL/TLS protocol implementation.

The other SSL/TLS implementation method is OpenSSL that is developed by worldwide community of volunteers. Though OpenSSL is an opensource, commercial-grade, full-featured software, it has several know vulnerabilities. This software is actively maintained by Open Source Software Institute (OSSI).

Table 1 shows a comparison of the performance among different security methods that we used at the University of Louisville.

Back to Top

Conclusion

We have focused on the security of SCADA communication protocols and presented two possible security alternatives that we have tested at the University of Louisville, to confirm the soundness of these enhancements. Although improved protocols that we the tested and implemented could significantly enhance the security of SCADA, we acknowledge that an enhanced security feature can never be as secure as the one that is incorporated in the early phase of the design. Recognizing the lack of inherently secure-open SCADA communication protocol, we envision a new, inherently secure open SCADA protocol that will make use of secure-software principles and include features such as MIME Object Security Services. We believe that in such an endeavor, the communities of SCADA vendors, SCADA organizations, and others volunteers can play key roles.

Back to Top

Back to Top

Back to Top

Back to Top

Figures

F1 Figure 1. A Detailed Outline of a Typical SCADA Architecture

F2 Figure 2. Authentication Using Authentication Octets

F3 Figure 3. SCADA System Test Bed

Back to Top

Tables

T1 Table 1. Comparison of Suggested Security Approaches

Back to top

    1. Basin, D., Mödersheim, S., and Viganò, L. An on-the-fly model-checker for security protocol analysis. Proceedings of 8th European Symposium on Research in Computer Security (Gjøvik, Norway, Oct. 13–15 2003), Springer-Verlag, 253–270.

    2. Byres, E. News Release, bcit News, "The Myths and Facts behind Cyber Security Risks for Industrial Control Systems," Oct. 4, 2004.

    3. Dacey, R. Critical infrastructure protection: Challenges in securing control systems. Information Security Issues, United States General Accounting Office, Oct. 2003.

    4. Graham, J. and Patel, S. Correctness proofs for SCADA communication protocols. Proceedings of the 9th World Multi-Conference on Systemics, Cybernetics, and Informatics (Orlando, July 10–13 2005), 392–397.

    5. Jackson, K. and Hruska, J. Computer Security Reference Book. CRC Press, Boca Raton, FL, 1992.

    6. Patel, S. Secure internet-based communication protocol for SCADA networks. Doctoral Dissertation, University of Louisville, Louisville, Kentucky, 2006.

    7. Poulsen, K. Brits found OpenSSL bugs. SecurityFocus, Sept. 2003.

    8. Rescorla, E., SSL and TLS: Designing and Building Secure Systems, Addison-Wesley, 2001.

    9. Saul, E. and Hutchison, A. Security protocol engineering and analysis resources, version II; http://www.cs.uct.ac.za/Research/DNA/SPEAR2/ (Accessed 5/13/2009).

    DOI: http://doi.acm.org/10.1145/1538788.1538820

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More