Received: 16 November 2016 Revised: 6 March 2017 Accepted: 22 March 2017

DOI: 10.1002/ett.3188

SPECIAL ISSUE ARTICLE

Anomaly behavior analysis for IoT sensors

Jesus Pacheco Salim Hariri

National Science Foundation Center for

Cloud and Autonomic Computing, Abstract
Department of Electrical and Computer
The Internet of Things (IoT) will not only connect computers and mobile devices but
Engineering, The University of Arizona,
Tucson, Arizona, USA also interconnect smart buildings, homes, and cities, as well as electrical grids, gas,
and water networks, automobiles, airplanes, etc. IoT will lead to the development
Correspondence
of a wide range of advanced information services that need to be processed in real
Salim Hariri, National Science Foundation
Center for Cloud and Autonomic time and require large storage and computational power. The integration of IoT with
Computing, Department of Electrical and fog and cloud computing not only brings the computational requirements but also
Computer Engineering, The University of
Arizona, Tucson, Arizona, USA.
enables IoT services to be pervasive, cost-effective, and accessible from anywhere
Email: [email protected] and at anytime. In any IoT application, sensors are indispensable to bring the physical
world into the digital world that can be implemented by leveraging fog computing.
Funding information
Air Force Office of Scientific Research, However, IoT sensors will introduce major security challenges as they contribute to a
Grant/Award Number: FA95550-12-1-0241; significant increase in the IoT attack surface. In this paper, we present a methodology
National Science Foundation, Grant/Award
to develop an intrusion detection system on the basis of anomaly behavior analysis to
Number: 1624668, SES-1314631, and
DUE-1303362 ; Thomson Reuters detect when a sensor has been compromised and used to provide misinformation. Our
preliminary experimental results show that our approach can accurately authenticate
sensors on the basis of their behavior and can detect known and unknown sensor
attacks with high detection rate and low false alarms.

1 INTRODUCTION

Advances in mobile and pervasive computing, social network technologies, and the exponential growth in Internet applications
and services will lead to the development of the next generation of Internet services (Internet of Things [IoT]) that are pervasive
and ubiquitous and that touch all aspects of our life. It is expected that the number of IoT devices will reach more than 50 billion
devices by 2020.1 With the support of fog computing, the IoT services will be a key enabling technology to the development
of smart cities that will revolutionize the way we do business, maintain our health, manage critical infrastructure, and conduct
education and to how we secure, protect, and entertain ourselves.2,3 Since fog computing hosts services at the network edge, its
advantages include low service latency, high quality of services, support for mobility, awareness of location, and easier imple-
mentation of security measures. It was shown that fog computing supports IoT applications that require predictable latency,3,4
such as smart infrastructures (SIs), for example, smart buildings (SBs) and smart cities. As one of the IoT applications, SB
automation systems aim at integrating building equipment with sensors, actuators, and control devices to achieve reliable and
efficient operations and significantly reduce operational costs. However, with the use of fog computing and IoT techniques, we
are experiencing major challenges to secure and protect such advanced information services because of the significant increase
in the attack surface.3 The interconnections between growing amounts of devices expose the vulnerability of IoT applications to
attackers. Even devices that are intended to operate only in local area networks are sometimes connected to the Internet because
of careless configuration or to satisfy special needs (eg, they need to be remotely monitored). This makes control system data
vulnerable to falsification attacks that lead to incorrect information delivery to users, causing them to take wrong and dangerous
actions or to be unaware of an ongoing attack, as was the case with Stuxnet attack.4 Another example is in the work of Legezo,5

Trans Emerging Tel Tech. 2018;29:e3188. wileyonlinelibrary.com/journal/ett Copyright © 2017 John Wiley & Sons, Ltd. 1 of 15
https://doi.org/10.1002/ett.3188
2 of 15 PACHECO AND HARIRI

where the author showed how a Bluetooth connection was used in a city to change traffic sensors’ firmware to gather informa-
tion and to modify the data provided by those sensors. Finally, Takahashi et al.6 showed a comprehensive study of cyberattacks
targeting information gathered from medical wireless sensor networks. Here, the main concern is medical information disclo-
sure and falsification. These are some real-world scenarios that show how critically important it is to secure and protect the IoT
operations against cyberattacks, especially when it comes to IoT sensors.
In this work, we present a methodology to protect IoT sensors against a variety of cyberattacks. We first introduce our IoT
security framework for SIs that consists of 4 layers: devices (end nodes), network, services, and application. We then present a
methodology to develop a general threat model to better recognize the vulnerabilities in each layer and the possible countermea-
sures that can be deployed to mitigate their exploitation. In this scope, we show how to develop and deploy an anomaly behavior
analysis intrusion detection system (ABA-IDS) on the basis of the discrete wavelet transform (DWT) to detect anomalies that
might be triggered by attacks against the sensors in the first layer of our IoT framework. We have evaluated our approach by
launching several cyberattacks (eg, sensor impersonation, replay, and flooding attacks) against our SB testbed developed at the
Center for Cloud and Autonomic Computing, The University of Arizona. The results show that our approach can be used to
deploy effective security mechanisms to protect the normal operations of IoT sensors. Moreover, our approach can detect known
and unknown attacks against IoT end nodes with high detection rate and low false alarms.
The remainder of this paper is organized as follows. In Section 2, we provide background information about the concepts of
SIs, fog computing, IoT cybersecurity, ABA-IDS, and the use of a threat model. In Section 3, we explain our IoT security frame-
work for SIs. Section 4 is devoted in explaining our ABA methodology. In Section 5, we present our experimental environment
and discuss our evaluation results. In Section 6, we conclude this paper and discuss future research direction.

2 BACKGROUND

2.1 Smart infrastructures

Smart infrastructures integrate autonomy and adaptive control that can be used to better manage resources in a city, in a building,
or at home. To illustrate the characteristics of SIs, we will use an SB as an example. Smart buildings link controllers, automation,
information technology, sustainable development, security, and communication (among other systems) to achieve advanced
information services that significantly reduce operational cost, improve human comfort, and reduce energy consumption.7
Because of the wide range of users, interconnected systems, and environmental factors, the computational power needed to
operate SBs is similar to that needed in large-scale data centers. One solution to fulfill the needs is fog computing, which aims
at providing computational power, storage, and network services to end devices.8,9

