HIDS by signature for embedded devices in IoT

networks
Bruno V. Dutra∗ , João F. de Alencastro† , Francisco L. de Caldas Filho‡ , Lucas M. C. e Martins§ ,
Rafael T. de Sousa Júnior¶ and Robson de Oliveira Albuquerquek
National Science and Technology Institute on Cyber Security, Electrical Engineering Department,
University of Brası́lia (UnB), P.O. Box 4466, Brası́lia–DF, Brazil, CEP 70910-900
Email: brunovdutr@gmail.com∗ , joao.alencastro@gmail.com† , francisco.lopes@redes.unb.br‡ ,
lucas.martins@redes.unb.br§ , rafael.desousa@redes.unb.br¶ and robson@redes.unb.brk

Abstract—Cybersecurity in Internet of Things (IoT) has be-
come a major concern due to its characteristics. One possible way
to protect IoT devices is to enhance smart devices with intrusion
detection capabilities considering its limited resources. With such
assumptions in mind, this paper describes the development of a
host-based intrusion detection system by signature for IoT smart
devices. The signatures remain in a central controller on the
cloud, which is periodically consulted by the hosts. The use
of the proposed system may prevent IoT devices with known
vulnerabilities to join botnets, taking actions in the system defined
by the administrator. In addition, the proposed system is also able
to notify the IoT controller about potential failures.
Index Terms—HIDS, smart devices, HIDS controller, HIDS
rules, IoT, sensors, IoT vulnerabilities, Mirai.
I. I NTRODUCTION
Since the first definition of the term, in 1999 by Kevin
Ashton [1], Internet of Things (IoT) has been largely seen
with an enormous potential of growth and development of
new technologies. The IoT has the purpose of expanding the
limits of the traditional computing, which uses desktops and
conventional computers, to a new environment where common
objects, like toasters and sensors, will be interconnected to
exchange data and be remotely controlled. As described in
[2], the new computational revolution will be given by the
connection between objects to create smart environments.
Nowadays IoT has had an impressive growth. According
to [3], some projections estimate that by 2020 the number of
devices connected to IoT instances will grow exponentially to
50 billions.
This growth and popularization of IoT instances in the
society has brought with it a cybersecurity threat through
BotNets. The Cisco’s Annual Cybersecurity Report in 2018
classified the problem as imminent and pointed out the in-
creasing scope and intensity of Distributed Denial of Service
(DDoS) attacks [4]. These attacks are taking advantage of low
security devices that are being implemented with no concerns
about basic security, like default passwords, and causing a
huge vulnerability to BotNets like Mirai, which uses this kind
of devices to perform DDoS attacks.
An attack performed by BotNets is defined by two main
steps. The first step consists in taking control of devices by
the attackers: they will execute a search for vulnerable devices,
which are often IoT devices with basic security vulnerabilities,
as explained above, and through them establish control over
the device, without its knowledge. The second step consists
in manipulating the devices: the attackers must be able to
orchestrate the devices they control to perform as a unit and
achieve a specific objective [5]. Usually manipulating devices
occurs in a disseminated and coordinated way by a single
malicious agent.
Given the high vulnerability exposed above that IoT devices
currently have, these are being targeted by malwares that use
BotNet, the most famous being the Mirai BotNet malware.
Facing the seriousness of this problem, this paper presents a
Host-Based Intrusion Detection System (HIDS) by signature
with the function of detecting attacks and vulnerabilities in an
IoT network instance.
Within IoT architectures, there is no pattern for the process-
ing power of devices. Sensors that often have basic functions
such as temperature, humidity, light, which are widely used in
agricultural applications, have very limited processing power,
which makes it a challenge to develop safety means for them
[6]. Other devices, which are capable of having a UNIX-like
operating system such as Raspberry Pi, are also used in IoT
instances and have a higher processing power. This article will
propose a security system for these devices.
Besides this introduction, the paper is organized as follows:
in Section II, we present a literature review about security
in IoT and, in Section III, we present the related works. In
Section IV, we present the proposed HIDS for IoT devices
and, in Section V, we highlight the proposed HIDS life cycle.
In Section VI, we present the testing methodology and the
results. Finally, in Section VII, we present our conclusions
and our suggestions for future work.
II. S TATE OF THE A RT
This paper focus on security issues in IoT domain. To
discuss that, we present the academic and industry view
of some concepts that are useful for understating the paper
content.
A. IoT Architecture
IoT solutions are being used and projected to be used
in several domains like agriculture, transportation, logistics,
industry, smart grid, home automation, surveillance, health
care and personal assistance [2]. Each one of these domains trace and verify information relative to logs registers, events,
has its own characteristics, but we point out two common file systems, permissions, among others. Stenven R. Snapp
issues they have: heterogeneity of technologies and a large et al. [10] specifies tagged objects, that are thought to be
number of entities in the solution. There’s a lot of technol- interesting in the intrusion detection matter. Any file, device or
ogy heterogeneity and entities because it’s supposed to be a process can be tagged, that way it can be distinguished easily
ubiquitous solution and, to achieve this, the devices need to be and verified frequently.
cheaper, smaller and more abundant than conventional ones. D. Wagner et al. [11] shows a different approach, where in-
We can see IoT architecture as a layered architecture trusions are detected by anomalies based on processes system
composed by devices, network connectivity, middleware and calls normal behaviour. For instance, if an e-mail application
applications. Devices layer has all sorts of devices acting as client starts to open and write files, create sockets and listen to
sensors and/or actuators, including the smart devices. Network different ports in which they are not supposed to, it is possible
connectivity layer embraces the network infrastructure to make that this client was infected.
possible the devices to connect to the middleware. Middleware
layer corresponds to a software or a set of software that D. Botnets
supports devices activities, for instance, by providing storage There are several ways to invade computing systems, one of
and processing capabilities. Applications layer is composed by the most successful methods yet invented are the botnets, also
services and applications that interact with data and actions called zombie nets. A botnet is a network of computing devices
provided by the devices. that are explored without their owner acknowledgment. Once
the devices are invaded, malicious scripts and codes can be
B. UIoT Middleware executed, accomplishing multiple routines. One of them is
The UIoT Middleware was proposed in [7] to “control and to send continuous TCP, UDP or ICMP requests to a victim
notify the current state of generic devices”. It evolved to be server in order to overwhelm the listener, and stop it from
a cloud-based IoT middleware that is capable to store large functioning correctly, the basic idea of a DDoS attack. Botnets
amounts of data and process it for the connected IoT devices. can also be used to collect sensitive data and personal identities
It is composed by a set of components such as the cloud-based or to distract organizations from real attacks.
UIoT Gateway, that handles all requests the devices makes The life cycle of a typical botnet consists on:
to the middleware; the Data Interface Management System
(DIMS), that is the API interface for all data handled by the
middleware; the User Interface Management System (UIMS),
that is the user-friendly interface for the middleware’s data and
operations.
As an authentication mechanism, the middleware demands a
registration before the new device is able to interact with other
devices or the middleware. As described in [8], it uses a self-
registration model in which the device must ask its registration
to the middleware, using a set of REST APIs. To successfully
accomplish the self-registration process, the device should say
its identification data and its services. When the middleware
validates the given registration data, the device is able to send
data to the middleware, as well to consume its data.
Some IoT devices are resource-constrained in terms of
power, memory, processing and/or networking so that, for
instance, they communicate only in non-TCP/IP protocol.
Another issue that prevents certain IoT devices from integrat-
ing with an IoT network is called “silo solutions” in which
the device is only capable of communicating with hardware
and software from the same manufacturer [9]. As in [8], Figure 1. Life cycle of a Botnet. [12]
the UIoT Gateway acts like a semantic gateway, translating
communications from the devices to the middleware.
E. Botnets: Entry Vulnerabilities
C. Host-Based IDS 1) Vulnerabilities in conventional systems: Traditional op-
Host based Intrusion Detection Systems were the first type erating systems have a list of known vulnerabilities that are
of IDS’s to be conceived. They usually run only within the the first to be explored by an attacker, those include:
target host with the task of monitoring and analyzing its files • Known vulnerabilities of default TCP ports, such as 135,
and processes, therefore the network traffic addressed to the 139 or 593;
host is not taken into account. One of its main function is to • Backdoors left behind by a Trojan previously installed;
 • Default passwords;
