Intelligent Systems Research Laboratory

Technical Report TR-ISRL-04-01

Dept. of Computer Engineering and Computer Science

University of Louisville Louisville, KY 40292

September 2004

Security Considerations in SCADA Communication Protocols

James H. Graham Phone: (502) 852-0475

Fax: (502) 852-4713 jhgrah01@louisville.edu

Sandip C. Patel Phone: (502) 635-3777

Fax: (502) 852-4713 patels@marshall.edu

1

Abstract

Supervisory Control and Data Acquisition (SCADA) networks control the critical utility and process control infrastructures in many countries. They perform vital functions for utility companies including electricity, natural gas, oil, water, sewage, and railroads. However, little attention was given to security considerations in the initial design and deployment of these systems, which has caused an urgent need to upgrade existing systems to withstand unauthorized intrusions potentially leading to terrorist attacks. This research identifies threats faced by SCADA and investigates effective methods to enhance its security by analyzing DNP3 protocols, which has become a de facto industry standard protocol for implementing the SCADA communications. We propose cost-effective implementation alternatives including SSL/TLS, IPsec, object security, encryption, and message authentication object. This report evaluates implementation details of these solutions, and analyzes and compares these approaches. We also suggest new research directions to more adequately secure SCADA communications over the long run. Keywords: SCADA Networks, Computer Security, Communication Protocol Security, DNP3 Protocol.

I Introduction

A Supervisory Control and Data Acquisition (SCADA) system allows equipment in many different locations to be monitored and controlled from a central location. The SCADA technology is utilized for industrial measurement and control systems and is commonly used by infrastructure and utility companies such as electric power generation, transmission, and distribution; oil and gas refining and pipelines; water treatment and distribution; chemical production and processing; railroads and mass transit; and manufacturing. SCADA networks enable remote monitoring and control of a variety of remote field devices such as water and gas pumps, track switches, traffic signals, valves, and electric circuit breakers. Increased demand for industrial automation from companies enticed by the benefits of web-enabled automation is fuelling the SCADA market [40]. The market analysis and technology forecast by the ARC Advisory Group [3] reports that the worldwide market for SCADA systems for the electric power industry alone is estimated to be $1.6 billion by the year 2005 and $1.7 billion by 2006. The report also states that SCADA is moving towards knowledge management and is serving a more diverse range of client groups. The worldwide SCADA systems market for the oil and gas, and water and wastewater industries will reach $780 million by the end of 2005, growing at 3.5 percent per annum, according to another study by ARC [57]. European SCADA systems market revenues are expected to reach $1.16 billion in 2007. Positive growth rates are forecast for this market as development continues within all geographical regions and most product segments [40].

The SCADA architecture consists of one of more Master Terminal Units (MTUs) which the operators utilize to monitor and control a large number of Remote Terminal Units (RTUs) installed in substations. An MTU is often a general purpose computing platform, like a PC, running SCADA management software. RTUs or Intelligent Electronic Devices (IEDs) are generally small dedicated devices which are hardened for outdoor use and industrial

2

environments. One or more MTUs retrieve real-time analog and status data from RTUs. MTUs store and analyze these data so that MTUs can automatically control some field devices or the operators can manually send control commands to remotely operated field devices.

Since the SCADA networks control and monitor critical infrastructure of many countries, they require protection from a variety of serious threats. The SCADA technology was initially designed to maximize functionality and performance with little attention to security. This weakness in security makes the SCADA systems vulnerable to manipulation of operational data that could result in serious disruption to public health and safety. A SCADA system involves significant capital investment, so replacement of legacy systems with a new architectural design or new technologies to obtain increased security can be costly. The SCADA systems are built using public or proprietary communication protocols which are a set of formal rules or specifications describing how to transmit data and commands, especially across a network.

The security of a SCADA network can be improved in a number of ways such as

installing firewalls, securing devices that make the network, implementing access control, network enhancements, and so forth. We identify SCADA communication protocol such as DNP3 (Distributed Network Protocol version 3.0) as the most essential and appropriate place to enhance the security and propose various methods to secure the protocols. This report provides an in-depth survey of security issues for SCADA in general and DNP3 in particular, and proposes a set of corrective measures for SCADA security shortcomings. The proposed enhancements could protect this critical and growing business sector by providing intrinsic and economical security for SCADA systems. The proposed solutions could be easily applied to both the SCADA systems that are currently in operation as well as those that may use the protocol in the future. Section 2 of this report describes SCADA systems, their architecture, and the literature review. Section 3 presents details on SCADA communication protocols with a focus on DNP3 protocols. We investigate and propose security solutions and directions for future work in section 4. Section 5 contains the conclusions. II SCADA Systems

The development of supervisory control and data acquisition (SCADA) can be traced back to the early 1900’s with the advent of telemetry which involves the transmission and collection of data obtained by sensing real-time conditions. SCADA networks have become popular since the 1960’s to control electrical and other infrastructure systems. As discussed in the introduction, the broad architecture of SCADA involves receiving field-data collected by RTUs and controlling physical devices such as switches and pumps by using RTUs. The master computers (MTUs) provide the information such as meter readings and equipment status to human operators in a presentable form and allow the human operators to control the field equipments or control devices automatically. The MTU initiates almost all communication with remote sites. Many early SCADA systems used mainframe computer technology making them hierarchical and centralized in nature and required human oversight to make decisions [72]. SCADA systems were developed for gathering data from long distances using poor communication systems but providing high levels of reliability and

3

operability. MTUs were specialized, dedicated computers which gathered information and sent control command over 1200-baud communication lines to RTUs with no local intelligence or function beyond serving the master station. Very little change occurred in SCADA system concepts during the first 30 year of the industry [73]. The recent advances in the communication technologies and media (fiber optics, direct satellite broadcast and so forth), and increased processing power available at substation freed the SCADA architecture and functionality from the archaic 100-baud limitation of the past communication systems [73].

Since the early 1990’s SCADA systems perform more operations automatically. SCADA also often have Distributed Control System (DCS) components. Use of "smart" RTUs or PLCs (programmable logic controllers), which are capable of autonomously executing simple logic processes without involving the master computer, is increasing [35]. Today’s RTU devices, equipped with distributed processing architecture and support for multiple media and multiple IEDs, provide functions such as system protection (say, from power surges), local operation capabilities, and data gathering/concentration from other subsystems. Current generation digital IEDs and microprocessor relays have the ability to transmit varying degrees of functional and real-time information. A single IED can provide a number of applications and could be configured for different system parameters. The following block diagram illustrates today’s SCADA architecture:

IED

IED

Employees, customers

RTU

Satellite, radio, microwave, telephone lines

SCADA users (Web browser)

SCADA users

The Internet

Communication interface (servers, gateways, and modems) ______________________ Control station LAN with master stations and operators

Corporate network with WAN/LAN/RAS

RTU

Figure 1: Modern SCADA Architecture1

4

1 RAS refers to Remote Access Service

