## 5 Anomaly Detection in Water Systems  
In March 2000, the water treatment system of Maroochy in Queensland Australia was compromised by a disgruntled attacker who was turned down for a job at the facility [15]. The attacker ceased control of 150 pump stations remotely and in the three months it took to detect the breach he was able to release 150 million litres of untreated sewage into local water ways. The system did have security mechanisms in place but the attacker was involved in the installation of the upgrades to the system and used this knowledge to bypass them. The system exhibited unexplained behaviour during this period which was eventually noticed by the engineers who were eventually able to track him down and have him arrested. At this point however, the attacker had already caused a substantial amount of damage. This example will be used to illustrate the benefits anomaly detection in critical infrastructure applications by looking at how the system failed and how anomaly detection could have been used to limit the damage. Some of the most notable faults exhibited by the system during the breach were [59]: (1) unexplained alarms, (2) increased network traffic, (3) misbehaving pumps, (4) alarms not going off when they were supposed to, and (5) communication lockups. These faults can clearly be classified as system anomalies which can be classified by detection schemes. SCADA systems consist of the corporative and the control networks [6]. The former is responsible the general system supervision while the latter is more intimately involved with the control of the various subsystems. This discussion will be constrained to the control network which is where the sensor networks are located. Each of the notable system faults will now be discussed to ascertain how an anomaly detection scheme at the control level could have led to the breach being detected sooner. The system exhibited several alarms which could not be explained by the administrators. Anomaly detection schemes however deal with raw system data at the control level. This means that a detected anomaly can be isolated to a specific part of the network which would have made it easier find the source of the problem. In this instance, the administrators would have been able to approach the problem from the sensor level, e.g., specific sensors within the system are measuring uncharacteristic values based on historic data. The problem of alarms not going off when they were supposed to could have also been aided by these schemes. In this case however, this would have only been useful once the problem had been detected. The alarms still wouldn't have gone off because that was modified at an administrative level, but the anomalies would have been detected and logged making it easier to find the source. The other three faults were general anomalies which would have been easily detected by any anomaly detection scheme. The attack on the Maroochy water system was however not very sophisticated which is why it could have been detected easily using appropriate schemes. The authors in [60] used a water treatment dataset to show that more sophisticated attacks can also be detected in water systems. In this case the system was tested against a variety of spoofing attacks which could lead to, among other things, overflow and underflow errors. The former can lead to flooding and the latter can potentially damage the pumps. The system was able to detect all the various attacks it was tested against and isolate the anomalies to specific sensors within the system. This would make it easier for a system to recover once compromised because administrators would know the exact location of the problems. The authors in [61] went further by using the FACIES testbed to compare model-based fault detection (FD) and network anomaly detection.