Supervisory control and data acquisition (SCADA) systems are used for gathering real-time data, monitoring equipment and controlling processes in industrial facilities and public utilities, including, among others, water and sewage treatment plants [NCS, 2004]. They include servers, capable to communicate with sensors and control devices, located with some water plants or at remote locations, or with whatever equipment needs to be monitored or controlled. A SCADA network, serving the SCADA system, can cover large geographical areas, especially in the case of public utilities.

A SCADA system generally includes three kinds of components: the field devices, the server(s), and the client machines. Field Devices include sensors and controllers (e.g., Remote Telemetry Units (RTUs) and programmable logic controllers (PLCs), or a combination of both). Sensors are used to collect data from various sources. Controllers perform actions (e.g. starting a pump or closing a valve) based on sensor data and implemented control algorithms. RTUs and PLCs are small dedicated devices, which are hardened for outdoor use and industrial environments. They may be interfaced using serial connections or Ethernet.

Servers are responsible for collecting and analyzing various field inputs. They are responsible for raising alarms, starting and stopping processes, and implementing the logic required to automate processes.

Finally, client machines can interact with the servers via terminals (direct access) or Web-based protocols (remote access). Clients usually monitor the state of a SCADA network, and have the ability to start and stop processes running within the network. SCADA systems have traditionally used combinations of radio and direct wired connections. The remote management or monitoring function of a SCADA system is often referred to as telemetry. SCADA protocols are designed to be very compact. Many are designed to send information only when the master station polls the RTU. Typical legacy SCADA protocols include Modbus RTU, RP-570, Profibus and Conitel. These communication protocols are all SCADA-vendor specific but are widely adopted and used. Standard protocols are IEC 60870-5-101 or 104, IEC 61850 and DNP3. These communication protocols are standardized and recognized by all major SCADA vendors. Many of these protocols now contain extensions to operate over TCP/IP.

SCADA systems have evolved through several generations [Karnouskos, 2011]. Early SCADA system computing was done by large minicomputers. With the advent of distributed systems, SCADA information and command processing was later on distributed across multiple stations, which were connected through a LAN. Information was shared in near real time. Each station was responsible for a particular task, which reduced the cost as compared to monolithic-generation SCADA systems. But the network protocols used were still not standardized.

Later on, SCADA designs were adapted to large networks, where the system may be spread across more than one LAN network called a process control network (PCN) and separated geographically. Several distributed architecture SCADAs running in parallel, with a single supervisor and historian, could be considered a network architecture. This allows for a more cost effective solution in very large scale systems.

Finally, today, we witness the Internet of Things generation of SCADA systems. With the commercial availability of cloud computing, SCADA systems have increasingly adopted Internet of Things technology to significantly reduce infrastructure costs and increase ease of maintenance and integration. As a result, SCADA systems can now report state in near real-time and use the horizontal scale available in cloud environments to implement more complex control algorithms than are practically feasible to implement on traditional programmable logic controllers. Further, the use of open network protocols such as TLS inherent in the Internet of Things technology provides a more readily comprehensible and manageable security boundary than the heterogeneous mix of proprietary network protocols typical of many decentralized SCADA implementations. One such example of this technology is an innovative approach to rainwater harvesting through the implementation of real time controls (RTC).