Most SCADA systems were originally built before and often separate from other corporate networks. As a result, SCADA administrators and managers typically operated on the assumption that these systems cannot be accessed through corporate networks or from remote access points [71]. However, the situation has changed drastically in the recent years. Figure 1 illustartes how the modern SCADA networks are integrated with corporate networks and the Internet. The figure also shows that the field data (obtained using RTUs and IEDs) is transmitted over a wide range of communication lines and can even be accessed via a web browser to SCADA users. Communication between such integrated system elements often uses Ethernet and Internet technology. Network enabled devices, routers, switches, and Window-based operating systems are now quite common in SCADA systems, bringing with them the vulnerabilities that are experienced in desktop computers and corporate networks [72]. 2.1 Literature Review

This section presents research literature describing the historical position and the current state of security considerations of SCADA. The results of this review are broken into four categories to illustrate that SCADA faces many tangible and potential threats but the industry and the research have responded with only isolated and individualistic (applicable to only selected plants) solutions. Some managerial and administrative solutions have been suggested but scientific research seeking or offering more general solutions is lacking. In summary, the review showed a clear need of research on finding generic and fundamental solutions to SCADA security issues. We found the literature on SCADA security to fall under one of the following four categories:

(1) Literature discussing and describing the need of the SCADA security in light of tangible or potential threats. (2) Literature describing the implemented SCADA security measures (or just SCADA implementation) at plant sites. (3) Literature addressing overall SCADA network security issues and making suggestions from the managerial or system administration point of view. (4) Literature describing the low-level technical details ensuring or enhancing SCADA security.

The literature in the above categories is described in the following sections. 2.1.1 Security Demands: Literature discussing and describing the need of the SCADA security in light of actual/potential threats.

The literature in this category was published either by government agencies describing the potential threats or from private or semi-private agencies. For example, a White House memo [86] listed the Presidential Directive on Homeland Security that identified and prioritized United States critical infrastructure to protect them from terrorist attacks. In [85], the attendees at a U.S. Department of Energy meeting discussed vulnerabilities of SCADA

5

system and sought to chart out (how to proceed) a path for national SCADA program. In [55], a bulletin by National Infrastructure Protection Center, terrorist interest in SCADA systems is described. Government agencies such as the Dept. of Homeland Security [87] and the Department of Transportation [88] have also published such memos regularly. The reports on increased threats to SCADA also come from educational institures such as the one by British Columbia Institute of Technology [9].

The calls for improved SCADA security have also come from industries. In [92], Westin Solutions emphasizes the need for the entire industry (owners, users, operators, vendors, integrators, engineers, etc.) to quickly reach a consensus on the minimum level of security features that need to be implemented on all municipal water/wastewater systems. In a report by American Gas Association [1], collaborative efforts of several organizations including the IEEE and NIST make security policy, and operational, quality, and system recommendations to provide security systems for various utilities infrastructures. Data Interchange Standards Association, a not-for-profit organization, describes the SCADA security challenges faced by the utility sector [51].

Studies have been conducted to statistically analyze the effectiveness of the security measures or the potential threats. For example, in order to apply security safeguards to prevent an attack, as the first step, organizations depend on a methodology such as the one suggested by Farahmand et al. [36] that guide managers and assist them to assess and understand the vulnerabilities of the business operations and control measures. In this study, the authors developed a scheme for probabilistic evaluation to assess the expected damages due to attacks, and managing the risk of attacks.

Security risk analysis allows for the systematic review of risk, threats, hazards, and

concerns, and provides cost-effective measures to lower risk to an acceptable level. Industry’s interest in risk assessment as an effective method of analyzing complex systems has increased dramatically over the last few years. Risk assessment serves two purposes: to identify existing weaknesses in the systems, and to cost-justify and prioritize the cost of additional safeguards [62]. U.S. Congress has considered risk management as a potential requirement for federal managers. For example, a report by the General Accounting Office recommended that the Department of Defense mandate risk assessments and they be performed routinely to determine vulnerability to attacks [42].

This category of literature makes the case for urgency of the security aspects and

provides some methods for statistical measures but falls short of providing concrete or technical research ideas. 2.1.2 Security Applications: Literature describing the implemented SCADA security measures (or just SCADA implementation) at a plant.

Many of the articles published under this category are case study-type papers presenting solutions applied to a plant or a SCADA network. As early as 1976, Mulder et al. [54] described an application using microprocessors for data acquisition and control system for a power system. Petree [64], [63] described implementation of SCADA with Linux at

6

Virginia Power Company. In [64], the author described the standard medium of communication between the RTUs and SCADA master computers that used dedicated serial lines. Subsequently, in [63], the author gave an update on Linux substation controllers and a new data monitoring system. In a case study, the Unix operating system (Linux) was also used by Fini [37] to show that it can solve a typical problem of data acquisition in an industrial environment. In [67], Prayurachatuporn, et al. showed how software agent technology can be used to increase the reliability of a control system.

Recommendations for implementing an intelligent supervisory system combining numerical and reasoning techniques in SCADA systems have also been proposed. For example, a knowledge-based approach for the supervision of the deflocculation problem in activated sludge processes (wastewater treatment) was considered and applied to a full-scale plant in [24]. In [93], the authors presented automated monitoring and control electric system, based on open modular controllers and a PC-based visual human/machine interface and data acquisition system. The authors claimed that the intelligent SCADA platform provided economical and user-friendly solutions to electric power facility management. The concept of Marcov reward model was applied in availability analysis of SCADA systems by Fricks et al. [39]. This model can be applied during the evaluating process that precedes deployment of master station units. Ramsay, B. et al. [69] and Hasan et al. [45], [46] discussed use of AI and fault diagnosis. Three expert-system toolkits are also described in [69]. Teo [82] has also proposed knowledge-based fault diagnosis for distributed network such as SCADA.

Some articles discussed SCADA in relation to its interface with other systems. For example, in a survey [28] that addressed the problem of supply restoration following an outage in an electric distribution system, discussed SCADA interface briefly. To demonstrate the development of a Java-based application that can be used for information exchange by market participants such as generators, market operators, and network owners, a SCADA Laboratory Applications Program was implemented in [59].

Among other case studies, Taylor et al. [81] proposed architecture for the embedded devices that utilized GSM mobile phone network for communications. They suggested that this architecture allowed SCADA applications to be built utilizing shared network infrastructure to communicate with distributed devices. In [77], two wide area network architectures for a Taiwan Power Company’s regional distributed management systems were investigated. The aim of this study was to verify whether the hardware design could accommodate the communications load and save expenses on network equipments.

Although SCADA is typically used in oil, gas, power, and water supply industries, some publications described use of SCADA in non-traditional industries. Preu et al. [68] described the steps followed in implementing a temperature controller and a supervisory controller in a SCADA system to control a reactor in a pharmaceutical factory. Gieling et al. [43] described a network with SCADA for on-line process control in greenhouses.

This category of research provided good insight as case studies but did not provide insight as to how it could be applied to any SCADA implementation. Also, many of them did

