TRANSMISSION
Investigating the security of
by Edward Chikuni, Polytechnic University of Namibia, and Maxwell Dondo, Defence R&D, Canada
Supervisory control and data acquisition (SCADA) systems control and monitor the majority of the utility networks today. The increased number
of attacks on computer systems and computer networks has resulted in an increased concern of security issues in inter-networked industrial
automation systems.
Internal and external saboteurs pose a big
threat that could disrupt power delivery. To
give us a better understanding of the nature
of the vulnerabilities to supervisory control and
data acquisition system (SCADA) systems and
highlight the need to defend and protect the
SCADA systems from ongoing cyber threats,
we investigate the vulnerabilities and ways
to protect them which are unique to SCADA
systems. We achieve this by studying SCADA
communication systems as well as taking
a survey of common SCADA vendors; we
focus our attention to SCADA on the electric
power grid. We find that SCADA vendors do
not implement adequate security measures
in their products, and we recommend that a
security policy be put in place to ensure the
security of the vital public infrastructures.
To assist in the management and control
of the country’s critical infrastructures, such
as the electrical power grid, automation
processes like SCADA were developed
and implemented – complete with remote
communications. The complexity of the
interconnected controls adds new challenges
for the deliver y of secure and reliable
services by these systems. The electrical
power system SCADA system controls and
Fig. 1: SCADA communications in an electric power system.
power system SCADA
monitors the equipment essential for power
delivery. It is used, among other things, for
fault detection, equipment isolation and
restoration (protection), load and energy
management, automated meter reading,
and substation control.
Many of the SCADA systems being used by
today’s utilities were developed many years
ago; before the Internet and there were
no public or private computer networks.
The only security threat to the utilities and
SCADA systems was physical destruction
[11]. Nobody foresaw advances in the utility
industr y in equipment automation and
deregulation which would require SCADA
systems to be interconnected. The need
for remote connectedness of these control
devices opened up the whole interconnected
system to new and challenging vulnerabilities
that every computer network in the world is
facing today– cyber-attacks [3], [18]. Utilities,
governments, and other stake-holders are
teaming up together to tackle these latest
threats.
Although the biggest threat to electric utilities
is still physical destruction, the number
of cyber attacks to SCADA systems has
energize - December 2007 - Page 22
prompted many researchers to focus their
attention to this critical and often overlooked
part of public infrastructure [3], [12]. The 2003
power blackout in Canada and parts of the
USA served as a wake-up call to what could
happen in the event of a successful attack
to power grid [15].
SCADA background
The geographically dispersed electric power
system grid is commonly controlled by a
SCADA system consisting of at least one
computer running appropriate application
software. The components of the SCADA
system are interconnected by varying types
of communications media.
Ideally, the SCADA communications are
intended to be interconnected to every
part of the utility as illustrated in Fig. 1. The
majority of the SCADA’s main controls are in
the control center where operators man the
SCADA computers.
Access to the control room is usually limited
to the few controllers who work on the control
machines. SCADA systems have a wide
variety of functions which are crucial to the
day-to-day running of the electrical power

