SCADASim—A Framework for Building SCADA ... - IEEE Xplore

IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011

589

SCADASim—A Framework for Building SCADA Simulations Carlos Queiroz, Abdun Mahmood, and Zahir Tari

Abstract—Supervisory Control and Data Acquisition (SCADA) systems control and monitor industrial and critical infrastructure functions, such as electricity, gas, water, waste, railway, and traffic. Recent attacks on SCADA systems highlight the need of stronger SCADA security. It is important to analyze the security risks and develop appropriate security solutions to protect such systems. However, a key problem is the lack of proper modeling tools to evaluate the security of SCADA systems. As widely accepted in academic and industrial communities, it is impractical to conduct security experiments on live systems. A modeling simulation tool would enable the simulation of SCADA systems with the benefit of testing different attack and security solutions. This paper proposes a simulation tool for building SCADA simulations that supports the integration of external devices and applications. A key benefit of this tool is the ability to test the effect of attacks on real devices and applications, even though using a simulated environment. The paper further describes two case studies that demonstrate how the tool can be efficiently used to create SCADA simulations and perform malicious attacks. Index Terms—Computer security, computer simulation, SCADA systems, smart grids.

I. INTRODUCTION

S

CADA (Supervisory Control and Data Acquisition) systems control and monitor industrial and critical infrastructure functions, such as electricity, gas, water, waste, railway, and traffic [1]–[4]. In the past, such systems for controlling the national critical infrastructures were somewhat secure as they had proprietary controls and limited connectivity. Due to the increased connectivity to Internet and corporate network and the use of commodity hardware, software, and standard protocols [2], [5], SCADA systems are no longer immune to cyber attacks. In fact, the threat posed to the critical infrastructure is far greater in terms of impact and scale of attack than common computer vulnerabilities. Examples of threats to SCADA include an attack on a sewage treatment system in Maroochy Shire, Queensland, where 800 000 liters of raw sewage were released to spill out into local parks and rivers, causing death of marine life, stench, and discoloration of water [6], the Davis-Besse nuclear power plant in Oak Harbor, Ohio, was attacked by the Slammer SQL server worm, which disabled a safety monitoring system of the nuclear power plant for nearly 5 hours [7]. More recently, Stuxnet [8], a threat specifically written to target industrial Manuscript received October 16, 2010; revised July 05, 2011; accepted July 10, 2011. Date of publication September 06, 2011; date of current version November 23, 2011. This work has been supported in part by ARC Linkage Grants LP100100404 and LP110100602. Paper no. TSG-00188-2010. The authors are with the School of Computer Science and Information Technology, RMIT University, Melbourne, Australia (e-mail: [email protected]; [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TSG.2011.2162432

control systems was discovered. The threat was designed to damage nuclear power plants in Iran, some reports suggest [9]. All of these utilities are essential in the proper functioning of our daily life; therefore, its security and protection are extremely important as well as of national concern. To better understand the protection of SCADA systems [3], it is important to analyze the security risks of such systems and develop appropriate solutions to protect them from malicious attacks. A key problem in the research and development of security solutions for SCADA systems is the lack of proper modeling tools to evaluate the security of such systems. A SCADA simulation framework would enable the creation of simple models of SCADA systems with the additional benefit of testing real attacks and trying different security solutions. Simulations are important due to the fact that it is impractical to conduct security experiments on a real system because of the scale and the cost of implementing standalone systems, as well as the potential risk and downtime of services provided by the critical infrastructure controlled by the SCADA system. There are few instances of active SCADA testbed and simulation development [10]–[14]. However, these tools are either proprietary, used by researchers within the organization, and the software is not released for external use or is not generic enough to support different architectures, protocols, and systems. Another important issue regarding the successful modeling of a SCADA system is how to control real devices, such as sensors and actuators from within the simulation environment. In this paper we introduce SCADASim, a framework for building SCADA simulations. It provides a modular SCADA modeling tool that allows real-time communication with external devices using SCADA protocols. This work builds on the basic simulator we proposed previously [15]. It adds value on top of our previous work by making SCADASim truly flexible for connecting real and simulated devices, and also offering a plug-n-play solution that supports multiple protocols and external applications for building SCADA simulations. This novel framework provides: 1) A modular, extensible, and flexible tool to model SCADA simulations. SCADASim provides a set of modules that represent SCADA components such as RTU, PLC, MTU, and protocols (such as Modbus/TCP and DNP3). Such modules and protocols can be easily extended, compounded into other modules and used in any SCADASim simulation. 2) The integration of external components into the simulation simultaneously. SCADASim introduces the concept of gates. A gate is an object that links the external environment with the simulation environment. SCADASim simulations may have multiple gates communicating with different external environments at the same time.

1949-3053/$26.00 © 2011 IEEE

590

IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011

Fig. 1. SCADA architecture [19].