2.2 Fog computing

Fog computing technology can be seen as an intermediate layer between the IoT lower levels and the cloud.10,11 Since fog
computing hosts services at the network edge, its advantages include low service latency, high-quality services, support for
mobility, location awareness, and easier implementation of security mechanisms (eg, keeps sensitive data on premises).12 It has
been shown that fog computing can be effective in supporting IoT applications that demand predictable latency, mobility, and
protection mechanisms. For example, Yaseen et al.12 proposed a model for detecting malicious mobile sensors, leveraging the
infrastructure of fog computing to achieve this goal.

2.3 IoT cybersecurity

The Internet of Things (IoT) can be viewed as an ubiquitous network that enables monitoring and controlling a large number of
heterogeneous devices that are geographically dispersed by collecting, and processing and acting on the data generated by smart
objects.13 It represents intelligent end-to-end systems that enable smart solutions and covers a diverse range of technologies,
including sensing, communications, networking, etc.14 This diverse and dynamic use of resources has made security a major
challenge. Traditional IT security solutions are not directly applicable to IoT because of the following issues13 : (1) The IoT
extends the “Internet” through the traditional Internet, mobile network, non-IP networks, sensor network, cloud computing,
and fog computing, (2) computing platforms, constrained in memory and processing capability, consequently may not support
complex security algorithms, (3) all “things” will communicate with each other. This leads to multiple access points that can be
PACHECO AND HARIRI 3 of 15

used to exploit existing vulnerabilities, and (4) some IoT devices and services may be shared and could have different ownership,
policy, and connectivity domains.
These challenges need to be addressed to build a secure and resilient IoT infrastructure, where confidentiality, integrity, and
availability must be assured. Consequently, there is a strong research interest in securing and protecting IoT and their services
using resilient techniques.15

2.4 Anomaly behavior analysis

Current cybersecurity solutions are far from being satisfactory to stop the exponential growth in number and complexity of
cyberattacks.12,16 In addition, the effort and knowledge required to launch sophisticated attacks is decreasing while their propa-
gation has been reduced from days in the early 1980s to a fraction of seconds in 2000s.15 There are 2 basic intrusion detection
techniques to detect cyberattacks: signature- and anomaly-based intrusion detection systems (IDSs).17 The signature-based IDS
builds a database of known attack signatures or identities. However, this system cannot detect new types of attacks or even a
known attack with a slight change on its signature. The main feature of the anomaly detection approaches is their capability in
detecting novel and new attacks. The anomaly-based IDS defines a baseline model for normal behavior of the system through
offline training and considers any activity that lies outside this normal model as an anomaly.17
Any attack, misconfiguration, or misuse will lead to deviation from the normal behavior; we name it as abnormal behavior.
The main limitation of this approach is the large number of false alarms that can be produced. Our approach overcomes this
limitation by performing fine grain ABA, as will be discussed in further detail when we introduce our ABA-IDS approach.

2.5 Threat model

Improving security and reducing risks in information systems depend heavily on analyzing threats, risks, and vulnerabilities
to develop the appropriate countermeasures to mitigate their exploitations.18 To better understand the IoT security landscape,
a general IoT threat model needs to be developed.19 A threat model defines threat scenarios with associated risk distributions.
It helps in analyzing security problems, designing mitigation strategies, and evaluating mitigation solutions. When created in
the design phase, a threat model helps identify changes that need to be made to the design to mitigate potential threats. When a
threat model is created for a deployed system, it can be used to prioritize the mitigation actions.18 In general, the steps to create
a general threat model are as follows19 : (1) Identify attackers, assets, and threats, (2) rank the threats, (3) choose mitigation
strategies, and (4) build mitigation solutions based on these strategies. We will follow these steps to create the threat model for
our IoT framework, and then we will show how to use it to secure and protect IoT sensors.

3 IOT SECURITY FRAMEWORK FOR SMART INFRASTRUCTURES

There are several IoT frameworks that can be used to create a threat model and apply mitigation strategies.20-22 Figure 1 shows
an architecture that can be used to guide the security development of IoT SIs. The framework consists of 4 layers: IoT end nodes
(end devices), network, services, and applications. Cyberattacks can be launched against the functions and services provided
by each layer shown in Figure 1. For each layer in our framework, we can define the threats by target, impact, and mitigation
methods.
In the first layer (end nodes), the information passes through physical devices to identify the physical world. This information
includes object properties, environmental conditions, data, etc. The key components in this layer are the sensors for capturing
and representing the physical world in the digital world and the actuators to modify the environment to a desired state. The
targets at this level are local controllers, sensors, actuators, and information. The impact can be loss or waste of energy, money,
human safety, provider’s reputation, and time. Mitigation mechanisms include lightweight encryption, sensor authentication,
IDS, anti-jamming, and behavior analysis.
Network layer is responsible for the reliable transmission of information from/to end nodes.22 The technologies used in this
include the Internet, mobile communication networks, wireless sensor networks, network infrastructures, and communication
protocols. Network security and management play an important role to defend against cyberattacks targeting firewalls, routers,
protocols, and personal information. The impacts might be in money, reputation, safety, energy, control, and time. Network
mitigation mechanisms include authentication, anti-denial-of-service (DoS), encryption, packet filtering, congestion control,
anti-jamming, intrusion detection, and behavior analysis.
4 of 15 PACHECO AND HARIRI

Appli-
Appli- Users Devices
cations
cations
Internet Internet

IoT Fog
Services
Services

Internet
Network
Access Secure
Control Gateway

Local
Network

End Controller Controller

Nodes Non IP
IP Network
Network

Devices Devices

FIGURE 1 IoT security framework for SIs

