Building a SCADA Security Testbed

2009 Third International Conference on Network and System Security Building a SCADA Security Testbed Carlos Queiroz, Abdun Mahmood, Jiankun Hu, Zahir Tari, Xinghuo Yu RMIT University {cqueiroz, abdun.mahmood, jiankun.hu, zahirt, x.yu}@cs.rmit.edu. Abstract—SCADA (Supervisory Control and Data Acquisition) systems control and monitor industrial and critical infrastructure functions, such as the electricity, gas, water, waste, railway and traffic. Recent attacks on SCADA systems highlight the need of a SCADA security testbed, which can be used to model real SCADA systems and study the effects of attacks on them. We propose the architecture of a modular SCADA testbed and describe our tool which mimics a SCADA network, monitors and controls real sensors and actuators using Modbus/TCP protocol. Using Distributed Denial of Service (DDoS) scenarios we show how attackers can disrupt the operation of a SCADA system. evaluate the security of the SCADA system. A SCADA testbed allows us to create a simple model of a SCADA system with the additional benefit of testing real attacks on the system and trying different security solutions. A testbed is important due to the fact that it is impractical to conduct security experiments on a real SCADA system because of the scale and cost of implementing standalone SCADA 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 development in the United States [7-10] and the European community has also recently started working on creating a SCADA security testbed [11, 12]. However, these testbeds are proprietary, used by researchers within the organization, and the software is not released for external use. Another important issue regarding the successful modelling of a SCADA system is how to control real devices, such as sensors and actuators from within the testbed environment. In this paper, we propose an open source, modular SCADA modelling testbed that allows real time communication with external devices using SCADA protocols. A key benefit of such a tool is its ability to test the effects of attacks on a real control process (NXT devices) through a simulated network environment (OMNET++) using realistic SCADA protocols (Modbus/TCP). In Section II, we describe the SCADA system architecture. In Section III, we highlight the reasons why we cannot use a real SCADA system for security testing. In Section IV, we describe the main components of our SCADA simulation using a case study of a water treatment plant SCADA system. In Section V, we present the SCADA simulation architecture. In Section VI, we conduct a security experiment on the simulated SCADA system using an attack scenario using Distributed Denial of Service (DDoS) attack. In Section VII, we show the results of the experiment. Finally in Section VIII, we conclude by briefly mentioning our future plans on this project. Keywords-SCADA, Security, Testbed, DDoS I. INTRODUCTION SCADA (Supervisory Control and Data Acquisition) systems control and monitor industrial and critical infrastructure functions, such as electricity, gas, water, waste, railway and traffic. 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, 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 litres of raw sewage were released to spill out into local parks and rivers, causing death of marine life, stench and discoloration of water [1, 2]. Recently, the Davis-Besse nuclear power plant in Oak Harbor, Ohio, USA, was attacked by the Slammer SQL server worm, which disabled a safety monitoring system of the Nuclear Power plant for nearly five hours [3]. 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. In this paper, we propose a SCADA simulation architecture and security tool that can be used to identify attacks on a SCADA system. In order to better understand how to protect SCADA systems [4-6], it is important to analyse the security risk of these systems and develop appropriate security solutions to protect them from attacks. A key problem in the research and development of security solutions for the SCADA system is the lack of proper modelling tools to 978-0-7695-3838-9/09 $26.00 © 2009 IEEE DOI 10.1109/NSS.2009.82 II. SCADA SYSTEM ARCHITECTURE Figure 1 illustrates how a modern SCADA system is connected [13, 14]. The field devices consist of Remote Terminal Units (RTU), Programmable Logic Devices (PLC), and Intelligent Electronic Devices (IED). A number of RTUs in remote locations collect data from 352 357 d. Unintended loop holes: A risk associated with a quick security fix on a SCADA system is that it may leave unintended loop holes in the configuration software, which would allow further intrusions based on change of policy, user rights, and uninstalled software used during the security testing. Finding and patching such loopholes is difficult and cumbersome in a real SCADA environment. e. Isolation from the wider Internet: The simulation testbed is a self-contained simulated networking environment; therefore, it protects the public Internet from the side effects of the security experiments conducted on the testbed. The testbed provides containment of malicious code as well as control over the effects of generated attack and background traffic. devices and send log data and alarms to a SCADA terminal using various communication links including Figure 1 An illustration of a SCADA system showing how the SCADA servers are connected to both the field and the corporate LAN. IV. traditional telephone and computer network, wireless network, and fibre-optic cables. 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. III. SIMULATION ENVIRONMENT The network topology used in our simulation is based on a real SCADA network. We use the same components used by real SCADA systems; RTUs, sensors, actuators, 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 RTUs being used and the number of malicious hosts attacking the network, which we describe later. Figure 2 shows a generic SCADA topology used in our simulation. The left part of the figure shows the field or process network consisting of RTUs, sensors and actuators. The right part of the figure shows the corporate network consisting of the MTU, the HMI server and the client. The process network and the corporate network are connected to each other with routers over the Internet. In the field network, the sensor sends information about the water level in the tank, and the actuator is a pump motor that is turned ON or OFF. PROBLEMS OF SECURITY TESTING ON A SCADA SYSTEM Although there is a need to evaluate the security standards of an existing SCADA system, there are several practical problems that limit the use of security testing and evaluation on those systems. a. 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 its large scale. b. Downtime: Some security vulnerabilities like Denial of Service (DoS) attack or Distributed Denial of Service (DDoS) attack overwhelms the attacked services and cause them 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. c. Risk of failure: Like any security testing, there is always a risk that the intended security measure will fail to protect 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. Figure 2 V. SCADA simulation network topology. COMPONENTS OF THE SCADA SIMULATION The sensors and actuators are realized using the distance meter sensor (Sd) and servo motor (Am) of the NXT [15] device. The gateway (gw) component (described in Section F) makes the real sensors and 358 353 actuators accessible to the simulation environment. The HMI client is implemented as an external application connecting to the simulator through the gateway. All the internal objects in the simulation, such as the RTU, MTU, sensor, actuator and the HMI client are implemented as OMNET++ [16] modules (explained below) in the SCADA simulation. The external real objects such as sensors, actuators and the HMI client are represented in the simulation through their respective proxies. Each component has got its own proxy that mimics the state of the external devices inside the simulation environment. In this section we explain the software and hardware used in the simulation: OMNET++ [16] , a discrete event simulation tool, Lego Mindstorms NXT [15], a microcontroller programmable unit and Modbus TCP/IP [17], a standard protocol widely adopted by critical infrastructure applications. For the scenarios described on this simulation we only have made use of the following sensor and actuator: • Distance meter using ultrasound (Sd) - It measures distance in centimetres and inches. It is able to measure distances up to 255 centimetres with a precision of +/-3 cm. • Motor Actuator (Am) - The actuators used on the simulation are servomotors. The motors have a built-in rotation sensor that allows precise control of the motors movement. The rotation movement is measured in degrees from 0 to 360. An off-the-shelf NXT device does not have socket capabilities between the device and the simulator. In order to facilitate socket communication, we replaced the NXT’s firmware by LeJOS [20] firmware, which provides a Java based API for developing applications that run within the device. We have used this API to capture the status changes of the sensor Sd and to turn the actuator motor (Am) ON and OFF. The Java program opens a connection to the simulator to send sensor status changes and to receive requests for turning the motor ON or OFF. A. Simulation Platform The simulation platform is based on OMNET++ [16], which is an object-oriented discrete event simulation framework written in C++. It is based on the concepts of modules that communicate with each other using message passing. The communication between modules occurs either through input and output gates or through direct messages. Modules can be combined in a hierarchy of levels. OMNET++ provides a set of tools for the design and implementation of discrete event simulations. Specifically, for the SCADA testbed we have used the topology visual editor, the OMNET++ Integrated Development Environment (IDE) and of the INET framework [18]. INET is a framework that implements the commonly used Internet protocols, such as the TCP, UDP, IP, and the MAC protocols. However, there is a lack of SCADA specific protocols that are required for our simulation. C. Modbus Protocol The Modbus protocol [21] was developed in the late 1970s by Modicon. Originally, it was intended to work only on Modicon programmable controllers. However, it has now become an industry standard for transferring discrete, analogue I/O information and register data between industrial control and monitoring devices. Modbus devices communicate using a master-slave (Client-Server) approach. In the Modbus transaction nomenclature the slave is designated as the server and the master as the client. In this system, only the master (Client) can initiate the communication. The slaves (Servers) respond by supplying requested data to the client (master) or by executing the requested actions. There are two main variants of the Modbus protocol: Modbus/RTU (master/slave communication over serial links) and Modbus/TCP. The RTU variant is specified for running over serial lines (physical layer). The TCP variant is the similar to the serial Modbus with a TCP interface that runs over Ethernet. This is also known as Modbus TCP/IP. For our simulation we have used the Modbus TCP/IP protocol. The Modbus TCP/IP message structure includes a header containing the Modbus Application Protocol (MBAP) and a Protocol Data Unit (PDU). Figure 3 illustrates the message structure of the Modbus protocol. The Modbus header (MBAP) has four fields over seven bytes. The Transaction ID field helps identify the response of a given request. A unique Transaction ID is created on the request message from a Client, which the Server includes in its response. The Protocol Identifier indicates the application protocol encapsulated by MBAP (0 for Modbus). The Length Field defines the total size of the remaining fields (unit ID + PDU). The Unit ID B. Simulation Hardware Device For the simulation hardware device, such as sensors and actuators we use the Lego Mindstorms NXT [15], which is a micro-controller device containing a CPU for executing programmable code. The device supports up to seven devices (four sensors and three actuators) connected to it using ports. Its CPU is based on a 32-bit ARM7 with 256 Kbytes of flash memory and 64 Kbytes of RAM. It also has Bluetooth [19] wireless communication (Bluetooth Class II V2.0 compliant) and USB 2.0 connection with 12 MBits/s speed. In our simulation it mimics the functionality of a SCADA process control Programmable Logic Controller (PLC) unit. We have used it for acquiring sensor data and simple actuator actions, such as turning the servomotors ON and OFF. We do not use the NXTs for any data or logic processing, since these processing takes place in the RTUs and MTUs of the SCADA system. 359 354 identifies the slave device associated with the transaction. The Modbus PDU has two fields, one byte field for function code and the other one for the message payload. The payload has a variable size with a limit of 252 bytes. The function code in a request message specifies the operation requested by the master (MTU). The corresponding field on the response message is used to carry status information back to the master. The payload contains data pertaining to the function code, request or response results messages. Response messages have the same structure as the request messages. The master device (MTU) connects to slave devices (RTU) through socket connections. The slave device listens for incoming TCP Figure 3 using a TCP/IP port on the gateway and sending their information. The gateway resends this information to the sensors proxy inside the simulation. When the RTU inside the simulation requests information from a sensor, the sensor proxy responds back with the relevant data. The RTUs have both sensor proxies and actuator proxies connected to them. The gateway communicates to the simulation proxies through standard Modbus TCP messages. However, we have created a simpler protocol for communication between the gateway and external devices. The gateway communicates with the external NXT device using a simple and intuitive custom protocol called ExtComm. It contains 3 fields; Address, Function code and the Payload. The Address field matches the simulated sensor/actuator with real sensor/actuator. Figure 4 shows the message structure of the ExtComm protocol. The Address field has 2 unsigned bytes, which means it can map up to 65535 sensors/actuators. The Function code defines only two functions, read and write of 1 byte each. The payload contains the data to be transmitted. Its maximum size is 57 bytes as we want to have a fixed size for our messages. Modbus message structure. connections on port 502 by default. The Modbus specification requires that only one application PDU is sent in a single message. The Modbus TCP/IP implementation used in our simulation is ported from the libModbus library [22]. The libModbus implementation uses real BSD sockets as it is used on real Modbus systems. Our simulation makes use of the INET framework [18] for TCP/IP support. The framework offers a class equivalent socket structure, the TCPSocket class. It is used as a replacement for the socket structure inside an OMNET++ based simulation. For compliancy with OMNET++ standard, we have replaced all the sockets references with the INET TCPSocket class. We have also modified the original methods to be more object-oriented and reduced the amount of data being passed between each function call within Modbus. Although these changes improve the performance of our implementation, the method functionalities and its operation remain very similar for compatibility purposes. Figure 4 ExtComm message structure. E. Simulation Messages There are two types of messages in the simulation: Modbus TCP/IP messages and ExtComm messages. The ExtComm messages are exchanged between the gateway and the NXT device only. All messages exchanged inside the simulation environment are Modbus TCP/IP messages, including the HMI Client. The sensors send information when an event occurs. Events are defined as changes detected in the values being monitored by the real sensors. Every time a change occurs, the sensor sends its new value to the gateway using ExtComm messages. Figure 8 shows a sequence diagram that illustrates the flow of a message sent from the real sensor to the RTU. The sensor sends an extc_sensor_reading message to the gateway. The gateway translates this ExtComm message into a Modbus mb_write_register_ request message and sends it to the appropriate sensor proxy. The proxy then sends this message to the RTU, the RTU performs the requested operation and sends a mb_write_register_request response back to the sensor proxy. In the illustrated sequence diagram, the RTU requests the servo motor to turn itself ON by sending a Modbus mb_write_coil_request message to the servomotor proxy. The servo motor proxy then sends this message to the D. Integrating real devices into the Simulation The simulation consists of two distinct environments: the simulation environment and the external environment (real world). The simulation environment is the simulated world consisting of simulated components. In contrast, the external environment is the real world, where the actual sensors and actuators work in the SCADA process. In order to integrate these environments, we have created a gateway (gw) that translates the information between the simulation world and the real world. This gateway is implemented as a TCP/IP server listening for incoming requests from the external world and sending requests and responses from the simulation world to the external environment. Figure 7 illustrates this relationship. The real sensors send their status to the gateway by opening a connection 360 355 3) Field Device Proxy The Field Device Proxy represents the field devices inside the simulation. It contains all the information provided by the field device. RTUs receive information update from these proxies. Any action requested to be performed by MTU are also sent to the proxies, then they are forwarded through the gateway to the real field device. 4) 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 gateway, 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 gateway then to the real HMI Client. 5) Gateway (GW) The Gateway is responsible for translating requests and responses from real devices to the simulation and viceversa. It listens to requests on a predetermined TCP/IP port, (port 1502) and communicates with all external devices, sensors, actuators and the HMI Client. If the external destination is the HMI client, then messages do not need to be translated as the client also uses the Modbus protocol. 6) RTU The RTU represents a real RTU device, and they perform the same tasks as the real RTUs. As defined on the Modbus TCP specification [17], RTUs are slave servers that act upon requests. They cannot initiate a communication procedure. They respond to requests from the MTU for actions and passes information back to the MTU. 7) 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 network and to request actions to be performed on the network. 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. gateway, which translates it to an ExtComm extc_turn_motor message and sends it to the external actuator (servo motor). The servomotor performs the action and returns a confirmation message extc_confirmation_operation to the gateway, which is translated to a Modbus response message modbus_write_register_response to the servomotor proxy and forwarded to the RTU. F. Simulation Components The simulation consists of seven main components; Field Device, Field Device Proxy, Gateway, RTU, MTU/HMI, HMI Client Proxy, and HMI Client. Figure 5 shows these components and their relationship. The components are described in more detail below. 1) Field Device The Field Device is a real sensor or actuator. It is one of the four sensors and three motors that can be attached to the Lego NXT. The Field Device communicates with the simulation by sending messages to the gateway through a socket connection. It receives messages from the simulation through the gateway using a socket connection. The Field Device and the gateway are two different devices connected over a physical communication medium. For this simulation we have used the Bluetooth protocol [19] to connect these devices. The ExtComm protocol, mentioned earlier, uses Bluetooth for communication. Figure 5 VI. Relationship among SCADA simulation components. DEMONSTRATION OF A SCADA DDOS ATTACK This simulation aims to evaluate the capacity of a SCADA network to survive a malicious attack. Using a simple SCADA network we provide users with an HMI GUI application, which gives them the ability to control external devices and monitor some environment variables such as tanks water level. Under normal scenario users (HMI operators) should be able to start up and shutdown the motor engines (actuators) controlled by the system. They also should be able to request information about the water level of the tanks controlled by the system. From the GUI console an operator can check the tanks water level and then based on such information turn pumps 2) HMI Client In real SCADA systems, the HMI client is used by operators to monitor and control the system. For this reason, we have implemented it as a real HMI client running outside the simulator. The operations executed on it are real control actions performed by human operators. In order to communicate to the simulator it sends TCP/IP messages to the gateway, which then translates them into simulation messages and passes them on to the HMI Client proxy and then to the HMI Server. 361 356 defined by the SCADA operator, the RTU will send a message to the servomotor to turn itself ON until the water level reaches the appropriate height. For safety, the operators can also force the water pump ON manually by using the HMI client. The manual operation overrides the logic preset in the RTU. In reality, there will be tens and hundreds of pumps and tanks managed by the MTU. In the next section we demonstrate how malicious attacks can disrupt the above SCADA process. (actuators) ON or OFF. Under an attack scenario, the functionalities of the system will be affected. Operators would get wrong and delayed information about the environment, such as incorrect water level of a tank. Based on this wrong information, operators are likely to take wrong actions that could adversely affect the normal operation of the system. In the next section we introduce the SCADA network topology and the attack scenario originating from it. A. Water plant SCADA system The water plant SCADA scenario is a simplified version of a real SCADA system that monitors and controls water plants. This simplified version, as shown in Figure 6, consists of two tanks (tank1, tank2) and a pump. On the top of tank2 there is a sensor that measures the water level of the tank. If the water level is lower than predefined value the pump has to turn on to pump water from the tank1 into tank2. If tank1 has no water to pump out an alarm has to fire up alerting the operators through the HMI client application. The operator can make the necessary procedures to fill water into tank1. The operator also can manually turn the pump on to fill up tank2. Needleless to say, all operations are performed through the HMI client application. Even though it is a simple scenario it represents a real operation in a water treatment plant. Figure 6 B. Attack Scenario In the attack scenario, the functionalities of the system will be affected. For instance, operators would get wrong and delayed information about the environment, for example, incorrect water level information and the time of event. Based on such wrong information the operator is likely to take wrong actions that could adversely affect the operation of the SCADA system. Huitsing et al. [23] have described taxonomies of attacks on the Modbus protocol. In this experiment we used a TCP SYN flooding attack. Our intent is to disrupt the normal operation of the Water plant SCADA system. VII. RESULTS FROM THE DDOS ATTACK In our DDoS attack scenario, malicious attackers will flood the RTU with TCP SYN packets aiming to disrupt the normal system operation. OMNET++ and INET do not support the possibility of simulating connection overloads on the nodes, in our case, the RTU. To achieve such behaviour we have modified the INET framework in order to limit the number of simultaneous TCP connections. The limit is configurable through the simulation configuration file. In addition, inactive TCP connections will be dropped after a certain period of time, simulating normal host behaviour. Our implementation is a modified version of the open-source project Rease [24]. Rease also provides a DDoS implementation based on the TFN (Tribe Flood Network) tool [25]. We have used it to implement the malicious attackers. In order to experiment with the TCP SYN flood attack, we have kept track of the number of TCP connections being created, dropped and closed during the entire simulation, under both normal and attack circumstances. Simple SCADA Water plant. Figure 9 shows the effect of the DDoS attack on the SCADA RTU. In this simulation we have used 10 attackers, each sending 1000 TCP SYN packets. The attack starts at Time = 700 in the simulation timeline. The time between 0 and 700 seconds (0”T ”700) displays the normal behavior of a typical SCADA RTU, where TCP connections are being created, accepted and closed without any problem. At Time = 700 the RTU starts to receive an enormous amount of packets requesting new TCP connections. The number of open TCP connections at the RTU shoots up and reaches its limit of concurrent Figure 6 shows the SCADA network topology used in this scenario. There is an RTU with a sensor and an actuator attached to it. There is also an HMI client and MTU/HMI Server host and routers to route the messages between the two LANs over the Internet. The water level meter is represented by the NXT’s distance meter sensor (Sd) and the water pump is represented by a NXT’s servomotor (Am). The sensor regularly updates the RTU about any changes in the water level. In case the water level reaches the minimum level 362 357 8. National Laboratory - National SCADA Test Bed Program. [cited 2009; Available from: http://www.inl.gov/scada. connections, in this case 100, and starts dropping new connection requests. After the attack finishes (around T = 730), the RTU will accept connections again, however, only when the already opened connections start closing, either by timeout or by user request. The red circle in the figure shows this syncronism. For every closed connection a new accepted connection is created. Since we simulated a SCADA network with low traffic, the number of dropped connections will stay constant after the attack. 9. Davis, C.M., et al. SCADA Cyber Security Testbed Development. in Power Symposium, 2006. NAPS 2006. 38th North American. 2006. 10. Oman, P. and M. Phillips. Intrusion Detection and Event Monitoring in SCADA Networks. in Critical Infrastructure Protection. 2008. 11. Deconinck, G., et al., Testbed deployment of representative control algorithms. Deliverable D9, Project CRUTIAL EC IST-FP6-STREP, 2008. 27513. VIII. CONCLUSION 12. Christiansson, H. and E. Luiijf. Creating a European SCADA Security Testbed. in Critical Infrastructure Protection Critical Infrastructure Protection. 2007. The proposed testbed architecture is based on a combination of network simulation and real devices connectivity. It allows real world devices (such as sensors, and actuators) to be attached to the simulator to study the effects of malicious attacks on the devices and on the simulated network. Many argue that simulations do not represent real world scenarios accurately. The proposed architecture aims to provide more realistic evaluations by adding real devices into the simulation. In the future, we intend to incorporate various other SCADA protocols, for example, Zigbee, and DNP3 that are popular with diverse industry applications ranging from home automation to power generation. In addition, we would like to use the testbed for more complex protocol attacks on SCADA protocols and SCADA devices, and propose solutions that can be incorporated into firewall rules and intrusion detection systems. 13. Igure, V., S. Laughter, and R. Williams, Security issues in SCADA networks. Computers & Security, 2006. 25(7): p. 498-506. 14. Verissimo, P., N. Ferreira Neves, and M. Correia, The CRUTIAL reference critical information infrastructure architecture: a blueprint. International Journal of System of Systems Engineering, 2008. 1(1): p. 78-95. 15. Group, L. Lego Mindstorms NXT. 2009 14/04/2009]; Available from: http://mindstorms.lego.com. 16. Varga, A., The OMNeT++ discrete event simulation system. Proceedings of the European Simulation Multiconference (ESM’2001), 2001. 17. Swales, A. and S. Electric, OPEN MODBUS/TCP SPECIFICATION. Schneider Electric, 1999. 18. INET Framework for OMNeT++ 4.0. 2009 2009; Available from: http://inet.omnetpp.org/. REFERENCES [cited 1. Slay, J. and M. Miller, Lessons Learned from the Maroochy Water Breach. Intl. Federation for Information Processing Publications, 2008. 253: p. 73. 19. Organization, B. Bluetooth Technical Specification. 2009 [cited 2009; Available from: http://www.bluetooth.com/Bluetooth/Technology/Building/Spec ifications/. 2. Abrams, M. and J. Weiss, Malicious Control System Cyber Security Attack Case Study - Maroochy Water Services, Australia. 2008, Technical Report, Mitre.org. p. 1-16. 20. LeJOS - Java for Lego Mindstorms. 2009 [cited 2009 29/04/2009]; Available from: http://lejos.sourceforge.net/. 21. Modicon, I. Modicon Modbus Protocol Reference Guide. 1996; 121]. Available from: http://modbus.org/docs/PI_MBUS_300.pdf. 3. Poulsen, K. Slammer Worm Crashed Ohio Nuke Plant Network. 2003 [cited 2009; Available from: http://www.securityfocus.com/news/6767. 22. Raimbault, S., Libmodbus - A modbus library for Linux and OSX. . 2009. 4. Bessani, A., et al., The Crutial Way of Critical Infrastructure Protection. Security & Privacy, IEEE, 2008. 6(6): p. 44-51. 23. Huitsing, P., et al., Attack taxonomies for the Modbus protocols. International Journal of Critical Infrastructure Protection, 2008. 1: p. 37-44. 5. Brundle, M. and M. Naedele, Security for Process Control Systems: An Overview. Security & Privacy, IEEE, 2008. 6(6): p. 24-29. 6. Dzung, D., et al., Security for industrial communication systems. Proceedings of the IEEE, 2005. 93(6): p. 1152-1177. 24. Gamer, T. and M. Scharf, Realistic simulation environments for IP-based networks. Simutools '08: Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems & workshops, 2008: p. 1-7. 7. The Center for SCADA Security - Sandia National Labs. [cited 2009; Available from: http://www.sandia.gov/scada/home.htm. 25. Dittrich, D. The "Tribe Flood Network" distributed denial of service attack tool 1999 [cited 2009; Available from: http://staff.washington.edu/dittrich/misc/tfn.analysis. 363 358 Figure 7 Integration between the simulation and the physical devices. Figure 8 Request and response message workflow. Figure 9 RTU under Attack. 364 359