2.

0 SCADA Overview

SCADA is an acronym for Supervisory Control and Data Acquisition. SCADA

systems are used to monitor and control a plant or equipment in industries such
as telecommunications, water and waste control, energy, oil and gas refining and
transportation. These systems encompass the transfer of data between a SCADA
central host computer and a number of Remote Terminal Units (RTUs) and/or
Programmable Logic Controllers (PLCs), and the central host and the operator
terminals. A SCADA system gathers information (such as where a leak on a
pipeline has occurred), transfers the information back to a central site, then
alerts the home station that a leak has occurred, carrying out necessary analysis
and control, such as determining if the leak is critical, and displaying the
information in a logical and organized fashion. These systems can be relatively
simple, such as one that monitors environmental conditions of a small office
building, or very complex, such as a system that monitors all the activity in a
nuclear power plant or the activity of a municipal water system. Traditionally,
SCADA systems have made use of the Public Switched Network (PSN) for
monitoring purposes. Today many systems are monitored using the
infrastructure of the corporate Local Area Network (LAN)/Wide Area Network
(WAN). Wireless technologies are now being widely deployed for purposes of
monitoring.

SCADA systems consist of:

• One or more field data interface devices, usually RTUs, or PLCs, which
interface to field sensing devices and local control switchboxes and valve
actuators
• A communications system used to transfer data between field data
interface devices and control units and the computers in the SCADA
central host. The system can be radio, telephone, cable, satellite, etc., or
any combination of these.
• A central host computer server or servers (sometimes called a SCADA
Center, master station, or Master Terminal Unit (MTU)
• A collection of standard and/or custom software [sometimes called Human
Machine Interface (HMI) software or Man Machine Interface (MMI)
software] systems used to provide the SCADA central host and operator
terminal application, support the communications system, and monitor
and control remotely located field data interface devices
Figure 2.1 shows a very basic SCADA system, while Figure 2.2 shows a typical
SCADA system. Each of the above system components will be discussed in detail
in the next sections.

2.1 Field Data Interface Devices

Field data interface devices form the "eyes and ears" of a SCADA system.
Devices such as reservoir level meters, water flow meters, valve position
transmitters, temperature transmitters, power consumption meters, and
pressure meters all provide information that can tell an experienced operator
how well a water distribution system is performing. In addition, equipment such
as electric valve actuators, motor control switchboards, and electronic chemical
dosing facilities can be used to form the "hands" of the SCADA system and assist
in automating the process of distributing water.

However, before any automation or remote monitoring can be achieved, the

information that is passed to and from the field data interface devices must be
converted to a form that is compatible with the language of the SCADA system.
To achieve this, some form of electronic field data interface is required. RTUs,
also known as Remote Telemetry Units, provide this interface. They are
primarily used to convert electronic signals received from field interface devices
into the language (known as the communication protocol) used to transmit the
data over a communication channel.

The instructions for the automation of field data interface devices, such as pump
control logic, are usually stored locally. This is largely due to the limited
bandwidth typical of communications links between the SCADA central host
computer and the field data interface devices. Such instructions are traditionally
held within the PLCs, which have in the past been physically separate from
RTUs. A PLC is a device used to automate monitoring and control of industrial
facilities. It can be used as a stand-alone or in conjunction with a SCADA or
other system. PLCs connect directly to field data interface devices and
incorporate programmed intelligence in the form of logical procedures that will
be executed in the event of certain field conditions.

PLCs have their origins in the automation industry and therefore are often used
in manufacturing and process plant applications. The need for PLCs to connect
to communication channels was not great in these applications, as they often
were only required to replace traditional relay logic systems or pneumatic
controllers. SCADA systems, on the other hand, have origins in early telemetry
applications, where it was only necessary to know basic information from a
remote source. The RTUs connected to these systems had no need for control
programming because the local control algorithm was held in the relay switching
logic.

As PLCs were used more often to replace relay switching logic control systems,
telemetry was used more and more with PLCs at the remote sites. It became
desirable to influence the program within the PLC through the use of a remote
signal. This is in effect the "Supervisory Control" part of the acronym SCADA.
Where only a simple local control program was required, it became possible to
store this program within the RTU and perform the control within that device.
At the same time, traditional PLCs included communications modules that
would allow PLCs to report the state of the control program to a computer
plugged into the PLC or to a remote computer via a telephone line. PLC and
RTU manufacturers therefore compete for the same market.

As a result of these developments, the line between PLCs and RTUs has blurred
and the terminology is virtually interchangeable. For the sake of simplicity, the
term RTU will be used to refer to a remote field data interface device; however,
such a device could include automation programming that traditionally would
have been classified as a PLC.

2.2 Communications Network

The communications network is intended to provide the means by which data

can be transferred between the central host computer servers and the field-based
RTUs. The Communication Network refers to the equipment needed to transfer
data to and from different sites. The medium used can either be cable, telephone
or radio.
The use of cable is usually implemented in a factory. This is not practical for
systems covering large geographical areas because of the high cost of the cables,
conduits and the extensive labor in installing them. The use of telephone lines
(i.e., leased or dial-up) is a more economical solution for systems with large
coverage. The leased line is used for systems requiring on-line connection with
the remote stations. This is expensive since one telephone line will be needed per
site. Dial-up lines can be used on systems requiring updates at regular intervals
(e.g., hourly updates). Here ordinary telephone lines can be used. The host can
dial a particular number of a remote site to get the readings and send
commands.

Remote sites are usually not accessible by telephone lines. The use of radio offers
an economical solution. Radio modems are used to connect the remote sites to the
host. An on-line operation can also be implemented on the radio system. For
locations where a direct radio link cannot be established, a radio repeater is used
to link these sites.

Historically, SCADA networks have been dedicated networks; however, with the
increased deployment of office LANs and WANs as a solution for interoffice
computer networking, there exists the possibility to integrate SCADA LANs into
everyday office computer networks.

The foremost advantage of this arrangement is that there is no need to invest in

a separate computer network for SCADA operator terminals. In addition, there
is an easy path to integrating SCADA data with existing office applications, such
as spreadsheets, work management systems, data history databases, Geographic
Information System (GIS) systems, and water distribution modeling systems.

2.3 Central Host Computer

The central host computer or master station is most often a single computer or a
network of computer servers that provide a man-machine operator interface to
the SCADA system. The computers process the information received from and
sent to the RTU sites and present it to human operators in a form that the
operators can work with. Operator terminals are connected to the central host
computer by a LAN/WAN so that the viewing screens and associated data can be
displayed for the operators. Recent SCADA systems are able to offer high
resolution computer graphics to display a graphical user interface or mimic
screen of the site or water supply network in question. Historically, SCADA
vendors offered proprietary hardware, operating systems, and software that was
largely incompatible with other vendors' SCADA systems. Expanding the system
required a further contract with the original SCADA vendor. Host computer
platforms characteristically employed UNIX-based architecture, and the host
computer network was physically removed from any office-computing domain.

However, with the increased use of the personal computer, computer networking
has become commonplace in the office and as a result, SCADA systems are now
available that can network with office-based personal computers. Indeed, many
of today's SCADA systems can reside on computer servers that are identical to
those servers and computers used for traditional office applications. This has
opened a range of possibilities for the linking of SCADA systems to office-based
applications such as GIS systems, hydraulic modeling software, drawing
management systems, work scheduling systems, and information databases.

2.4 Operator Workstations and Software Components

Operator workstations are most often computer terminals that are networked
with the SCADA central host computer. The central host computer acts as a
server for the SCADA application, and the operator terminals are clients that
request and send information to the central host computer based on the request
and action of the operators.

An important aspect of every SCADA system is the computer software used

within the system. The most obvious software component is the operator
interface or Man Machine Interface/Human Machine Interface (MMI/HMI)
package; however, software of some form pervades all levels of a SCADA system.
Depending on the size and nature of the SCADA application, software can be a
significant cost item when developing, maintaining, and expanding a SCADA
system. When software is well defined, designed, written, checked, and tested, a
successful SCADA system will likely be produced. Poor performances in any of
these project phases will very easily cause a SCADA project to fail.

Many SCADA systems employ commercial proprietary software upon which the
SCADA system is developed. The proprietary software often is configured for a
specific hardware platform and may not interface with the software or hardware
produced by competing vendors. A wide range of commercial off-the-shelf (COTS)
software products also are available, some of which may suit the required
application. COTS software usually is more flexible, and will interface with
different types of hardware and software. Generally, the focus of proprietary
software is on processes and control functionality, while COTS software
emphasizes compatibility with a variety of equipment and instrumentation. It is
therefore important to ensure that adequate planning is undertaken to select the
software systems appropriate to any new SCADA system.

Software products typically used within a SCADA system are as follows:

• Central host computer operating system: Software used to control the
central hostcomputer hardware. The software can be based on UNIX or
other popular operating systems.
• Operator terminal operating system: Software used to control the central
host computer hardware. The software is usually the same as the central
host computer operating system. This software, along with that for the
central host computer, usually contributes to the networking of the central
host and the operator terminals.
• Central host computer application: Software that handles the transmittal
and reception of data to and from the RTUs and the central host. The
 software also provides the graphical user interface which offers site mimic
screens, alarm pages, trend pages, and control functions.
• Operator terminal application: Application that enables users to access
information available on the central host computer application. It is
usually a subset of the software used on the central host computers.
• Communications protocol drivers: Software that is usually based within
the central host and the RTUs, and is required to control the translation
and interpretation of the data between ends of the communications links
in the system. The protocol drivers prepare the data for use either at the
field devices or the central host end of the system.
• Communications network management software: Software required to
control the communications network and to allow the communications
networks themselves to be monitored for performance and failures.
• RTU automation software: Software that allows engineering staff to
configure and maintain the application housed within the RTUs (or PLCs).
Most often this includes the local automation application and any data
processing tasks that are performed within the RTU.

The preceding software products provide the building blocks for the application-
specific software, which must be defined, designed, written, tested, and deployed
for each SCADA system.

3.1 Attacks Against SCADA Systems

In today’s corporate environment, internal networks are used for all corporate
communications, including SCADA. SCADA systems are therefore vulnerable to
many of the same threats as any TCP/IP-based system. SCADA Administrators
and Industrial Systems Analysts are often deceived into thinking that since their
industrial networks are on separate systems from the corporate network, they
are safe form outside attacks. PLCs and RTUs are usually polled by other 3rd
party vendor-specific networks and protocols like RS-232, RS-485, MODBUS4,
and DNP, and are usually done over phone lines, leased private frame relay
circuits, satellite systems, licensed and spread spectrum radios, and other token-
ring bus topology systems. This often gives the SCADA System Administrators a
false sense of security since they assume that these end devices are protected by
these non-corporate network connections.

Security in an industrial network can be compromised in many places along the

system and is most easily compromised at the SCADA host or control room level.
SCADA computers logging data out to some back-office database repositories
must be on the same physical network as the back-end database systems, or
have a path to access these database systems. This means that there is a path
back to the SCADA systems and eventually the end devices through their
corporate network. Once the corporate network is compromised, then any IP-
based device or computer system can be accessed. These connections are open
24x7 to allow full-time logging, which provides an opportunity to attack the
SCADA host system with any of the following attacks:
 • Use a Denial of Service (DoS) attack to crash the SCADA server leading to
shut down condition (System Downtime and Loss of Operations)
• Delete system files on the SCADA server (System Downtime and Loss of
Operations)
• Plant a Trojan and take complete control of system (Gain complete control
of systemand be able to issue any commands available to Operators)
• Log keystrokes from Operators and obtain usernames and passwords
(Preparation for future take down)
• Log any company-sensitive operational data for personal or competition
usage (Lossof Corporate Competitive Advantage)
• Change data points or deceive Operators into thinking control process is
out of control and must be shut down (Downtime and Loss of Corporate
Data)
• Modify any logged data in remote database system (Loss of Corporate
Data)
• Use SCADA Server as a launching point to defame and compromise other
systemcomponents within corporate network. (IP Spoofing)

3.2 Developing a SCADA Security Strategy

For a company to protect its infrastructure, it should undertake the development

of a security strategy that includes specific steps to protect any SCADA system.
Such a strategy may include the following approach.

Developing an appropriate SCADA security strategy involves analysis of

multiple layers of both the corporate network and SCADA architectures
including firewalls, proxy servers, operating systems, application system layers,
communications, and policy and procedures. Strategies for SCADA Security
should complement the security measures implemented to keep the corporate
network secure

Successful attacks can originate from either Internet paths through the
corporate network to the SCADA network, or from internal attacks from within
the corporate office. Alternatively, attacks can originate from within the SCADA
network from either upstream (applications) or downstream (RTUs) paths. What
is an appropriate configuration for one installation may not be cost effective for
another. Flexibility and the employment of an integrated and coordinated set of
layers are critical in the design of a security approach.

Most corporate networks employ a number of security countermeasures to

protect their networks. Some of these and a brief description of their functions
are as follows:

• Border Router and Firewalls Firewalls, properly configured and

coordinated, can protect passwords, IP addresses, files and more.
However, without a hardened operating system, hackers can directly
penetrate private internal networks or create a Denial of Service
condition.
• Proxy Servers A Proxy server is an internet server that acts as a firewall,
mediating traffic between a protected network and the internet. They are
critical to re-create TCP/IP packets before passing them on to, or from,
application layer resources such as Hyper Text Transfer Protocol (HTTP)
and Simple Mail Transfer Protocol (SMTP). However, the employment of
proxy servers will not eliminate the threat of application layer attacks.
• Operating Systems Operating systems can be compromised, even with
proper patching, to allow network entry as soon as the network is
activated. This is due to the fact that operating systems are the core of
every computer system and their design and operating characteristics are
well known world wide. As a result, operating systems are a prime target
for hackers. Further, in- place operating system upgrades are less efficient
and secure than design-level migration to new and improved operating
systems.
• Applications-Application
Applications layer attacks; i.e., buffer overruns, worms,
Trojan Horse programs and malicious Active-X5 code, can incapacitate
anti-virus software and bypass the firewall as if it wasn’t even there.
• Policies and Procedures Policies and procedures constitute the foundation
ofsecurity policy infrastructures. They include requiring users to select
secure passwords that are not based on a dictionary word and contain at
least one symbol, capital letter, and number, and should be over eight
characters long. Users should not be allowed to use their spouse, child, or
pet’s name as their password. The above list is common to all entities that
have corporate networks. SCADA systems for the most part coexist on the
same corporate network.. The following list suggests ways to help protect
the SCADA network in conjunction with the corporate network:
• SCADA Firewalls-SCADA
Firewalls Systems and Industrial Automation Networks,
like corporate network operating systems, can be compromised using
similar hacking methods. Oftentimes, SCADA systems go down due to
other internal software tools or employees who gain access into the
SCADA systems, often without any intention to take down these systems.
For these reasons, it is suggested that strong firewall protection to wall off
your SCADA networking systems from both the internal corporate
network and the Internet be implemented. This would provide at least two
layers of firewalls between the SCADA networking systems and the
Internet.
• SCADA Internal Network Design-SCADA
Design networks should be segmented
off intotheir own IP segment using smart switches and proper sub-
masking techniques to protect the Industrial Automation environment
from the other network traffic, such as file and print commands. Facilities
using Wireless Ethernet and Wired Equivalent Protocol (WEP) should
change the default name of the Service Set Identifier6 (SSID).