• Configuration files in unsecured locations;
• Database related vulnerabilities;
• Default routes and directories;
2) Vulnerabilities in IoT systems: With an IoT system
environment in mind, some of the vulnerabilities known, as
presented by [13], are quoted below:
• Authentication and/or insufficient authorization;
• Denial of Service Attacks in the Internet of Things;
• Eavesdropping in the Internet of Things;
• Node Capture in the Internet of Things;
• Physical Security of the Sensors;
F. HIDS: Prevention Methods
A Host-Based Intrusion Detection System (HIDS) works
with information collected from inside a computational device,
this allows the HIDS to perform daily routine activities to
determine which processes and users might be involved in
some kind of attack. As discussed in [14] an HIDS is used
to check and maintain securely host’s system and its network
activities if a system has been attacked or not.
Still according to the [14] Host-based IDS utilize the audit
data, incoming traffic, logs produced by the applications to
detect malicious activities, to prevent intruder‘s activities and
to trace the attacks. Therefore, most of the existing audit
mechanisms are implemented in the host operating system.
G. HIDS: Audit
Keeping audit-trails and analysing them can reveal a lot of
information about events that might have occurred, such as:
1) Improper changes in the system’s configuration files;
2) Connection attempts that are inconsistent or reiterated
(like Brute-force);
3) Illegal application processes creation, or the removal of
the legitimate ones;
4) Sudden scarcity of resources, e.g. of memory and pro-
cessing;
5) Abnormal increase of disk usage;
6) Irregular attempts to address connections;
H. HIDS IoT
An HIDS has a fundamental role in the discovery of
vulnerabilities in conventional networks, because they alert
the administrator to possible attacks, helping them understand
where the vulnerabilities come from. There are numerous
implementations of HIDS applications for traditional network
devices, for instance: OSSEC, Tripwire, AIDE and Prelude
Hybrid IDS. However, according to [15], IoT needs a robust
IDS that can detect new attacks and that is, simultaneously,
light weight to run on.
This HIDS will have a distributed behavior to publish the
rules that were created in the network and to report to the
controller occurrences of detected attacks in its audits. Thus,
each computational system that hosts the cited HIDS will be
part of a “web of trust”, consisting in all host devices that have
a distributed HIDS agent. Each instance of HIDS in your host
operating system will have to submit to a central controller
that will aid in rule distribution and incident control. Each
instance of distributed HIDS will have some features of a
conventional HIDS, so it will have mechanisms to audit all
the topics mentioned in the previous subsection and once rules
are configured, they will be able to perform actions on events
detected in the audit.
Finally, HIDS on hosts (sensors with higher processing
capacity) will be specifically configured to detect if the device
is being controlled and/or if it is part of a botnet. So its audit
will focus on basic specific vulnerabilities of IoT networks.
The HIDS agent will still be able to perform response actions
on the device. Such actions include closing connections,
generating reports and setting actions.
III. RELATED WORK
There are numerous studies on intrusion detection systems
in resource constrained devices. However, most are concerned
with studying how traditional network IDS’s operate on an
embedded device such as a Raspberry Pi.
One interesting work is [16], which looks at how a tradi-
tional IDS acts on a Raspberry Pi while observing the use of
CPU and RAM in a resource-constrained device. In this sense,
the analysis of an already established intrusion detection tool
in a Raspberry Pi is similar to the one proposed here, since it
requires a greater management of resource use.
Another relevant study was [17] which attempts to analyze
which traditional IDS running on a Raspberry Pi has the best
management in resource usage versus packet capture rate for
vulnerability analysis.
In [5], the authors relate the growth of botnet networks
with the increase of IoT devices that have security holes
and are included in botnets networks such as Mirai, but in
their work the referenced authors do not propose any security
mechanisms to mitigate such attacks.
Different from the one proposed in the works mentioned
previously in [18], it is proposed an analysis of intrusion
detection methods for IoT in a general context. Considering a
wide variety of devices used in IoT.
The majority of IDS implementation in IoT is based on
using detection tools already established in devices usually
used in this context and managing the resources used. The
proposal here, however, was based on the creation of a custom
host-based intrusion detection system for the IoT context with
a set of rules intended for common Iot vulnerabilities.
IV. P ROPOSAL
This paper presents the development of a signature-based
HIDS for smarts devices that will try to connect to the IoT
network. This HIDS will be composed of some well-defined
entities (Figure 2) that aim to detect attacks and vulnerabilities
in smart devices connected to a given IoT network. These
entities are described below:
1) HIDS Agents in smart devices;
2) Communication API between HIDS Controller and
HIDS Agent;
 3) HIDS Controller;