3) The possibility of testing attack scenarios seamlessly. SCADASim supports four main types of attacks: denial of service, man-in-the-middle, eavesdropping, and spoofing. Users can easily create attacks to run inside the simulated environment or they can use tools such as trinno [16] to run attacks against the external components. SCADASim also provides a library with some well-known attacks such as worm attack and distributed denial of service (DDoS) attack. A key benefit of SCADASim is its high scalability while integrating both real hardware and prototype software modules. In addition to that, the integration of existing external components into simulations simplifies evaluation of these components since topologies, traffic patterns, and other parameters can be changed easily within the tool. This paper evaluates SCADASim by simulating two smart grid scenarios. The first scenario simulates a network of smart meters connected to an energy utility provider. The second one demonstrates a wind power plant. The plant is monitored by a SCADA system that controls the generation and distribution of electricity. Malicious attacks are evaluated in both scenarios. Section II introduces SCADA systems, highlights the reasons why it is not a good idea to use real systems for security testing, describes the requirements of the framework and provides a comparison between other simulation platforms. Section III introduces SCADASim, its architecture, and main components. Section IV discusses the types of attacks supported by SCADASim. Section V conducts a security experiment and evaluation of how to build a SCADA simulation with an attack scenario. Finally, Section VI concludes by briefly mentioning some limitations of the project and highlighting some ongoing work. II. SCADA SYSTEMS A typical SCADA architecture is illustrated by Fig. 1. In general field devices are connected to the SCADA network, which is connected to the corporate network. Operators control the de-

vices from PCs connected to the corporate network. Field devices consist of remote terminal units (RTU), programmable logic control (PLC), and intelligent electronic devices (IED). A number of RTUs in remote locations collect data from devices and send log data and alarms to a SCADA terminal using various communication links including traditional telephone and computer network, wireless network, and fiber-optic cables [17], [18]. Data acquisition begins at the RTU or PLC level and includes meter readings and equipment status reports that are communicated to SCADA as required. Some industrial systems use PLCs to control end devices like sensors and actuators. Data from the RTUs and PLCs is compiled and formatted in such a way that a control room operator using a human machine interface (HMI) can make supervisory decisions to adjust or override normal RTU (or PLC) controls. This data may also be collected and stored in a historian, a type of database management system, to allow auditing, and the analysis of trends and anomalies. A. Problems of Security Testing on SCADA Environments Although there is a need to evaluate the security standards of existing SCADA systems, there are several practical problems that limit the use of security testing and evaluation on such systems. • Cost of scale: It is obvious that implementing a SCADA system for testing purposes alone is cost prohibitive. Unlike other stand-alone systems, SCADA systems comprise of many distributed data gathering equipments and wide range of communication devices that are too expensive to implement due to their large scale. • Downtime: Some security vulnerabilities like denial of service (DoS) attack or distributed denial of service (DDoS) attack overwhelms the attacked services and cause them to slow down in responses or shut down completely. Such a scenario is not acceptable for live SCADA systems monitoring critical infrastructure like electricity, gas, and water. • Risk of failure: Like any security testing, there is always a risk that the intended security measure will fail to protect

QUEIROZ et al.: SCADASIM—A FRAMEWORK FOR BUILDING SCADA SIMULATIONS

TABLE I SCADA SIMULATION FUNCTIONALITIES ACROSS DIFFERENT IMPLEMENTATIONS

the system. Therefore, a live SCADA system is not the appropriate place to try untested security solutions, until they have been more rigorously tested elsewhere. B. SCADA Systems Simulator Requirements Based on discussions with some industry partners and on our own experience any simulator tool aiming SCADA systems should: 1) allow plug-n-play for creation of simulations—The tool should target system experts, not developers necessarily. It is reasonable to assume that system experts do not have much programming skills. Therefore, a tool that does not require programming skills is necessary. 2) allow connectivity to multiple external hardware and/or software—In general SCADA systems consist of hundred of devices that monitor and control end-systems. Simulation tools should provide support for handling multiple connections to multiple external devices in real-time and simultaneously. 3) support multiple industry standard protocols (e.g., DNP3 [20], Modbus/TCP [21], etc.)—Usually SCADA systems consist of different devices running different protocols, sometimes from different vendors. A flexible tool should support as many protocols and vendors as possible giving options to users creating their simulations. III. SCADASIM SCADASim aims to provide an environment to build flexible SCADA system simulations efficiently. As shown in Table I, it allows multiprotocol integration with external devices and applications. SCADASim is built on top of OMNET++ [22], a discrete event simulation engine. OMNET++ consists of modules that communicate with each other through message passing. The communication occurs either through input and output gates or through direct messages. Modules can also be combined in a hierarchy of levels making possible to build complex simulation components. It also provides a set of tools for designing network topologies (NED language and editor) and supports architecture of plug-ins extensions. Plug-ins can be used to modify the default behavior of the simulation engine. For example, a different message scheduler can be added to a simulation, which changes the default behavior of the scheduling of messages. To choose OMNET++ as simulator engine we evaluated few other engines such as NS2/NS3 [25]. OMNET++ was chosen because it is a generic simulation engine and it allows plug-nplay through its NED WYSIWYG editor and also allows integration to external applications and devices. According to [26] there are three ways of integrating an OMNET++ simulation with external applications: source code, shared libraries, and sockets.