The service layer acts as an interface between the application layer in the top level and the network layer in the lower level.21
At this layer, all the required computational power is mostly provided as a cloud and fog services. In this layer, cyberattacks
target personal and confidential information, IoT end devices, and monitor and control functions. The impact includes people
safety, money losses, and information leakage. Protection mechanisms include encryption, authentication, session identifiers,
intrusion detection, selective disclosure, data distortion, and behavior analysis.
The application layer provides the personalized services according to the needs of the user.22 The access to the IoT services is
through this layer, and it can be via mobile technology such as cell phone, mobile applications, or a smart appliance or device. In
this layer, data sharing is an important characteristic, and consequently, application security must address data privacy, access
control, and information leaks. The impacts can be in illegal access to intellectual properties, disclosure of critical business
plans, money loss, and damaging business reputation. Some mitigation mechanisms include encryption, authentication, and
ABA of applications and their services.
Attackers may use any existing vulnerability to gain access to the system and launch an attack. Our framework can be used to
identify the potential vulnerabilities and the appropriate mitigation mechanism. For instance, an IP temperature sensor located
in a remote place can be easily replaced by a computer to obtain illegal information and launch an attack (eg, replay attack).
Since sensors usually have low (or no) computational power, it is unrealistic to apply encryption techniques; a more suitable
approach is to authenticate each sensor and its data.

3.1 Attack surface

Attacks on a system take place either by launching an attack within the system’s operating environment (insider attack) or by
launching it from an external source (outsider attack).23 In both cases, an attacker will use the system’s resources (methods,
channels, and data) to launch attacks. We consider 2 sides of the IoT application, ie, 1 for local networks (insiders) and 1 for
public networks (outsiders).24 Local networks include end devices, IP and non-IP networks, controllers, and gateways. Public
networks include IoT services and applications.
We focus our work on the local networks, where sensors share data and can be compromised by adversaries. Sensors’
data protection is crucial to prevent the propagation of attacks to other layers of the framework (eg, device-to-controller and
controller-to-network attacks) or in the same layer (eg, device-to-device attack). The IoT security framework shown in Figure 1
can be used to derive the attack surface shown in Table 1.

3.2 Smart building testbed

The smart building testbed (SBT) has all the characteristics and functionalities of the actual SBs such as sensors, actuators,
automation systems, and communication channels. In our testbed, the user can monitor SB variables and control elements using
a variety of protocols (eg, ZigBee, Wi-Fi, and BACnet). Variables include temperature, distance, motion, current, humidity, and
illumination. The elements to control (actuators) are lights, ventilators, door, and electric sockets. Our testbed is also equipped
PACHECO AND HARIRI 5 of 15

TABLE 1 Attack surface for SB in IoT

Location Attack surface
Inside Device to Device
(local network) Door ⇔ Alarm
Device to Controller
Lights ⇔ Controller
Controller to Gateway
Command ⇔ Service
User to Gateway
Authentication ⇔ Access

Outside User to IoT services

(public network) User ⇔ Stored data
Service to service
Health care ⇔ Payment
Application to service
Smart Home ⇔ Electricity
IoT device to service
Smart phone ⇔ Fog data

with several control units such as Arduino UNO, BACNet controller, and NI CompactRIO.25 The monitor and control tasks can
be performed locally by accessing our secure gateway and remotely by using fog or cloud services. The SBT will enable us
to experiment with and evaluate different security mechanisms and resilient algorithms and study their impacts on normal SB
services.

4 ABNORMAL BEHAVIOR ANALYSIS METHODOLOGY

We have developed a methodology to protect the operations of end nodes against any type of threat by using continuous mon-
itoring and performing anomaly behavior analysis of the end node operations. The main modules to implement our approach
are shown in Figure 2: (1) continuous monitoring, (2) sensor behavior data structures (SBDSs), (3) anomaly behavior analysis
(ABA), (4) sensor classification, and (5) recovery actions.

4.1 Continuous monitoring

We have used Wireshark, a network monitoring tool, to capture the behavior of IoT components that are required to characterize
their normal operations.26,27 Among other tools (eg, Tcpdump, Ethereal, and Net2PCAP26 ), Wireshark can also be used to
visualize measured network traffic. Its main advantages include the following: (1) It is an independent platform, (2) it is robust in

FIGURE 2 ABA methodology for sensors

6 of 15 PACHECO AND HARIRI

the amount of data it can handle (outstanding performance), and (3) it provides useful capture and display filters. The information
obtained from Wireshark includes source IP, destination IP, and content of packets. The monitoring process occurs between the
controller and the secure gateway so we can detect any anomalous events before reaching the secure gateway. Hence, this enables
us to avoid the propagation of any attack. The sensor’s data are extracted from the payload and sent to the SBDS module, where
the sensor is automatically identified and its runtime profile is obtained. We refer to the sensor profile as the sensor-DNA data
structure (s-DNA) that is built by using the DWT method.

4.2 Sensor behavior data structure

The SBDS is created offline to build a reference model (s-DNA) of the normal operations of sensors in a controlled environment.
It contains a matrix of DWT coefficients (explained in Section 4.2.1) and the limits of normal operation (explained in Section
4.3) for each sensor in the system. The main reasons to use a matrix instead of other data structure (eg, heap, hashing, and graph)
are due to the memory constraints in the control, and it is easier to use matrix coefficients than any other data structures when
evaluating the sensor profile at runtime.
The s-DNA is stored in the ABA module to be compared with the runtime data structure. This module performs 3 tasks: (1)
Compute the DWT coefficients from the sensor signal, (2) identify sensor type (sensor discovery) based on the received data,
and (3) build the sensor’s runtime profile that will be compared with the reference s-DNA.

4.2.1 DWT coefficients

The data obtained from the sensor are decomposed using the DWT method, as shown in Equations 1 and 2.28,29 In each level of
the decomposition, the extracted coefficients are used to build the s-DNA data structure that is used by the ABA module.
∑
yhigh [k] = x[n]∗ g[2k − n] (1)
n

∑
y𝑙𝑜𝑤 [k] = x[n]∗ h[2k − n] (2)
n