utility. These functions include identifying faults,
isolating them and restoring service, circuit
breaker and recloser control, feeder switching
and reconfiguration, line switching, voltage
control, load management, automatic
meter reading, automatic generation
control, economic dispatch, simulation
and emulation, capacitor bank switching,
voltage regulator monitoring, transformer
temperature, and metering [5], [7].
It is important to mention at this point that
the electric utility is constructed with built-in
automatic safeguards and controls that
are ideally intended to ensure reliable
supply as specified in the the IEEE standard
C37.1 (among many other powers systems
standards). Automatic relays, reclosers and
circuit breakers ensure that power supply
is uninterrupted by altering the power
flow routes to circumvent faults that may
disrupt power flows. If SCADA systems fail,
or they send a control signal that ends up
needlessly shutting down power flows, then
the automatic controls would self-correct
and send the right signal to ensure continued
power supply.
The bottom line is that SCADA controls can
only work within the specified parameters
of the powers systems network they are
controlling. For example, they cannot raise
the temperature of the substation when there
are no heaters in the substation.
SCADA devices
The main component of the SCADA system is
the SCADA master. This is usually a computer
system (PC based systems or workstations)
running the appropriate SCADA software
under an appropriate operating system
[7]. These computers also provide for and
interface with monitors to provide controllers
with a visual state of the system.
A SCADA system consists of remote terminal
units (RTUs) located in different parts of
the utility, such as substations and power
plants. RTUs are special purpose computers
containing both analog to digital converters
and digital to analog converters. They
communicate their data with the SCADA
master, sub-master, or with other RTUs through
the multiple sports.
More than one ma s t e r s t a t i o n m a y
communicate with an RTU. In large systems,
sub-masters (slave masters) gather information
from the RTUs and relay it to and from the
control master station. Depending on the
architecture, repeaters may also be required.
Generally, RTUs interface with intelligent
electronic devices (IEDs) used in transmission
and distribution substations. IEDs include
meters, voltage regulators, transformer tap
positions, relays, reclosers and other electrical
transducers.
SCADA devices are interconnected by
communication links such as optical fiber,
radio, telephone line, microwave, satellite,
or ethernet. The IEEE standard C37.1-1994
specifies the communication topologies
used in SCADA. They vary from simple a point-
to-point to composite architectures with one
single master station, multiple sub-master
(slave master) stations and multiple RTUs.
One or more IEDs may link to a RTU through
a fieldbus [4] such as Profibus or Foundation
Fieldbus. The communication links may also
use different interface types, e.g. RS-232,
RS-485, depending on the SCADA protocol
and architecture being used. SCADA systems
can also be connected to the local area
network (LAN). This enables anyone within
the LAN with the correct authentication and
applications software to be able to access
the SCADA system.
SCADA software
The SCADA master also runs some selected
energy management system (EMS)
applications. The additional utility applications
software are used to communicate and
control other parts of the grid, like the
protection or unit commitment systems.
Software is available in either proprietary or
open protocol implementations. Most utilities
would prefer open software so that they don’t
depend on just one equipment manufacturer,
and they don’t have to pay royalties [4], [7].
RTU software is used to communicate with
the master station and other RTUs. Some
RTUs have sufficient processing power to
be able to perform some local control, e.g.
automatic switching of capacitor banks for
var compensation.
Other key components of the SCADA software
include alarms, trends, and databases. It also
needs to be fault-tolerant, scalable and able
to support client/server distributed computing.
The vendors range from providers of the
computer operating systems to the SCADA
applications that sit on these operating
systems (OSs). While the UNIX multi-tasking
operating system was traditionally used for
higher sophistication and complexity, it is
gradually being replaced by Windows. Linux
is gaining popularity as an OS of choice in
SCADA systems due to its low cost and UNIX-
like properties [7].
Typical SCADA vulnerabilities
When SCADA systems were first put into
widespread use, the only plausible threat
to the SCADA system was considered to be
energize - December 2007 - Page 23
TRANSMISSION
sabotage through the physical destruction
of the utility ’s property. SCADA systems
were secured by limiting physical access
to the SCADA terminals and consoles that
control the electric grid to a few authorised
controllers. However, as the modernisation of
SCADA systems continues, they are getting
increasingly interconnected to internal and
external networks (and the Internet as a
whole). This exposes the SCADA system to
vulnerabilities inherent in these networks,
such as the numerous reported cases of
attacks and potential threats on SCADA
systems worldwide [6], [9]. These range from
attempted DoS attacks on an Israeli power
plant [17] to slammer worm attacks on an
Ohio nuclear power plant [13], [14]. There
are also reported vulnerabilities like the GE
XA/21 [15] bug that could be exploited by
attackers if systems are not patched. This
bug contributed to the North American
blackout of 14 August 2003.
These attacks are not unique to SCADA
systems. The vulnerabilities capitalised in
these cases affect all networked computers
regardless of where they are deployed. The
unique thing about SCADA systems is that they
are highly customized and rarely have the
same configuration and functionality. Thus,
attacking SCADA systems requires specific
and detailed knowledge.
Historically control of utility power systems was
a failsafe system that did not rely on computer
systems. The use of computer systems in
SCADA has exposed the SCADA networks
to computer vulnerabilities. We will look at
SCADA vulnerabilities by considering the
computing vulnerabilities at various points in
the SCADA network. We then present possible
solutions to those vulnerabilities that are
unique to SCADA systems, paying particular
attention to the elements of computer
security (authentication, confidentiality,
integrity, availability).
SCADA computing vulnerabilities
We discuss the computing vulnerabilities
whose sources include protesters, activists,
hobbyist hackers, terrorists, employees
and former employees, vendors, and
contractors.
SCADA hardware
The vulnerabilities on the different SCADA
hardware devices (RTUs, IEDs, SACAD masters,
etc.) are similar to the vulnerabilities of
regular computer systems: interruption (DoS),
interception and eavesdropping. Similarly, the
communications link between the hardware
devices is also susceptible to vulnerabilities
seen in regular computer networks.
TRANSMISSION
SCADA information usually travels through
exposed communication links. In most cases,
messages are not encrypted. This may result
in data or password interception; whether
proprietary protocols are used or not. SCADA
monitors are generally not shielded to protect
radiation emissions that could be read by
unauthorised people.
One important remedy to hardware
vulnerabilities is to have a strong security
policy in place. New hardware should always
pass the National Computer Security Center
(NCSC) C2 rating. Encryption can also be
used on the communication links, and in
some cases, fibre optic cables may reduce
the risk of interception, fabrication, and
modification of SCADA data. SCADA monitors
should also be shielded if the control room is
not located in a very secure environment.
SCADA software
Like any other software, the most common
vulnerabilities of SCADA software are
interruption, interception, and modification.
Software may be deleted intentionally by
an attacker resulting in a potentially serious
malfunction. The most lethal attacks on
software are usually related to software
modification. In this attack, software is
modified to either make it fail or perform
unintended tasks. Bugs are also very serious
form of software vulnerability [15]. If they are
not fixed in time, hobbyist hackers with very
little skills can take advantage of publicised
vulnerabilities to attack and unpatched
SCADA.
Again, there are no unique ways to prevent
these software attacks in SCADA systems that
are not similar to what is currently being done
in computer systems. Because of the nature of
the systems being protected, stricter controls
like configuration management systems to
control software access would reduce the
risk software deletion, modification, and
theft. It would also be advisable to use OSs
and software applications that pass at least
NCSC C2 level rating.
SCADA data integrity
SCADA data has more value to an attacker
than the software and hardware. Metering,
status, and control data can be used to the
detriment of the utility if not handled with
extreme caution. As in ordinary networks,
SCADA data may be stolen for use by
competitors or saboteurs. Data may also be
modified to perform tasks that are harmful to
the utility or its personnel.
Currently, only CRC error checking is performed
on SCADA data. To safeguard data integrity,
vital data needs to be encr ypted. The
American Gas Association (AGA) has been
researching on cryptographic protection of
SCADA communications [1] through the Gas
Technology Institute (GTI). It is recommending
the use of encryption to protect vital data.
SCADA networks
Each point in the SCADA network is a
potential entry point and remote access is
usually available. While these security holes
are also present in any current computer
network, SCADA systems are particularly more
vulnerable since very little work has been
done to enhance their security; nobody
believed that there was a problem there.
To make matters worse, some of the SCADA
networks are interconnected through the
Internet, and use common internet protocols
for communication. With less security in
place for SCADA systems, it makes them
vulnerable to potential internet attacks.
Like any computer network, connecting
the SCADA network to the Internet without
the proper safeguards is a recipe for
disaster. A complete security policy should
be implemented in this case. Properly
configured firewalls and IDSs need to be
part of the connection policy.
Other computing vulnerabilities
In addition to the vulnerabilities stated
above, other sources of security concern
exist. Unauthorised access to computing
equipment may deny a legitimate user or
process access to required resources thus
resulting in the failure of the SCADA system
to perform what it is intended to.
Another source of vulnerability which is more
widespread in SCADA systems is the screening
of people who are allowed access to the
SCADA controls. In most cases, there are
limited consoles to the SCADA system, and
controllers take turns to use the controllers.
As a result, passwords are either written
somewhere or they are not that secret. A
disgruntled or former employee may cause
extensive damage to the system through
unauthorised access and execution of
restricted commands.
The other false sense of security with SCADA
vendors and clients alike is that they use
proprietar y protocols and therefore do
nothing about security since they believe
nobody else knows the protocols well
enough to attack their SCADA. However, this
is not necessarily so. Former employees of
the utility or SCADA vendor, SCADA experts
and consultants are very well conversant
with these protocols and can pose a big
threat to the SCADA system. Software tools
to analyse protocols can be downloaded
form the Internet.
Once again, these vulnerabilities are not
just unique to SCADA systems. However, one
energize - December 2007 - Page 24
quick solution that may be unique to SCADA
access control would be to house computers
that have SCADA consoles in very secure
buildings and locations. This reduces the
likelihood of a disgruntled former employee
having access to the SCADA controls.
Other SCADA vulnerabilities
SCADA systems still need to be housed in
secure locations where access is restricted to
authorised personnel only. This also applies to
all IEDs and RTUs. Pole mounted IEDs should
be placed in locations that are inaccessible
to unauthorized users. The control room may
need to be shielded so that emissions from
control monitors may not be accessible to
unauthorised individuals.
Unlike most IT professionals, SCADA operators
are not generally trained and aware of the
need for SCADA security. Most operators
do not have a full picture of the SCADA
security policy and roles. In some cases, any
employee could walk into a SCADA control
room, without anyone stopping them.
Telephone and modem dial-in
access is another source of possible
SCADA vulnerability that need special
attention. Where available, access to
relays, controllers, IEDs, and RTUs should
be password controlled. Remote
communications with these devises is very
common, so secure communications is
very important. For example, encryption
modems [2] are available for secure dial-
up communications. Using phone numbers
that you perceive are unknown to the public
is not good enough, since there are ways
of getting unlisted phone numbers, e.g.
through wire tapping, “war-dialing”, or using
software widely available on the internet.
Security solutions unique to SCADA
There are no new solutions that are unique to
SCADA systems per se. Most of the security
solutions to potential vulnerabilities in SCADA
systems are already known to the Internet
security world. Due to the nature of the assets
being protected, the computing resources
used have to be able to withstand most of
the known vulnerabilities. We will explore this
through the basic elements of security.
Authentication
All employees with access to SCADA control
terminals should be authorised to do so,
an their authorisation needs to be current.
Strong authentication should be used. Simple
password protection may not be sufficient.
At least a two-factor authentication system
should be used. Access to IEDs should require
the use of strong authentication or smart
card access.

