This document presents a framework for developing context-aware security solutions to detect malicious traffic in IoT healthcare environments. The framework includes an open-source IoT traffic generator called IoT-Flock that can generate both normal and malicious IoT traffic using MQTT and CoAP protocols. The framework was used to generate an IoT healthcare dataset by modeling an ICU and capturing traffic from normal and attacking devices. Machine learning techniques were then applied to the dataset to demonstrate how the framework can be used to develop AI-based cybersecurity solutions for healthcare IoT systems.
Russian Escorts Delhi | 9711199171 | all area service available
A Framework for Detecting Malicious Traffic in IoT Healthcare
1. Article
A Framework for Malicious Traffic Detection in IoT
Healthcare Environment
Faisal Hussain* 1, , Syed Ghazanfar Abbas 1, Ghalib A. Shah 1, Ivan Miguel Pires* 2,3,4 ,
Farrukh Shahzad 1,, Ubaid U. Fayyaz 1 , Nuno M. Garcia 2 , and Eftim Zdravevski 5
1 Al-Khwarizmi Institute of Computer Science (KICS), University of Engineering & Technology (UET), Lahore
54890, Pakistan; {ghazanfar.abbas, ghalib, farrukh.shahzad, ubaid.fayyaz}@kics.edu.pk
2 Instituto de Telecomunicações, Universidade da Beira Interior, 6200-001 Covilhã, Portugal; impires@it.ubi.pt
and ngarcia@di.ubi.pt
3 Computer Science Department, Polytechnic Institute of Viseu, 3504-510 Viseu, Portugal
4 UICISA:E Research Centre, School of Health, Polytechnic Institute of Viseu, 3504-510 Viseu, Portugal
5 Faculty of Computer Science and Engineering, University Ss Cyril and Methodius, 1000 Skopje, Macedonia;
eftim.zdravevski@finki.ukim.mk
* Correspondence: Faisal Hussain (E-mail: faisal.hussain.engr@gmail.com), Ivan Miguel Pires (E-mail:
impires@it.ubi.pt)
Version April 1, 2021 submitted to Sensors
Abstract: Internet of things (IoT) has emerged as a topic of intense interest among the research and
1
industrial community since it created revolutionary impact on human life. The rapid growth of
2
IoT technology has revolutionized the human life by inaugurating the concept of smart devices,
3
smart healthcare, smart industry, smart city, smart grid, etc. The security of IoT devices has become
4
a serious concern nowadays, especially for the healthcare domain where recent attacks exposed
5
damaging vulnerabilities in IoT security. Traditional network security solutions are well established
6
but due to the resource constraint property of IoT devices and distinct behaviour of IoT protocols, the
7
existing security mechanisms cannot be deployed directly for securing the IoT devices and network
8
from the cyber-attacks. To enhance the level of security for IoT, researchers need IoT specific tools,
9
methods and datasets. To address mentioned problem, we provide a framework for developing
10
the IoT context aware security solutions to detect malicious traffic in IoT use cases. The proposed
11
framework consists of newly created, open-source IoT data generator tool, named IoT-Flock. The
12
IoT-Flock tool allows researchers to create an IoT usecase comprised of both normal and malicious
13
IoT devices and also generate traffic for them. Additionally, the proposed framework provides an
14
open-source utility for converting the captured traffic generated by IoT-Flock into IoT dataset. In
15
this research, using the proposed framework, we first generated an IoT healthcare dataset which
16
comprised of both normal and IoT attack traffic. Afterwards, over the generated dataset, we applied
17
different machine learning techniques to detect the cyber-attacks in order to secure and protect the
18
healthcare system from cyber-attacks. The proposed framework will help in developing the context
19
aware IoT security solutions, especially for sensitive use case like IoT healthcare environment.
20
Keywords: Internet of Things (IoT); IoT Healthcare Systems; Healthcare Monitoring; Machine
21
Learning; Securing Healthcare Systems; IoT Healthcare Dataset; IoT Traffic Generator; IoT Flock;
22
Healthcare Security; Intrusion Detection
23
1. Introduction
24
The Internet of things (IoT) refers to real-world objects having communicative and cognitive
25
capability using smart devices. IoT is a tremendous communication paradigm where the plethora of
26
heterogeneous devices will be connected and talking to each other. These communication devices will
27
Submitted to Sensors, pages 1 – 19 www.mdpi.com/journal/sensors
2. Version April 1, 2021 submitted to Sensors 2 of 19
play an important role in the life of human being. IoT is creating a revolutionary impact in the world
28
of technology and the social life of people. With the passage of time, IoT devices are growing rapidly.
29
According to statistics, the number of IoT devices connected worldwide was 23.14 billion in 2018 [1].
30
And it is estimated that by 2025 there will be 75.44 billion IoT connected worldwide [1]. The footprints
31
of IoT have been identified in various domains such as manufacturing, agriculture, transportation,
32
electric grid, healthcare etc. [2,3]. In an IoT-based healthcare system, security is the major concern as
33
the data is directly related to human beings. An intensive care unit (ICU) is a special and critically
34
operational department of a hospital where the specialized treatment is given to the patients which
35
require critical medical care. Usually, the patients which are acutely unwell or injured severely and
36
require continuous medical care are admitted to the ICU. The equipment and devices concerned to the
37
ICU play a vital role in keeping the patient alive and healthy. In such a scenario, any communication
38
breakdown due to cyber security breach may cause severe effects on a patient’s life and even death in
39
certain cases. So, an attack-proof IoT-based healthcare system is a primary need of the hour. Hence,
40
providing an IoT-based healthcare system with secure and robust data communication among medical
41
sensors and actuators is obligatory.
42
So far, a lot of work has been done to automate the patients monitoring and assisting the medical
43
professional to remotely asses the patient’s health status [4–8]. However, the cyber-attacks on IoT
44
healthcare systems have become the primary focus of the intruders [9]. It is reported that more than
45
90% of the healthcare systems have been the victim of the cyber-attacks [10]. In 2017, White House
46
intelligence reported that the healthcare sector has become attractive for the cyber-criminals [11]. And
47
during the COVID-19 era, the cyber-attacks are exponentially surging across the with the spread
48
of COVID-19 [12]. The cyber-criminals have now started targeting the IoT healthcare services and
49
systems actively [12,13]. Any change in the patient’s medical record may lead to accidental death if
50
unnoticed by the medical professional [9]. Furthermore, the cyber-attacks on IoT healthcare systems
51
can cause critical disruption in the medical treatments [9,13]. For example, if a hacker gains the access
52
of an infusion pump, and the hacker changes the configuration of the infusion pump in such a way
53
that it starts releasing a large amount of insulin to a patient then it may cause a severe hypoglycemia
54
[10]. Similarly, if a cyber-criminal gains the access of a pacemaker and either slows down the heart rate
55
or speed up the heart rate then severe bradycardia or tachycardia may happen to the patient instantly
56
thus ultimately lead to death [10]. Henceforth, the security of healthcare systems has become the most
57
significant concern of this age.
58
The IoT devices are resource constraint because of the limited amount of memory, computational
59
capacity and power [14]. Therefore, it is very challenging to design a security mechanism for IoT
60
devices. The manufacturing industries are producing a huge amount of IoT products with the goal
61
of creating low-cost IoT devices in a short span of time [3,15]. Due to the race to the market for
62
capturing the market as earlier as possible, the manufacturers are giving less importance to the device
63
security [3]. Moreover, the IoT device manufacturers also create back doors in their devices to access
64
the device remotely or using that device for their malicious intent. Most of the consumer-deployed
65
IoT devices are connected to the network without any security defence line [16]. Hence, IoT devices
66
can be compromised easily. Therefore, security of the IoT devices has become an important concern
67
nowadays.
68
The traditional security mechanisms are deployed at two levels, i.e., network level or host level.
69
In the existing internet era, host-level security approach is considered more secure as compared to the
70
network level security approach [14]. Since the IoT devices are low powered and resource constrained,
71
so the host level security mechanisms cannot be deployed on them. Therefore, the network-based
72
security mechanism is preferable for IoT devices as compared to the host-based security system [14,16].
73
Among the existing security mechanisms, an intrusion detection system (IDS) is a compulsory line
74
of defence. An IDS is responsible for identifying malicious activities in the network. The IDS is also
75
classified into network-based and host-based IDS. The network-based IDS scrutinizes network events
76
while the host-based IDS scrutinizes host events. To protect the IoT networks and network from
77
3. Version April 1, 2021 submitted to Sensors 3 of 19
cyber-attacks, the network-based IDS needs to be trained in IoT perspective. The IDS are trained
78
either on live traffic or on a recorded network traffic dataset. The IDS training on live traffic is an
79
expensive and time taking procedure. However, the training of IDS on an appropriate network traffic
80
dataset is a fast and low-cost procedure. Thus, having an appropriate IoT dataset for the training and
81
testing of the IDS is a crucial need. Although, the existing IDS technology is well entrenched, however,
82
it is inadequate for the IoT devices and network [17,18] due to the limited processing and storage
83
capacity. Moreover, the commonly used IoT protocols like MQTT, CoAP, etc., are not supported by the
84
traditional IDS solutions. Therefore, it the need of the hour, to develop IoT-supported IDS.
85
The IoT devices are resource constraint because of the limited amount of memory, computational
86
capacity and power [14]. Therefore, it is very challenging to design a security mechanism for IoT
87
devices. The manufacturing industries are producing a huge amount of IoT products with the goal
88
of creating low-cost IoT devices in a short span of time [3,15]. Due to the race to the market for
89
capturing the market as earlier as possible, the manufacturers are giving less importance to the device
90
security [3]. Moreover, the IoT device manufacturers also create back doors in their devices to access
91
the device remotely or using that device for their malicious intent. Most of the consumer-deployed
92
IoT devices are connected to the network without any security defence line [16]. Hence, IoT devices
93
can be compromised easily. Therefore, security of the IoT devices has become an important concern
94
nowadays.
95
The traditional security mechanisms are deployed at two levels, i.e., network level or host level.
96
In the existing internet era, host-level security approach is considered more secure as compared to the
97
network level security approach [14]. Since the IoT devices are low powered and resource constrained,
98
so the host level security mechanisms cannot be deployed on them. Therefore, the network-based
99
security mechanism is preferable for IoT devices as compared to the host-based security system [14,16].
100
Among the existing security mechanisms, an intrusion detection system (IDS) is a compulsory line
101
of defence. An IDS is responsible for identifying malicious activities in the network. The IDS is also
102
classified into network-based and host-based IDS. The network-based IDS scrutinizes network events
103
while the host-based IDS scrutinizes host events. To protect the IoT networks and network from
104
cyber-attacks, the network-based IDS needs to be trained in IoT perspective. The IDS are trained
105
either on live traffic or on a recorded network traffic dataset. The IDS training on live traffic is an
106
expensive and time taking procedure. However, the training of IDS on an appropriate network traffic
107
dataset is a fast and low-cost procedure. Thus, having an appropriate IoT dataset for the training and
108
testing of the IDS is a crucial need. Although, the existing IDS technology is well entrenched, however,
109
it is inadequate for the IoT devices and network [17,18] due to the limited processing and storage
110
capacity. Moreover, the commonly used IoT protocols like MQTT, CoAP, etc., are not supported by the
111
traditional IDS solutions. Therefore, it the need of the hour, to develop IoT-supported IDS.
112
In order to enhance the level of security for IoT devices and networks, the researchers need IoT
113
specific tools, methods and datasets. The training and testing of IDS require an efficient IoT traffic
114
dataset which contains both normal and malicious IoT traffic. Only a few researchers are working
115
to produce a suitable IoT dataset for the testing and evaluation of the IoT-supported IDS. In order to
116
efficiently develop the IoT context aware security solutions, in this work, we propose a framework
117
for developing the IoT context aware security solutions to detect malicious traffic in IoT healthcare
118
environment. The proposed framework consists of newly created, open-source IoT data generator tool,
119
named IoT-Flock for generating IoT use case specific traffic. Additionally, the proposed framework
120
provides an open-source utility for converting the captured traffic generated by IoT-Flock into IoT
121
dataset. Finally, by applying different machine learning techniques over the generated IoT dataset,
122
we demonstrate how the the proposed framework can be used to develop an AI-based cyber-security
123
solution in order to secure and protect the healthcare system from cyber-attacks. The proposed
124
framework will help in developing the context aware IoT security solutions, especially for sensitive
125
healthcare environment.
126
4. Version April 1, 2021 submitted to Sensors 4 of 19
1.1. Research Contributions
127
The main contributions of this research work are as following:
128
• This paper presents a framework for developing the IoT context aware security solutions to
129
detect malicious traffic in IoT use cases, especially for the IoT healthcare environment. The
130
proposed framework consists of an open-source IoT traffic generator tool and an IoT use case
131
specific dataset to ease the research community.
132
• To the best of our knowledge, it is for the first time that an open-source IoT traffic generator tool
133
is introduced which is capable of generating both the normal and malicious IoT traffic based
134
on two IoT application layer protocols, i.e., Message Queuing Telemetry Transport (MQTT)
135
and Constrained Application Protocol (CoAP). So far, no IoT traffic generator tool is capable of
136
generating malicious IoT traffic.
137
• We used the IoT traffic generator tool to create an attacking network and normal network of IoT
138
devices for generating the traffic and capturing the packets along with complete payload for the
139
dataset.
140
• We designed a real-life ICU use case in IoT traffic generator tool and created the data profiles
141
and time profiles of the devices used in ICU by analyzing real-time value ranges for generating
142
the real-time IoT traffic.
143
• In order to generate a widespread and reliable IoT traffic dataset for the training and testing
144
of IoT-supported IDS, we not merely extracted the network layer features but also introduced
145
such an extensive set of application layer features and payload features which has not been done
146
before in IoT perspective.
147
• Finally, we demonstrated the applicability of the proposed framework and the generated dataset
148
for developing the IoT context aware security solutions using six commonly used machine
149
learning algorithms.
150
The rest of the paper is structured as follows: Section II presents the literature review of existing
151
IDS datasets. Section III describes the framework proposed for developing the IoT context aware
152
security solutions along with a detailed overview of our IoT traffic generator tool, IoT healthcare
153
use case conceived for generating the dataset, traffic generation scenario, data capturing procedure
154
used for recording the generated traffic, the features of dataset. We discussed the results of the
155
proposed framework in Section IV. ends with the analysis of generated dataset using machine learning
156
techniques. Lastly, Section V concludes the paper.
157
2. Literature Review
158
The rapid growth of IoT technology has revolutionized the many areas of life by familiarizing
159
the concept of smart cities, smart health, smart wearables, smart industries, smart agriculture etc.
160
IoT-based health monitoring systems are becoming smarter day by day. In recent years, various
161
IoT-based smart health monitoring systems have been proposed. However, IoT still endures infancy
162
in the security of healthcare systems. The conventional network security solutions cannot be used
163
for IoT-based healthcare systems due to the resource constraint property of IoT devices and different
164
security level requirements. So there is a strong need for obstructing the malicious activity from
165
accessing the network of resource-constrained IoT-based medical devices.
166
In the current era, security is the major concern of IoT. Firewalls, IDS and intrusion prevention
167
system (IPS) are the major security shields to protect the devices and network from the cyberattacks.
168
Most of the firewalls filter the normal and suspicious traffic based upon the static defined rules.
169
However, IDS and IPS filter the intrusive attempts using artificial intelligence (AI) techniques which
170
are more reliable and effective as compared to the static predefined rules. The IDS and IPS are trained
171
and tested using malicious and benign network traffic datasets. These datasets are collected by two
172
approaches, i.e. either by using real systems to generate suspicious and normal network traffic or by
173
5. Version April 1, 2021 submitted to Sensors 5 of 19
using the traffic generators i.e. traffic generators which are the tools that mimic the real-time network
174
traffic.
175
The training and testing of the IDS and IPS using the network traffic dataset generated by real-time
176
systems is a very difficult job and also costly. However, this dilemma can be untangled by generating
177
the dataset through a traffic generator tool. No matter, the present IDS technology is quite mature but
178
these are inadequate for IoT Systems [17] [18]. The main reason behind this is the limited processing
179
and storage capacity of the IoT nodes which is the main challenge for host IDS. Another crucial factor
180
is the communication protocols (like CoAP, MQTT etc.) which IoT devices use, are not employed
181
in the traditional network as different protocols carry different vulnerabilities and demands for IDS
182
[18]. In order to address this issue, the main focus of this work is to generate a vast and reliable IoT
183
network traffic dataset for the development of IDS specifically for the IoT-based ICU environment as
184
any security breach in such a scenario either may cause a severe effect on the patient or even death in
185
certain cases. The following sections provide a brief analysis of the existing state-of-the-art datasets
186
which are used for the training and testing of IDS for the conventional network and IoT network.
187
2.1. State-of-the-Art Datasets
188
The network traffic datasets that are proposed during the past few years are being used widely
189
until this age. Some of them are realistic datasets i.e. generated using the real-time systems while some
190
are simulated datasets i.e. generated through simulation tool. Some of the state-of-the-art datasets are:
191
DARPA [19], KDD-99 [20], NSL-KDD [21], DEFCON [22], LBNL [23], CAIDA [24], UNIBS [25] , ISCX
192
[26], and UNSW-NB15 [27].
193
DARPA [19] is the pioneer dataset proposed in 1998 at MIT Lincoln Laboratory. This dataset was
194
developed for the assessment of IDS and contains recorded data of seven weeks. It contains the data
195
of emails, FTP, Telnet, IRC, and SNMP related events. Different types of attacks like denial of service
196
(DoS) attack, remote to local (R2L) attacks and user to remote (U2R) attacks simulated using Windows,
197
UNIX platforms. However, this dataset does not contain real-time traffic and has some irregularities
198
like the absence of false positives [28].
199
KDD-99 [20] dataset was produced using DARPA [19] in order to inspect the IDS designed
200
specifically for detecting the inbound attacks. It contains DoS attacks like pod-DoS, smurf-DoS,
201
Neptune-DoS, and buffer overflow attacks. This dataset had a major problem of imbalanced learning
202
as it consists of 80% attack traffic. Later on, NSL-KDD [21] was generated to fix the problems of
203
KDD-99 [20]. But it is also outdated as it doesn’t the current normal and attack events.
204
The DEFCON [22] dataset has two versions i.e. DEFCON-8 and DEFCON-10 were recorded in
205
2000 and 2002 respectively during a capture flag (hacking and anti-hacking) competition. DEFCON-8
206
includes the port scanning attacks and buffer overflow attacks while DEFCON-10 includes attacks
207
related to port scan, malicious packets, and FTP attacks.
208
LBNL [23] dataset was produced by gathering the inbound, outbound and routing traffic of two
209
edge routers in 2004. It was collected at a medium-sized site, contains full header files only. It suffers
210
from heavy anonymization.
211
CAIDA [24] dataset contains only traffic header without the payload and collected from the
212
internet backbone of a large scale enterprise. It includes specific attacks such as DDoS attack. The
213
recorded dataset was not further processed to generate new features that could improve the distinction
214
between normal and malicious traffic. Moreover, it is unlabeled, so not useful for the direct performance
215
assessment of IDS. As it needs the preprocessing for labelling.
216
UNIBS [25] dataset was captured through tcpdump of the router with the traffic flow of twenty
217
workstations. Only the DoS attack was focused. ISCX [26] was produced using real network
218
configurations in 2012. A group of people was involved to simulate real network traffic. It is a
219
labelled dataset with different attack scenarios. It contains two profiles i.e. Alpha-profile carried out at
220
multi-stage attack scenarios and Beta-profile carried out normal traffic. It contains full packet payloads
221
of different protocols like HTTP, FTP, SMTP etc. However, it doesn’t contain the HTTPS which is the
222
6. Version April 1, 2021 submitted to Sensors 6 of 19
70% of current age traffic [3]. UNSWNB-15 [27] dataset was collected by generating the IXIA storm to
223
generate malicious and normal traffic in a commercial penetration testing environment.
224
Bot-IoT [29] is a dataset which contains the simulated IoT network traffic and along with different
225
types of attacks.To our best knowledge, it’s the only one publically available IoT dataset which
226
contains both normal and malicious traffic. Bot-IoT [29] dataset includes the IoT traffic generated
227
by the normal and attacking virtual machines for the five IoT scenarios provoked with three types
228
of attacks i.e. probing attacks, DoS attacks, and information theft attacks. Although Bot-IoT [29]
229
dataset contains approx. 72 billion instances but only one IoT specific protocol is considered i.e. MQTT.
230
While in our developed ICANT [?] dataset, two major IoT application layer protocols i.e. MQTT
231
and CoAP are generated. Moreover, it contains the IoT real-time generated traffic and a variety of
232
attacks. Furthermore, we not only extracted the network layer features but also introduced such an
233
extensive set of application layer features and payload features which has not been done before in IoT
234
perspective.
235
3. Proposed Framework
236
From the IoT use case traffic generation to the development of context-aware IoT security solution
237
for malicious traffic detection in IoT healthcare use case, the proposed framework consist of five major
238
stages as illustrated in Figure 1. These modules include use case setup, IoT normal and attack traffic
239
generation, IoT traffic capturing, IoT dataset creation, and machine learning (ML) model development.
240
The proposed framework starts from designing IoT use case and then execute the use case to
241
generate real-time IoT traffic. The generated traffic is then captured to create IoT dataset for training
242
the ML models. Finally, ML models are trained and tested by applying different ML techniques to
243
efficiently detect the malicious network traffic in the underlying IoT use case.
244
Use Case Setup
Using IoT Flock
XML
IoT Traffic
Generation
Using IoT Flock
Traffic
Capturing Using
Wireshark
IoT Dataset
Creation
Machine Learning
for Classifying IoT
Normal & Attack
Traffic
Output
Detection Accuracy.
Sensitivity.
Specificity.
NORMAL & IOT
ATTACK TRAFFIC
CSV
PCAP
Figure 1. Framework for research in IoT health care security.
3.1. IoT Use Case Generator
245
IoT use case generator is the first module of the proposed framework which consist of our recently
246
developed, open-source IoT traffic generator tool, i.e., IoT-Flock [14]. The IoT-Flock tool [14] can
247
generate both the normal and attack traffic of IoT-based devices in any use case. With the IoT-Flock,
248
one can easily create IoT use cases according to his/her needs and generate IoT traffic for different use
249
cases with the capability of generating the traffic for hundreds of IoT device in a real-time live network
250
by using a single physical machine. The basic architecture of the IoT-Flock is shown in Figure 2.
251
The IoT-Flock [14] tool has the following distinct features as compared to the other commercially
252
or publicly available traffic generator tools:
253
7. Version April 1, 2021 submitted to Sensors 7 of 19
FRONT END FUNCTIONALITIES
IOT APPLICATION LAYER PROTOCOLS APIS
VIRTUAL IP FOR EACH IOT DEVICE
IoT Usecase Creation IoT Device Setup
Data Profiles Time Profiles
Attacking Entities Usercase XML Export
MQTT Client API COAP Client API
Figure 2. Basic Architecture of the IoT-Flock [14] Tool Developed for IoT Traffic Generation
1. IoT-Flock is an open source tool with easily understandable and extendable code.
254
2. IoT-Flock is capable of creating the real-time IoT use cases with the support of a large number of
255
devices that can be added in.
256
3. Most of the open source and commercially available traffic generator tools does not provide the
257
support for creating the attacking entities. While IoT-Flock allows the researchers to create both
258
normal and attacking devices in the same use case and generate its traffic. Thus, the generated
259
traffic contain both normal and attacking patterns which can help to design IDS and IPS in a
260
better way.
261
4. IoT-Flock not only provides the support to export the designed use case into XML but also
262
provide the support to import the XML generated whether by using IoT-Flock or some other
263
third party tool. This can motivate the researchers to create more user-friendly use cases, export
264
them to XML and run it using IoT-Flock console application for IoT traffic generation.
265
5. IoT-Flock is capable of generating the latest MQTT, CoAP specific attacks. That is not supported
266
yet by any other open source IoT traffic generator tools, so the users can simply select an attack
267
type and create a malicious device thus can easily generate malicious traffic.
268
IoT-Flock has two working modes i.e. GUI mode and Console mode. The GUI mode is basically
269
designed to provide a user-friendly environment for creating IoT use cases. One can make any IoT
270
use case and add any number of devices into it. The devices added to the use case are able to mimic
271
the real-time devices. A user can create a single IoT device or multiple IoT devices at a time. For
272
creating a single IoT device or multiple IoT devices, a user will have to provide the relevant functional
273
and non-functional information about the device. The functional information defines the working
274
behaviour of an IoT device. This includes the information about the device type (i.e. normal or
275
malicious), protocol, data profile, time profile, commands and controls (i.e. subscribe, publish topic
276
in case of MQTT while get, post control in case of CoAP). On the other hand, the non-functional
277
information is provided by the user in order to distinguish an IoT device from the other IoT devices.
278
The functional and non-functional information fields are briefly discussed in the following sections:
279
1. Functional Information Fields
280
• Device Type - IoT-Flock can create two types of devices named as normal device and malicious
281
device. The normal device is an ordinary device which sends or receives data or perform
282
both operations simultaneously as defined by the user. Whilst the malicious device is an
283
attacking (harmful, malignant) device which can disturb the normal traffic flow of the use
284
case.
285
8. Version April 1, 2021 submitted to Sensors 8 of 19
• Protocol - IoT-Flock supports two IoT application layer protocols i.e. MQTT and CoAP. In case
286
of MQTT device, the user will have to provide further details about the device like broker
287
IP, username, password, subscribe or publish topic. While in case of CoAP device, the user
288
will have to provide the information about the CoAP server IP, and the CoAP command.
289
• Data Profile - The data profile of an IoT device will illustrate the type of data that an IoT device
290
can send. An IoT device can send either digital or analogue data (values) attached with
291
some notification message. The digital device will send the binary values like on, off or
292
1, 0 whereas the analogue device will send the values in a given range appended with a
293
notification message provided by the user. The notification message can either be a small
294
text or a very large text of megabytes.
295
• Time Profile - The time profile of an IoT device will prescribe the moment when the device
296
will send the data as shown in Figure 3. The IoT-Flock supports two kinds of time profile
297
entitled as periodic or random. An IoT device with the periodic time profile will transmit
298
the data after a fixed interval of time as given by the user while a device with random time
299
profile will transmit the data after some arbitrary interval within the random time range as
300
specified by the user.
301
Initiate Sensor
Simulation
Send
MQTT/COAP
Message
Initiate next
Iteration of
Sensor
Add Five Second
(USER DEFINED)
Delay to Next Input
Figure 3. Time Profile.
2. Non-functional Information Fields The non-functional information of a device is also necessary
302
in order to uniquely identify an IoT device. This includes device name, device IP, and the number
303
of devices. Device IP identifies the IoT device in traffic. Each device of use case will be assigned
304
a separate IP which is used in communication.
305
The generation of IoT use cases can help researchers to understand and meet the context-aware
306
requirements of that specific domain. Moreover, use cases can also help researchers to analyze different
307
dimensions like security requirement, etc. IoT use cases developed in GUI mode of IoT-Flock can be
308
exported to XML format. IoT-Flock development is done with this consideration that IoT use case
309
developed from any third party tool is provided in XML format can be run in IoT-Flock. For this
310
purpose IoT console mode is introduced, where the user can simply provide XML file and complete
311
IoT use case traffic generation will be started.
312
9. Version April 1, 2021 submitted to Sensors 9 of 19
BODY
TEMPERATURE
INFUSION
PUMP
BLOOD
PRESSURE
GLUCOMETER
ECG
MONITORING
MOUTH AIR FLOW
PULSEOXIMETER
EMG
GSR
INTENSIVE
CARE UNIT
MQTT BROKER
COAP SERVER
PATIENT
CONTROLLER
ENVIRONMENT
CONTROL
SYSTEM
AIR HUMIDITY SENSOR - AIR TEMPERATURE SENSOR - CO SENSOR - FIRE SENSOR - SMOKE SENSOR - BAROMETER - SOLAR RADIATION
Figure 4. IoT ICU use case
3.1.1. IoT-based ICU Use Case Setup
313
As discussed earlier that in this work, we aimed to generate the IoT traffic specifically for IoT-based
314
healthcare system use case. In this regard, we created an ICU use case using IoT-Flock. For this purpose,
315
we first analyzed the purpose, working principle and type of data that is produced by the devices
316
which are used commonly in an ICU as shown in Figure 4. So, we created the IoT-based ICU use case
317
using IoT-Flock and added devices into it. Table 1 and Table 2 shows the list and the description of the
318
devices that we added for developing the IoT-based ICU in IoT-Flock. Based upon the utilization, the
319
devices enlisted in Table 1 and Table 2.
320
The devices used in ICU use case, are classified into two categories, i.e., environment monitoring
321
devices and patient monitoring devices. The environment monitoring devices are used to monitor
322
the environmental conditions of the ICU in order to maintain an adequate environment in the ICU.
323
These devices are enlisted and described in Table 1. Whilst the patient monitoring devices are mounted
324
at particular parts of the body in order to observe the physical condition of the patient. The patient
325
monitoring devices are used to continuously examine the physical condition of a patient in order to
326
provide medical aid on the spot if the patient’s condition starts diminishing. These devices are enlisted
327
and described in Table 2.
328
10. Version April 1, 2021 submitted to Sensors 10 of 19
Table 1. Environment Monitoring Sensors
Device Name Description Data Profile Time
Profile
Air Humidity
Sensor
Measures the air humidity 0-100 % Rh (Relative
Humidity)
1 min
Air Temperature
Sensor
Measures the air temperature -20-70 C 1 min
CO Sensor Measures the concentration of CO
gas in Environment
0-2000 ppm 1 sec
Fire Sensor Detects the presence of fire and
flame
Flame detected (0,1) 5 sec
Smoke Sensor Detects the smoke in the air 300-10000 ppm 5 sec
Barometer Measures the atmospheric
pressure
800-110 hPa 5 min
Solar Radiation
Sensor
Measures the direct solar
radiations by thermopile
Spectrum of
radiation ( 0-2000
Watt/m2 )
5 min
Table 2. Patient Monitoring Sensors
Device Name Description Data Profile Time
Profile
Remote
Electrocardiogram
(ECG) monitoring
Test the electrical and muscular
functions of the heart
Pulse Rate
(0-200bpm)
1 sec
Infusion Pump A generic device used to deliver
the nutrients and drugs to patient
at a controlled amount.
Dose
(10-100 mL)
10 min
Pulsoximeter
(SPO2)
A device that tells the oxygen
saturation (i.e. amount of oxygen
dissolved) in blood
Oxygen in blood
(35-100%)
1 sec
Nasal / Mouth
AirFlow Sensor
Provides the (breathing)
respiratory rate of a patient
Device
Respiratory rate
(0-60 ppm
peaks/min)
5 sec
Blood pressure
monitor Sensor
Measure the pressure of the blood
in the arteries when heart beats.
systolic &
diastolic pressure
(0-300 mm Hg)
10 min
Glucometer A device used to determine the
amount of glucose in the blood.
Glucose in Blood
(10-150 mg/dL)
10 min
Body Temperature
Sensor
Measures the temperature of the
body
Temperature
(0-120 F)
10 min
Electro-
myography (EMG)
Sensor
Measures the electric potential
produced by the body muscles
Muscle rate
(0-60 cpm)
(contractions/min)
5 min
Galvanic skin
response (GSR)
Sensor
Measures the electrical
conductance of skin.
Conductance
(0-20 uS) (micro
Semens)
5 min
The IoT devices deployed in an ICU transmit a certain kind of data after a certain interval as set
329
by the ICU administrators. So, we added two more characteristics of each device enlisted in Table 1
330
and Table 2. We called these characteristics as data profile and time profile. In the data profile, we
331
11. Version April 1, 2021 submitted to Sensors 11 of 19
specified the type and range of data transmitted by each device whereas, in time profile, we specified
332
the time interval after which each device will transmit or receive the data. The data profile is specified
333
by consulting the datasheet of each device whereas the time profile is specified based upon the general
334
perception of the authors.
335
After the data profile and time profile of each device is specified, the next step we moved towards
336
creating the device template using IoT-Flock. Once the device template is created in IoT-Flock, it can
337
add multiple times as it is or added after editing as required for a use case. In our scenario, we created
338
a use case of IoT-based ICU with the capacity of 2 beds where each bed is equipped with 9 patient
339
monitoring devices (sensors) and one control unit and called it as Bedx-Control-Unit where x depicts
340
the number of each bed, i.e., Bed1 to Bed2. The Bedx-Control-Unit is responsible to take the certain
341
actions like it can set the time profile, quantity of the dose given to the patient via infusion pump or
342
can generate the emergency alarm based upon the physical condition of the patient as observed by
343
the patient monitoring devices. Similarly, we added another control unit for environment monitoring
344
devices and called it as Environment-Control-Unit. The Environment-Control-Unit is responsible
345
for controlling the ICU environment conditions like keep certain temperature, humidity level, detect
346
smoke and generate an emergency alarm in case of emergency conditions in order to maintain the
347
required ICU environment.
348
In our use case, the both the patient monitoring and environment monitoring devices are
349
MQTT-based devices. The MQTT protocol is a connection-oriented protocol and ensures that the
350
packet is transmitted properly. Figure 4 illustrates the overall IoT-based ICU use case.
351
3.2. IoT Traffic Generation
352
For the development of an extensive dataset, we divided the testbed infrastructure into two
353
networks, i.e., esteemed network and Invader network. The esteemed network is a normal IoT-based
354
ICU network where MQTT broker is deployed along with multiple MQTT devices transmitting and
355
receiving the data with one another. Whilst the invader network is an attacking network which
356
contains the attacking entities which are capable of originating the different types of attacks on targeted
357
device or server.
358
3.2.1. Normal Traffic Generation
359
For the dataset generation, we first designed an IoT esteemed network using IoT-Flock tool which
360
contains both patient and environment monitoring MQTT devices sending and receiving the data
361
over the network under the normal conditions. Since, we created use case of IoT-based ICU with the
362
capacity of 2 beds where each bed is equipped with 9 patient monitoring devices (i.e. sensors) and
363
one control unit, we called it as Bedx-Control-Unit where x depicts the number of each bed i.e. Bed1
364
to Bed2. All these devices created using IoT-Flock tool which was running on a Linux machine. For
365
each device, a virtual network interface was created by the IoT-Flock tool on a single physical machine
366
through which these devices were communicating. Moreover, the MQTT broker and the CoAP server
367
were running on the separate machine.
368
3.2.2. Attack Generation
369
After normal network started generating the IoT traffic, we created invader network. The invader
370
network includes 10 attacking devices which are generating four types of attacks. The following
371
sections describes the types of attack launched by invader network:
372
• MQTT Publish Flood - DDoS attack can exhaust network bandwidth and resources of victim
373
system. Because of better mitigation techniques at network and transport layer DDoS attackers
374
have now moved up the stack and targeting application layer [30]. IoT devices follow periodic or
375
event driven model for sending data using application layer protocols. In periodic model device
376
is set to send data after ever x interval e.g temperature sensor sends temperature data after every
377
12. Version April 1, 2021 submitted to Sensors 12 of 19
five second to server and in event driven model device send data when some event occur e.g
378
motion sensor in ICU can only send data to server when it detect motion in ICU. According to
379
[31] MQTT publishing message at high rate can cause denial of service attack as shown in Figure
380
??. Such attacks delay the data transmission and very harmful specifically at industrial level or
381
some other high level like smart hospital, smart transport system etc. where the delay in data
382
transmission can demolish these assets and can also be very harmful for human life.
383
• MQTT Authentication Bypass Attack [32] - To connect to MQTT broker which require
384
authentication, MQTT clients send MQTT connect requests consists of username and password
385
fields. It was discovered that MQTT authentication can be bypassed by eliminating the password
386
field from the MQTT packet with only providing an existing user-name. Although,this attack
387
has been handled in the latest MQTT brokers but still an MQTT broker has to process this wrong
388
packet which if sent in a large amount can cause the delay in MQTT broker operations. Therefore,
389
if such an invalid packet is blocked by the IPS then the delaying issue of MQTT broker can be
390
prevented.
391
• MQTT Packet Crafting Attack [33] - In this attack MQTT packets are specially crafted to crash
392
an application. The attacker established a connection with MQTT broker at Transport layer and
393
sends publish command right at the beginning instead of sending connection request to MQTT
394
broker.
395
• CoAP Replay Attack - In this attack, an intruder initially scans the network to get CoAP client
396
and server addresses and payload information. Then the intruder changes the payload with
397
incorrect data and send it to the CoAP server with spoofed CoAP client IP. The severity of this
398
attack can be seen in paper use case where environment sensors are using CoAP protocols to
399
transmit surrounding data to CoAP server e.g temperature sensor is sending ICU temperature
400
change and based on that value air condition is set. Now if an attacker using spoof IP send ICU
401
temperature with some abnormal value and cause vulnerable and drastic damage in ICU. An
402
exmaple of CoAP replay attack is shown in Figure 5.
403
COAP
SERVER
COAP
CLIENT
SPOOF IP
ATTACKER
PUT LIGHT ON
PUT LIGHT OFF
Figure 5. CoAP Replay Attack.
3.3. IoT Traffic Capturing
404
After the invader network and the esteemed network devices created and started transmitting
405
and receiving the data, the next step is to capture the packet flows and packets along with the payload.
406
We used Wireshark [34] for capturing the packets. Wireshark [34] is a world known and open source
407
network analysis tool which is used to capture the real-time packets and let you filter and inspect them.
408
13. Version April 1, 2021 submitted to Sensors 13 of 19
While for capturing the packet flows, we developed a python utility to trace-out the packet flows in
409
order to extract the application layer features from the .pcap files as shown in ??.
410
3.3.1. Dataset Features and Format
411
Most of the cyber-attacks are application layer attacks in current era [35]. The traditional publicly
412
available datasets consists of network and transport layer traffic details. Distributed Denial of Service
413
(DDoS) attack at network and transport layer was known issue in traditional network domain and
414
researchers have contributed a lot for its defense [36].
415
According to the Imperva Incapsula’s Global DDoS Threat Landscape Report 2017 [30], there
416
have been a decrease in network layer attacks and increase in application layer attacks. Similarly,
417
Kaspersky[37] reported that “the cream of cyber-criminal communities are now focusing on application
418
layer DDoS attacks”. Although, the protection against DDoS attacks on traditional application layer
419
protocols like HTTP is under research[36]. But there is no significant effort done yet to defend IoT
420
application layer protocols (CoAP, MQTT) against DDoS attacks. The main reason behind the lack of
421
attention is unavailability of IoT datasets that consist of IoT application layer attack traffic. To this aim,
422
we developed a python utility to extract network and application layer features of IoT Traffic.
423
3.4. IoT Dataset Creation
424
In order to extract the network and application layer features of IoT Traffic, we developed a
425
python utility which processes the pcap files and extract features using tshark library. In this work,
426
we extracted network and application layer features from each generated pcap file and saved it into
427
csvs with relevant traffic labels. Table ?? shows all the features, i.e., network layer features, application
428
layer protocol-based features, and payload features along with their description.
429
3.5. ML Model Development
430
The ML model development module consists of three major steps, i.e., Dataset pre-processing,
431
feature selection, ML models training and testing. These steps are described in the subsequent sections:
432
3.5.1. Dataset Pre-Processing
433
The dataset created after capturing the traffic was in the form of pcap files. In order to pre-process
434
and analyze the created dataset, we converted the pcap files into csv files using a script written in
435
python. Furthermore, we substituted the categorical features of the dataset like protocol type (e.g.
436
MQTT, CoAP) with numerical values using Label Encoder for the ease of further processing. Finally,
437
we authenticated the dataset for checking the missing values. We found some missing values in the
438
dataset and replaced them with 0.
439
3.5.2. Features Selection
440
Feature selection plays a significant role in the performance of a machine learning model. After
441
preprocessing the data, we applied Logistic Regression (LR) algorithm due to its efficient performance
442
in existing literature [3,15]. So, using LR algorithm, we selected 10 most significant features in order to
443
train and test the machine learning models. These features include [’frame.time_delta’, ’tcp.time_delta’,
444
’tcp.flags.ack’, ’tcp.flags.push’, ’tcp.flags.reset’, ’mqtt.hdrflags’, ’mqtt.msgtype’, ’mqtt.qos’, ’mqtt.retain’,
445
’mqtt.ver’]. The details of these features are given in [38].
446
3.5.3. ML Models Training and Testing
447
When the data is processed and the features are selected, then the next step is to train the machine
448
learning model. Before training the machine learning models, we split the data into training and testing
449
set. For this purpose, we randomly splitted into train and test with split ratio of 70:30, i.e., 70% of the
450
dataset was randomly selected for training while 30% for testing. Afterwards, we train six commonly
451
14. Version April 1, 2021 submitted to Sensors 14 of 19
used machine learning classifiers for malicious traffic detection in IoT healthcare environment using
452
the training dataset. These six commonly used machine learning classifiers include Naive Bayes
453
(NB), K-Nearest Neighbors (KNN), Random Forest (RF), Adaboost (AB), Logistic Regression (LogR),
454
Decision Tree (DT) classifier. Finally, we test the trained models over the test set for evaluating the
455
performance of each individual classifier for detecting the malicious traffic detection in IoT healthcare
456
environment.
457
4. Results and Discussion
458
The performance of the machine learning classifiers is evaluated on the basis of the four commonly
459
used performance parameters which include precision, recall, accuracy, and F1-score. These parameters
460
are defined as follows:
461
Precision - It is defined as the ability of the system to correctly detecting the attack upon the
occurrence of the security breach. It tells about the ratio between the correctly predicted attacks (i.e.,
TP) and the actual results (i.e., TP+FP). Mathematically, it is described in equation 1:
Precision =
TP
TP + FP
× 100 (1)
Recall - It defines the ability of the system to correctly detect the botnet attack upon the occurrence
462
of the attack in the network. Mathematically, it is expressed in equation 2:
463
Recall =
TN
TN + FN
× 100 (2)
Accuracy - It is defined as the ability of the system to correctly classify the attack packet as an
464
“attack packet” and normal packet as a “normal packet”. It tells about the ratio of correct predictions
465
with respect to all samples. Mathematically, it is expressed in equation 3:
466
Accuracy =
TP + TN
TP + FN + TN + FP
× 100 (3)
F1-score - It is the harmonic mean of precision and recall. It tells about the ratio of correct
467
predictions in test set for both normal and attack traffic. Mathematically, it is expressed in equation 4:
468
F1-score = 2 ×
Precision ∗ Recall
Precision + Recall
(4)
In order to calculate above mentioned performance parameters, we need the confusion matrix of
469
each machine learning classifier. Further, we also need to define the following terms:
470
• True Positive (TP) : The ML model truly predicted the attack flow as an attack.
471
• True Negative (TN) : The ML model truly predicted the normal flow as normal.
472
• False Positive (FP) : The ML model wrongly predicted the normal flow as an attack.
473
• False Negative (FN) : The ML model wrongly predicted the attack flow as normal.
474
Table 3 - Table 8 shows the confusion matrices of each individual ML classifier, obtained for
475
malicious traffic detection over IoT healthcare test dataset generated using IoT-Flock [14]. Based
476
on these confusion matrices, we evaluated the performance of each ML classifier using the above
477
mentioned performance parameters. Finally, in Table 9, we enlisted the performance evaluation results
478
of ML classifiers test for both the normal and malicious traffic detection over test-set extracted from
479
the IoT healthcare dataset that we generated using IoT-Flock [14].
480
15. Version April 1, 2021 submitted to Sensors 15 of 19
Table 3. Confusion Matrix of Naive Bayes (NB) Classifier Test for Malicious and Normal Traffic
Detection over IoT Healthcare Dataset Generated using IoT-Flock [14]
NB Classifier Predicted
Normal Attack
Actual
Normal 32583 37
Attack 11471 12518
Table 4. Confusion Matrix of K-Nearest Neighbors (KNN) Classifier Test for Malicious and Normal
Traffic Detection over IoT Healthcare Dataset Generated using IoT-Flock [14]
KNN Classifier Predicted
Normal Attack
Actual
Normal 32545 75
Attack 123 23866
Table 5. Confusion Matrix of Random Forest (RF) Classifier Test for Malicious and Normal Traffic
Detection over IoT Healthcare Dataset Generated using IoT-Flock [14]
RF Classifier Predicted
Normal Attack
Actual
Normal 32571 49
Attack 117 23872
Table 6. Confusion Matrix of Adaboost (AB) Classifier Test for Malicious and Normal Traffic Detection
over IoT Healthcare Dataset Generated using IoT-Flock [14]
AB Classifier Predicted
Normal Attack
Actual
Normal 32487 133
Attack 119 23870
Table 7. Confusion Matrix of Logistic Regression (LogR) Classifier Test for Malicious and Normal
Traffic Detection over IoT Healthcare Dataset Generated using IoT-Flock [14]
LogR Classifier Predicted
Normal Attack
Actual
Normal 30071 2549
Attack 119 23870
16. Version April 1, 2021 submitted to Sensors 16 of 19
Table 8. Confusion Matrix of Decision Tree (DT) Classifier Test for Malicious and Normal Traffic
Detection over IoT Healthcare Dataset Generated using IoT-Flock [14]
DT Classifier Predicted
Normal Attack
Actual
Normal 32572 48
Attack 125 23864
Table 9. Performance Evaluation of Six Commonly Used Machine Learning Classifiers Test for
Malicious and Normal Traffic Detection over IoT Healthcare Dataset Generated using IoT-Flock [14]
ML Classifier Precision Recall Accuracy F1-score
NB 79.6711 99.7053 52.1823 68.5092
KNN 99.6502 99.6867 99.4873 99.5869
RF 99.7068 99.7952 99.5123 99.6535
AB 99.5548 99.4459 99.5039 99.4749
LogR 95.287 90.3516 99.5039 94.7072
DT 99.6944 99.7993 99.4789 99.6388
Figure 6 illustrates the performance comparison of all six ML classifiers for detecting the normal
481
and malicious traffic in IoT healthcare environment. It can be observed that among the six ML
482
classiifers, the RF classifier outperformed all other classifiers with 99.7068% precision, 99.7952% recall,
483
99.5123% accuracy and 99.6535% F1-score.
484
Figure 6. Performance Comparison of Six Commonly Used Machine Learning Classifiers for Malicious
Traffic Detection over IoT Healthcare Dataset.
The experiments demonstrates how the proposed framework can be used to detect the
485
cyber-attacks to secure and protect the IoT healthcare environment from the cyber-attacks. By following
486
the key steps of the proposed framework as illustrated in Figure 1, one can easily develop the AI-based
487
security solutions for any other IoT use case. Furthermore, the experimental results and dataset
488
generated are also helpful for developing the context-aware IoT security solutions, especially for IoT
489
healthcare environment. The dataset generated in the current study, can be shared with the other
490
researchers for further experimentation based on their request.
491
17. Version April 1, 2021 submitted to Sensors 17 of 19
5. Conclusion
492
The rapid advancement of IoT technology has caught the attention of researchers and technologist
493
to design IoT healthcare systems. In recent years, many IoT healthcare systems have been proposed
494
but these systems endure the security backdoor. The security of IoT healthcare systems is very crucial
495
as any security breach or cyber-attack in such systems may cause rigorous effect on the human life
496
and even may cause the death in certain cases. Hence, in this work, we proposed a framework
497
for developing the IoT context aware security solutions to detect malicious traffic in IoT healthcare
498
environment. The proposed framework consist of an IoT traffic generator tool in which an IoT-based
499
ICU use case is created for generating the normal and malicious traffic. The generated dataset is
500
used for the training and testing of six commonly used machine learning classifiers for malicious
501
and normal traffic detection in IoT healthcare environment. The performance of the trained ML
502
classifiers is then test and analyzed. Among these Random Forest classifier performed best with
503
99.7068% precision, 99.7952% recall, 99.5123% accuracy and 99.6535% F1-score. The developed IoT
504
traffic generator tool is an open source tool and available at [39]. The experimental results and dataset
505
generated are also helpful for developing the context-aware IoT security solutions, especially for IoT
506
healthcare environment. Furthermore, with the help of the proposed framework, the researchers can
507
easily develop and test the AI-based security solutions for any other IoT use cases.
508
Author Contributions: For research articles Conceptualization, F.H., S.G.A, I.M.P.; methodology, F.H., S.G.A,
509
G.A.S., U.U.F., F.S.; validation, G.A.S., U.U.F., F.S., I.M.P.; investigation, N.M.G., E.Z.; writing–original draft
510
preparation, F.H., S.G.A.; writing–review and editing, G.A.S., U.U.F., F.S., I.M.P.; visualization G.A.S., U.U.F., F.S.;
511
supervision, G.A.S., U.U.F., F.S., I.M.P., N.M.G., E.Z.; project administration, S.G.A., G.A.S., I.M.P; All authors
512
have read and agreed to the submitted version of the manuscript.
513
Funding: This work is funded by FCT/MEC through national funds and co-funded by FEDER – PT2020
514
partnership agreement under the project UIDB/50008/2020 (Este trabalho é financiado pela FCT/MEC através de fundos
515
nacionais e cofinanciado pelo FEDER, no âmbito do Acordo de Parceria PT2020 no âmbito do projeto UIDB/50008/2020).
516
This work is also funded by National Funds through the FCT - Foundation for Science and Technology, I.P., within
517
the scope of the project UIDB/00742/2020.
518
Acknowledgments: This work is funded by FCT/MEC through national funds and co-funded by FEDER
519
– PT2020 partnership agreement under the project UIDB/50008/2020 (Este trabalho é financiado pela FCT/MEC
520
através de fundos nacionais e cofinanciado pelo FEDER, no âmbito do Acordo de Parceria PT2020 no âmbito do projeto
521
UIDB/50008/2020). This work is also funded by National Funds through the FCT - Foundation for Science and
522
Technology, I.P., within the scope of the project UIDB/00742/2020. This article is based upon work from COST
523
Action IC1303–AAPELE–Architectures, Algorithms and Protocols for Enhanced Living Environments and COST
524
Action CA16226–SHELD-ON–Indoor living space improvement: Smart Habitat for the Elderly, sup-ported by
525
COST (European Cooperation in Science and Technology). More information in www.cost.eu. Furthermore,
526
we would like to thank the Al-Khwarizmi Institute of Computer Science (KICS), University of Engineering &
527
Technology Lahore (UET), Lahore, Pakistan and Politécnico de Viseu for their support.
528
Conflicts of Interest: The authors declare no conflict of interest.
529
References
530
1. Internet of Things (IoT) connected devices installed base worldwide from 2015 to 2025. https://www.
531
statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/, Accessed February 6, 2021.
532
2. Patel, C.; Doshi, N. Security Challenges in IoT Cyber World. In Security in Smart Cities: Models, Applications,
533
and Challenges; Springer, 2019; pp. 171–191.
534
3. Hussain, F.; Abbas, S.G.; Fayyaz, U.U.; Shah, G.A.; Toqeer, A.; Ali, A. Towards a Universal Features Set for
535
IoT Botnet Attacks Detection. 2020 IEEE 23rd International Multitopic Conference (INMIC), 2020, pp. 1–6.
536
doi:10.1109/INMIC50486.2020.9318106.
537
4. Habibzadeh, H.; Nussbaum, B.H.; Anjomshoa, F.; Kantarci, B.; Soyata, T. A survey on cybersecurity, data
538
privacy, and policy issues in cyber-physical system deployments in smart cities. Sustainable Cities and
539
Society 2019, 50, 101660.
540
5. Pires, I.M.; Hussain, F.; Garcia, N.M.; Zdravevski, E. Improving Human Activity Monitoring by Imputation
541
of Missing Sensory Data: Experimental Study. Future Internet 2020, 12, 155.
542
18. Version April 1, 2021 submitted to Sensors 18 of 19
6. Pires, I.M.; Hussain, F.; Garcia, N.M.; Lameski, P.; Zdravevski, E. Homogeneous Data Normalization and
543
Deep Learning: A Case Study in Human Activity Classification. Future Internet 2020, 12, 194.
544
7. Hussain, F.; Ehatisham-ul Haq, M.; Azam, M.A.; Khalid, A. Elderly assistance using wearable sensors by
545
detecting fall and recognizing fall patterns. Proceedings of the 2018 ACM international joint conference
546
and 2018 international symposium on pervasive and ubiquitous computing and wearable computers, 2018,
547
pp. 770–777.
548
8. Hussain, F.; Umair, M.B.; Ehatisham-ul Haq, M.; Pires, I.M.; Valente, T.; Garcia, N.M.; Pombo, N. An
549
Efficient Machine Learning-based Elderly Fall Detection Algorithm. arXiv preprint arXiv:1911.11976 2019.
550
9. Seh, A.H.; Zarour, M.; Alenezi, M.; Sarkar, A.K.; Agrawal, A.; Kumar, R.; Khan, R.A. Healthcare data
551
breaches: Insights and implications. Healthcare. Multidisciplinary Digital Publishing Institute, 2020, Vol. 8,
552
p. 133.
553
10. Gaukstern, E.; Krishnan, S. Cybersecurity Threats Targeting Networked Critical Medical Devices 2018.
554
11. Worldwide threat assessment - The Director National Intelligence’s view. https://www.intelligence.senate.
555
gov/sites/default/files/documents/os-coats-051117.pdf, Accessed February 15, 2021.
556
12. Lallie, H.S.; Shepherd, L.A.; Nurse, J.R.; Erola, A.; Epiphaniou, G.; Maple, C.; Bellekens, X. Cyber security
557
in the age of covid-19: A timeline and analysis of cyber-crime and cyber-attacks during the pandemic.
558
Computers & Security 2021, p. 102248.
559
13. Hackers are targeting hospitals crippled by coronavirus, 2020. https://www.wired.co.uk/article/
560
coronavirus-hackers-cybercrime-phishing, Accessed January 18, 2021.
561
14. Ghazanfar, S.; Hussain, F.; Rehman, A.U.; Fayyaz, U.U.; Shahzad, F.; Shah, G.A. Iot-flock: An open-source
562
framework for iot traffic generation. 2020 International Conference on Emerging Trends in Smart
563
Technologies (ICETST). IEEE, 2020, pp. 1–6.
564
15. Hussain, F.; Abbas, S.G.; Husnain, M.; Fayyaz, U.U.; Shahzad, F.; Shah, G.A. IoT DoS and DDoS Attack
565
Detection using ResNet. 2020 IEEE 23rd International Multitopic Conference (INMIC), 2020, pp. 1–6.
566
doi:10.1109/INMIC50486.2020.9318216.
567
16. Kumar, A.; Lim, T.J. Early Detection Of Mirai-Like IoT Bots In Large-Scale Networks Through Sub-Sampled
568
Packet Traffic Analysis. arXiv preprint arXiv:1901.04805 2019.
569
17. Santos, L.; Rabadao, C.; Gonçalves, R. Intrusion detection systems in Internet of Things: A literature review.
570
2018 13th Iberian Conference on Information Systems and Technologies (CISTI). IEEE, 2018, pp. 1–7.
571
18. Zarpelao, B.B.; Miani, R.S.; Kawakani, C.T.; de Alvarenga, S.C. A survey of intrusion detection in Internet
572
of Things. Journal of Network and Computer Applications 2017, 84, 25–37.
573
19. 1998 DARPA Intrusion Detection Evaluation Dataset. https://www.ll.mit.edu/r-d/datasets/1998-darpa-
574
intrusion-detection-evaluation-dataset, Accessed February 4, 2021.
575
20. KDD Cup 1999 Data. http://kdd.ics.uci.edu/databases/kddcup99/kddcup99.html, Accessed February 4,
576
2021).
577
21. NSL-KDD dataset. https://www.unb.ca/cic/datasets/nsl.html, Accessed February 6, 2021.
578
22. DEFCON. https://www.defcon.org/html/links/dc-ctf.html, Accessed February 6, 2021.
579
23. LBNL/ICSI Enterprise Tracing Project. http://www.icir.org/enterprise-tracing/, Accessed February 6,
580
2021.
581
24. Center for Applied Internet Data Analysis (CAIDA). https://www.caida.org/data/, Accessed February 6,
582
2021).
583
25. UNIBS: Data sharing. http://netweb.ing.unibs.it/~ntw/tools/traces/index.php, Accessed February 6,
584
2021.
585
26. ISCX. http://www.iscx.ca/datasets/, Accessed February 6, 2021.
586
27. Moustafa, N.; Slay, J. UNSW-NB15: a comprehensive data set for network intrusion detection systems
587
(UNSW-NB15 network data set). Military Communications and Information Systems Conference (MilCIS),
588
2015. IEEE, 2015, pp. 1–6.
589
28. Sharafaldin, I.; Lashkari, A.H.; Ghorbani, A.A. Toward Generating a New Intrusion Detection Dataset and
590
Intrusion Traffic Characterization. ICISSP, 2018, pp. 108–116.
591
29. Koroniotis, N.; Moustafa, N.; Sitnikova, E.; Turnbull, B. Towards the Development of Realistic Botnet
592
Dataset in the Internet of Things for Network Forensic Analytics: Bot-IoT Dataset. arXiv preprint
593
arXiv:1811.00701 2018.
594