The original signal x[n] is decomposed into an approximation coefficient yhigh [k] and a detail coefficient ylow [k] by applying a
high-pass g[n] and a low-pass h[n] filter, respectively. The number of samples in the signal follows n = 2i , where i is the number
of levels of decomposition. The DWT can be efficiently computed in a linear time, which is important when dealing with large
datasets. We use Haar wavelet as the function to extract the coefficients because any continuous function can be approximated
with Haar function.29 Once the signal is decomposed, the coefficients of each high-pass filter level are aggregated in a single
vector that is used to build the s-DNA data structure.

4.2.2 Sensor discovery

The next step is to identify the type of sensor based on the received data. The idea is to identify what kind of sensor is providing
data from a certain IP address, meaning that, if there are multiple sensors of the same type sending data, they will be identified by
type (eg, distance sensors). One possible issue is that, if we have different families of the same type of sensor (eg, thermocouple
and integrated circuit temperature sensor), in such a case, we need to identify each family differently as they exhibit different
behavior. To optimize the time for discovery, we divided this task into 2 steps. (1) Use a rule-based classification to obtain at
most 3 possible sensors, which is the worst case scenario based in our experimentation explained in section 5.2. (2) Use the
Euclidean distance (ED) to uniquely identify the sensor type. This is explained in Section 4.2.2.
The rules were created using Weka30 data mining tool. We use raw data sensors to classify them according to the value
variation. Notice that using value variation (or range) will introduce confusion in the rules; however, it is useful to immediately
(ie, less than 1 second) discard a set of sensors (eg, temperature variations that are significantly different from current variations).
Several classifiers were tested, eg, OneR, JRip, PART, and ZeroR. The best results were obtained with JRip, based on the minor
percentage of incorrect classified instances, which was of 7.48%. JRip builds a ruleset by adding rules to an empty ruleset until
the knowledge space is covered. Each rule is built by adding conditions to the antecedent of a rule. After a ruleset is constructed,
it is optimized to reduce its size and improve its fit to the training data (for more detailed description of the JRip algorithm,
please see the work of Weka30 ). We chose rule classification instead of decision tree because if one of the rules failed, then the
other rules do not get affected.
PACHECO AND HARIRI 7 of 15

Once some of the sensors are discarded, the ED Dj in Equation 3 is computed between the runtime vector of coefficients v
and a matrix M (detailed in Section 5.1) of coefficients obtained from all the available sensors during the offline training phase.
√
√ n
√∑ ( )2
Dj = √ Mi,j , − vi (3)
i=1

The smallest distance obtained is used to classify the sensor type. This procedure can be taken as an authentication mechanism
for sensors. Once the sensor type has been identified, the rest of the data is compared with the coefficients in the same column
(j) of the matrix to obtain the ED in runtime.

4.2.3 Sensor’s runtime profile

After discovering the type of sensor and computing the ED, the runtime profile is built as follows: Pruntime = {v, Dj , j}, where
v is the vector of DWT coefficients for the sensor identified by the j-index (that will be described later). v and Dj are updated
at each iteration to provide new values to the ABA module; however, j is kept once the sensor has been discovered to improve
performance (no need to identify the sensor again). The runtime profile is sent to the ABA module to inspect the behavior of
the identified sensor.

4.3 Abnormal behavior analysis

The ED (taken from Pruntime ) is compared with the reference model in the ABA. The reference model is built offline by using
normal measurement attributes (normal ED) for each sensor. Five vectors are used to find the control limits (CLs) for normal
operation. Each vector is compared with the rest having 10 EDs (referred as Euclidean samples [ES]) to build CLs.31 As men-
tioned in the work of Montgomery,31 10 samples are enough to inspect deviation from nominal values in a normal distributed
population. Once all the distances are computed, the mean value (CL) is calculated from the ES. The upper control limit (UCL)
and the lower control limit (LCL) for the normal behavior are calculated using Equations 4 and 5, where x is the mean value, σ
is the standard deviation, and Zα/2 is a sensibility level.

𝑈 𝐶𝐿 = x + Zα∕2 σ (4)

𝐿𝐶𝐿 = x − Zα∕2 σ (5)

The sensitivity level can be chosen depending on the required robustness. It is expected that at least 100(1 − α)% of the ES
falls between the UCL and the LCL; thus, we can choose a value between 0 and 1 for α such that31
( )
P x − Zα∕2 ,σ ≤ Dj ≤ x + Zα∕2 σ = 100 (1 − α) % (6)

For normal CLs, we assume that Zα/2 = 3 (P = 99.73%); this means that the probability of not discovering a deviation from
normal behavior is only 0.27%.31 We can also establish warning upper and lower limits (WUL and WLL, respectively) at Zα/2 = 2.
Figure 3 shows the control chart for the normal behavior of sensors using the ED. Any observation outside the CLs is taken as
an abnormal behavior.

4.4 Classification
Once the ABA module has determined that there is an abnormality in the analyzed sensor data, the classification unit function
is to identify the type of observed abnormality. For this task, Dj is used to detect behaviors and trends. For example, in a DoS
attack, the distance shows sudden changes above the UCL. It is possible to detect a trend before Dj falls out of boundaries or to
detect a mean shift in the data (ED); however, those scenarios will be inspected in future works.
8 of 15 PACHECO AND HARIRI

FIGURE 3 Control chart for normal behavior (temperature sensor)

TABLE 2 Sensor classification (j-index)

j-index Sensor type
1 Temperature
2 Illumination
3 Motion
4 Moisture
5 Distance

4.5 Recovery actions

When an abnormal behavior is detected, several recovery actions can be taken (eg, discard data, de-authenticate the sensor, and
change network configuration). However, there is a possibility that the attack cannot be classified (eg, new attacks); in such
cases, the data are rejected and Pruntime is reset to its nominal values, asking the sensor to re-authenticate itself.

5 EXPERIMENTS AND RESULTS

5.1 Experimental setup

