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:

R
T IED
U

Employees, Corporate The SCADA

customers network users
with Internet (Web
WAN/LAN browser)
/RAS
IED
R
T
Satellite,
U
radio,
microwave, Communication interface
(servers, gateways, and
SCADA telephone
lines modems)
users ______________________
Control station LAN with
master stations and operators

Figure 1: Modern SCADA Architecture1

1
RAS refers to Remote Access Service

4
 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 ….. S-HTTP DNS …..
SSL/TLS UDP
TCP
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
[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.

24