4) Rules;
5) Events Reports;

A. HIDS Agent
The HIDS Agent is an application that runs on the IoT smart
device. This application performs the tests provided in the
rules registered in the local database and compare the output
of these tests with the expected output. If the output is different
from the expected output, the action foreseen in the rule will
be executed and an event report will be generated and sent to
the HIDS Controller. To test the rules in the local database,
the HIDS Agent will use the functions described below:
1) Threat Scan: This function of the HIDS application
reads each of the rules present in the local database and
performs a case test for each of them. The case test consists
of verifying if the output obtained by executing the rule code
is equal to the standard output expected that is set by the
controller during the registration of the rule. Once the output
generated by executing the rule code is different from the one
in the output field, the action foreseen in the rule will be
executed and an event report will be generated and sent to
the HIDS Controller by the communication API.
2) Enable Self Analysis: Enables the Threat Scan to be
done automatically and periodically.
3) Disable Self Analysis: Disables the Threat Scan.
4) Update Rules: This function makes a request to update
rules to the HIDS Controller through the communication API.
Thus, the request is sent from the HIDS Agent to the HIDS
Controller which validates if it is valid and responds with
the most updated set of rules in the format described in
Figure 3. Once the instance receives the updated rules, the
HIDS application will check whether rules have been updated,
added, or removed from the it previous rule set, and will persist
the data in the local rule database.
5) Set the time between the rules updates: Rule updating
can be initiated using the CLI, but the HIDS application
predicts that rule update requests are made automatically and
periodically. This function allows you to set the time between
update requests. If it is not explicitly configured the default
time associated with the instance will be 15 minutes.
6) Show Rules: Show the existing rules in the local rules
database.
7) Show settings: Shows the settings of the HIDS applica-
tion, such as the request period of updated rules, communica-
tion API configurations, etc.