This decentralization of data also requires a different approach to SCADA than traditional PLC based programs. When a SCADA system is used locally, the preferred methodology involves binding the graphics on the user interface to the data stored in specific PLC memory addresses. However, when the data comes from a disparate mix of sensors, controllers and databases (which may be local or at varied connected locations), the typical 1 to 1 mapping becomes problematic. A solution to this is Data Modelling [Mercurio, the concept derived from object oriented programming.

In a Data Model, a virtual representation of each device is constructed in the SCADA software. These virtual representations (“Models”) can contain not just the address mapping of the device represented, but also any other pertinent information (web based info, database entries, media files, etc.) that may be used by other facets of the SCADA/IoT implementation. As the increased complexity of the Internet of Things renders traditional SCADA increasingly “house-bound,” and as communication protocols evolve to favour platform-independent, service-oriented architecture (such as OPC UA), it is likely that more SCADA software developers will implement some form of data modelling.

To give an example of the kind of challenges faced, we consider here the case of the Australian SCADA system for water management, one of the very complex, because of the vastness of the country and the remoteness of many of the water utility plants and field stations. It is famous due to the system breach occurred at Maroochy Water Services on Queensland’s Sunshine Coast in Australia [Hughes, 2003]. In March 2000, Maroochy Shire Council experienced problems with its new wastewater system. Communications sent by radio links to wastewater pumping stations were lost, pumps were not working properly, and alarms put in place to alert staff to faults was not going off. While initially it was thought there were teething problems with the new system, an engineer who was monitoring every signal passing through the system discovered that someone was hacking into the system and was deliberately causing the problems. The perpetrator, Vitek Boden, used a laptop computer and a radio transmitter to take control of 150 sewage pumping stations. Over a three-month period, he released one million liters of untreated sewage into a stormwater drain from where it flowed to local waterways. The attack was motivated by revenge on the part of Mr. Boden after he failed to secure a job with the Maroochy Shire Council. The Maroochy Water Services case has been cited around the world as an example of the damage that could occur if SCADA systems are not secured. The incident was mentioned in a recent report on IT security by the U.S. President’s Information Technology Advisory Committee [US, 2005].

The Maroochy SCADA system included two monitoring stations and three radio frequencies to control the operations of 142 sewage pumping stations. During the attack, the system experienced several faults [Mustard, 2005]: unexplained pump station alarms, increased radio traffic that caused communication failures, modified configuration settings for pump station software, pumps running continually or turned off unexpectedly, pump station lockups and pumps turned off without any alarms, and computer communication lockups and no alarm monitoring. For such manifestations, it was easier for the engineers to blame installation errors. However, upon reinstalling all the software and checking the system, they noticed that pump station settings kept changing beyond the ability of the system to do this automatically. Therefore, they concluded that an external malicious entity was responsible. With the help of advanced monitoring tools, they determined that a hacker was using wireless equipment to access the SCADA system. The analysis of the incident made several important points. First, it is very difficult to protect against insider attacks. Second, radio communications commonly used in SCADA systems are generally insecure or are improperly configured. Third, SCADA devices and software should be secured to the extent possible using physical and logical controls; but it is often that case that security controls are not implemented or are not used properly. Finally, SCADA systems must record all device accesses and commands, especially those involving connections to or from remote sites; this requires fairly sophisticated logging mechanisms.

Today, several technical solutions are already available for securing SCADA systems. The solutions vary in their coverage and may not be very robust; nevertheless, they are good starting points for implementing security in SCADA systems. Due to their specialized architecture, protocols and security goals, it is not appropriate to simply apply IT security techniques and tools to SCADA systems. Instead, it is important to design security solutions catered specifically to SCADA systems. For example, tools that understand SCADA protocols and are designed to operate in industrial environments would be able to identify and block suspicious traffic in a more efficient and reliable manner.

Peterson [Peterson, 2004] discusses the need for specialized intrusion detection systems for SCADA networks. Most existing systems only pick up traditional attacks, e.g., an attacker attempting to gain control of a server by exploiting a Windows vulnerability; effective intrusion detection systems must also incorporate SCADA attack signatures. Likewise, SCADA-aware firewalls must also be developed; their specialized SCADA rule sets would greatly enhance the blocking and filtering of suspicious packets. Peterson also emphasizes the need for logging activities and events in SCADA systems. Logs can provide valuable information pertaining to attacks. This includes information about the escalation of user privileges in SCADA applications, failed login attempts, and disabled alarms and changed displays, which could fool operators into believing that a system is running normally.

In addition to investing in security techniques, mechanisms and tools, it is imperative to focus on the human aspects of SCADA security. Staff must be well trained and should be kept abreast of the latest security practices, exploits and countermeasures. Security policies and procedures should be developed, refined periodically, and applied consistently. Only the combination of technological solutions and human best practices can ensure that SCADA systems are secure and reliable.