TRANSMISSION

Investigating the security of power system SCADA

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 countrys 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

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 todays 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

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 SCADAs 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

Fig. 1: SCADA communications in an electric power system.

energize - December 2007 - Page 22

TRANSMISSION
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 pointto-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 dont depend on just one equipment manufacturer, and they dont 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 UNIXlike 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 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 dialup 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.

TRANSMISSION
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 internetbased 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 overTCP/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 utilitys 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 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 missioncritical 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 dont 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 IBMs 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. GEs 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. 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. A Beyer, Securing dialup communications with encryption modems, Tech. Rep., 2003. [3] R Carlson, Sandia SCADA program: Highsecurity SCADA LDRD final report, Sandia National Laboratories, Tech. Rep., 2002. G Clarke and D Reynders, Practical Modern SCADA Protocols: DNP3, 60870.5 and Related Systems. Oxford: Elsevier, 2004. 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. 383386, April 2003. R Farrow, Critical infrastructure security and you, Network Magazine, 2002. D G Fink and H W Beaty, Standard Handbook for Electrical Engineers. New York, NY: McGrawHill, 1978. GE Network Solutions, XA/21, General Electric, 2002. B Gellman, Cyber-attacks by al qaeda feared:terrorists at threshold of using internet as tool of bloodshed, experts say, Washington Post, 2002. Hathaway Industrial Automation, California iso project, Tech. Rep.,1999. Internet Security Systems, Assessment and remediation of vulnerabilities in SCADA and process control systems, Internet Security Systems, pp. 110, April 2003. NERC, Security guidelines for the electricity sector, North American Electric reliability Council, Tech. Rep., 2002. 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. SecurityFocus, Software bug contributed to blackout, SecurityFocus News, February 2004. Survalent Technology, Quindar products, ltd. unveils new identity, aggressive growth plans, Survalent Technology, 2002. G Yamini, Iranian hacking attempt to electric corporation foiled, Online: Haaretz, 2003. L Zocco, SEL and electric power utilities working to safeguard the electric power grid, in Power Systems World, 2002.

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

[2]

[4]

[5]

[6] [7]

[8] [9]

[10] [11]

[12]

[13]

[15]

[16]

[17] [18]

Contact Edward ChikuniPolytechnic University of Namibia, echikuni@polytechnic.edu.na or Maxwell Dondo, Defence R&D Ottawa, maxwell.dondo@drdc-rddc.gc.ca v