For this experiment, we used 5 IP sensors; the j-index is used to identify each sensor type, as shown in Table 2.
There are 2 phases to implement the ABA methodology: (1) offline to train the system and (2) online to test the ABA-IDS.
In both phases, we use 5 levels of decomposition for DWT; this means that the sensor behavior is inspected every 32 samples
of raw data (Section 5.4 shows how we choose the sample size). However, for rule generation, 500 samples of raw data from
each sensor were used. Sensor’s samples are taken every 10 ms to avoid overhead and to make DWT more stable in the number
of samples taken during a period of time. All the experiments were conducted in the SBT environment. For this specific case,
we used an Arduino UNO as the main controller with a Raspberry PI 3 as the gateway. Arduino is connected to the network
through an Ethernet shield as described in the work of Lee et al.32 One reason to test our approach in the Arduino platform is
due to its low computational capacity (2-KB RAM, 32-KB Flash memory). In this approach, we can show that our technique
works well even in platforms that have limited memory and storage capacity. In what follows, we describe the experiments and
the obtained results for each phase.

5.2 Offline training phase

The first step is to generate the rules for the preselection of sensors. As aforementioned, for this specific task, 500 samples of
raw data are taken to increase accuracy. After each sample is tagged with its corresponding j-index, a database is created with
the values of the 500 samples. This database is inspected by Weka using JRip algorithm to create rules such that each rule
launches a set Sj of at most 3 possible sensors. For example, Sj = {1, 2, 4} means that the candidate sensors are temperature,
illumination, and moisture, respectively. Figure 4 shows examples of the rules generated for temperature, illumination, and
moisture. We used 5 different types of sensors during the experimentation; in the worst case scenario, we obtained 3 possible
PACHECO AND HARIRI 9 of 15

FIGURE 4 An example of the rules used for preclassification

TABLE 3 Correlation matrix for sensors’ data (%)

j-index 1 2 3 4 5
1 100 0 0 0 0
2 0 100 0 0 0
3 0 0 100 0 0
4 0 13 0 73 14
5 0 0 0 0 100

Temperature (Raw Data) DWT Coefficients

10
32
Coefficients Magnitude
9
Temperature (Celcius)

32 8
7
31 6
31 5
4
30
3
30 2
29 1
0
29 -1
0 50 100 150 200 250 0 50 100 150 200 250
Samples Coefficient Number
(A) (B)
FIGURE 5 Temperature sensor. A, raw data and B, DWT coefficients (254 samples)

sensors, and consequently, we choose 3 as a threshold for our system. However, there is a chance that we can obtain only 1
possible candidate, which is the best case scenario.
Analyzing the sensor data, we can observe that there is no strong correlation between them, as shown in Table 3. However,
we can notice that the moisture sensor introduces noise to the system; thus, using rules is not enough to uniquely identify the
sensors.
The next step is to apply DWT to the signal so that we can have a signature for each sensor. Figure 5A shows raw data
for temperature sensor, and Figure 5B shows its DWT coefficients with 8 levels of decomposition. The number of samples is
important to accurately detect some of the attacks; Section 5.3 explains how to choose the number of samples.
A vector of DWT coefficients is generated for each sensor and stored into matrix Mi , j , where j represents the j-index of the
sensor, and i is the DWT coefficient number used to compute Dj .
Once the matrix of coefficients is built and all the EDs are computed (as explained in Section 4.3) for the different sensors
that are used in our experimental evaluation, the limits of normal operation are calculated. Table 4 shows the results of the
offline training for each sensor.
Once the system has been trained for the normal behavior of a given sensor, the next step is to launch attacks against that
sensor to learn its behavior under attacks. The classification of the attacks is based on the trend of the ED (see Figure 6).
Depending on the intensity of the attack, it is possible to detect it before it goes out of the CLs by applying a trend rule. This rule
applies also for unknown attacks since the ED is developed for the normal distribution (verified with the Kolmogorov-Smirnov
test31 ). A window of 7 continuous EDs is used to verify any trend in the behavior. However, for some attacks (eg, DoS), the
7 ESs are not needed since the ED goes out of the CLs rapidly.
10 of 15 PACHECO AND HARIRI

TABLE 4 Sensors’ normal operation limits

j-index CL UCL LCL
1 7.80 11.20 4.30
2 5.19 9.23 1.14
3 3074.95 5717.77 432.13
4 3.15 9.06 0
5 1.90 3.33 0.47

FIGURE 6 Sensor behavior under attacks

5.3 Online testing phase

Once the s-DNA profile is obtained during the offline training phase, the system is tested and evaluated for a wide range of
cyberattacks. Figure 7 shows the comparison between the normal and abnormal behaviors of a temperature sensor under DoS
attack. In Figure 7, each point in the graph needs 32 sensor readings (each point represents a single ES).
All the current popular applied attacks target the availability of data. The applied attacks are replay, delay, DoS, flooding,
sensor impersonation, pulse DoS, and noise injection. In replay attack, the attacker (usually a Man-In-The-Middle) collects
real information in the network to retransmit it later. This gives the opportunity to the attacker to disrupt the communication
between 2 devices without triggering alerts.33 In flooding attack, a stream of packets is sent to fill the memory of the target (end
device). An attacker can reduce the delivery success from 80% to 90% to less than 40% if the attacker targets the shared medium
with 10 times more than the normal traffic intensity.34 In delay attack, the commands from the victim are delayed by sending
continuous stream of packets to the coordinator (controller). The attack manipulates the time interval between 2 consecutive
packets.34 In general, DoS attack aims at blocking a service or a device for a period of time. DoS can start from jamming or
flooding. High-data-rate (more than 200 Mbps) attacks can severely affect the transmission rate in the network, and it may cause
PACHECO AND HARIRI 11 of 15

Normal vs Abnormal Behavior

18

16

Euclidean distance
14

12

10 Normal
Abnormal
8

4
0 20 40 60 80 100
Samples

FIGURE 7 Normal behavior vs abnormal behavior for DoS attack

TABLE 5 Tested attacks

Attack Detection Classification
Rate Rate
Replay Attack 98% 98%
Delay Attack 98% 88%
DoS Attack 99.9% 98%
Flooding Attack 98% 98%
Sensor Impersonation 97.4% 85%
Pulse DoS 96% 93%
Noise Injection 100% 95%