591

• Source code—In the case of source code integration, the application source code needs to be compiled together with the simulation, so that a final simulation binary would be generated. • Shared library—In this case a dynamic or static library previously compiled for the target platform needs to be linked to the simulation code. • Sockets—Using sockets we can create an object that acts as a server proxy to the external world within OMNET++. The proxy needs to maintain a listening socket waiting for external connections and is responsible to delivering messages from the simulation components to the external world and vice versa. From these three options a socket based integration is the only solution capable of integrating both external devices and applications. The socket integration is seamless without requiring changes to the external components. It does not require shared library files or source code that are either not practical or available for commercial and legacy SCADA systems. However, it suffers from one major drawback, only socket-based protocols are supported. This also means that we cannot have gates communicating to devices through serial connections. Because of these issues we introduced a new integration option. In our approach gates allow the integration with different type of protocols (such as socket-based, serial, or many others). This flexibility enables users to create simulations using socket-based protocols such as Modbus/TCP, serial ones such as Modbus Serial and so forth. More details about Gates are given in Section III-A2. A. SCADASim Architecture The SCADASim architecture is based on three main components: SSScheduler, a real-time scheduler; SSGate, a communication port that implements protocols for communication to the external environment; SSProxy, a simulation object that represents an external component within the simulation environment. Fig. 2 illustrates the various components of the SCADASim architecture. Gates are the only components able to communicate with the external environment. Proxies communicate with the external environment through Gates. SCADASim allows multiple gate instances each representing communication paths to the external environment. For instance, one may have two gates one listening to socket connections and then other listening to serial connections. The gates are managed by the SSScheduler. Next, we describe the operation of each of these components in more detail. 1) SSScheduler: OMNET++ offers a plug-in scheduler architecture. Users can add new schedulers to OMNET++. New scheduler implementations can be added by implementing the cScheduler abstract class. The SSScheduler extends cScheduler and adds new functionalities to control and synchronise messages received from the external environment. The class diagram described in Fig. 3 shows the relationship between the SSScheduler and the other components in the SCADASim architecture. The SSScheduler manages a list of SSGate instances that are responsible for sending and receiving messages to and from the external environment. Every time the simulation engine will process an event the scheduler loops through all active gates getting their messages and adding them to the simulation

592

IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011

Fig. 4. Sequence diagram—Gateway startup.

Fig. 5. Proxy binding table. Fig. 2. SCADASim component architecture.

Fig. 3. SCADASim class diagram.

queue to be processed and consequently delivered to their destination. The synchronization process guarantees that the messages between the two environments will be synchronized. 2) SSGate: The SSGate provides the connection to the external environment by implementing a protocol, which is used to communicate with external SCADA components. At the moment, SCADASim provides three gate implementations: ModbusGate, DNP3Gate, and HTTPGate. However, programmers can add implementation of other protocols by extending the SSGate abstract class (see Fig. 3). Gates run as system threads so that the framework can handle multiple instances simultaneously. Consequently, satisfying one of the framework requirements. A SSGate instance maintains a list of registered proxies. When a proxy is initialised, it registers itself with the gate by calling the proxyBinding method on the gate class (see Fig. 4). The gate then adds the proxy to an internal table as illustrated in Fig. 5), so that the gate keeps track of the external addresses and objects associated with the proxy during the simulation. Row 1 in Fig. 5 shows that a smart meter proxy is representing an external component that has IP address 192.168.1.1.

For a gate instance to be used by the simulation it needs to be registered with the simulation engine. The attribute extgates must be added to the simulation configuration file (omnetpp. ini) where all registered gates are separated by commas. The SSScheduler reads this attribute when it initializes. 3) SSProxy: The SSProxy represents a real device or external application in the simulated environment. They interact with simulated objects such as simulated MTUs and with a SSGate, which is responsible for routing their messages to external components. There is a relation of one to one between a real component (hardware device or application) and a proxy object. Proxies are linked to external objects through their “names.” Every proxy must have a name that identifies which external object it is representing. For instance, a proxy with name 192. 168.1.1 represents an external object with this IP address. It is the responsibility of the simulation creator to configure the proxies names in the omnetpp.ini configuration file. The gate matches the source IP of an external request to the proxy name of an object in its internal proxy table. This is how the gate knows how to route their messages to the right proxies. It is easy to create proxies and simulated objects within SCADASim/OMNET++. Objects are created by a composition of modules. Fig. 7 illustrates a smart meter simulation object built through module composition. The device has PPP and Ethernet interfaces, supports IP, TCP, and Modbus/TCP. The entire smart meter component is built without writing any code thanks to the OMNET++ NED editor. SCADASim provides built-in modules such as RTU, PLC, MTU, and modules that represent types of attacks, for instance a DDoS module. B. Protocols SCADASim handles protocols in two distinct ways: the ones used within SCADASim/OMNET++ environment to communicate to other simulation components in the same environment, here called simulated protocols, and the ones used by external devices and applications to communicate to SSGates, called original protocols. Fig. 6 illustrates an example of a typical SCADASim simulation. External devices communicate to SSGates using the original version of SCADA protocols, for instance, an external PLC could use Modbus/TCP to communicate to a SSGate that implements Modbus/TCP (ModbusGate).