B. Communication API
This component is responsible for the communication of
the HIDS Agent present in the Smart Device with the HIDS
Controller allocated in the midleware IoT, according to the ar-
chitecture proposed in Figure 2. The communication between Figure 2. Logical architecture of the proposed implementation.
the mentioned entities occurs via HTTP protocol with POST
method in a standard JSON file, as shown in the Figure 3.
 Table I of the functions of the HIDS Controller are described below:
L IST OF AVAILABLE COMMANDS 1) Registration of new rules: Registers the rules in a remote
Name Description CLI Command database. This function is responsible for sending the updated
scan threats Checks for threats accord- python manage rules to all smart devices associated with the HIDS Controller.
ing to rules specified in scan 2) Definition of Assumptions: Defines the default output of
the rules database.
enable auto scan Enables scanning periodi- python manage the rules. The output is used in the tests performed in the
cally for threat detection. enable auto scan HIDS Agents to verify threats and vulnerabilities.
disable auto scan Disables scanning period- python 3) Event Report Analysis: Analyzes the event reports that
ically for threat detection. manage dis-
able auto scan arrive at the controller from the HIDS Agents associated with
update Updates periodically the python manage it.
database of threats rules. update 4) Threat Treatment: Based on the event report, it performs
set update rules period Changes the time in which python manage
the HIDS rules is update. set update time
some action to remove the reported vulnerabilities.
show rules Shows all available rules. python manage
show all rules
show info Displays HIDS configura- python manage
tion information. info

Figure 3. JSON to update rules in the local database.

Figure 5. Procedure for registering rules in the HIDS Controller.

D. Rules
A rule is a series of information that assists the HIDS Agent
in taking some previously defined actions. In the abstraction
defined here the rule has 6 main fields:
Figure 4. JSON to send event reports to the HIDS Controller. • Name: Rule name;
• Id: Uniquely Identifies a rule;
• Date: Date of creation;
C. HIDS Controller • Assumption: Value taken as true for a given condition or

The responsible entity for managing the HIDS Agents, characteristic of the system;
logging and updating rules, defining rules premises, analyzing • Test Case: Code that finds the characteristic or condition

event reports, and providing the data visualization for the to be tested and returns it for verification;
control. In addition, it is the entity that will communicate • Action: In case the value find in the Test Case is different