7

not elaborate on the security implementation aspects. That is, they fell short in providing details necessary to use these publications as a resource for further research. 2.1.3 Administrative and Managerial Solutions: Literature addressing overall SCADA network security issues and suggesting the managerial or system administrative aspects.

The articles in this category explicitly address the security issues and make recommendations that are not highly technical in nature. Security guidelines sometime come from government agencies. For example, a report by Department of Energy lists 21 steps providing security guidelines to improve SCADA network security [84]. These steps consist of suggestions such as defining security roles of personnel, establishing rigorous management processes and conducting self-assessments.

In [1], American Gas Association focused on retrofitting security to existing networks with a common goal of protecting resource delivery systems and safeguarding utility company assets in the most efficient and least intrusive manner possible. The recommendations were classified under categories such as, security policy, technical, operational, quality, and system. SCADA link security protocols described exchange of management information between cryptographic modules. Ventuneac et al. [90] proposed policies for authentication, access control, security management, identity administration and accountability. This report proposed generic security framework for any Web-based application not particularly for SCADA. Kokai et al. [50] surveyed SCADA systems based on the open system concept from the supplier and user point of view. The authors remarked that the system security could be a problem for an open system. A suggestion was made to use the gateways to improve security. 2.1.4 Technical Solutions: Literature describing the technical details ensuring or enhancing SCADA security.

The literature in this category was the most relevant for the research described in this report. However, there were very few publications available on the topic. In [1], SCADA link security protocols described exchange of management information between cryptographic modules. Although the information was quite detailed, it was inadequate to be used as a basis for the doctoral research. The available publications do not see security as a major integral part of the system and consequently there is limited research material on the topic. For example, while presenting the design of a microcomputer-based RTU for SCADA systems, Heng [47] very briefly mentions message security check used in the protocols. Boriani [7] considered software engineering aspects to design general communications protocol of a SCADA system, but failed to consider security as an important design/specification aspect.

Several SCADA applications have successfully used SSL/TLS solutions [70], [2], [80], [56] including organizations such as the Bow Networks Inc. [8] and the California ISO [10] (a not-for-profit public benefit corporation which is part of California’s restructured electricity industry). The use of SSL/TLS with SCADA has also been approved by IEC Technical Committee 57 work group 15 [48]. SSL/TLS solution can be applied not only to the TCP/IP based connections but also to any reliable connection-oriented protocol such as

8

X.25, or OSI [41]. However, the SSL/TLS has several known vulnerabilities [11], [89], [12], [53] and shortcomings [65], [70]. The vulnerabilities are also reported in its implementations [17-23], [83], [91], [58], [25], [26] including those in OpenSSL [61], the leading SSL/TLS open source implementation. Details of the SSL/TLS solution have been discussed in section 4.1.

Interesting technical solutions to security are also proposed without directly pointing to SCADA but have potential to be applied to SCADA. For example, Kato et al. [49] designed a Secure Tele-operation Protocol (STP) specification for Internet-based control systems. Freudenthal et al. [38] proposed a “switchboard” for continuous monitoring of a credential’s liveness and the trust relationships that authorize it. Tak et al. [78] proposed a framework by prioritizing security classes. Berket et al. [5] designed InterGroup protocols (released an alpha version) that scale well to a large number of nodes and wide-area networks avoiding large latencies and frequent faults. The authors also proposed a secure group layer (SGL) that built on InterGroup to provide SSL-like security for groups. SGL provided distributed applications with a platform they could use to achieve reliable and secure communication among distributed components. Using Dijkstra’s Weakest Precondition reasoning (stated goals and the actions of an algorithm are analyzed to produce the weakest precondition), Yasinsac et al. [94] proposed a tool to analyze cryptographic protocols such as TLS. The tool used the criteria that interactions between the different sub-protocols should be reflected in the verification condition (that uses conditional “if”).

We also reviewed literature on formal analysis of security protocols and their

correctness evaluation which can be used to prove that a security model meets its design requirements or specifications. Formal methods use mathematical or logical analysis to provide verification of security protocols. The use of tools such as the following can be very helpful in reducing the extensive time and effort characteristically spent in such security analyses:

• Casper with FDR2 [14] • Security Protocol Engineering and Analysis Resources (SPEAR), version II [74] • On-the-Fly Model-Checker (OFMC) [60] • CASRUL [15] • Common Authentication Protocol Specification Language (CAPSL) [13] • EVA project’s [34] Hermes and Securify • Symbolic Trace Analyzer (STA) [79] • Spi-Calculus based Proveif [75] and Cryptographic Protocol Type Checker

(CRYPTC) [44] Based on the above literature showing facts that (1) there is a crisis presenting clear

need of SCADA security (section 2.1.1), (2) only isolated work is done in response to this challenge lacking generic solutions (section 2.1.2), (3) security is more often approached from the managerial or administrative point of view (section 2.1.3), and (4) there is a lack of technically detailed research on SCADA security (section 2.1.4), it was concluded that there was a good scope for the research in the area described in this report.

9

2.2 SCADA Security Considerations

SCADA networks have been reportedly threatened by several terrorist groups. For example, a computer belonging to an individual with indirect links to Osama bin Laden contained programs that suggested that the individual was interested in structural engineering as it related to dams and other water-retaining structures [29], [55]. The report also stated that 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 and in other countries. The threats against the SCADA networks have been ranked high in the list of government concerns. Reportedly, in 2003 U.S. government and industry officials became gravely concerned about attack on other networks and protocols for "critical infrastructures" that included telephone switching networks, parcel delivery tracking systems, and electric utility SCADA systems [66]. Per this report, former cybersecurity czar, Richard Clarke, briefed President Bush personally on this issue [66].

The security aspects important to the companies using SCADA differ from other