QUEIROZ et al.: SCADASIM—A FRAMEWORK FOR BUILDING SCADA SIMULATIONS

593

and registered as the simulation scheduler. During its initialization the scheduler instantiates all SSGate implementations registered to it. Then, the simulation engine initializes all proxies and simulation components. During the initialization proxies register themselves to the SSGate they would like to bind to. D. SSProxy Communication Fig. 6. Simulation architecture example.

Fig. 7. Simulated smart meter.

In the simulated environment all communication among the components use the simulated versions of the SCADA protocols. These changes are necessary because the simulation does not provide the environment where the original protocol was designed to run. For instance, the Modbus/TCP simulated protocol uses sockets, however the socket stack cannot be used to send messages among the components of the simulation, as OMNET++ uses a different technique. Thus the adapted version of Modbus/TCP needed to have its socket stack replaced by INET [27], a OMNET++ library that simulates the TCP/IP protocol. SCADASim provides a library of SCADA protocols (simulated and original) to be used in simulations. In the current version we have ported Modbus/TCP (adapted from [28]), DNP3/TCP (adapted from [29]) and HTTP protocols to SCADASim. Fig. 7 shows how a protocol can be used as part of a simulation component. For example, the Modbus/TCP protocol module is connected to the TCP module provided by the INET [27] library, making the smart meter capable of communicating with other components using the Modbus/TCP protocol. All protocols available in the protocol library can be used by any SCADA simulation without the need of writing any code. It is possible to use proprietary protocol implementations (with no changes) to exchange messages between external devices and applications to SCADASim gates; however, as mentioned earlier, communication protocols need to be adapted to run within SCADASim simulations. Proprietary protocols are no different; they would need to be adapted in order to be used in SCADASim simulations. C. SCADASim Startup Process Fig. 4 illustrates the startup process of SCADASim. The SSScheduler class is initialised by the OMNET++ simulation engine

The proxy bootstrap process is initiated when a proxy starts communicating with an external component for the first time. There are two ways for a proxy to start communication with external components: it sends a request or it receives a request. These two processes are handled quite differently by the SSGate, as described below. 1) Proxy Receives a Request: When the SSGate receives a request from an external component to route a message to a proxy it needs to know to whom the message is addressed to. It is important to remember that external components may only have the IP address and port (in case of sockets) of the SSGate. The SSGate looks up its Proxy Binding Table and finds out which proxy name matches to the IP address of the message sender. If a match is found the SSGate creates a message using the simulated protocol of the original version and sends the message to the proxy. Protocols that do not rely on IP addresses have to use another technique to match proxy names. 2) SSProxy Sends or Responds a Request: The SSProxy creates a message using the simulated protocol and delivery it to its SSGate, the gate creates a request using the original protocol and sends the message to the final destination. IV. SIMULATING MALICIOUS ATTACKS In addition to being a framework to create SCADA system simulations, SCADASim also supports the creation of malicious attacks targeting SCADA systems. In [30], authors categorized attacks (threats) into four main types as illustrated in Fig. 8. Denial of services are attacks where the attacker (Bob) denies source (Alice) access to the destination (Mary). Man-in-the-middle are attacks where Bob impersonates Mary, consequently, receiving all requests from Alice to Mary. Bob then changes the requests and relays them on to Mary. Spoofing are attacks where Bob masquerades as Alice, so that it can create and send requests to Mary. Eavesdropping are attacks where Bob receives all requests sent to Mary by Alice, even though Mary and Alice have no knowledge of that. SCADASim supports all four types of attacks. However, SCADASim does not provide implementations of all types of attacks to all SCADA protocols. There are more than 150 protocols used by SCADA systems [17]. We have decided to initially support the most used protocols such as Modbus/TCP [21] and DNP3 [31]. According to [32] DNP3 is predominant in the U.S. energy sector with over 75% of electric utilities using it in their SCADA applications. As mentioned earlier SCADASim users can add their own protocol implementations. As SCADASim supports the integration of external applications and devices into simulations, there are three possible attack scenarios supported by SCADASim: 1) Attacks launched from within SCADASim targeting SCADASim internal components—it is the most common one, where you have all components within SCADASim, even though they may represent external components. An