TABLE 6 Detection rate comparison

Attack Detection Detection Rate
Rate (Known Attacks) (Unknown Attacks)
Specification IDS31 98% 80%
Signature IDS28 100% 0%
Secure HAN32 100% 60%
Our ABA-IDS 98% 96%

a complete block of the network devices. For pulse DoS, the attack will be launched for a very short time, but with a very large
number of packets.34 A malicious computational device can claim that it is the sensor by taking the sensor’s IP in the network to
send fake data. This attack is known as sensor impersonation and is one of the most difficult to detect because the computational
device can follow closely the behavior of the real sensor.35 Sensors can be compromised by injecting malicious packets through
the network or by physically manipulating them, thus introducing noise to the system. Noise injection attack is easy to identify
but hard to classify because of the diversity on the sources of noise (eg, network noise and sensor natural failures).36
We have evaluated the performance of our ABA-IDS approach for the aforementioned attacks when they are launched against
all the sensors available in our testbed. Table 5 summarizes the detection and classification accuracy of our approach for each
attack type.
From Table 5, the pulse DoS and noise injection attacks are 2 new attacks that were not used during the offline training phase.
Here, the system detects these attacks and classifies them as “new attack”. There are 2 cases that trigger false positives. The
first case happens when the behavior is not considered in the training phase (eg, a cold object near the temperature sensor). In
the second case, the sensor needs to reach its steady state after an attack. Our experiments show that, at most, 3.2% of these
situations produced false positive alerts.
Table 6 shows that our ABA-IDS has a detection rate better than the compared approaches for unknown attacks, and unlike
signature-based IDS, it is able to detect new attacks.
12 of 15 PACHECO AND HARIRI

Detection Rate vs Levels of Decomposition

100.00
Imperson
80.00

Detection Rate
ation

60.00 DoS

40.00 Noise

20.00 Replay

0.00
3 4 5 6 7 8 9 10
Levels of Decomposition

FIGURE 8 Detection rate per level of decomposition.

5.4 Sample size

Sample size is linked with the number of levels of decomposition in DWT (as explained in Section 4.2.1). It is important to
choose the right number of samples of sensor’s raw data to perform our ABA methodology. For example, if the number of
samples taken is small, attacks like replay might not be detected; on the other hand, if the number of samples is too large, attacks
like sensor impersonation can go unnoticed. Another reason to inspect the sample size is to reduce overhead and false positive
rate. Figure 8 shows the detection rate on each level of decomposition for a representative set of attacks. Notice that level 2 is
not used, and the reason is because 22 = 4 samples are not enough to create a unique signature according to our experiments.
For each level of decomposition, the CLs are computed in normal operation and then the attacks are launched. As shown in
Figure 8, level 5 (25 = 32 samples) offers the best scenario in our experiments, where most of the attacks are detected with more
than 97% accuracy, but for replay attack, the detection rate is 88.75%. The low detection rate for replay is due to the amount
of date information used to launch the attack. For example, if the attacker has enough information to launch a long-term attack
(eg, 1 day of data), then our approach fails to detect the attack; what is required in such a scenario is to perform data analytics
using fog computing. However, we manage to improve the detection rate up to 98% for replay attack by using moving target
defense (MTD) mechanism.
It is important to mention that, because of memory constraints in our experiments (2-KB RAM), the levels of decomposition
together with the type of attack have big impacts on the detection rate. As shown in Figure 8, after level 7, the detection rate
drops dramatically; for example, noise attack shows 100% detection rate for level 7 and drops to 0% in level 8. To avoid this
problem, we can use controllers with high memory. However, we are showing that our approach works for low computational
power devices and it can be applied to sensors. For impersonation and DoS attacks, the detection rate can be improved for levels
6 and 7 by using two-sigma limits; however, this will introduce more false positive alerts and we will still face memory issues for
levels 8 to 10. Therefore, it is not effective to use shorter limits, and hence, it is better to characterize the behavior of the system.
For different levels of decomposition, different CLs are used. This can introduce false positives, meaning that an abnormal
behavior is detected (ED outside the CLs) when the behavior is normal. Figure 9 shows the false positive rate introduced by
each level of decomposition. For this experiment, only normal data were inspected (no attacks were launched), and 1000 EDs
were computed to verify how many of them fall outside the CLs. Figure 9 shows that level 5 gives the best results with 0.4% of
false positives; meanwhile, level 10 is the worst giving up to 2.1% of false positives.
Another parameter to take into consideration when selecting the sample size is the overhead. Any operation on the data
will require extra amount of time, which adds overhead to the process. Our approach requires 2 basic operations, ie, the DWT

False Positives vs Level of Decomposition

2.50
% False Positives

2.00

1.50

1.00

0.50

0.00
3 4 5 6 7 8 9 10
Levels of Decomposition

FIGURE 9 False positives per level of decomposition

PACHECO AND HARIRI 13 of 15

Overhead vs Level of Decomposition

8.0
7.0

% Overhead
6.0
5.0
4.0
3.0
2.0
3 4 5 6 7 8 9 10
Levels of Decomposition

FIGURE 10 Overhead per level of decomposition

coefficient extraction and the ED computation, each one requiring certain amount of time depending on the volume of data
being processed. Figure 10 shows that levels 6 and 7 give the best results (less overhead), with less than 3% in time overhead.
Figures 8 and 9 show level 5 as the best option in detection rate and false positives. Figure 10 shows that level 5 gives more
overhead (3%) compared with levels 6 (2.4%) and 7 (2.8%). However, taking into consideration the detection and false positive
rates, level 5 is the best option, meaning that the system will use 32 samples of raw data to perform the ABA.
Figure 10 shows another effect of memory constraints. For levels below 6, the system needs to perform several inspections
and the whole process takes more time; for example, level 3 performs 2 inspections to reach the analysis capability of level 4.
On the other hand, from level 7, the memory usage represents a problem for the system as it needs to allocate the incoming
data and perform the operations over this data. As we can see, the overhead jumps after level 7, which is consistent with the
detection rate behavior in Figure 8.