industries. For example, eavesdropping (listening secretly to others' communications) may not be a problem for many SCADA companies. At the protocol level an eavesdropper picks up data, not information. That is, s/he picks up analog values, but probably cannot relate them to real, usable, information. Also, interception and alteration might be of low-risk threats which only causes SCADA operator an inconvenience and is unlikely to seriously affect the business. Similarly, the denial of service attack (preventing the devices or network from operating or communicating) is more of inconvenience rather than a serious threat. On the other hand, spoofing (impersonating a valid device) could be a serious problem, especially if the hacker spoofs a control request. The hacker could successfully send a control message that shuts down a power plant unexpectedly or cause malicious valve or traffic signal manipulations.

SCADA security measures consist of physically securing MTUs, RTUs, and the media

and employing cyber security features such as password protection. Although SCADA MTUs are typically located in a secured facility, RTUs and IEDs may be in unmanned stations secured by barbed wires. Very few communication links have physical security. Cyber security measures might include a dial-up line with a “secret” phone number, using leased lines, RTUs requiring passwords, or using “secret” proprietary protocols instead of using open protocols. However, such measures are weak since a war dialer program can be used to identify the phone numbers that can successfully make a connection with a computer modem, a leased line can be tapped without much effort, passwords are either sent in plaintext of seldom changed, the proprietary protocols provide very little “real” security, and they can be decoded by reverse engineering. Some organizations install firewalls and gateways but they have their own limitations especially that they fail to provide the end-to-end (application-to-application) security. A few SCADA protocols have built-in security features in them since they were primarily designed to maximize features such as performance, reliability, robustness, and functionality. Security features were either overlooked in favor of these features or ignored completely since most protocols were designed and in operation much before the 9/11 attacks. Considering these facts, we suggest that securing protocols are at the core of making a SCADA system secure.

10

III SCADA Communication Protocols

The SCADA systems are built using public or proprietary communication protocols which are used for communicating between an MTU and one or more RTUs. The SCADA protocols provide transmission specifications to interconnect substation computers, RTUs, IEDs, and the master station. The most common protocols used are: IEC (International Electrotechnical Commission) 60870-5-101, DNP3 (Distributed Network Protocol version 3.0), and Modbus. The IEC and DNP3 protocols provide more functionality than Modbus and are used for higher data volumes. IEC protocols dominate the market in Europe whereas DNP is a major market player in North America [52]. DNP3 protocols are also widely used in Australia and China. This report identifies SCADA protocol such as DNP3 as the right place to enhance the security, and investigates and proposes various methods to secure communications in SCADA networks. Considering its greater functionality, major market role around the world, public distribution, and extensive use, we selected DNP3 to examine security enhancement approaches although most of our findings are applicable to other protocols as well.

3.1 DNP3 Protocol

Distributed Network Protocol (DNP3) emerged as a response to proprietary or non-standardized utility communications protocols so that vendors compete based upon their computer equipment’s features, costs and quality factors instead of who has the best protocol. Utilities are not stuck with one manufacturer after the initial sale. The increased popularity of DNP3 is driven by industry through the DNP Users Group [31], which has since 1993 taken ownership of the protocol and assumed responsibility for its evolution. It is an open and public protocol standard that is now owned and maintained by the DNP User Group and DNP Technical Committee [33].

DNP3 is based on the early work of the International Electronical Commission (IEC) that resulted in the IEC 60870-5 protocol for SCADA. DNP3 and IEC 60870-5 are both part of the IEEE Standard 1379. The use of DNP3 is not limited to serial wire connections within a substation or from a substation to a SCADA master using a modem and phone lines. DNP3’s functionality contributes to the protocol’s widespread use in substation local area networks using TCP/IP Ethernet, on corporate frame relay networks, fiber optic systems, standard or CDPD cellular systems as well as many licensed or unlicensed radio systems. DNP3 is often viewed as a competitor to the Utility Communications Architecture or UCA/MMS (Utility Communications Architecture / Manufacturing Message Specification), a protocol developed by EPRI (Electric Power Research Institute) for the utility industry although each has its strengths and weaknesses. DNP3 and UCA/MMS can coexist on the same physical LAN and the same lower level protocols such as TCP/IP. Using the protocol converters, one data type can also be converted to the other [32].

More and more vendors use TCP/IP (the protocols used to communicate over the Internet) to transport DNP3 messages in lieu of the traditional media mentioned above (dedicated and dial-up telephone lines, multi-dropped telephone line, fiber optic cable, licensed/unlicensed radio, corporate frame relay networks, standard or CDPD cellular systems). Link layer frames are embedded into TCP/IP packets for transmission. This approach has enabled DNP3 to take advantage of Internet technology and permitted collecting

11

data economically and controlling widely separated devices [33]. By using any web browser, SCADA users can get the latest data from a variety of widely-separated remote field devices instantaneously and conveniently.

A DNP3 frame consists of a header and data section. The header specifies the frame size, the IDs of the DNP3 station sending receiving the frame, and data link control information. The data section contains the data passed down from the layers above. DNP3 “events” are associated with something significant happening. Examples are state changes, values exceeding some threshold, snapshots of varying data, transient data and newly available information. An event occurs when a binary input changes from an on to an off state or when an analog value changes by more than its configured dead band limit. DNP3 provides the ability to report events with and without time stamps so that the client can generate a time sequence report. An “unsolicited message mode” is a mode of operating where the server (an RTU) spontaneously transmits a response, possibly containing data, without having received a specific request for the data from a client (a master station). Not all servers have this capability, but those that do must be configured to operate in this mode. This mode is useful when the system has many slaves and the master requires notification as soon as possible after a change occurs without waiting for the master station polling.

The benefits of using the Internet technology to carry SCADA communications (see figure 1) come at the cost of compromised security since the data over the Internet can be an easy target for an attack. To make the situation more challenging, DNP3, as most other SCADA protocols, has no built-in security feature such as message authentication [6], which assures that a party to some computerized transaction is not an impostor. Just like SCADA designs, this inherent weakness was a result of overlooked security considerations at the time of the protocol design. DNP3 was designed to optimize the transmission of data acquisition information and control commands from one computer to another with little or no security consideration. Various threats that DNP3 faces include eavesdropping, man-in-the-middle attack (in which a malicious hacker not only listens to the messages between two unsuspecting parties but can also modify, delete, and replay the messages), spoof and replay (an attack that attempts to trick the system by retransmitting a legitimate message). The following section analyzes various security approaches that can be taken to reduce or eliminate these threats.

IV Security Approaches for Enhancing SCADA Security

We divide the security approaches into three categories: (1) solutions that wrap the DNP3 protocols without making changes to the protocols, (2) solutions that alter the DNP3 protocols fundamentally, and (3) enhancements to the DNP3 application. The solutions that wrap the protocols include SSL/TLS and IPsec, which would provide a quick and low-cost security enhancement. The solutions that would require altering the DNP3 protocols tend to be more time-consuming to implement and expensive but provide better end-to-end security, (more application specific security). Such solutions can either be deployed at either a protocol level (“object security”), or within an application.

12

4.1 SSL/TLS Solution

We studied SCADA security enhancement by using an open source implementation OpenSSL of Secure Sockets Layer (SSL) / Transport Layer Security (TLS) protocols. SSL/TLS secures communication channels for any reliable communication over TCP/IP and has been in use for about a decade providing virtual private network for the Internet users. SSL/TLS secures communication between a client and a server by allowing mutual authentication and provides integrity (verifying that the original contents of information have not been altered or corrupted) by using digital signatures and privacy via encryption (transforming data into a form unreadable to everyone except the receiver). The SSL/TLS protocols were specifically designed to protect against both man-in-the-middle and replay attacks. Other SSL/TLS features include error-encryption, data compression and transparency. The protocols are administered by an international standards organization (IETF). SSL is well established in areas of Web browser, Web servers, and other Internet systems that require security. As more systems connect to Internet and more Internet transactions require security, SSL/TLS’s influence will only grow. DNP3 would benefit by going with this prominent and open source SSL/TLS solution that provides critical security features.

In addition to these inherent SSL/TLS benefits, “wrapping” DNP3 with SSL/TLS has the following advantages:

1. SSL/TLS covers the most of necessary components expected at a protocol level. 2. The implementation would be fast, cost-effective, and straightforward. 3. The IEC Technical Committee has recently accepted SSL/TLS as a part of a security standard for their communication protocols [48]. This endorsement is noteworthy and relevant especially considering DNP3’s similarity with IEC protocol. 4. Since UCA/MMS protocols can share the same lower level protocols (such as TCP/IP) with DNP3, any security enhancement done via securing TCP/IP would secure UCA/MMS transmissions also. Thus both DNP3 as well as UCA/MMS protocols benefit from SSL/TLS solution. However, SSL/TLS solutions are not without limitations. The SSL/TLS protocols

have fundamental constrains such as they can run only on a reliable transport protocol such as TCP, they have higher performance costs associated with them, they are unable to provide non-repudiation service (i.e., assurance that the sender is provided with proof of delivery and that the recipient is provided with proof of the sender's identity so that neither can later deny having processed the data), and they can provide only channel security (not object security). Secondly, the protocols rely on other components such as encryption and signature algorithms. No SSL/TLS implementation can be any stronger than the cryptographic or signature tools on which it is based. In particular, it does not provide protection against an attack based on a traffic analysis. Thirdly, SSL/TLS cannot protect data before it is sent or after it arrives its destination. That is, SSL/TLS cannot be used to store encrypted data on a disk or in a cookie. In the light of recent ISN based TCP attack of April 21, 2004 that reset

13

TCP sessions (resulting in denial of service attacks) as well as injected data into TCP-based sessions [16], such attack could not be protected by SSL/TLS. This is because SSL/TLS cannot prevent a connection reset since the connection handling is done by a lower level protocol (i.e., TCP).

4.1.1 SSL/TLS Implementation

Several implementations of SSL/TLS protocols are available. OpenSSL [61] is a leading open source SSL/TLS implementation. It is non-proprietary and open to public and is available free of charge. By using an open source, SCADA utility companies are not stuck with a proprietary company for their security needs. In addition, an open source benefits from contributions from thousands of its users. The companies using an open source benefit from these contributions. Vulnerabilities are identified easily since it is used by many heterogeneous users. Government agencies such as the Department of Homeland Security (http://www.us-cert.gov/index.html) also publish advisories on widely used protocols such as OpenSSL which are readily available on the Internet. The OpenSSL code is actively maintained by Open-Source Software Institute (OSSI). Very recently, the OSSI had a vital success in the core cryptographic module of OpenSSL certified by the National Institute of Standards and Technology [4].

If a particular SSL/TLS implementation was developed just for DNP3 instead of using and open source, it would have limited user exposure not resulting in the benefits listed here. OpenSSL has several know vulnerabilities, some of which are critical and hard to find [66]. In addition, it is easy to add malicious code in OpenSSL since there is no accountability for such an action. Several other open source choices are also available some of which are listed in [76]. Weighing the pros and cons of OpenSSL led us to conclude that OpenSSL would still be the best choice for SSL/TLS implementation on DNP3.

MIME S/MIME SMTP HTTP ….. DNS ….. SSL/TLS

S-HTTP

TCP UDP

IP IPsec

Figure 2: Protocol Stack2

4.2 IPsec (secure IP) Solution

Security can also be provided at the lower layer of the protocol stacks than TCP, such as at the IP level, by securing IP packets (pieces of data divided up for transit). IPsec operates at a lower level than SSL/TLS does (see figure 2), but provides many of the same security services. Since the security at the lower levels of the stack can account for more traffic, IPsec can secure any TCP or IP traffic as opposed to SSL/TLS securing only the traffic running on 2 Gray-background protocols are secured alternatives. Reference: [70].

14

TCP. This can be advantageous for capturing some attacks. Particularly, solutions that operate above the Transport Layer, such as SSL/TLS, only prevent arbitrary packets from being inserted into a session. They are unable to prevent a connection reset (denial of service attack) since the connection handling is done by a lower level protocol (i.e., TCP). On the other hand, the Network Layer cryptographic solutions such as IPsec prevent both arbitrary packets entering a Transport-Layer stream and connection resets because connection management is integrated into the secured Network Layer. Additionally, unlike SSL/TLS, IPsec provides security for any traffic between two hosts. This means that once IPsec is installed, all applications gain some security.

IPsec’s place in the protocol stacks is also a reason for its limitations. Since IPsec is lower in the stack than SSL/TLS is, it is even more sensitive to interference by intermediaries in the communications channel. So, it is would be complicated to send encrypted or authenticated data to a machine behind a firewall. Additionally, the lower level protocols provide less flexibility in security. In other words, they fail to provide the exact security that the application needs. For example, they cannot provide advanced features such as non-repudiation. In that regard, the higher-level security measures are preferred to those applied to the lower levels.

Many vendors provided IPSec implementations at reasonable price. The Free S/WAN project has developed an open source implementation of IPSec for Unix which can be downloaded free of cost.

SSL/TLS is a compromise between application security (which offers better protection) and IP security (which offers more generality) [70]. Rescorla [70] suggests that if TCP is used for connection, SSL would work better. If only IP is used, use IPsec. If communication parties are not directly connected, then use application-level security. Considering the criticality of the SCADA networks and low cost of implementations, we would suggest combining both the solutions: SSL/TLS and IPsec. In the following sections, we discuss the application-level security.

4.3 Protocol Enhancements: Object Security

SSL/TLS provides “channel security” by associating security with the communication channel, independent of the characteristics of the data moving over the channel which is a similar approach used by modems that encrypt data. A different approach to security is to provide security services for data objects which associate security with distinct chunks of data. A server assumes some of the end-to-end duties of the client, including the work of adding and removing security wrappers to the data objects.

In object security, as the data move through each leg of the communication system, associated security information moves with the data. Instead of encrypting the channel, object security sends protected objects over a clear channel. Hence the security mechanism is entirely independent of the details of the communications channels. This approach is sometimes referred to as using a security wrapper [27] and can be implemented in addition to or in lieu of channel security. A disadvantage of this approach is that since the individual protocol object need to be secured, object security protocols are usually application specific. For example, Secure HTTP (which provides security for HTTP transactions) and S/MIME

15

(which provides security for Internet mail messages) are quite different. That is, since security is implemented at higher protocol levels, object security approach is less general than SSL/TLS approach. So, if a SCADA organization decides to adopt this approach, costly and fundamental modifications to their SCADA/DNP3 application would be required. In return, by applying digital signature and encryption services to DNP3 objects, DNP3 could ensure authentication and non-repudiation of data origin and message integrity by using digitally signed messages and confidentiality (privacy) and data security by using encryption reducing the risks of eavesdropping, man-in-the-middle, and replay attacks.

4.4 Application Enhancements

Instead of thorough changes to the DNP3 fundamentals to make it secure, organizations can enhance security by applying standard technologies to DNP3 applications. Even though the work may include tasks such as revising the message formats, making changes in data and control structures, or including authentication and encryption in DNP3, the effort would not be as complex and costly as adding object security and still would provide the end-to-end security at the application level. This approach would provide much better security than that provided by securing the lower levels (IP or the Transport Layer) by using SSL/TLS or IPsec. This approach does not have to be an all-or-none approach in terms of implementation. Depending upon the company budget and the security needs, a company can choose one or more techniques listed in this section to make DNP3 inherently secure.

4.4.1 Message Encryption

The only good solution to the threats of eavesdropping and traffic analysis is complete encryption of a protocol stream. Unfortunately, encryption can be very processing-intensive and would not be a good solution for some of the smaller devices currently deploying DNP3 since this would decrease communication speed to a great extent [30]. Another problem is that there are exporting, licensing, and key exchange issues with encryption that must be dealt.

4.4.2 Authentication using Message Authentication Object

To detect modification of a transmitted message, an authentication object can be designed which can be appended to each message or to any DNP3 message that required authentication. The DNP Technical Committee has discussed a possibility of such an object called Message Authentication Object (MAO) [30] which has fields for timestamp, nonce, hash-method, length, and hash value. It would contain the results of a secure hash function performed on the concatenation of the message and a secret, or password with only the valid sender and receiver knowing the secret. The hash would verify that the message has not been changed in transmission. However, authentication methods exist that are faster and yet can protect against the active threats of spoof, replay, repudiation and modification. Objects such as MAO will not protect against eavesdropping or traffic analysis. Nevertheless, it can prevent outputs from being incorrectly activated by unauthorized users even if these users have the power to eavesdrop on the network.

4.4.3 Authentication using Hash Algorithms

Standard hash algorithms provide data integrity assurance and data origin authentication avoiding man-in-the-middle attacks. Per an estimate by DNP3 Technical

16

Committee, a total of 59 to 77 bytes may be needed to be added to every protected message. It was also found that implementing encryption would be a similar amount of work to implement the hash algorithm. However, processing time of encryption versus just hashing may be different. In that case, it can be chosen to encrypt only the control messages and authenticate all messages. Assuming this data works for all devices and situations, it means that using the MAO on every message does not provide significant processor savings over encrypting the entire stream. However, using the MAO on selected messages, say only on controls, would still be better than encrypting the complete stream. Even if the DNP3 data should be encrypted, there is still need of an authentication function, for which MAO can be used.

4.5 Other Security Enhancement Approaches

Several additional security enhancements are also being investigated. A “switchboard” architecture [38] for continuous monitoring of the credentials and the trust relationships that were validated at the time the connection was established should be evaluated. Client-server communications that do not monitor connections once they are established are vulnerable to several threats common to prolonged communications. Considering the fact that SCADA connections stay on for extensive periods of time, such enhancements could be valuable augmentation to security. The authors also propose evaluation of a secure group layer (SGL) that builds on InterGroup protocols [5] to provide SSL-like security for groups. SGL provided distributed applications with a platform they could use to achieve reliable and secure communication among distributed components. Finally more work needs to be done in fundamental security analysis of the SCADA and DNP3 security issues using tools such as Dijkstra’s weakest precondition reasoning. Yasinsac and Childs [94] have done some initial work in this direction for general Internet security.

V Conclusions

This report has discussed many aspects of the security of SCADA communication protocols. After discussing the importance and the scope of the SCADA networks and the protocols that implement SCADA systems, we took a closer look at the security challenges faced by SCADA and its communication protocols. The report examined several enhanced security approaches in SCADA communications to reduce the vulnerability of these critical systems to malicious cyber attacks potentially avoiding the serious consequences of such attacks. The evaluation of these approaches showed that the SSL/TLS solution to the protocol security, using public domain toolkits such as OpenSSL, may provide a fast, standard, and economical solution in the short run. However, the SSL/TLS protocol and its implementation toolkits have their limitations so this approach will likely need refinement. IPsec can be used to provide IP-level security instead of, or in addition to, SSL/TLS. We further proposed the object security approaches that are costly to implement but can more integrally secure the protocols. The SCADA applications could be enhanced by a range of alternatives from adding authentication/encryption to making more inherent changes in ways in which the applications work. Finally, we proposed some new research directions to more adequately secure the protocols such as DNP3 and SCADA systems for the longer period. Such enhancements would fundamentally improve the security and reliability of this critical infrastructure component.

17

References [1] American Gas Association, “Cryptographic Protection of SCADA Communications,” AGA Report No. 12-1 (Draft) March 24, 2003. http://www.gtiservices.org/security/AGA%20Report%20No%2012%20Rev1.0.doc [2] Apache virtual host, “SSL/TLS Strong Encryption: An Introduction.” http://httpd.apache.org/docs-2.0/ssl/ssl_intro.html [3] ARC Advisory Group, Market Study, “SCADA Systems for Electric Power Worldwide Outlook.” http://www.arcweb.com/research/pdfs/Study_scadapwr_ww.pdf [4] Bent, Dan, “OSSI Making Progress on NIST Certification of Open SSL,” December 10, 2003. http://www.linuxworld.com/story/38162.htm [5] Berket, K., Agarwal, D. A. and Chevassut, O., “A practical approach to the InterGroup protocols,” Future Generation Computer Systems, Vol. 18, No. 5, April 2002, pp. 709-719. [6] Bishop, M. Computer Security, Addison-Wesley, 2003. [7] Boriani, D.V., “Axiomatic specification and logic programming: fast prototyping of correct designs,” ISA Transactions, Vol. 34, No. 1, March 1995, pp. 53-65. [8] Bow Network, Inc. products. http://www.bownetworks.com/products.asp [9] Byres, E., News Release, bcit News, “The Myths and Facts behind Cyber Security Risks for Industrial Control Systems,” October 04, 2004. http://www.bcit.ca/news/releases/newsrelease100404349.shtml and http://biz.yahoo.com/prnews/041004/to131_1.html [10] California ISO Remote Intelligent Gateway Specifications. http://www.caiso.com/docs/2002/10/21/2002102115313210338.pdf , pp. 19.

[11] Canvel, B., “Password Interception in a SSL/TLS Channel.” http://lasecwww.epfl.ch/memo_ssl.shtml [12] Canvel, B., Hiltgen, A., Vaudenay S., Vuagnoux, M., “Password Interception in a SSL/TLS Channel,” Advances in Cryptology -- CRYPT'03, Lecture Notes in Computer Science, No.2729, 2003, pp. 583-599. [13] CAPSL: Common Authentication Protocol Specification Language. http://www.csl.sri.com/users/millen/capsl/capslhome.html [14] Casper: Formal Analysis of Security Protocols. http://web.comlab.ox.ac.uk/oucl/work/gavin.lowe/Security/

18

[15] CASRUL. http://www.loria.fr/equipes/cassis/softwares/casrul/ [16] CERT Vulnerability Report in TCP dated: April 20, 2004 http://www.us-cert.gov/cas/techalerts/TA04-111A.html [17] CERT Advisory. http://www.cert.org/advisories/CA-2003-26.html [18] CERT Advisory Vulnerability Number: VU# 255484. http://www.kb.cert.org/vuls/id/255484 [19] CERT Advisory Vulnerability Number: VU# 380864. http://www.kb.cert.org/vuls/id/380864 [20] CERT Advisory Vulnerability Number: VU#686224. http://www.kb.cert.org/vuls/id/686224 [21] CERT Advisory Vulnerability Number: VU#732952. http://www.kb.cert.org/vuls/id/732952 [22] CERT Advisory Vulnerability Number: VU#935264. http://www.kb.cert.org/vuls/id/935264 [23] CERT Advisory Vulnerability Number: VU#104280. http://www.kb.cert.org/vuls/id/104280 [24] Comas, J., Rodríguez-Roda, I., Sànchez-Marrè, M., Cortés, U., Freixó, A, Arráez, J. and Poch, M, “A knowledge-based approach to the deflocculation problem: integrating on-line, off-line, and heuristic information,” Water Research, Vol. 37, No. 10, May 2003, pp. 2377-2387. [25] Common Vulnerabilities and Exposures, “CAN-2003-0543.” http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0543 [26] Common Vulnerabilities and Exposures, “CAN-2003-0544.” http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0544 [27] Crocker, D. and Klyne, G., “Internet Data Object Security,” The G5 Messaging Forum, March 12, 1998. http://www.brandenburg.com/articles/datasecurity/ [28] Cur i , S., Özveren, C. S., Crowe, L. and Lo, P. K. L. “Electric power distribution network restoration: a survey of papers and a review of the restoration problem,” Electric Power Systems Research, Vol. 35, No. 2, November 1995, pp. 73-86. [29] Dacey, R.F., Information Security Issues, United States General Accounting Office,. “CRITICAL INFRASTRUCTURE PROTECTION Challenges in Securing Control Systems” October 1, 2003. http://scada.trinux.org/local/d04140t.pdf

19

[30] DNP3 Organization’s ftp site, File: TD-AuthenticationObject-GG-1.doc. ftp://dnp.org/Tech%20Bulletin%20Drafts/ [31] DNP3 Organization’s homepage: http://www.dnp.org/ [32] DNP3 Organization’s Website. http://dnp.org/files/2000-06-UA-DNP.pdf [33] DNP3 Organization’s Website. DNP3 Technical Document: “A DNP3 Protocol Primer,” June 2000. http://dnp.org/files/dnp3_primer.pdf [34] EVA Tools. http://www-verimag.imag.fr/~Liana.Bozga/eva/securify.php?evafile_init=woolamV_m [35] Fact Index, SCADA Systems. http://www.fact-index.com/s/sc/scada.html [36] Farahmand, F., Navathe, S.B., Enslow, P.H., and Sharp, G.P., “Managing vulnerabilities of information systems to security incidents,” Proceedings of the 5th international conference on Electronic commerce, Pittsburgh, Pennsylvania, September 2003, pp. 348 – 354. [37] Fini, L. “Linux in Embedded Industrial Applications: A Case Study,” Linux Journal, Vol. 2000 , No. 77es September 2000, Article 12. [38] Freudenthal, E.,Port, L., Pesin, T., Keenan, E., and Karamcheti, V., “Switchboard: secure, monitored connections for client-server communication,” Proceedings of the 22nd International Conference on Distributed Computing Systems Workshops, 2-5 July 2002, pp. 660-665. [39] Fricks, R.M. and Trivedi, K.S. “Availability modeling of energy management systems,” Microelectronics and Reliability, Vol. 38, No. 5, May 1998, pp. 727-743. [40] Frost and Sullivan, Company news, "European SCADA systems Market in Dynamic Shape,” October11, 2001. http://www.engineeringtalk.com/news/fro/fro144.html [41] Garfinkel, S., Web Security, Privacy & Commerce, Second Edition, O’Reily & Associates, Inc., Sebastopol, California, 2002. [42] General Accounting Office, “Computer Attacks at Department of Defense Pose Increasing Risks,” GAO/AIMD-96-84. http://www.gao.gov/archive/1996/ai96084.pdf [43] Gieling, Th. H., van Meurs, W. Th. M., and Janssen, H. J. J. “A computer network with scada and case tools for on-line process control in greenhouses,” Advances in Space Research, Vol. 18, No. 1-2, 1996, pp. 171-174. [44] Gordon, A., and Jeffrey. A., Cryptographic Protocol Type Checker (CRYPTC), 2002. http://cryptyc.cs.depaul.edu/

20

[45] Hasan, K., Ramsay B. and Moyes, I. “Object oriented expert systems for real-time power system alarm processing : Part I. Selection of a toolkit,” Electric Power Systems Research, Vol. 30, No. 1, June 1994, pp. 69-75. [46] Hasan, K., Ramsay B. and Moyes, I., “Object oriented expert systems for real-time power system alarm processing : Part II. Application of a toolkit,” Electric Power Systems Research, Vol. 30, No. 1, June 1994, pp. 77-82. [47] Heng, G. T., “Microcomputer-based remote terminal unit for a SCADA system,” Microprocessors and Microsystems, Vol. 20, No. 1, March 1996, pp. 39-45. [48] IEC (The International Electrotechnical Commission), “Power system control and associated communications - Data and communication security.” https://domino.iec.ch/webstore/webstore.nsf/artnum/030578 [49] Kato, H., Furuya, M., Tamano-Mori, M., Kaneko, S., Nakano, T., “Risk analysis and secure protocol design for www-based remote control with operation-privilege management,” Proceedings of the IEEE International Conference on Systems, Man and Cybernetics, vol. 2, pp. 1107-1112, 2001. [50] Kokai, Y., Masuda, F., Horiike, S. and Sekine, Y. “Recent development in open systems for EMS/SCADA,” International Journal of Electrical Power & Energy Systems, Vol. 20, No. 2, February 1997, pp. 111-123. [51] Kotok, A., White Paper, “Utility Deregulation Requires Effective E-Business Standards,” June 2002. http://www.disa.org/pdfs/white_paper03.pdf [52] Makhija, J. and Subramanyan, L.R., “Comparison of protocols used in remote monitoring: DNP 3.0, IEC 870-5-101 & Modbus.” http://www.ee.iitb.ac.in/~esgroup/es_mtech03_sem/sem03_paper_03307905.pdf [53] Möller, B., "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures." http://www.openssl.org/~bodo/tls-cbc.txt or http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/tls-cbc.txt [54] Mulder, M.C. and Fasang, P.P., “A microprocessor oriented data acquisition and control system for power system control,” Proceedings of the 3rd annual symposium on Computer architecture, January 1976, Vol. 4, No. 4, pp. 74 – 78. [55] National Infrastructure Protection Center, ”Terrorist Interest in Water Supply and SCADA Systems” Information Bulletin 02-001, 30 January 2002. http://www.nipc.gov/publications/infobulletins/2002/ib02-001.htm [56] Network Working Group, “RFC 2246 - The TLS Protocol Version 1.0.” http://www.faqs.org/rfcs/rfc2246.html

21

[57] News Diary, Industrial Networking, “Market Reports from ARC,” Vol. 7, No. 3, Feb. 2004. http://www.industrialnetworking.co.uk/mag/v7-3/f_markreps.html [58] NISCC Vulnerability Advisory 006489/OpenSSL http://www.uniras.gov.uk/vuls/2003/006489/openssl.htm [59] Ong, Y. S. Gooi, H. B. and Lee, S. F. “Java-based applications for accessing power system data via intranet, extranet and internet,” International Journal of Electrical Power & Energy Systems, Vol. 23, No. 4, May 2001, pp. 273-284. [60] On-the-Fly Model-Checker (OFMC). http://www2.inf.ethz.ch/~moederss/research/ [61] OpenSSL Project Homepage. http://www.openssl.org/ [62] Peltier, T.R., Information Security Risk Analysis, Auerbach Publicagtions, Boca Raton, Florida 2001. [63] Petree, V., “Linux Means Business”, Linux Journal, Vol. 1998, No. 54es, October 1998 Article 16. [64] Petree, V. “SCADA-Linux Still Hard at Work,” Linux Journal, Vol. 1995, No. 10es, February 1995, Article 4. [65] Portmann, M.; Seneviratne, A.; “Selective security for TLS”, . Proceedings of Ninth IEEE International Conference on Networks, October 10-12, 2001, pp. 216 -221. [66] Poulsen, K., “Brits pound OpenSSL bugs” SecurityFocus Sep 30 2003. http://www.securityfocus.com/news/7103 [67] Prayurachatuporn, S. and Benedicenti, L., “Increasing the Reliability of Control Systems with Agent Technology,” ACM SIGAPP Applied Computing Review, Vol. 9, No. 2, Summer 2001, pp. 6-12. [68] Preu, K., Lann, Le, Cabassud M. and Anne-Archard, G., “Implementation procedure of an advanced supervisory and control strategy in the pharmaceutical industry,” Control Engineering Practice, Vol. 11, No. 12, December 2003, pp. 1449-1458. [69] Ramsay, B. and Moyes, I. “Electric Power System Alarm Management with an OOP Toolkit,” Engineering Applications of Artificial Intelligence, Vol. 8, No. 4, August 1995, pp. 461-467. [70] Rescorla, E., SSL and TLS: Designing and Building Secure Systems, Addison-Wesley, 2001. [71] Riptech Inc., White Paper, “Understanding SCADA System Security Vulnerabilities,” January 2001. http://www.iwar.org.uk/cip/resources/utilities/SCADAWhitepaperfinal1.pdf

22

[72] Sandia National Laboratories, “The Center for SCADA Security.” http://www.sandia.gov/scada/history.htm [73] Sciacca, S.C., Block, W.R., “Advanced SCADA concepts,” IEEE Computer Applications in Power, Volume: 8, No. 1 , Jan. 1995, pp. 23 – 28. [74] SPEAR: Security Protocol Engineering and Analysis Resources, version II. http://www.cs.uct.ac.za/Research/DNA/SPEAR2/ [75] Spi Calculus and Proveif. http://www.cse.psu.edu/~catuscia/teaching/cg597/01Fall/lecture_notes/TheSpiCalculus.ppt and http://www.di.ens.fr/~blanchet/crypto/proverif-bin.html and http://www.di.ens.fr/~blanchet/crypto.html [76] SSL/TLS Web page by Dan Kegel. http://www.kegel.com/ssl/ [77] Su, C. -L., Lu C. -N. and Lin, M. -C. “Wide area network performance study of a distribution management system,” International Journal of Electrical Power & Energy Systems, Vol. 22, No. 1, January 2000, pp. 9-14. [78] Sungwoo Tak, Yugyung Lee and Eun Kyo Park, “A software framework for non-repudiation service in electronic commerce based on the Internet,” Microprocessors and Microsystems, Vol. 27, No. 5-6, June 11, 2003, pp. 265-276. [79] Symbolic Trace Analyzer, STA. http://www.dsi.unifi.it/~boreale/tool.html [80] Takahashi, R. J. “Server Impact of SSL/TLS,” White Paper, Corrent Corporation. http://www.corrent.com/pdfs/SSL%20Impact%20White%20Paper.pdf [81] Taylor, K. and Palmer, D. “Applying enterprise architectures and technology to the embedded devices domain,” Proceedings of the Australasian information security workshop conference on ACSW frontiers 2003, Adelaide, Australia, January 2003, pp. 185–190. [82] Teo, C. Y., “Machine learning and knowledge building for fault diagnosis in distribution network,” International Journal of Electrical Power & Energy Systems, Vol. 17, No. 2, April 1995, pp. 119-122. [83] US Department of Energy, Computer Incident Advisory Capability. http://www.ciac.org/ciac/bulletins/n-159.shtml [84] US Department of Energy, “21 Steps to Improve Cyber Security of SCADA Network,” www.ea.doe.gov/pdfs/21stepsbooklet.pdf [85] US Department of Energy, DOE/DHS SCADA meeting, July 16, 2003. http://www.ea.doe.gov/pdfs/scada.pdf

23

24

[86] US Department of Homeland Security, Presidential Directive/Hspd-7, “Critical Infrastructure Identification, Prioritization, and Protection,” December 17, 2003. http://www.whitehouse.gov/news/releases/2003/12/20031217-5.html [87] US Department of Homeland Security, Advisories and Information Bulletin, “Threats and Protection,” http://www.dhs.gov/dhspublic/interapp/editorial/editorial_0335.xml [88] US Department of Transportation, “Safety and Security.” http://transit-safety.volpe.dot.gov/ [89] Vaudenay, S., "Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS", Proceedings of In Advances in Cryptology - EUROCRYPT'02, Amsterdam, Netherlands, 2002, pp. 534-545. [90] Ventuneac, M., Coffey, T., and Salomie, I., “A Policy-Based Security Framework for Web-Enabled Applications,” Proceedings of the 1st international symposium on Information and communication technologies, Dublin, Ireland, 2003, pp. 487– 492. [91] Viega, J., Messier, M. and Chandra, P., Network security with OpenSSL, O’Reilly & Assoc. Inc., 2002. [92] Westin Solutions. http://www.pcis.org/getDocument.cfm?urlLibraryDocID=44 [93] Yao, A.W.L. and Ku, C. H., “Developing a PC-based automated monitoring and control platform for electric power systems,” Electric Power Systems Research, Vol. 64, No. 2, February 2003, pp. 129-136. [94] Yasinsac, A. and Childs, J.; “Analyzing Internet security protocols,” Proceedings of the Sixth IEEE International Symposium on High Assurance Systems Engineering, Oct. 22-24, 2001, pp. 149 -159.