594

IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011

Fig. 8. Attack categories.

user can launch attacks and monitor their behavior easily from the controlled environment. 2) Attacks launched from the external environment targeting an internal SCADASim components—the only reason to launch this type of attack is when the user has no access to the source code of the attack making it impossible to adapt the code to run within SCADASim. 3) Attacks launched from the external environment targeting an external component. There are so many sorts of attacks targeting SCADA systems with some researchers listing more than 50 different type of attacks targeting DNP3 [32] and Modbus [33]. These are attacks against protocols specification, technically supported by SCADASim, even though we have not implemented all of them. V. SCADASIM EVALUATION In order to evaluate SCADASim we demonstrate two common attack scenarios that show how malicious attacks can be implemented in SCADASim. The first scenario is a denial of service attack. Attackers launch flood attacks against a smart meter network. The second one is a spoofing attack. An intruder connects to the local field network to send fake messages to the PLCs as they were coming from a real MTU. A. Denial of Service Attack Scenario In this scenario a “smart” house is connected to the grid distribution company. The home updates its energy consume frequently to the company servers. With this information the utility provider can predict consumption scenarios and consequently provide more efficiently, and in same cases cheaper, electricity to their clients. Fig. 9 illustrates the scenario. The SCADA system controls and monitors smarter meters installed at homes. For the sake of simplicity the presented scenario shows only one home connected to the grid. The scenario consists of a smart meter monitoring power consumption in a “smart” home. The house is equipped with a smart meter that informs home spending to the utility company automatically.

Fig. 9. SCADA system network of a smart meter deployment.

Fig. 10. Smart meter network topology.

To simulate the smart meter we have implemented an application that simulates the electricity consumption and sends it to the SCADASim simulation. 1) Simulation Environment: The network topology used in the simulation is based on a real SCADA network. The same components are utilized; RTUs (Smart meter), MTU, HMI Server, and HMI client. The network topology consists of local area networks (LAN) connected with each other through the Internet. Different network topologies arise simply from the differences in the number of “smart” houses being used. Fig. 10 shows a generic SCADA topology used in our simulation. The upper left part of the figure shows the “smart” house with its RTU (smart meter) and its router connected to the ISP router. The right part of the figure shows the corporate network consisting of a MTU, an HMI server, and an HMI client. The smart grid network and the corporate network are connected to each other via routers over the Internet. In this environment all messages exchange between the MTU and the smart meter proxy are implemented by Modbus/TCP protocol [21], a widely used SCADA protocol. The Modbus/TCP version used in the simulation is a port from the LibModbus library [28]. The adapted version is part of the SCADASim library of simulated protocols.

QUEIROZ et al.: SCADASIM—A FRAMEWORK FOR BUILDING SCADA SIMULATIONS

The external application communicates to the SCADASim simulation through Modbus/TCP, therefore, the ModbusGate translates the request to the simulated Modbus/TCP before to delivery it to the proxy. 2) Components: The simulation consists of six main components; Smart Meter, Smart Meter Proxy, SSScheduler, MTU/ HMI, HMI Client Proxy, and HMI Client. Smart Meter: The Smart meter is represented by the external application. It measures the power consumption of a fictitious home. However, for the sake of simplicity, the house only has a water heater being monitored. HMI Client: In real SCADA systems, the HMI client is used by operators to monitor and control the system. We have developed a real but simple HMI web application that runs as part of the HTTPGate. The operations executed on the web application are real control actions performed by human operators. In order to communicate to the simulator the HMI client (represented by a Web browser) sends HTTP requests to the HTTPGate, which then translates them into simulated HTTP messages and passes them on to the HMI Client proxy that then passes it on to the HMI Server. Smart Meter Proxy: The Smart Meter Proxy represents the smart meter (implemented by the external application) inside the SCADA simulation. It contains all the information provided by the smart meter, in this case the energy consumption. It reads its information by receiving Modbus/TCP requests from the external application (smart meter). HMI Client Proxy: The HMI Client Proxy represents the HMI Client application inside the simulation. Every request coming from the HMI Client goes through the HTTPGate, and then it is passed on to the HMI Client Proxy, which then sends it to the HMI Server. Following the reverse route, the responses are routed from the HMI Client Proxy to the HTTPGate then to the real HMI Client. SSSCheduler: The SSScheduler module is responsible for synchronising the clocks between both environments (SCADASim and external) and to control the active gates (SSGate) running in the simulation. MTU/HMI Server: The MTU is responsible for controlling and monitoring the SCADA system. It performs the same activities performed by the real MTU device. It communicates with the RTUs to gather information about the system and to request actions to be performed in the system. The HMI Server is responsible for providing reports on the SCADA system for human operators. The HMI server receives requests from and provides responses to the HMI client. In this simulation the RTU is represented by a smart meter. 3) Results: In this scenario a TCP SYN flooding attack is performed. The intent is to disrupt the normal operation of the smart metering network. For instance, operators would get delayed information about power consumption of the monitored houses. Based on such delayed information the operator is likely to take wrong actions that could adversely affect the operation of the SCADA system. To perform the attack we have used a modified version of the Tribe Flood Network (TFN) tool [16]. Fig. 11 shows the effect of the DDoS attack on the smart meter. The attack occurs within in the SCADASim environment. It starts at time = 700 s in the simulation timeline by ten attackers, each sending 1000 TCP SYN packets to the smart

