Chapter 1 IMPLEMENTING AND TESTING A CUSTOM IDS FOR SUBSTATION AND PROCESS CONTROL SYSTEMS Paul Oman and Matthew Phillips Dept. of Computer Science, University of Idaho Moscow, ID 83844–1010 (contact:
[email protected]) Abstract
Real-time control systems provide for safe, reliable, accurate, and timely operation of our nation’s critical infrastructures. Rapid advances in Supervisory Control And Data Acquisition (SCADA) systems provide many short-term productivity gains and reduced costs by carrying control data over public lines and airwaves. Regrettably, this convenience has introduced vulnerabilities into systems once considered robust. Transmitting critical control and monitoring data over public communications systems leaves our critical infrastructures exposed to a worldwide pool of electronic attackers. As our SCADA systems remain vulnerable to electronic attack, enemies will seek to exploit these systems. In this paper we describe the implementation of a prototype network intrusion detection system on a model SCADA/Sensor testbed. By markedly increasing the logging of critical network events using these techniques, we show dramatic improvements in both the security and overall auditing capabilities of our system. We are able to warn of potential unauthorized access and when device configurations are changed, which not only improves the security of these critical networks, but also helps engineers recover from common errors more quickly.
Keywords: Process Control Systems, SCADA Systems, Intrusion Detection, Network IDS.
1.
Introduction
Power system control was once a laborious process. Prior to the age of digital control equipment and the use of communications networks
2 in power systems design, engineers had to travel to each substation to view system conditions and make changes. Advances in networking, and the introduction of digital devices, allowed engineers to monitor their systems centrally, controlling perhaps dozens of substations from a single terminal [1]. Further advances now allow power engineers direct control over their systems from home through the Internet, telephone system, and wireless networks [2]. When control systems were stand-alone, devices were required to meet strict controls on operating temperature, random electrical disturbances, and many other environmental concerns. The operating environment has changed. In addition to meeting the harsh realities of nature, engineers must now account for a new avenue of disturbance: electronic attack. Process control systems are known to be very heterogeneous environments. A power substation, for example, may have devices from a dozen different manufacturers. Some may communicate serially, others communicate via proprietary protocols on proprietary cabling, others using Ethernet and still others tunneling protocols over Ethernet. In addition to numerous types of devices and various communications systems, some devices may be 20 years old, while others brand new. Primarily, process control systems are built to operate in high stress, time-sensitive environments. Devices are simple and dedicated to performing their small task well. Thus, most equipment does not have the memory, processing power, or bandwidth necessary to perform most security functions carried out by a modern personal computer (PC). While a PC can negotiate a secure connection with a server using secure sockets layer (SSL) or secure shell (SSH) connections, today’s process control devices are not able to provide the calculations and bandwidth necessary to achieve such security. Real-time control systems have several additional limitations, including: weak authentication mechanisms that do not differentiate between human users no privilege separation or user account management to control access (one account, one password) most devices do not record login attempts (success, failure, number of attempts) most devices are not capable of running user programs, only performing simple logic operations many users do not change devices from factory default settings
Oman & Phillips
3
many control networks are not designed with electronic risks and defenses in mind proprietary protocols slow the integration of common security tools into control networks an overall lack of monitoring and auditing (track settings changes over time, firmware upgrades) devices are notoriously difficult to set up, and are typically configured once and left alone a disjoint between IT professionals and engineers who design process control networks heterogeneous control networks, with components varying greatly in age and capabilities, require singular attention to secure, making broad adoption unaffordable These factors severely hamper efforts to secure control systems [3, 4]. As is the case with modern power control systems, devices are capable of providing excellent protection against natural disturbances. Controlling these systems over public communications systems, however, notably increases the uncertainty of the long-term reliability of our critical infrastructures and other process control systems [5]. Fortunately, the items described are well-known in the information technology field [6]. Though building new control systems with embedded capabilities may take perhaps billions of dollars and decades to achieve, many of the items above can be remedied using existing technology at a significantly lower cost. We have identified common security weaknesses in automated process control systems, with particular attention to remotely accessible power substations, and created a model SCADA/sensor testbed used for Intrusion Detection System (IDS) experimentation. Contemporary IDS auditing tools and methods including network monitoring, signature profiling, revision control and automated backups of device settings, uptime statistics, mean time to repair (MTTR), and more are part of the SCADA IDS experimental testbed. We intentionally do not review the large body of IDS literature; rather, we focus on an experimental application of an IDS within a model SCADA system.
2.
The UofI SCADA/Sensor Testbed and Power Laboratory
SCADA security and survivability pedagogy is an important aspect of information assurance [7]. In order to provide a safe and separate
4
Figure 1.
The UofI SCADA/Sensor System Testbed.
system on which to train, test, and teach security of SCADA systems, a SCADA/Sensor System Testbed was designed and implemented in the University of Idaho’s (UofI) Electrical Engineering power lab, a fully functioning high-voltage laboratory [8, 9]. The SCADA/Sensor testbed consists of four parts, a communications system, a sensor system, a digital fault simulator, and a priority messaging system. The communication system includes a wired Ethernet network that simulates passing information over the Internet or corporate LAN’s and a wireless network passing information over an 802.11b network. These networks connect a substation communications processor to the SCADA Master and other computers enabling remote access. The communications processor is a microprocessor-based device that replaces the traditional (and archaic) Remote Terminal Unit (RTU) still found in many SCADA systems. It is logically programmable and acts as a data collection and communications hub with connections to the sensor system and protective relay equipment. The wireless component of the communication system consists of two wireless bridges configured to communicate on a point to multi-point topology. The protective relays are used to monitor the power system, control circuit breakers and report faults. Sensors in-
Oman & Phillips
5
clude motion, temperature, and alarm conditions. Figure 1 contains a simplified diagram of the UofI SCADA/Sensor System Testbed. The power laboratory includes electric machinery with integral horsepower motor-generator sets, ranging in size from 5 to 20 HP. There is a mix of AC and DC machines, permitting flexible experimentation with active loads. The largest is a 20 HP synchronous generator modified for developing and testing schemes for protecting large generators from internal faults. It is connected to the SCADA/Sensor system via power quality measurement equipment. Supply capability includes: 240V three phase AC at 115A, 120V three phase AC at 150A, 120V at 400A DC, and 240V at 180A DC. Each supply is fed at 480V three phase AC through transformers housed within the lab. The DC is generated by motor-generator sets. The laboratory also has a transient network analyzer, that can be configured to have four transmission line segments for modeling a transmission system. The system has full instrumentation for SCADA and power system protection. This enables a wide range of experiments in power system protection. The controls for the prime movers on this systems are adjustable, allowing the system to reproduce dynamic oscillations on a power grid, and show how changes in SCADA control settings can impact the system. The system can also be used for modeling and testing custom electronic power controllers. Central to the ability to perform analysis of specific transient scenarios is the implementation of a computer controlled fault generator. With the fault generator, complex multiple and progressive faults are modeled making real time voltage and current behavior during those events available for extensive analysis. The system currently has mechanical circuit breakers controlled by commercial protective relays.
3.
Research Objectives
A typical Network Intrusion Detection System (NIDS) acts as an eavesdropping tool, listening on the network for different types of traffic or payload data. This capability would noticeably improve security in SCADA systems. In addition to network monitoring, these networks need ways to track settings changes on devices remotely. Network monitoring and settings auditing provide the basis for intrusion detection in IT networks, and the same approach is applicable in SCADA/sensor testbed [8–10]. Our objectives were threefold. First, we wanted to better secure the communication systems of critical infrastructure networks by monitoring for commands capable of causing damage to the reliable operation
6 of these networks. Second, we wanted to better monitor settings on the varied devices that make up a critical infrastructure network, by using an automated process of gathering settings and comparing them automatically to known working versions. And third, we wanted to use existing technologies to show our method is an extensible and cost-effective approach to improving intrusion detection and event monitoring in process control networks. As mentioned, process control and SCADA devices severely underreport many important details regarding system access. Thus, any effort to detect intrusions must include the observation or recording of basic network events. These events include: Login attempts to any network device, including: – the time of day – the origin and destination IP addresses of the attempt – whether an attempt succeeds or fails – a frequency count of all login attempts over a given time interval Major SCADA-specific commands, including: – commands to view or set passwords – commands to upload new firmware – commands to show or settings – attempts to upgrade user privileges Our aim was to add both monitoring and intrusion detection to the SCADA/Sensor testbed. Due to the critical nature of the work performed by these devices, it is important to record even legitimate access attempts. Research shows that many errors can be attributed to mistakes by humans; it is logical to provide these services to better prevent human error.
4.
Research Approach and Resulting Prototype
The goal was to enable automated gathering and comparison of device settings over time. This is highly useful for practical reasons; no longer must engineers rely on personal notes and reminders on what settings where changed, and when. Because the most common means within the industry of connecting to SCADA devices being Telnet, we chose to automate this process using the Perl programming language and its
Oman & Phillips
Figure 2.
7
Logical diagram of event monitoring flow and testbed components.
Expect module. Expect is a language that automates interactions with other programs. This combination has proven highly useful in automating terminal connections with the various devices in the testbed, and is extensible to more secure connection protocols like SSH and SSL. To complement the settings gathering and command logging, we added a customized uptime measurement component to the testbed. Using Ping, Telnet, Expect and a database backend, we are able graphically represent the uptimes of each device in the lab. The data is graphed over day, two-week, and month-long intervals. This has already proven effective in finding faulty devices and network paths, especially among devices that are seldom used but expected to be reliable. We test for network connectivity to all devices and calculate the mean time to repair (MTTR) for each device. Figure 2 is a logical diagram of the real-time monitoring IDS depicted in the upper center of Figure 1.
4.1
Initial Configuration
Providing the basis for both the intrusion detection and automation components of the project, the XML format was chosen to represent basic details for each device in the testbed. An XML profile, one for each device, resides on the system. Details such as IP address, Telnet port, legal commands for that device, whether to create an IDS signature or not for a specific command, and whether or not to issue a certain command during the automated settings retrieval phase are all contained
8 Table 1.
Portion of the XML profile for the RTU.
XML