5.4.1 MTD to improve detection rate

Some attacks require gathering information to later use this information and launch the attack. For example, the success of replay
attack heavily depends on the amount of information collected. Hence, by changing at least 1 parameter in the communication
(eg, communication medium), the amount of information collected is not enough to launch a successful attack.
Taking into consideration the sample size, the best option would be to shift the communication medium (eg, from Wi-Fi to
Ethernet) every 64 samples; this will give 100% detection rate. However, this shifting rate will introduce more overhead to the
system. By sacrificing 2% of detection rate, we can shift the communication medium every 512 samples, avoiding overhead
(less than 1%) and, at the same time, having an acceptable detection rate (up to 98%). The mechanism to apply MTD is out of
the scope of this work. However, we followed the methodology proposed in the work of Mac Farland and Shue.37

5.5 Recovery actions

Once the attack is detected and classified, the needed actions to solve the problem are taken. Table 7 shows the results of our eval-
uation of the ability of the s-DNA to detect a wide range of attacks and the potential actions that can be taken. As shown, many of
the actions include the use of our s-DNA as a credential. This enables us to use our approach as an authentication-authorization
mechanism, adding resiliency to the entire IoT infrastructure.

TABLE 7 Recovery actions

Attack Recovery Actions
Replay Attack Sensor authentication by using s-DNA as credential. The sensor data is rejected.
Delay Attack Dynamically change the network’s configuration to avoid malicious packets.
Denial of Service (DoS) Attack The network configuration is changed to avoid the attack.
Flooding Attack Dynamically change the hardware configuration to tolerate this attack.
Sensor Impersonation Attack Sensor authentication by using s-DNA as credential. The impersonated sensor data are discarded.
14 of 15 PACHECO AND HARIRI

6 CONCLUSIONS AND FUTURE WORK

In this paper, we presented an IoT security framework for SIs that consists of 4 layers: devices (end nodes), network, service,
and application layers. We also presented a methodology to develop a threat model that can be used to identify potential attacks
against each layer, their impacts, and how to mitigate and recover from these attacks.
In our experimental results, we showed how to use the threat model to secure and protect sensors in smart IoT infrastructure.
Our anomaly behavior analysis methodology includes the use of an s-DNA profile that is developed to accurately characterize
normal sensor operations. We showed that our s-DNA data structure can be used as an authentication mechanism for IoT sensors.
We have also shown that the ABA-IDS approach can detect both known and unknown attacks with high detection rates and
low false positive alarms (less than 0.5%). We have also developed an attack classification methodology with 98% accuracy for
known attacks and up to 97.4% accuracy for unknown attacks (classified as “new attacks”).
It is important to emphasize that our methodology is intended to protect the normal operation of end nodes where the number
of sensor is limited (eg, in a single room) and, before an attack, can affect other systems as we showed in the attack surface.
However, for large amount of sensors (eg, SBs), where data association techniques are required, we need to test our approach
in upper layers (eg, in the service layer with fog computing). In such case, other factors such as behavioral drift may affect the
outcome of our ABA-IDS module.
We are currently investigating techniques for detecting attacks by analyzing the behavior of other layers. For example, if an
attacker collects enough sensors’ information (eg, 1 day of information), it can launch a replay attack without the need of using
the same dataset. We are working on several solutions for such kind of attacks, including: (1) big data analytics to search for
patterns in the stored data and (2) applied MTD strategy that will make it extremely difficult for an attacker to collect relevant
data because they will not be relevant in the future because of the continuous random change in the configuration.

ACKNOWLEDGEMENTS
This work was partly supported by the Air Force Office of Scientific Research Dynamic Data-Driven Application Sys-
tems (award FA95550-12-1-0241), the National Science Foundation (research projects NSF 1624668, SES-1314631, and
DUE-1303362), and Thomson Reuters in the framework of the Partner University Fund project (a program of the French
Embassy in the United States and the FACE Foundation and is supported by American donors and the French Government).

REFERENCES
1. Verizon. Create intelligent, more meaningful business connections. http://www.verizonenterprise.com/solutions/connected-machines/. Accessed
June 2016.
2. Zanella A, Bui N, Castellani A, Vangelista L, Zorzi M. Internet of Things for Smart Cities. IEEE IoT Journal. 2014;1(1):22-32.
3. Pacheco J, Hariri S. IoT security framework for smart cyber infrastructures. Paper presented at: IEEE 1st International Workshops on Foundations
and Applications of Self* Systems (FAS*W); 2016; Augsburg, Germany.
4. Kushner D. The Real Story of Stuxnet: How Kaspersky Lab tracked down the malware that stymied Iran’s nuclear-fuel enrichment program.
IEEE Spectr. 2013;50(3):48-53.
5. Legezo D. How to trick traffic sensors. Kaspersky Lab. https://securelist.com/blog/research/74454/how-to-trick-traffic-sensors/. Accessed
April 2016.
6. Takahashi D, Xiao Y, Hu F. A survey of security in telemedicine with wireless sensor networks. In: Xiao Y, Chen H, eds. Mobile Telemedicine:
A Computing and Networking Perspective. Boca Raton, Florida, United States: CRC Press; 2008:209-235.
7. Wang Z, Wang L, Dounis A, Yang R. Multi-agent control system with information fusion based comfort model for smart buildings. Appl Energy.
2012;99:247-254.
8. Mehta A, Tärneberg W, Klein C, Tordsson J, Kihl M, Elmroth E. How beneficial are intermediate layer data centers in mobile edge networks?
Paper presented at: IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS*W); 2016; Augsburg, Germany.
9. Orsini G, Bade D, Lamersdorf W. CloudAware: A context-adaptive middleware for mobile edge and cloud computing applications. Paper
presented at: IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS*W); 2016; Augsburg, Germany.
10. Hegyi A, Flinck H, Ketyko I, Kuure P, Nemes C, Pinter L. Application orchestration in mobile edge cloud: Placing of IoT applications to the edge.
Paper presented at: IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS*W); 2016; Augsburg, Germany.
11. Garcia-Perez C, Merino P. Enabling low latency services on LTE networks. Paper presented at: IEEE 1st International Workshops on Foundations
and Applications of Self* Systems (FAS*W); 2016; Augsburg, Germany.
12. Yaseen Q, AlBalas F, Jararweh Y and Al-Ayyoub M. A fog computing based system for selective forwarding detection in mobile wireless sensor
networks. Paper presented at: IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS*W); 2016; Augsburg,
Germany.
PACHECO AND HARIRI 15 of 15