directly with the IoT Gateway to define the personalized from the value found in the Assumption, the Action
assumptions and report the findings. The rules registered in defined here must be taken.
the controller can be done directly in the application running The registered rules are designed to end certain anomalies
on the server (Figure 5) or indirectly via the Web API. Some commonly found in IoT systems. For simplification of appli-
cation these rules are classified in different contexts described
below:
1) Network;
2) Resources;
3) Known vulnerabilities;
1) Network: HIDS Agents communicate with the gate-
way through a traditional network infrastructure. Traditional
networks have a number of well-known vulnerabilities and
attacks. Such vulnerabilities can serve as a way in for a
malicious agent to take control of the smart device that
has the HIDS Agent. Thus, rules were developed to detect
vulnerabilities and attacks related to the network context,
Among some examples of rules implemented in this context
we can mention:
1) Port Scan Detection;
2) DDoS attacks Detection;
3) DNS attacks Detection;
2) Resources: The use of resources such as processing,
memory and disk space is of great importance to smart devices.
Thus, these resources can be the target of attacks that aim to
disable or reduce these resources for legitimate applications.
To detect such attacks, the rules of this context have been
created. Among some examples of rules implemented in this
context we can mention:
1) Processes with excessive memory use;
2) Processes with excessive processing usage;
3) Processes with excessive usage of HD memory;
4) High temperature;
3) Known vulnerabilities: This context provides for the
creation of rules for classic vulnerabilities in the IoT environ-
ment as well as good practices for configuring smarts devices.
Among some examples of rules implemented in this context
we can mention:
1) Default passwords;
2) Standard Open ports;
3) Configuration files in standard and unprotected directo-
ries;
E. Event Report
An Event Report is a set of information that are sent to
the HIDS Controller. This set of information is sent at the
moment a vulnerability is detected by the rules. In Figure 4
the information is shown and it will be detailed next:
1) instance id; Identifier of the HIDS Agent;
2) instance ip; IP address of the HIDS Agent;
3) instance mac; MAC address of the HIDS Agent;
4) rule id; Identifier of the rule that detected the vulnera-
bility;
5) output rule; Output found by the rule;
6) occur time; Hour the vulnerability was found;
V. L IFE C YCLE OF A HIDS
For the detection and treatment of vulnerabilities/attacks it is
necessary that the application of HIDS operate on some well
defined steps as shown in Figure 6. This sequence of steps
transparently executes the application on the smart device that
wants to send data to the cloud application that will handle
the received data. These steps consist of:
1) Register the HIDS Agent on the HIDS Controller;
2) Download HIDS source code;
3) Request updated rules to the HIDS Controller;
4) Validate the HIDS Agent request and respond with the
updated rules;
5) Update the local rules database;
6) Run case test for each local database rule;
7) Perform the actions provided in the rules;
8) Send Event Report;
9) Handle event report received;
A. Register the HIDS Agent on the HIDS Controller
Once Smart Device wishes to enter the IoT network to send
data from its monitoring to the application in the cloud. A
self-registration process described in the II section is required.
Once this process is completed the smart device will be
registered in the HIDS Controller as an associated smart
device.
B. Download HIDS source code
The process of self-registration of the HIDS Agent in the
controller is finished. The Smart Device downloads the HIDS
application source code and starts the installation process. At
this point the Smart Device is already running an instance of
HIDS and can be accepted as a valid device in the IoT network
that it is part of.
C. Request updated rules to the HIDS Controller
In this step, the HIDS Agent sends to the controller, using
the communication API, a request to update rules.
D. Validate the HIDS Agent request and respond with the
updated rules
The HIDS Controller will validate the requesting HIDS
Agent based on its identification that is previously registered
during the self-registration process. Thus, the instance is
validated and shortly after the HIDS Controller will respond
with the set of updated rules taken from the remote database.
E. Update the local rules database
Once the updated rules have been received in the HIDS
Agent, the local rules database is updated.
F. Run case test for each local database rule
Once the local rules database is updated, each rule is tested
to determine if the output found is different from the output
expected by the rule.
G. Perform the actions provided in the rules
For each rule that fails on the tests run, the HIDS Agent
will execute the action provided in the rule.
H. Send Event Report
For each rule that fails the tests run, an event report is
generated and sent to the associated HIDS Controller.
 Figure 6. Application lifecycle from the standpoint of the HIDS Agent on the Smart Device.