595

Fig. 11. Smart meter under attack.

Fig. 12. MTU perceived service time.

meter. The time between 0 and 700 seconds displays the normal behavior of the smart meter. As we can see in Fig. 11 during this time the smart meter receives a constant number of requests and process them normally. At Time = 700 (dashed ellipse) the smart meter starts to receive an enormous amount of packets requesting new TCP connections. From this time on the smart meter starts to show an unusual behavior. There is a huge drop on the number of processed requests, even though the processing time does not change. Such behavior indicates that many legitimate requests are not being processed at all, they are just being dropped by the smart meter. Looking at the behavior of the MTU, Fig. 12 shows that when the attack starts the service perceived time spikes up dramatically. Clearly, it demonstrates that the attack is affecting the smart meter responses to the MTU. B. Spoofing Attack Scenario In this scenario we show how a wind power plant simulation can be integrated to SCADASim. We also shows how a spoofing attack can compromise the wind power plant by injecting fake requests to the PLCs that control the power plant. The wind power plant is represented by a MATLAB/Simulink model (adapted from MATLAB/Simulink SimPowerSystems demos—see Fig. 13). The model consists of a wind farm of six 1.5 (MW) wind turbines connected to a 25 (kV) distribution system that exports power to a 120 (kV) grid through a 25 (kV) feeder. The turbines are simulated in pairs, therefore, in total the model has 3 pairs of turbines that together generates 9 (MW) of electricity. Each wind turbine pair has a protection system that monitors the voltage, current, and speed. The reactive power is absorbed by induction generators and the rest of the reactive power required is provided by a 3 (Mvar) STATCOM. 1) Simulation Environment: Fig. 14 shows the SCADA network topology used in the simulation. The network consists of a field network connected with the utility provider corporate network through the Internet. The down left side of the figure shows part the smart grid generation and distribution simulation, more specifically, it shows the wind turbine pair number

596

IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011

Fig. 15. Spoofing attack scenario.

pairs as can be seen in Fig. 15, the malicious attack breaks down the entire wind power plant as the turbines stop generating any power, even though only one pair of turbines were attacked. VI. CONCLUSION Fig. 13. Wind farm power plant.

Fig. 14. SCADA network topology.

