# Attack Classification Schema for Smart City WSNs
## 4 Attack Classification
### Classification Procedure  
Above, generic attack types that can compromise smart city WSNs have been shown. Below, we present a procedure to identify an attack type by analyzing the alarms generated with the detection engines explained in Section 3. As previously seen, the proposed framework can gather a plethora of AT1, AT2 and AT3 alarms from many different nodes triggered by the same attack. As mentioned in Section 3.2.2, administrators can implement correlation rules in order to group some of these alarms and, thus, trigger a high severity AT4 alarm to warn them when the evidence of attacks is strong. Thus, the proposed classification procedure starts upon receiving an AT4 alarm, which, as previously shown, is considered reliable, and therefore, these type of alarms require administrators' attention. Figure 5 presents the workflow with the classification schema. As the figure shows, the process begins when administrators receive a high severity AT4 alarm (Step (a)). Then, administrators have to decide which other alarms registered in the system could be related to the incident and, therefore, have to be collected for analysis (Step (b)). In general, these related alarms are the ones triggered by nearby nodes during a short time interval before or after the incident, or by other components of the same network, or the same provider, etc. As a result of Step (b), administrators identify a set of alarms that is relevant for the classification of the incident. In the subsequent steps, this set of alarms is analyzed to answer the following questions:  
* Are multiple nodes affected? (Step (c)). * Are the affected nodes geolocalized together? (Step (d)). * Are multiple services affected? (Steps (e) and (k)). * Are multiple frequency bands affected? (Step (f)). * Is the gateway involved in the attack? (Steps (g), (l) and (m)). * Are the alarms in the set of alarms relevant? (Step (i)). * Do vertical paths show signs of being affected? (Step (j)). It is worth noting that verifying whether a gateway is involved in the attack is usually the responsibility of the gateway provider, who has full access to the gateway. Moreover, as mentioned in Section 4.1, we consider that gateways are not constrained in terms of processing power, are connected to the electricity grid and have reliable telecommunication connections. Therefore, providers can perform complete analysis on the gateways with conventional security tools (e.g., anti-virus, IDS) to test if they have been compromised. In addition to the analysis through the aforementioned questions, the workflow eventually requires splitting the alarm set into several subsets according to a certain criterion (e.g., by frequency band) (Steps (h) and (n)). Splitting the alarm set is important to differentiate between several alarms due to different incidents occurring in the same devices around the same time. When there is no model clearly identifiable from the alarm set, as Loops (c)-(i) and (c)-(n) show, we propose an iterative process that divides the alarm set into several partitions, and each of them is used to start the classification procedure again. Thus, alarms that are not related are divided into different partitions and, therefore, analyzed separately. These unrelated alarms from the same area at the same moment in time can be due to concurrent attacks, false alarms, etc. Lastly, the final states of the procedure in Figure 5 show the attack model that fits the evidence given by an alarm set. The states where third party services or important communication nodes are affected are indicated by a red box. Below, in order to illustrate the classification process, an example incident is resolved:  
1. A high severity alarm (AT4) calls the smart city administrators' attention (Step (a)) to a parking WSN controlled by Provider A. This AT4 alarm is defined with a correlation rule that groups three or more AT1 alarms (triggered if the received RSSI is above a threshold) in a two-hour window.