I. Handle event report received B. False Positives

The HIDS Controller will perform actions to eliminate the Some rules that have a more general context tend to have
vulnerabilities reported by the HIDS Agent. a number of false detections by the HIDS Agent. Thus,
the same tests of the Table II were performed in legitimate
VI. R ESULTS environments, i.e., without simulated attacks to measure these
false positives according to the Table III.
The solution’s integrity check includes the detection of
expected attacks and the generation of the event report by the Table III
HIDS Agent for the HIDS Controller, which, once notified, T ESTS OF FALSE POSITIVES OF THE RULES IN LEGITIMATE
ENVIRONMENTS : E XECUTED (E XE .) V S D ETECTED (D ET.)
will perform an action. Thus, we measure the level of detected
attacks and vulnerabilities discovered in a real implementation Rule Description Exe. Det. Rate
of the proposed solution in order to verify the rate of detection Default Cre- An HIDS Agent was initialized on 150 0 0%
dentials a device with valid credentials.
of threats in the IoT network. SSH Port An HIDS Agent was initialized on 150 0 0%
Open by a device with SSH port closed.
Default
A. Simulated Attacks X Successful Detections
Anomalous An HIDS Agent was initialized on 150 20 13.3%
Process a device that is running standard
A rule was chosen for each one of the classes mentioned in Behavior processes.
the proposal, so, for each rule, attacks were executed, gener-
ating a detectable behavior by the HIDS Agent, according to
Table II. C. Comparison with traditional IDS
The rules described in the proposal can be made specifically
Table II to meet the desire of the application running on the smart
VALIDATION TESTS OF RULES FOR ATTACKS /V ULNERABILITIES :
E XECUTED (E XE .) V S D ETECTED (D ET.) device. In conventional IDS, there is a certain difficulty in
creating custom rules. On the other hand, in the proposed
Rule Description Exe. Det. Rate HIDS Agent, anyone with the least knowledge in the python
Default Cre- An HIDS Agent was initialized on 150 150 100%
dentials a device with standard credentials. programming language can create a custom rule and add it to
SSH Port An HIDS Agent was initialized on 150 150 100% the remote rule table to update the instances associated with
Open by a device with SSH port opened. the controller.
Default
Anomalous An HIDS Agent was initialized on 150 150 100%
Process a device that is running a resource-
VII. C ONCLUSION AND F UTURE W ORK
Behavior intensive process. The proposed HIDS for IoT devices that operates on a
Raspberry Pi with resource usage management was put in the
3 environments (Network, Resources, Known vulnerabilities).
It was able to detect all the vulnerabilities it was supposed to
reach by the rules. Surprisingly, even with more general rules,
it did not triggered into False Positives tests, except by the
one running standard processes.
The rules based in anomaly detection had a rate of 13.3
percent in the False Positive tests. The high percentage in
such cases is common and somewhat expected. This method
has great difficulty in deciding whether an action is part of
a previously pattern defined by analyzing the network over
a period of time. Is intended to use methods such as neural
network, deep learning, KNN, among others in future works
to minimize the amount of false positives.
Unlike what is usually implemented in the context of IDS
in IoT, we proposed a system created in a personalized and
private way for vulnerabilities in IoT. The HIDS proposed here
is suitable for IoT devices because it has been developed for
devices with restricted resources that forms an IoT network.
To support the above discussion, most of the known vul-
nerabilities in IoT devices are based on common and well-
known IoT vulnerabilities. For the proposed scenario, the
HIDS Agents run directly on the smart device associated with
the IoT network, but there is a diverse range of IoT devices
with limited processing capacity to perform these actions as
simple sensors and actuators.
As future work, we intend to develop new scenarios in
which the HIDS Agent runs on an auxiliary device to detect
vulnerabilities and subsequently replicate the rules to devices
with hardware limitations involves a significant amount of
research to inter operate with those devices.
[10] S. R. Snapp, J. Brentano, G. Dias, T. L. Goan, L. T. Heberlein, C.-L.
Ho, and K. N. Levitt, “DIDS (distributed intrusion detection system)-
motivation, architecture, and an early prototype,” 2017.
[11] D. Wagner and P. Soto, “Mimicry attacks on host-based intrusion
detection systems,” in Proceedings of the 9th ACM Conference on
Computer and Communications Security. ACM, 2002, pp. 255–264.
[12] C. A. Schiller, J. Binkley, D. Harley, G. Evron, T. Bradley, C. Willems,
and M. Cross, in Botnet: the killer web app, S. Publishing, Ed., 2007,
p. 36.
[13] A. T. Ebraheim Alsaadi, “Internet of things: Features, challenges, and
vulnerabilities,” International Journal of Advanced Computer Science
and Information Technology (IJACSIT), vol. 4, no. 1, pp. 1–13, 2015.
[14] K. Letou, D. Devi, and Y. Jayanta, “Host-based intrusion detection
and prevention system (HIDPS),” International Journal of Computer
Applications, vol. 69, pp. 30–31, 05 2013.
[15] M. F. Elrawy, A. I. Awad, and H. F. A. Hamed, “Intrusion detection
systems for iot-based smart environments: a survey,” Journal of Cloud
Computing, vol. 7, no. 1, p. 21, Dec 2018.
[16] A. Sforzin, F. G. Mármol, M. Conti, and J. Bohli, “RPiDS: Raspberry
pi IDS — a fruitful intrusion detection system for iot,” in 2016 Intl
IEEE Conferences on Ubiquitous Intelligence Computing, Advanced and
Trusted Computing, Scalable Computing and Communications, Cloud
and Big Data Computing, Internet of People, and Smart World Congress
(UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), July 2016, pp. 440–
448.
[17] A. Aspernäs and T. Simonsson, “IDS on Raspberry Pi: A performance
evaluation,” Bachelor’s Thesis, Linnaeus University, 2015.
[18] O. Anthony, J. Odeyabinya, and S. Emmanuel, “Intrusion detection in
internet of things (iot),” International Journal of Advanced Research in
Computer Science, vol. 9, no. 1, pp. 504–509, Feb 2018.