Availability, integrity and confidentiality
The software and hardware should at
least meet the NCSC class C2 rating.
VPN protocols (PPTP, IPSec, L2TP) should
be considered for communications on
substation RTUs and IEDs. Encryption should
be used for all sensitive data transfer,
including control requests. If an option to
use encryption is provided by the vendor,
it should be used. It is important that these
cryptographic algorithms be incorporated
into the SCADA communications protocols
and operational standards. For example,
the IEEE standard C37.1 recommends
the cryptographic algorithms to use with
SCADA systems. The same standard also
addresses the implementation of security
features in both asynchronous serial SCADA
communications as well as communications
over the internet.
The IEEE standard C37.1 also recommends
that high value communications should
integrate an IDS. In some cases firewalls
and router ACLs can be used to verify that
a SCADA signal destined for an RTU or IED is
intended for that system by checking firewall
and ACL rules for the SCADA protocol being
used. For example, MODBUS/TCP uses port
502, so, monitoring traffic logs using this port
can easily reveal attempted break-ins on
the system.
SCADA vendor survey on security
These surveys were carried out between
July and December 2004. The security
awareness of all the vendors surveyed was
very limited. The responses obtained from
the majority of the vendors listed below
showed limited implementation of security
features in SCADA on the vendor side. One
plausible argument raised by one vendor
is that industry (in this case the utilities) is
not pushing to have these security features
included, or the possible extra costs that
may be incurred discourages them from
pursuing this further; since they always have
a limited, but functionally reliable backup
system. The comments included in this
survey were obtained from the named
individual vendors though email, telephone
discussions, or both. Downloaded internet-
based data sheets were also used.
Survalent LT (formerly Quindar [16])
• Available on Windows and OpenVMS
platforms. The Windows SCADA system
uses Dell PowerEdge servers and Windows
Server 2003 OS. The VMS SCADA system
uses HP Alpha servers and OpenVMS
OS.
• Uses a System Manager software that
provides for operator authentication
and different security zones for users
and peripherals such as printers. Also
provides for login and Timeout, “settable”
user rights, “Select-Checkback” to field
devices, multi-level tagging zones
or Responsibility, and two-factor VPN
Authentication application and keys
for secure communications to remote
stations.
• Supports proprietary and open protocols–
both serial and over–TCP/IP interfaces.
• Not concerned about the data as it
travels between the master and the
RTUs or IEDs. This is up to the customer to
implement.
Siemens
• PC-based SCADA application uses a
central systemwide management for
users. System also has encrypted storage
of user information in a database format.
Maintains a log of all activities by the
users and administrators; including login
on/off, incorrect password entries and
commands send out. No SCADA data
encryption.
• Full web operation and monitoring using
OPC XML for communication.
• Other components used by the Siemens
WinCC SCADA are: MS Windows Server,
MS SQL server, MS VBA,MS OS(Win 2000,
XP), VBScript, ActiveX components.
• Authentication provided for operators
when they log on to the console. Password
log is available. Different authentication
and privileges for user categories.
• Supports both open and proprietary
protocols.
ABB Spider (also includes Ranger, Cadops)
• Network Manager is the SCADA/ EMS/
DMS/ GMS solution for large electrical
and gas systems available on Unix/Linux
and Windows platforms.
• Network Manager allows integration into
utility’s IT systems while maintaining the
existing security levels.
• Supports both open and proprietary
protocols.
• With ABB SCADA, clients are expected
to implement their own security policies
for their SCADA systems. Third party
firewall implementations are available
to securely separate the office networks
from the SCADA networks. Encryption
is also available through third party
applications. For example, California
ISO [10] implemented an ABB SCADA
security system that encr ypts data
between RTUs and SCADA masters. It
also uses a combination of firewalls, VPN
and digital certificates to ensure secure
communication.
Telvent OASys
• Supports both open and proprietary
protocols.
energize - December 2007 - Page 25
TRANSMISSION
• Authentication provided to operators
through SCADA PCs’ OS access control
• N o d a t a e n c r y p t i o n – c l i e n t ’ s
responsibility.
• Different levels of security provided for by
the LANs are also available to operators/
engineers.
GE XA/21 [8]
• Built-in proactive services performed by
application e.g. removing unwanted
files, learing unwanted users. Multilevel
authentication.
• PC based, intranet and internet browser
access, ODBC onnectivity through third
party tools, online capability to update
the database, add/delete/modify
terminal units and datalink objects, Data
sharing between sites.
• Supports various industr y standard
protocols. Determines the quality and
integrity of data based on preset limits,
normal/abnormal states, and other
standards.
• Secure repository database for mission-
critical data.
• Supported on IBM AIX6000, SUN/Solaris
and Motorola/AIX.
• To ensure data integrity, GE uses available
technology, like SSL, proximity devices,
digital signatures of software, strict
password policies, etc.
Discussion of SCADA vendor survey
While vendors showed some general level
of security awareness, a lot still needs to be
done. The security levels available in most of
these SCADA systems are those that come
with the computer systems that the SCADA
applications are installed on. Using the
metrics we established in Section III-A, we
discuss the SCADA vendor security awareness
in the following:
SCADA hardware
All the surveyed vendors use PC-based or
workstation-based SCADA systems. Most
of them did not explicitly state the type of
computer hardware to use with their SCADA.
We therefore assume that the SCADA is as
vulnerable as the computer being used. It is
recommended that utilities specify the use
of workstations and servers that meet the
NCSC C2 rating as a minimum requirement.
The hardware area found to be most lacking
with all the vendors was the security of the
communications link.
Software
No specifics were found on software
applications security. However, the security
of the application software is as good as the
software itself and if the weaknesses (in the
application(s)) are not public knowledge.
TRANSMISSION
Once weaknesses are known, patches need
to be applied fast before anyone exploits the
weakness e.g. the GE XA/21 bug.
In most cases, other EMS and protection
applications are running on the
same computer system. Under these
circumstances, care should be taken to
ensure that they don’t consume substantial
computer resources to effect a DoS on
the SCADA system. Siemens also adds to
its vulnerability by using many Microsoft
ActiveX components as well as the MS SQL
server which may be susceptible to attacks.
It would also be safer not to mention in
datasheets the type of database being
used; this may give attackers good hints on
how to attack the system.
Encrypted storage of data in databases
by Siemens is a good security step. On the
software side, the OS is the most critical;
there are many exploits for different OSs. MS
Windows XP and MS windows servers do not
currently have an NCSC rating; neither do
they have the Common Criteria Certification
rating yet. It is not advisable to use OSs that
are not NCSC C2 rated.
OSs that have earned the C2 rating include
versions of IBM’s OS/400 and Digital ’s
OpenVMS. NT 3.5 (Workstation and Server)
with Service Pack 3 (SP3) earned the C2 rating
in July 1995. Modern UNIX systems fulfil C2
requirements, and many OS vendors offer the
C2 package. It is therefore recommended
that the C2 package be used in all SCADA
systems using the Solaris, AIX, and Unix OSs.
This is applicable to ABB and Siemens SCADA
systems.
Data integrity
Except for CRC checks, there is very little
data protection on the vendor side. Almost
all vendors surveyed insists that this is the
responsibility of the client. GE’s XA/21 mentions
attempts to ensure data integrity through
different means. ABB claims to use VPNs
and encryption to ensure payload security.
These are good steps towards ensuring data
integrity, but overall more needs to be done
in order to standardise data integrity within
SCADA protocols.
Networks
All vendors surveyed are capable of internet
connectivity. This exposes the SCADA system
to unwanted attacks from the internet.
Once again, the connection and security
configuration of such networks were said to
be the responsibility of the client.
Summary and conclusions
We have looked at several aspects of
SCADA security and presented a vendor
sur vey on SCADA security. There were
several revelations that we got from this
work. SCADA, as a vital public infrastructure,
needs a more robust security policy and
awareness than what we found to be the
existing scenario.
To their credit, SCADA systems and the electric
utility have very robust built-in safeguards as
specified in the IEEE standard C37.1.
For example, the component limits of the
utility are usually coded into the SCADA
system. So, if an attacker inputs commands
that fall outside these ranges, then the
SCADA system is supposed to ignore them.
The same thing applies to the electricity grid.
If a command is issued to isolate a certain
section of the grid for no apparent reason,
the grid will automatically restore itself after
performing a self check.
In addition, SCADA systems are usually
custom made for that particular utility, and
no two utilities use the same configuration.
Therefore to effect serious damage on
the SCADA system, one has to be very
knowledgeable with the SCADA system as
well as the grid itself. This tends to limit the
number of possible attackers, and may
explain why the number of attacks on
SCADA have not been as widespread as in
other computer networking environments.
This does not, however, mean that SCADA
systems are safe from attacks. All it means is
that, the types of attacks that are likely to be
experienced by the utility are most likely from
professional saboteurs, rather than hobbyist
hackers. Thus a robust and hardened security
policy needs to be put in place.
In this work, we came to the conclusion
that there are no unique ways needed
to protect SCADA systems. All currently
known and available computer network
protection systems are equally applicable
to SCADA systems, although some custom
configurations may be needed. IEEE
standard C37.1 recommends some
important security aspects on SCADA systems
which should be taken into consideration
when designing SCADA systems.
Asynchronous serial communications,
which are common in SCADA systems can
be securely protected with retrofit security
features. Wise choice of SCADA software
and hardware also contributes to a robust
and secure SCADA system. Software and
hardware should at least meet the NCSC
class C2 rating. Secure communications
and encryption should be considered for
vital data, and access to IEDs and RTUs
should be restricted.
energize - December 2007 - Page 26
Acknowledgement
This paper was presented at the recent
IEEE African 2007 Conference in Namibia
in September 2007, and is republished with
permission.
References
[1] AGA Report No. 12-1, “Cr yptographic
protection of SCADA communications,” Tech.
Rep., 2003.
[2] A Beyer, “Securing dialup communications
with encryption modems,” Tech. Rep., 2003.
[3] R Carlson, “Sandia SCADA program: High-
security SCADA LDRD final report,” Sandia
National Laboratories, Tech. Rep., 2002.
[4] G Clarke and D Reynders, Practical Modern
SCADA Protocols: DNP3, 60870.5 and Related
Systems. Oxford: Elsevier, 2004.
[5] M G Dondo and M E El-Hawary, “An
approach to implement electricity metering
in real-time using artificial neural networks,”
IEEE Transactions on Power Delivery, vol. 18,
no. 2, pp. 383–386, April 2003.
[6] R Farrow, “Critical infrastructure security and
you,” Network Magazine, 2002.
[7] D G Fink and H W Beaty, Standard Handbook
for Electrical Engineers. New York, NY: McGraw-
Hill, 1978.
[8] GE Network Solutions, “XA/21,” General
Electric, 2002.
[9] B Gellman, “Cyber-attacks by al qaeda
feared:terrorists at threshold of using internet
as tool of bloodshed, experts say,” Washington
Post, 2002.
[10] Hathaway Industrial Automation, “California
iso project,” Tech. Rep.,1999.
[11] Internet Security Systems, “Assessment and
remediation of vulnerabilities in SCADA and
process control systems,” Internet Security
Systems, pp. 1–10, April 2003.
[12] NERC, “Security guidelines for the electricity
sector,” North American Electric reliability
Council, Tech. Rep., 2002.
[13] North American Electric Reliability Council,
“SQL slammer worm lessons learned. for
consideration by the electricity sector,” North
American Electric Reliability Council, 2003.
[14] K Poulsen, “Slammer worm crashed ohio
nuke plant net,” SecurityFocus, 2003.
[15] SecurityFocus, “Software bug contributed
to blackout,” SecurityFocus News, February
2004.
[16] Survalent Technology, “Quindar products, ltd.
unveils new identity, aggressive growth plans,”
Survalent Technology, 2002.
[17] G Yamini, “Iranian hacking attempt to electric
corporation foiled,” Online: Ha’aretz, 2003.
[18] L Zocco, “SEL and electric power utilities
working to safeguard the electric power grid,”
in Power Systems World, 2002.
Contact Edward ChikuniPolytechnic University
of Namibia, echikuni@polytechnic.edu.na
or Maxwell Dondo, Defence R&D Ottawa,
maxwell.dondo@drdc-rddc.gc.ca v