13. Suo H, Wan J, Zou C, Liu J. Security in the Internet of Things: A review. Paper presented at: International Conference on Computer Science and
Electronics Engineering (ICCSEE); 2012; Hangzhou, China.
14. Brito MSD, Hoque S, Steinke R, Willner A. Towards programmable fog nodes in smart factories. Paper presented at: 2016 IEEE 1st International
Workshops on Foundations and Applications of Self* Systems (FAS*W); 2016; Augsburg, Germany.
15. Ding C, Yang LJ, Wu M. Security architecture and key technologies for IoT/CPS. ZTE Technology Journal. 2011;17(1):11-16.
16. Can O, Sahingoz OK. A survey of intrusion detection systems in wireless sensor networks. Paper presented at: 6th IEEE International Conference
on Modeling, Simulation, and Applied Optimization (ICMSAO); 2015; Istanbul, Turkey.
17. Fayssal S, Hariri S, Al-Nashif Y. Anomaly-based behavior analysis of wireless network security. Paper presented at: 2007 Fourth Annual
International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous); 2007; Philadelphia, USA.
18. Xu D, Tu M, Sanford M, Thomas L, Woodraska D, Xu W. Automated security test generation with formal threat models. IEEE Trans Dependable
Secure Comput. 2012;9(4):526-540.
19. Schlegel R, Obermeier S, Schneider J. Structured system threat modeling and mitigation analysis for industrial automation systems. Paper
presented at: IEEE 13th International Conference on Industrial Informatics (INDIN); 2015; Cambridge, United Kingdom.
20. Jin J, Gubbi J, Marusic S, Palaniswami M. An information framework for creating a smart city through internet of things. IEEE Internet of Things
J. 2014;1(2):112-121.
21. Ferreira HGC, Canedo ED, de Sousa Junior RT. IoT architecture to enable intercommunication through REST API and UPnP using IP, ZigBee
and Arduino. Paper presented at: 2013 IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications
(WiMob); 2013; Lyon, France.
22. Soliman M, Abiodun T, Hamouda T, Zhou1 J, Lung C. Smart home: Integrating Internet of Things with web services and cloud computing.
Paper presented at: IEEE 5th International Conference on Cloud Computing Technology and Science; 2013; Bristol, United Kingdom.
23. Manadhata PK, Wing JM. An Attack Surface Metric. IEEE Trans Software Eng. 2011;37(3):371-386.
24. Hossain M, Fotouhi M, Hasan R. Towards an analysis of security issues, challenges, and open problems in the Internet of Things. Paper presented
at: IEEE World Congress on Services; 2015; New York, USA.
25. Pacheco J, Tunc C, Hariri S. Design and evaluation of resilient infrastructures systems for smart cities. Paper presented at: 2016 IEEE International
Smart Cities Conference (ISC2); 2016; Trento, Italy.
26. Hoque N, Bhuyan M, Charan Baishya R, Bhattacharyya DK, Kalita JK. Network attacks: taxonomy, tools and systems. J Netw Comput Appl.
2014;40:307-324.
27. Mishra C. Mastering Wireshark. Birmingham, UK: Packt Publishing Ltd; 2016.
28. Mallat S. A Wavelet Tour of Signal Processing, Third Edition: The Sparse Way. 3rd ed. Amsterdam, Netherlands: Academic Press; 2008.
29. Kozionov A, Kalinkin M, Natekin A, Loginov A. Wavelet-based sensor validation: Differentiating abrupt sensor faults from system dynamics.
Paper presented at: IEEE 7th International Symposium on Intelligent Signal Processing (WISP); 2011; Floriana, Malta.
30. Weka. http://weka.sourceforge.net/doc.dev/weka/classifiers/rules/JRip.html. Accessed June 2016.
31. Montgomery DC. Statistical Quality Control. 7th ed. Chichester: John Wiley & Sons; 2012.
32. Lee S, Jo J, Kim Y, Stephen H. A framework for environmental monitoring with Arduino-based sensors using Restful web service. Paper presented
at: 2014 IEEE International Conference on Services Computing (SCC); 2014; Anchorage, Alaska.
33. Hoehn A, Zhang P. Detection of replay attacks in cyber-physical systems. Paper presented at: American Control Conference (ACC); 2016;
Boston, MA.
34. Namboodiri V, Aravinthan V, Mohapatra S, Karimi B, Jewell W. Toward a secure wireless-based home area network for metering in smart grids.
IEEE Syst J. 2013;8(2):1-12. https://doi.org/10.1109/JSYST.2013.2260700
35. Tanabe N, Kohno E, Kakuda Y. A path authenticating method using bloom filters against impersonation attacks on relaying nodes for wireless
sensor networks. Paper presented at: 2013 IEEE 33rd International Conference on Distributed Computing Systems Workshops; July 8, 2013;
Philadelphia, Pennsylvania, USA.
36. Illiano VP, Lupu E. Detecting malicious data injections in wireless sensor networks: a survey. ACM Comput Surv (CSUR). 2015;48(2):
Article No. 24.
37. Mac Farland DC, Shue CA. The SDN shuffle: creating a moving-target defense using host-based software-defined networking. Paper presented
at: Proceedings of the Second ACM Workshop on Moving Target Defense; October 12, 2015; Denver, Colorado, USA.

How to cite this article: Pacheco J, Hariri S. Anomaly behavior analysis for IoT sensors. Trans Emerging Tel Tech.
2018;29:e3188. https://doi.org/10.1002/ett.3188