R EFERENCES
[1] K. Ashton. That ‘Internet of Things’ Thing. Accessed: Apr 05, 2019.
[Online]. Available: https://www.rfidjournal.com/articles/view?4986
[2] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of things
(iot): A vision, architectural elements, and future directions,” Future
generation computer systems, vol. 29, no. 7, pp. 1645–1660, 2013.
[3] A. L. Albertin and R. M. Albertin, “A internet das coisas irá muito além
as coisas,” GV-executivo, vol. 16, no. 2, pp. 12–17, 2017.
[4] “Annual CyberSecurity Cisco,” Cisco 2018, Tech. Rep.,
2018. [Online]. Available: https://www.cisco.com/c/dam/m/digital/elq-
cmcglobal/witb/acr2018/acr2018final.pdf
[5] C. Kolias, G. Kambourakis, A. Stavrou, and J. Voas, “DDoS in the IoT:
Mirai and other botnets,” Computer, vol. 50, no. 7, pp. 80–84, 2017.
[6] C. L. C. H. H. M. Lee TH., Wen CH., “A lightweight intrusion
detection scheme based on energy consumption analysis in 6LowPAN,”
in Advanced Technologies, Embedded and Multimedia for Human-
centric Computing. Lecture Notes in Electrical Engineering, vol. 260,
2014.
[7] H. G. C. Ferreira, “Arquitetura de Middleware para Internet das Coisas,”
Master’s Thesis, Universidade de Brası́lia, Brası́lia, DF, Brazil, 2014.
[8] F. L. d. Caldas Filho, L. M. C. e. Martins, I. P. Araújo, F. L. L. d.
Mendonça, J. P. C. L. da Costa, and R. T. de Sousa Júnior, “Design
and Evaluation of a Semantic Gateway Prototype for IoT Networks,” in
Companion Proceedings of the10th International Conference on Utility
and Cloud Computing, ser. UCC ’17 Companion. Austin, Texas, USA:
ACM, Dec 2017, pp. 195–201.
[9] C. F. C. Ribeiro, F. L. d. Caldas, L. M. C. e Martins, C. J. B. Abbas,
and R. T. de Sousa Júnior, “Protocolos de Redundância de Gateway
Aplicados em Redes IoT,” in Anais do XXXVI Simpósio Brasileiro de
Telecomunicações e Processamento de Sinais (SBrT 2018), Campina
Grande, PB, Brazil, sep 2018, pp. 1065–1069.