two, which will be attacked by a spoofing attack. The wind turbine has various PLCs monitoring its functioning; however, we chose to only show the PLC that will be targeted by the attack. The PLC is simulated by a MATLAB/Simulink s-function, a mechanism offered by MATLAB/Simulink where external code can be executed from the MATLAB/Simulink environment. In this case the function sends requests to the SCADASim PLC proxy informing the status of its monitored component, a threephase fault block, and updates its status based on the response. The status value is passed along to the fault block. The communication between SCADASim and the PLC is made by the Modbus/TCP protocol (LibModbus library [28]). The attack involves connecting a computer to the communication link. So that, the attacker can read, modify, and fabricate Modbus/TCP messages and/or network traffic easily. In this case the attacker will send a message to the field PLC, which monitors and controls the three-fault block, to generate a fault in the circuit. The fault will make the wind turbine pair number two unavailable, and as consequence the other turbine pairs (number one and three) will also become unavailable. Therefore making the entire energy generation and distribution to halt. Before the fault the turbine pairs are generating around 3 MW of power ). At simulation time of 26 s the attacker sends each (time a message to the PLC that makes the fault block to provoke a fault into the circuit. The fault cascades to the other turbines

The proposed framework is a novel solution to create realistic simulations of SCADA systems based on a combination of network simulation and real devices connectivity. It solves a number of logical and implementation problems in the widely used OMNET++ simulation environment to allow real world devices (such as smart meters, RTUs, etc.) to be attached to the simulator. The simulation framework, SCADASim, also allows us to study the effects of malicious attacks on the devices and on the simulated network. Our proposed framework provides realistic evaluations of SCADA systems by adding real devices into the simulation. Two practical case studies on smart grid simulation were conducted with DDoS and spoofing attacks being presented. Results demonstrate that SCADASim closely simulates the realistic behavior of actual SCADA devices. In the future, we intend to incorporate various other SCADA protocols, for example, Zigbee [34], which is popular with many industry applications ranging from home automation to power generation. In addition, we would like to use the SCADASim tool for more complex protocol attacks on SCADA protocols and SCADA devices, and offer solutions that can be incorporated into firewall rules and intrusion detection systems. SCADASim is a work in progress project. We have been adding examples, fixing bugs, porting new protocols, and implementing new functionalities to SCADASim constantly. SCADASim is an open source project hosted at https://github.com/caxqueiroz/scadasim. REFERENCES [1] T. G. Lewis, Critical Infrastructure Protection in Homeland Security: Defending a Networked Nation. Hoboken, NJ: Wiley, 2006. [2] R. Krutz, Securing SCADA systems. Indianapolis, IN: Wiley, 2006. [3] M. Brundle and M. Naedele, “Security for process control systems: An overview,” IEEE Security Privacy, vol. 6, no. 6, pp. 24–29, Nov. 2008. [4] M. Masera, I. Fovino, and R. Leszczyna, “Security assessment of a turbo-gas power plant,” in Critical Infrastructure Protection II, ser. IFIP Advances in Information and Commmunication Technology. New York: Springer, Jan. 2008, vol. 290, pp. 31–40. [5] K. Munro, “SCADA—a critical situation,” Network Security, vol. 2008, no. 1, pp. 4–6, Jan. 2008. [6] J. Slay and M. Miller, “Lessons learned from the maroochy water breach,” in Critical Infrastructure Protection, ser. IFIP International Federation for Information Processing, E. Goetz and S. Shenoi, Eds. New York: Springer, 2007, vol. 253, pp. 73–82. [7] K. Poulsen, “Slammer worm crashed Ohio nuke plant network,” 2009 [Online]. Available: http://www.securityfocus.com/news/6767 [8] N. Falliere, L. O. Murchu, and E. Chien, W32.Stuxnet Dossier, Symantec Tech. Rep. 1.4, 2011. [9] “Internet-based attacks on critical systems rise,” May 2011 [Online]. Available: http://www.bbc.co.uk/news/technology-13122339

QUEIROZ et al.: SCADASIM—A FRAMEWORK FOR BUILDING SCADA SIMULATIONS

[10] I. N. Fovino, A. Carcano, M. Masera, and A. Trombetta, “An experimental investigation of malware attacks on SCADA systems,” Int. J. Crit. Infrastruct. Protection, vol. 2, no. 4, pp. 139–145, 2009. [11] R. Cheung, M. Demokan, and K. Chow, “Modeling and simulation using network software to evaluate scada system configuration,” in Proc. 4th Int. Conf. Adv. Power Syst. Control, Oper., Manage. (APSCOM), Nov. 1997, vol. 2, pp. 609–613. [12] H. Christiansson and E. Luiijf, “Creating a European SCADA security testbed,” in Critical Infrastructure Protection, ser. IFIP International Federation for Information Processing, E. Goetz and S. Shenoi, Eds. New York: Springer, 2007, vol. 253, pp. 237–247. [13] C. Davis, J. Tate, H. Okhravi, C. Grier, T. Overbye, and D. Nicol, “SCADA cyber security testbed development,” in Proc. 38th North Amer. Power Symp. (NAPS 2006), Sep. 2006, pp. 483–488. [14] National SCADA Test Bed Sep. 2010 [Online]. Available: http://www. sandia.gov/ccss/National_Testbed.htm [15] C. Queiroz, A. Mahmood, J. Hu, Z. Tari, and X. Yu, “Building a scada security testbed,” in Proc. 3rd Int. Conf. Network System Security, Oct. 2009, pp. 357–364. [16] D. Dittrich, “The dos project’s ‘Trinoo’ distributed denial of service attack tool,” Univ. Washington. Seattle, 1999 [Online]. Available: http://www.cs.unc.edu/jeffay/courses/nidsS05/attacks/trinoo.pdf [17] V. Igure, S. Laughter, and R. Williams, “Security issues in scada networks,” Comput. Security, vol. 25, no. 7, pp. 498–506, 2006. [18] A. Bessani, P. Sousa, M. Correia, N. Neves, and P. Verissimo, “The crutial way of critical infrastructure protection,” IEEE Security Privacy, vol. 6, no. 6, pp. 44–51, 2008. [19] “Pacific northwest national laboratory and U.S. department of energy, The role of authenticated communications for electric power distribution,” in Proc. Natl. Workshop—Beyond SCADA: Networked Embedded Control for Cyber Physical Systems, Nov. 2006, p. 1. [20] G. Clarke and D. Reynders, Practical Modern SCADA ProtocolsDNP3, 60870.5 and Related Systems. Burlington, MA: Elsevier, 2006. [21] A. Swales, Schneider Electric, “Open MODBUS/TCP specification,” ver. Release 1.0, 1999. [22] A. Varga and R. Hornig, “An overview of the omnet++ simulation environment,” in Proc. 1st Int. Conf. Simul. Tools Tech. Commun., Netw., Syst. & Workshops, Mar. 2008, p. 10. [23] A. Hahn, B. Kregel, M. Govindarasu, J. Fitzpatrick, R. Adnan, S. Sridhar, and M. Higdon, “Development of the powercyber SCADA security testbed,” in Proc. 6th Annu. Workshop Cyber Security Inf. Intell. Res., 2010, pp. 1–4. [24] D. Bergman, D. Jin, D. Nicol, and T. Yardley, “The virtual power system testbed and inter-testbed integration,” in Proc. 2nd Workshop Cyber Security Experimentation Test, Aug. 2009, p. 5. [25] NS3 Simulator May 2011 [Online]. Available: http://www.nsnam.org/ [26] C. P. Mayer and T. Gamer, “Integrating real world applications into OMNeT++,” Institute of Telematics, Universität Karlsruhe (TH), Tech. Rep. TM-2008-2, 2008 [Online]. Available: http://doc.tm.uka.de/2008/TM-2008-2.pdf [27] INET Framework Sep. 2010 [Online]. Available: http://inet.omnetpp.org [28] LIBMODBUS Library Aug. 2010 [Online]. Available: http://www.libmodbus.org/ [29] DNP3 Library May 2011 [Online]. Available: http://code.google. com/p/dnp3/ [30] “Secure enterprise computing with the Solaris 8 operating environment,” Sun Microsystems, 2000 [Online]. Available: http://www.sun. com/software/whitepapers/wp-s8security/wp-s8security.pdf [31] DNP3 Specification May 2011 [Online]. Available: http://www.dnp. org/Modules/Library/ [32] S. East, J. Butts, M. Papa, and S. Shenoi, “A taxonomy of attacks on the dnp3 protocol,” in Critical Infrastructure Protection III, ser. IFIP Advances in Information and Communication Technology, C. Palmer and S. Shenoi, Eds. New York: Springer, 2009, vol. 311, pp. 67–81.

597

[33] P. Huitsing, R. Chandia, M. Papa, and S. Shenoi, “Attack taxonomies for the modbus protocols,” Int. J. Crit. Infrastruct. Protection, vol. 1, pp. 37–44, 2008. [34] ZigBee Standard Jun. 2011 [Online]. Available: http://zigbee.org/Standards/ZigBeeSmartEnergy/Overview.aspx

Carlos Queiroz received the undergraduate degree in computer science and the M.S. degree in computer networks from Federal University of Rio Grande do Norte, Brazil, in 1998 and 2001, respectively, and the M.Eng. degree in distributed computing at University of Melbourne, Australia, in 2006. He is currently working toward the Ph.D. degree at RMIT University, Melbourne. His research interests include computer security, industrial SCADA systems security and parallel and distributed systems. He has published papers on parallel and distributed systems and SCADA security. Abdun Mahmood received the B.Sc. degree in applied physics and electronics and the M.Sc. degree in computer science from the University of Dhaka, Bangladesh, in 1997 and 1999, respectively, and the Ph.D. degree from the University of Melbourne, Australia, in 2008. He joined the University of Dhaka as a lecturer in 2000, and Assistant Professor in 2003. Currently, he is a Postdoctoral Research Fellow at the Royal Melbourne Institute of Technology with the School of Computer Science and Information Technology. His research interests include data mining techniques for network traffic analysis, anomaly detection, and industrial SCADA security. He has published his work in IEEE Transactions and A-tier international journals and conferences. Zahir Tari received the undergraduate degree in mathematics from USTHB, Algeria, in 1984, and the M.S. degree in operational research and the Ph.D. degree in computer science from the University of Grenoble, France, in 1985 and 1989, respectively. Later he joined the Database Laboratory at Swiss Federal Institute of Technology (EPFL, 1990–1992), then moved to Queensland University of Technology (QUT, 1993–1995) and Royal Melbourne Institute of Technology (RMIT, since 1996). He is currently a Professor (in Distributed Systems) at RMIT University. He is the head of Distributed Systems and Networking (DSN) at the School of Computer Science and IT, where he pursues high impact research and development in computer science. He leads a few research groups that focus on some of the core areas, including networking (QoS routing, TCP/IP congestion), distributed systems (performance, security, mobility, reliability), distributed applications (SCADA, Web/Internet applications, mobile applications). His recent research interests are in performance (in Cloud) and security (in SCADA systems). He regularly publishes in prestigious journals (like IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, IEEE TRANSACTIONS ON WEB SERVICES, ACM Transactions on Databases) and conferences (ICDCS, WWW, ICSOC, etc.). He has coauthored 2 books (published by Wiley) and edited more than 10 books. He has been Program Committee chair of several international conferences, including the Distributed Object and Application Symposium (DOA), IFIP DS 11.3 on Database Security, and IFIP 2.6 on Data Semantics. He has also been General Chair of more than 12 conferences. He is the recipient of 14 Australian Research Council (ARC) grants.