Computers & Security: Omnia Abu Waraga, Meriem Bettayeb, Qassim Nasir, Manar Abu Talib

Computers & Security 88 (2020) 101648
Contents lists available at ScienceDirect
Computers & Security

journal homepage: www.elsevier.com/locate/cose
Design and implementation of automated IoT security testbed

Omnia Abu Waraga a,∗, Meriem Bettayeb b, Qassim Nasir b, Manar Abu Talib a
a
Department of Computer Science, University of Sharjah, United Arab Emirates
b
Department of Electrical and Computer Engineering, University of Sharjah, United Arab Emirates
a r t i c l e i n f o a b s t r a c t
Article history: The emergence of technology associated with the Internet of Things (IoT) is reshaping our lives, while
Received 28 April 2019 simultaneously raising many issues due to their low level of security, which attackers can exploit for ma-
Revised 22 September 2019
licious purposes. This research paper conducts a comprehensive analysis of previous studies on IoT device
Accepted 12 October 2019
security with a focus on the various tools used to test IoT devices and the vulnerabilities that were found.
Available online 16 October 2019
Additionally, the paper contains a survey of IoT-based security testbeds in the research literature. In this
Keywords: research study, we introduce an open source platform for identifying weaknesses in IoT networks and
Internet of Things communications. The platform is easily modifiable and extendible to enable the addition of new secu-
IoT testbed rity assessment tests and functionalities. It automates security evaluation, allowing for testing without
Vulnerability assessment human intervention. The testbed reports the security problems of the tested devices and can detect all
Automated testbed architecture attacks made against the devices. It is also designed to monitor communications within the testbed and
with connected devices, enabling the system to abort if malicious activity is detected. To demonstrate
the capabilities of the proposed IoT security testbed, it is used to examine the vulnerabilities of two IoT
devices: a wireless camera and a smart bulb.
© 2019 Elsevier Ltd. All rights reserved.
1. Introduction The concept of smart cities is emerging as a result of the perceived

benefits to citizens, government and the environment.
The Internet of Things (IoT) is a recent evolution in com- However, due to the limited capabilities of IoT devices, many of
munication technology that is rapidly reshaping our future. This them have vulnerabilities that make them prone to various attacks.
technology enables communication and interaction between small A vulnerable IoT device can be a dangerous hole in any network,
embedded devices, improving the ability of such devices to bet- regardless of its security level (Badve et al., 2017). Many attacks
ter serve our needs (Memos et al., 2018). In the future, IoT will have involved leveraging the vulnerabilities of IoT devices, includ-
be a key technological solution for many sectors including health ing actions such as replay attacks, zero-day attacks, impersonation
care, agriculture and manufacturing (Adjih et al., 2015, Tewari and attacks and spoofing attacks. An increase in botnet attacks has also
Gupta, 2018). For example, in the field of health care, IoT can moni- been observed. The Mirai botnet is a well-known example; it at-
tor and control human health indicators and rapidly deliver reports tacks devices by exploiting default credentials (Kolias et al., 2017,
and alarms to medical personnel. The application of these devices Gupta, 2018). According to Proofpoint, more than 25% of the bot-
is saving many lives. According to (Tewari and Gupta, 2017), the net’s targets were smart TVs, baby monitors and other smart home
total worth of all existing IoT devices is valued at around $6.2 tril- devices (Stergiou et al., 2018). Hundreds of IoT devices have been
lion, most of which is deployed in healthcare applications. corrupted and forced to launch Denial of Service (DoS) attacks on
Moreover, IoT technology is considered to be one of the main critical servers. These attacks use Domain Name Service (DNS) and
components in the up-and-coming trend of smart cities. Many Network Time Protocol (NTP) as a form of distributed DoS (DDoS)
studies have discussed the various uses of IoT in shaping health- attack. One study reported that the main reason the Mirai botnet
ier building structures, managing waste, monitoring noise, control- is so effective is the use of low-cost, easy-to-install IoT devices, de-
ling smart lighting and even relieving traffic (Zanella et al., 2014). veloped with little or no concern for security (Jerkins, 2017).
Testing the security of IoT devices before introducing them to
the market is an important step in product development, and this
∗
is a field in which testbeds can be extremely useful. A security
Corresponding author.
E-mail addresses: u17105683@sharjah.ac.ae, omniamohamedalmutasim@hotmail.
testbed is a predefined testing environment in which all triggers,
com (O. Abu Waraga), u17105766@sharjah.ac.ae (M. Bettayeb), nasir@sharjah.ac.ae tests, attacks and devices are controlled (Cao et al., 2015). Testbeds
(Q. Nasir), mtalib@sharjah.ac.ae (M. Abu Talib). are isolated to prevent interference from surrounding noise. They
https://doi.org/10.1016/j.cose.2019.101648
0167-4048/© 2019 Elsevier Ltd. All rights reserved.
2 O. Abu Waraga, M. Bettayeb and Q. Nasir et al. / Computers & Security 88 (2020) 101648
perform comprehensive vulnerability assessments on devices using trast, the smart bulb is an example of an IoT device that publishes
penetration testing tools within certain environmental conditions. its updated status in the network (advertisements). Such devices
Generally, testbeds consist of an array of software and hardware can usually be configured by using a mobile application that con-
tools working with simulators to change environmental settings nects directly to the IoT device through a Wireless Local Network
such as light, time, GPS location, etc. They assess the device’s vul- (WLAN) or by connecting to the vendor server. Due to the different
nerabilities under real-world conditions and analyze its behavior to structures of the two IoT devices, the tests conducted by the pro-
detect any malicious applications. Testbeds can specify various pa- posed testbed are different as well. It is the role of the automated
rameters to assess different security aspects. They examine the IoT testbed to identify the device type and the services hosted in every
device’s response to each test in order to draw conclusions about port in order to launch the appropriate test attack. In our experi-
the device’s weaknesses and vulnerabilities. ment, we reported that the wireless camera is vulnerable due to
According to Murad et al. (2018), testing IoT devices can be the fact that it sends user credentials in plain text with no encryp-
challenging due to the characteristics and limitations of these de- tion, and due to the fact that it does not use certificates. As for
vices. The next section of this paper is a comprehensive litera- the smart bulb, it is vulnerable to replay attacks, as it accepted re-
ture review presenting studies that attempt to analyze IoT device peated packets from nodes in the network other than the authen-
vulnerabilities and discussing the tests developed for each prod- ticated user.
uct. Some researchers have introduced structures for IoT security The structure of this research paper is as follows: Section 2 is
testbeds, but few of these designs were implemented. To the best a comprehensive review of the literature on IoT security and mit-
of our knowledge, one of the most comprehensive IoT security igation attempts including testbeds. Section 3 presents the re-
testbeds was implemented and developed by Siboni et al. (2018). quirements and structure of our proposed IoT security testbed.
They introduced a testbed structure and implementation plan for The setup for the proposed testbed is shown in Section 4.
testing IoT devices, using a closed-source tool as a testbed orches- Section 5 demonstrates a full implementation of our testbed and
tra. However, their testbed lacks scalability, making it difficult to shows its capabilities by testing two IoT devices and analyzing the
add more tests. The aim of this paper is to design an automated IoT results. Finally, some recommendations and future plans are sug-
security testbed that is comprehensive, easy to use and repeatable, gested in Section 6.
using only open-source tools. The testbed has a modular structure
so that tests can be added without affecting the testbed’s structure 2. Comprehensive study on IoT security analysis
and behavior. This testbed will assess the security of IoT products
that are fully functional and ready to be used. The main goal of Markets nowadays promote various types of IoT devices and
this testbed is to identify the minimum security level of IoT prod- products—smart cameras, smart plugs, etc.—some of which have
ucts. severe security issues. Many security researchers have conducted
The practical implications of our product are that it can be used vulnerability assessments for IoT products, which we discuss in
by IoT pen-testers and product manufacturers to assess the secu- this section.
rity of IoT devices before they are distributed. It can also be used
by market regulators to set a minimum level of security for IoT 2.1. IoT vulnerabilities
devices sold on the market. The modular nature of our software
also allows researchers to extend the system and add their own Several researchers have investigated security breaches in IoT
test cases to the IoT testbed, making it a powerful tool for research devices in order to assess their security mechanisms and identify
and experimentation. We are providing the IoT security testbed as all potential vulnerabilities (Ly and Jin, 2016, Wurm et al., 2016,
a service for individuals from academia and industry, and for smart Tabrizi and Pattabiraman, 2016, Kim et al., 2010, Ur et al., 2013,
home IoT end users. The implementation results in Section 5 show Ho et al., 2016, Chistiakov, 2017, Hernandez et al., 2014, Oren and
the testbed’s effectiveness at detecting the vulnerabilities of IoT de- Keromytis, 2014, Denning and Kohno, 2013). Section 2.1 concen-
vices. trates on the weaknesses found in IoT products in the academic
The main contributions of this paper are to: literature.
A case study on the security of the August Smart Lock was done
• Conduct a comprehensive analysis of previous studies on IoT
by Ye et al. (2017). The study analyzed the device’s vulnerabili-
device security stating what tools were used on which de-
ties, which include exposure of the device’s handshake key and the
vices and what vulnerabilities were found.
owner’s account data and personal information, as well as suscep-
• Introduce a survey of IoT-based security testbeds introduced
tibility to Denial of Service (DoS) attacks. Methods to defend the
in the research literature.
devices against these attacks were conducted in the study in an
• Define a structure for building an IoT security testbed to
effort to improve the device’s security. In another study, Ly and
assess the vulnerabilities of IoT devices using open source
Jin (2016) analyzed the problem of user information leakage. They
tools.
examined the firmware of tech wristbands including the Nike+ Fu-
• Introduce an automated testbed that reduces user interac-
elband, the Huawei band, the Xiaomi Mi band and the Codoon
tion. This will guarantee that all connected devices are au-
band and found insufficient security causing leakage of user infor-
thenticated in order to meet security requirements. It will
mation.
report attacks against devices as well as against the testbed
Another IoT device that has been the focus of security testing
itself. In addition, it is designed to monitor communication
is the smart meter. Two research teams, Wurm et al. (2016) and
within the testbed and with outboard connections. It aborts
Tabrizi and Pattabiraman (2016), both published studies in which
upon detecting malicious activity.
they simulated smart meter functionalities and launched con-
• Demonstrate the functionality of the fully implemented au-
trolled attacks to discover the device’s weak points. Tabrizi and
tomated testbed by testing two IoT devices: a wireless cam-
Pattabiraman (2016) proposed solutions to improve the device’s
era and a smart bulb.
security, while Tabrizi and Pattabiraman (2016) added an analysis
Our automated testbed is used on two IoT devices: a wireless tool to enable users to detect malicious activity.
camera and a smart bulb. The wireless camera is an example of an Smart lock security has also grabbed the attention of re-
IoT device that hosts a web server to provide its services. The de- searchers (Kim et al., 2010, Ur et al., 2013, Ho et al., 2016,
vice is configured via a web page hosted in the web server. In con- Chistiakov, 2017), many of whom have analyzed the various risks
O. Abu Waraga, M. Bettayeb and Q. Nasir et al. / Computers & Security 88 (2020) 101648 3
associated with these IoT devices. Some of the smart locks under they used the Joint Testing Action Group (JTAG) for hardware anal-
scrutiny exposed sensitive user information, while others could be ysis. Willingham and Henderson (2018) focused on assessing the
controlled by unauthorized devices. To solve the access control is- security of BLE devices. They tested the security of smart watches
sue, Kim et al. (2010) suggested that modern smart locks should manually using Wireshark, Kismet and Crackle.
have the following control levels: full, restricted, partial and min- Table 1 shows a summary of the research conducted to assess
imal. Chistiakov (2017) developed a new security design for smart the vulnerabilities of IoT products though attacks. The table lists
locks using an Electrically Erasable Programmable Read-Only Mem- the topic of each paper and the IoT products that were analyzed.
ory (EEPROM) chip. The improved design included user authentica- The table also lists the tools used and the attacks conducted in the
tion over the Hypertext Transfer Protocol Secure (HTTPS) channel. research papers, as well as the results and findings of each attack.
The Smart Nest Learning Thermostat is another smart home
device that has been analyzed by researchers. In their study, 2.2. Vulnerability mitigation techniques and security testbeds
Hernandez et al. (2014) tested the device by booting a mali-
cious image through a USB port. In another paper, Oren and To mitigate security holes, researchers have developed defense
Keromytis (2014) discovered attacks on smart TVs that targeted the methodologies. Some researchers, such as Prokofiev et al. (2018),
devices’ communication protocols. proposed tools that can detect attacks in advance. They intro-
With the emergence of IoT technology, another concept enter- duced a logistic regression method that analyzes IoT devices and
ing the market is smart home technology, which enables wire- their network characteristics to assess the probability of botnet
less control of doors, lights and other appliances. According to attacks on IoT devices. Gegick and Williams (2005) compiled at-
Denning and Kohno (2013), these types of home devices are vul- tack patterns that highlight security issues in software design and
nerable to attacks due to the lack of a professional administrator. found that matching these patterns to security threats in the de-
Studies by Denning et al. (2013) and Ur et al. (2014) have analyzed sign phase helps to prevent threats early. Miettinen et al. (2017) in-
access control policies and threats associated with these types of troduced a framework to secure vulnerable devices by identify-
devices. They also discussed possible attacks on smart home de- ing devices connected to a network using network traffic finger-
vices such as data destruction, illegal physical entry and attacks of printing and machine learning techniques. This is useful in in-
privacy violation. They showed how such attacks could reduce the creasing or decreasing the security restriction level on connected
security level of home devices. devices.
As the number of IoT devices deployed in homes increases, con- As discussed earlier, smart home security is essential.
trolling these devices becomes progressively more complicated be- Demetriou et al. (2017) increased security in the home envi-
cause each device uses a separate mobile application. This issue ronment by creating a software-defined network (SDN) that
can be resolved with a smart home system, such as Samsung’s categorizes IoT devices as nodes and smartphones as monitors to
SmartThings or Apple’s HomeKit, which controls all devices effi- check node behavior. Gelenbe et al. (2018) proposed SerIoT, an IoT
ciently using a single app. platform based on SDN and secure routers.
The analysis of Samsung SmartThings by Another important focus of recent research was testbed as-
Fernandes et al. (2016) identified four possible attacks that sessments. Generally, IoT testbeds analyze various aspects of IoT,
could be launched against IoT device control applications. These but they do not specifically address device security. According
included creating backdoors in mobile apps, snooping door-lock to Chernyshev et al. (2018) and Adjih et al. (2015), sometimes
pin codes, disabling protection setups and generating fake alarms. testbeds are used experimentally as a substitute for IoT simulators.
In addition, Gyory and Chuah (2017) found security bugs in Smart- For example, FIT IoT-LAB is a testbed for low-power wireless de-
Things that gave a third party privileged access to the system. vices used in conjunction with mobile robots for large-scale envi-
The researchers solved this issue by proposing IoT ONE, an open- ronment experiments. The resulting heterogeneous testing system
source automation platform developed by openHab that supports covers many IoT case studies and applications.
a number of IoT devices along with Z-wave, Zigbee and Wi-Fi pro- Nevertheless, to gain a more general understanding of IoT de-
tocols. However, openHab is not compatible with all SmartThings vice exploits and vulnerabilities, many researchers used security
devices. Ammar et al. (2018) also conducted a comprehensive testbeds. Berhanu et al. (2013) illustrated a testbed for securing IoT
analysis on Samsung SmartThings and Apple HomeKit, as well as devices in eHealth applications. For example, many low-power de-
IoT frameworks such as AWS IoT Amazon and Azure IoT Microsoft. vices communicate by receiving and forwarding patient indicators
Studies by Fernandez et al. (2007) and using low-rate communication media. The researchers developed a
Alghamdi et al. (2013) examined the security drawbacks of scenario for the assessment and validation of context-aware adap-
network protocols, which have been the target of attacks in re- tive security solutions for eHealth.
cent years. Fernandez et al. (2007) studied DoS attack patterns Moreover, Sachidananda et al. (2017) introduced a security
on VoIP networks and improved the security structure of the testbed to analyze the security issues of IoT devices. This testbed
protocol, but their improvement requires effort to be applied. specified architecture and design requirements to support the de-
Alghamdi et al. (2013) examined the security drawbacks of the velopment of penetration testing for security analysis. The pen-
Constrained Application Protocol (CoAP), which is an application etration testing included port scanning, fingerprinting, process
layer for constrained IoT devices. enumeration and vulnerability scanning. They conducted testing
Other researchers have launched attacks on IoT devices in or- based on the security holes in the IoT device market (i.e. Ama-
der to investigate potential security weaknesses (Wurm et al., 2016, zon Echo, Nest Cam, Philips Hue, SENSE Mother, Samsung Smart-
Cyr et al., 2014, Moody and Hunter, 2016, Ronen and Shamir, 2016). Things, Withings HOME, WeMo Smart Crock-Pot and Netatmo Se-
Cyr et al. (2014) conducted network analyses and firmware anal- curity Camera). The testbed included various IoT devices such as
yses on smart watches, while also checking for mobile app vul- smart home devices, smart wearables and Wireless Sensor Net-
nerabilities. The authors traced the user’s private address from the works (WSNs), which were tested according to security require-
IoT device, captured the key exchange, reverse-engineered the mo- ments. In terms of testbed control and management, their testbed
bile app, monitored traffic between the app and the Fitbit server uses NI TestStand software to manage testbed events and pro-
and used proxy Transport Layer Security (TLS) traffic to intercept cesses. NI TestStand is a closed source software that runs exclu-
and extract data. The authors used various tools including Uber- sively on Windows OS which is heavily restrictive and proprietary.
tooth, Wireshark, crackle, APK Extractor and dex2jar. Moreover, This prevents tests from managing wireless cards, passive capture
Table 1
Conducted IoT attacks and results.
Ref. Year Summary Products tested Tools Attacks Results
Cyr et al. (2014) 2014 • Analyzed smart • Fitbit smart watch. • JTAG • Trace private • MAC address is traceable.
watches by network • Ubertooth addresses. • Key exchange is not
analysis, firmware • Wireshark • Capture key exposed.
analysis. • Crackle exchange. • TLS was replaced
• Assessment of • APK Extractor • Reverse engineer through a proxy to extract
mobile app • Backsmali mobile app. clear text credentials.
vulnerabilities. • dex2jar • Monitor traffic
between app and Fitbit
server and intercept
TLS traffic with proxy.
Arias et al. (2015) 2015 • Created a Trojan • Nest Thermostat - • Hardware access on • Firmware and checksum
Horse that exposed • Nike+ Fuelband Nike+ FuelBand. modifiable.
devices to an • Physical tamper for
external IP address Nest to get backdoor.
to be attacked by a
server.
• Accessed devices
physically to change
firmware.
Bachy et al. (2015) 2015 • Multiple attacks on • Smart TV – 4 types. • Binwalk • Compromise devices • Firmware is updated in
smart TV by in public network an unsecured channel,
intercepting channel ADSL to extract making it prone to
or attacking apps firmware. firmware modification
running on the TV. • Apply XSS attacks on attack.
web browser.
Moody and 2016 • Used Kiddie Scripts • Nest thermostat. • Kiddie scripts • Physical access to • Failure to gain root
Hunter (2016) (tool for non-IT • Wireshark gain credentials. access.
practitioners) to • Ettercap • Packet analysis. • Communication was
exploit devices. • Forensic encrypted with AES128
• Toolkit (FTK) encryption.
• Autopsy
Wurm et al. (2016) 2016 • Analyzed security • Haier Smart Care • Wireshark, UART. • Obtain password • Telnet credentials were
of Haier home home automation with brute force exposed by root shell
systems through system. attack. access.
different attacks. • Gain root shell by • Firmware updates were
accessing UART. sent in clear text.
• Analyze network • Reversed firmware
analysis and reverse exposed details about
engineer firmware on device’s MQTT
air. information.
Ronen and Shamir 2016 • Analyzed smart • Limitless LED • Introduced their • Eavesdrop control • Private data were
(2016) bulb security issues • Philips Lux own receiver. packets. exposed during MITM
and attempted to • Extract secret attack.
gain control from information using API.
100 meters away.
Sivaraman et al. (2016) 2016 • Injected malware • Dlink • iOS App • Search nearby LANs • Use SSDP to collect
in an iOS mobile app • DCS-5500G camera. • a cloud- hosted to find devices. device responses in LAN
to discover BLE and • WeMO plug server to receive • Expose those devices and analyze them to check
wireless IoT devices • Netgear Nighthawk scan results from to a public IP address. for IoT devices.
with a server. R7000 AP [Emulated] the app. • Exposed devices enabled
• Devices exposed to server to attack devices.
external IP using
UPnP were attacked
by server.
Morgner et al. (2016) 2016 • Leverage insecurity • Philips Hue • Ubertooth • DoS attack. • ZLL devices vulnerable to
of Zigbee light link • Osram Lightify spectrum analyzer • Reset device attack. command injection, DoS
(ZLL) to attack smart • GE Link • Network hijacking. and device reset attacks.
bulbs. • Command injection • New passwords injected
attacks. by attackers as master
keys.
Ling et al. (2017) 2017 • Reversed • Socket Edimax plug. • Special attacking • Device scanning. • Insecure communication
communication of scripts written in • Brute force. protocols.
smart socket. python • Spoofing. • Lack of device
• Firmware authentication.
modification attack • Weak password policy.
Ling et al. (2017) 2017 • Analyzed • Edimax IP camera - • Scan online devices • The camera exposed its
communication system. by enumerating all connection status
protocols and possible MAC (online/offline).
architecture of combinations. • Vulnerable to brute force.
Edimax IP camera • Brute force device • Spoof attack can
and extracted credentials. impersonate real cameras
vulnerabilities. • Emulate victim to get authentication
camera to fool information.
authentication server.
(continued on next page)
Table 1 (continued)
Ref. Year Summary Products tested Tools Attacks Results
Seralathan et al. (2018) 2018 • Analyzed IP camera • IP Cameras • Nmap • Perform network • RTSP port found to
traffic. • Wireshark analysis and MITM. expose real-time streams
• Brute force port RTSP that can send commands.
to get video streams. • Commands/ credentials
• Reverse engineer sent in clear text.
mobile app. • Failed to get video
streams.
• Credentials in mobile
app are in clear text.
Huraj et al. (2018) 2018 • Created a reflected • IP camera • Hping3 tool. • Flood UDP DoS attack • Victim device services
UDP-based DoS • Philips Hue Bridge using victim’s IP. were not affected.
attack using IoT • AirLive Wireless
devices. Printer
• Raspberry Pi
Siboni et al. (2018) 2018 • Compromised • WiFi Printer. • Wireshark • De-authenticate • Successfully received
smart watch to • Printer Command legitimate printer and printing orders from
impersonate a WiFi Language (PCL) host fake AP. devices in network.
printer. • Airoplay
Xu et al. (2018) 2018 • Used Insecam • Different IP cameras • Angry IP (for • Checked open-access • Many IP cameras did not
website to retrieve taken from Insecam scanning domains). devices. have passwords set.
open cameras with website.
live streams.
Classen et al. (2018) 2018 • Analyzed many • Fitbit smartwatch • APKtool • Leak information. • Information leakage.
security • Gatttool • Analyze firmware • Injecting compromised
vulnerabilities and • Many others and modify protocols. firmware.
attacks on Fitbit • Modify Fitbit mobile • Modifying app to access
smartwatch. app to access cloud. developer mode and gain
access to cloud.
Willingham et al. 2018 • Find exploits in the • FitBit Charge • Wireshark • Packet sniffing • Ubertooth was not able
(2018) BLE protocol through • Logitech Keyboard • Kismet to read personal data.
testing smartwatches • LG watch • Crackle • Due to unawareness
using Kali Linux and packet, format packets
Ubertooth were not understandable.
of packets and other network or low-level functionalities, which is 1. The implemented IoT security testbed is based on open
considered a huge drawback as it limits network penetration test- source tools controlled by an open source Managment Sys-
ing capabilities. tem (MS).
Hale et al. (2018) proposes an open source platform called Se- 2. The IoT security testbed consists of an interface module, a
cuWear which identifies the vulnerabilities of commercial hard- testing module, a network module, a report module and a
ware. The SecuWear testbed captures the information necessary storage module. All modules interact to perform as a com-
for identifying different attacks, thereby assessing the security plete security testing software. They are controlled by the
of wearable devices. Moreover, it provides to the security com- MS and their updates are displayed to the user via an easy-
munity a process for performing attacks and mitigating infor- to-use GUI.
mation. The disadvantage of SecuWear is that identified vulner- 3. The modular structure and architecture of the testbed allows
abilities on Metawear must still be investigated in commercial other researchers to use it to build their own testing tools. It
IoT devices to determine if they apply. Furthermore, vulnerabil- is a flexible and extendible system, meaning that researchers
ities may be specific to certain open source components, caus- can adopt the initial structure and add to the modular de-
ing false positives when identifying security issues as common sign.
problems. 4. The IoT testbed lists all exploits and CVEs found for the de-
Table 2 summarizes the findings of our research on IoT secu- vice tested, as well as for the services the device hosts in
rity testbeds and compares it with our IoT security testbed. This each port. For example: OpenSSH 7.6 service on port 22 Se-
comparison is based on the testbed’s approach, the hardware setup cure Shell (SSH).
required to build the testbed, the devices tested, the attacks per- 5. The IoT testbed automatically generates formal word reports
formed by the testbed and the software tools used. Information is containing the results of all devices.
also included about whether or not the testbeds are automated,
the availability of a Management System (MS) that controls the
3. Testbed requirements, structure and components
testbed, and whether or not the MS is open source (OS), as well
as the existence of Wi-Fi and BLE options.
Building a security testbed for IoT devices requires defining the
main area of interest and developing a roadmap for the analy-
2.3. Our testbed contribution sis process. In this section, we propose an automated IoT testbed
structure to assess the vulnerabilities of IoT devices. This structure
In this paper, we propose an automated IoT security testbed automates the penetration testing task, thereby reducing user in-
that can evaluate the security of IoT devices. We also define its tervention. Our objective is to build a secure IoT testbed that tests
main components and structure. As the testbed leverages open devices from various security aspects. The testbed should:
source tools, it is easily modifiable and extendible. The model will
be tested on two off-the-shelf IoT devices. Later in this paper, we • Establish secure communication between testbed compo-
analyze the results and discuss vulnerability reports. Our IoT secu- nents
rity testbed has the following features: • Authenticate all nodes in the network
6
Table 2
Literature review of IoT security testbeds.
Ref. Year Testbed approach Hardware Setup Devices tested Attacks and experiments SOFTWARE Auto- MS OS Wi-Fi BLE
O. Abu Waraga, M. Bettayeb and Q. Nasir et al. / Computers & Security 88 (2020) 101648
covered mated
√ √
Tekeoglu and 2016 • Analyze captured • A hub that connects 2 • HDMI sticks • Nmap • Iptables ✗ ✗ -
Tosun (2016) packets from network access points • Wireless cameras • Cipher suit checks • Ebtables
layers 2 and 3. • Kali Linux machine • Drones • Firmware updates in • Wireshark
• Ubertooth with • Activity trackers clear text • Kismet
Wireshark in another • Smart watches • Weak password checks • OpenWrt
machine • Brute force detection • OpenVAS
• Smartphones to control checks • Binwalk
the IoTs from a different • Extracts video streams
WLAN from cameras
√ √ √ √
Sachidananda et al. 2017 • Penetration testing • Uses the closed source NI • Nest Cam • Port scanning • NMAP ✗
(2017) for security analysis. TestStand tool. • Philips Hue • Fingerprinting • Wireshark
• Amazon Echo • Process enumeration • Aircrack
• SENSE Mother • Nessus
• Samsung • OpenVAS
SmartThings • Cain & Abel
• Others • OSSEC
• Tenable
√ √
Hale et al. (2018) 2018 • Identify security risks • SecuWear with Metawear • Metawear only • Eavesdropping attack • Wireshark ✗ ✗ -
in wearable IoT chip (development chip • DoS attack
devices by using • Kali Linux simulating BLE
Metawear. • Ubertooth devices)
√ √ √ √ √
Our Proposed IoT 2019 • Develop an IoT • Multiple modules: • Smart Bulb • Port scanning • Nmap
Testbed penetration testing º GUI • IP camera • Vulnerability scans • Tshark
platform to assess º Testing • Downgrading attack • Metasploit
risks and º Network monitoring • Search exploits • WAFW00F
vulnerabilities of IoT º Reporting • Brute force directories, • SQLmap
devices º Storage passwords and port • SSLStrip
services • Dirb
• Testing SSL configuration. • SSL Scan
• Nikto
• TLS proper
Fig. 1. Structure of the proposed IoT Testbed.
• Control test modules and test sequencing

• Record events and test results
• Establish reusable tests and testbed components
• Ensure scalability of the testbed, enabling more tests to be
added
3.1. . Testbed structure
Our testbed uses a modular architecture, whereby every part

of the testbed is made of modules that can be extended or even
replaced completely. The structure also allows for the easy addition
of more security tests.
The initial testbed structure consists of five modules, as shown
in Fig. 1.
• Interface Module: This module acts as an I/O interface. It

consists of two units: a Graphical User Interface (GUI) unit
and an Output unit. The GUI takes input feeds from users
(when required) and delivers them to the Testing Module
for analysis. This method reduces user intervention during
the testing process. When the analysis is complete, a sum-
marized report is generated by the Report Module and sent
to the user. Fig. 2. IoT testbed components.
• Testing Module: This module manages the test cases and
launches them in order. All test cases and scripts are saved
mation about the tested devices and stores the test case
in the Storage Module. Once the testbed is in operation, it
scripts.
calls up general scripts from the database to examine the
general network characteristics of the IoT devices. Based on
3.2. Testbed main components
the device’s response, the testing module launches more ad-
vanced test cases to tackle security issues. For example, af-
In terms of function, our proposed automated testbed relies
ter recognizing any open ports in the IoT device, dedicated
on five components that use the testbed structure modules.
test cases will be launched to test the vulnerability of those
Fig. 2 summarizes the testbed components and their roles.
ports. Such vulnerabilities can include outdated services or
The testbed has the following five main functional components:
low-security configuration or authentication. Moreover, IoT
device responses will be checked to determine whether each • IoT Device Under Investigation (DUI). This is the IoT device
test case passed or failed. to be tested, such as a smart socket, smart wireless cam-
• Network Module: This module controls network activities era, etc. It will be connected to the wireless network of the
and communication with IoT devices. It creates and monitors testbed.
the Network Access Point (AP) and will be further discussed • Admin Machine. This is the main component of the secu-
in Section 3.2. rity testbed that runs the Kali Linux operating system. Using
• Report Module: This module generates a final report of the the Network Module, it audits all network traffic and exam-
security assessment results for the device. It is compiled ines packets in the network. It also sends an alert if any type
from test results and logs. of attack is detected using python scripts and Tshark. Any
• Storage Module: This unit stores all events initiated by the IP address requested by the DUI will be checked against IP
different modules for later retrieval and for final report gen- blacklists to determine whether or not it is malicious. Mali-
eration once the assessment is complete. It saves all infor- cious calls will be blocked and reported. Moreover, the ad-
min machine acts as an orchestra, using the Testing Mod- The formal report is a word file generated by a python script
ule to launch and coordinate test scenarios. Once a test is listing the test results in a format that is easy for a human opera-
launched, its results are analyzed to determine which test tor to understand. A sample report is shown in Fig. 4. The report
should be run next. The storage module stores information lists device information in a table, including its detected Operating
about all registered devices in the testbed, blocking unregis- System and port services. It also lists all CVEs and exploits found
tered devices from the network. using the device model number or device name. Additionally, as all
• Private Wireless Network. Usually, testbeds use wireless ports are scanned during the testing process, any services found in
routers to simulate network environments. Sniffing software the device’s open ports will be checked on the CVE and exploits
is then deployed to collect data broadcast over the local net- databases. The test results are then listed in the results section of
work. To acquire more information or packets between two the report. The Test Case column lists all tests launched against the
nodes in the network, interception tools such as Address IoT device, while the Test Result column informs the reader of the
Resolution Protocol (ARP) spoofing are used to launch an at- results of each test. The test result is listed as Not Vulnerable if
tack. Based on our experiments, new IoT devices detect ARP the device was not found to be vulnerable to the test and Vulnera-
spoofing attacks and disconnect automatically from the net- ble if the device was vulnerable. The Assessment column includes
work once they are discovered. Using the admin machine, a short comments generated by each test. Furthermore, some of the
Wireless hotspot is created using a virtual AP tool to create a complex tests generate extra logs and save them in a separate text
Wireless Local Access Network (WLAN). This method is pre- file to be reviewed later by the operator. Some tests don’t generate
ferred over using a physical router, as it gives the testbed au- any logs; these simply enter a dash (-) in the Additional Informa-
tomation system privileged access to Dynamic Host Config- tion column. If necessary, tests can be modified in the future to
uration Protocol (DHCP) server services and other function- include more comments.
alities in the AP. It therefore allows the testbed to audit net- In Section 4, we will focus on the testing mechanisms and tools
work traffic with administrative privilege to circumvent the that check the security aspects of IoT devices.
need for ARP Spoofing. The virtual AP tool provides commu-
nication encryption and security using the WPA2-PSK Wi-Fi 4. Experimental setup
key managed by the network module. In addition, it mon-
itors the outboard connection of the DUI. In other words, In this section, we demonstrate how the testbed architecture
the module checks all external IP addresses requested by the and components are used to test the security of IoT devices. Our
DUI against a collection of blacklisted IPs to prevent mal- experiments are conducted in two phases: a semi-manual Exten-
ware from attempting to connect to Command and Control sive Analysis Phase and an Automated Testing Phase. Analyzing the
(CNC) servers. If the device is already infected by malware, threads of IoT devices is a very complicated task, as pen-testing the
it will be detected and the device will be excluded from the devices involves testing the security of communications between
network. This countermeasure fulfills the security require- IoT devices and smartphones, as well as between IoT devices and
ments of the testbed. the cloud. It also requires testing the vulnerabilities of the IoT de-
• Controlling Applications. Some IoT devices can only be vice itself, and testing the effect of physical tampering. The process
controlled through their associated mobile application. The by which communications are sent and received by IoT devices—a
testbed therefore includes a smartphone device that is potential source of vulnerability—is shown in Fig. 5. The devil im-
equipped with authorized mobile applications to control IoT age represents hackers and their possible points of attack.
devices under testing. It generates traffic and packets with The first phase is conducted to understand the nature of the
controlling commands on the network, and can be used to IoT device, its communication characteristics, its possible vulnera-
check whether or not the controlling commands and mes- bilities and the used tools to detect them. This information is then
sages are sent in clear text, i.e. readable by attackers. In ad- used to shape the second phase: an extensive automatized secu-
dition, it replicates packets to form replay attacks, thereby rity analysis of the IoT device. Table 3 sets a comparison between
revealing weaknesses in IoT devices. these two phases. The comparison is based on testing setup, ex-
• Attacking Machine. The attacking machine (Kali Linux) is pected results in each phase and the method used to obtain the
used to launch attacks against the DUI to uncover weak- results.
nesses. For instance, it can launch replay attacks or brute
force password attacks. In addition, it runs DoS attacks 4.1. Phase 1- extensive analysis phase
against the testbed and the DUI to test their resistance and
ability to block such attacks. The first testing phase investigates the security of IoT devices
using the following steps, summarized below in Table 4:
• Gather information and scan for vulnerabilities. Before
To give a better idea of how the testbed modules cooperate, testing the IoT device, it is necessary to search for device
Fig. 3 summarizes the scenario for a DUI connected to the testing vulnerabilities and any related exploit attempts. This can
network. As shown in Fig. 3, once a new device tries to connect be done using Shodan, vulnerabilities databases such as the
to the network, the testbed will check its identity by looking it up Common Vulnerabilities and Exposures database (CVE), the
in the testbed local database records. The testbed operator regis- National Vulnerabilities Database (NVD) and the Rapid7 Ex-
ters the devices to be tested in the database of the program before ploits Database, and tools such as Snitch, OWASP ZAP, Was-
starting the test. If the network module does not find the device in can, Skipfish or other similar tools. If any exploits are found
the database, the testbed will reject the device from the network. for similar devices, whether of the same type or from the
After the authorization step, the testing module launches a list same vendor, these are tested on the DUI to assess its vul-
of test cases on the DUI, analyzes the DUI test results and stores nerability.
the results in the storage module. An example of a test case is the • Perform Nmap scanning. The DUI and all its ports are
scan test script, in which the testbed software scans DUI directo- checked using the Nmap scanner to analyze the vulnerabil-
ries, seeking open directories with no authentication. This vulner- ity of any open ports. Nmap responses should be checked to
ability could lead to system intrusion and data leakage. After all ensure that the DUI doesn’t expose critical information dur-
tests have been run, test results will be listed in a formal report. ing the Nmap test.
Fig. 3. Communication between testbed modules.
Table 3
Comparison between extensive analysis phase and automated testing phase.
Research phases Set up Expected result Methodology
Phase 1: Extensive Each device is tested individually Each test will generate different Tests are done manually.
Analysis using a list of tools conducting results/outcomes. Results are obtained manually
different hacking attempts to find through analysis
the IoT device’s vulnerabilities.
Phase 2: Automated The testbed system’s software is The test results will be expressed The module’s test cases are in
Testing based on a modular structure. as Vulnerable or Not Vulnerable. If Python code. The module
Each testing module will the device passes a given test, it is analyzes the IoT device’s
automatically run a list of tests to not vulnerable in that area; if it responses to each test script
check the IoT device’s fails, the device is vulnerable to to determine if it passed or
vulnerabilities. attack. failed the security test.
Fig. 4. Sample of report generated by the IoT testbed.
Fig. 5. Points of weakness in IoT device communications.
• Check Secure Sockets Layer (SSL) certificate. The SSL cer- without any encryption at all, as is the case with HTTP. This
tificate is tested to see if a DUI that hosts a web server has test forces communications to downgrade from HTTPS to
a reliable certificate. This can be checked using TLS-proper, HTTP using SSLStrip, Ettercap, Better-cap, etc. If a conversa-
SSLScan and Nikto tools. tion is successfully downgraded, critical information such as
• Check asynchronous connection with a time server. This credentials and control packets may be collected by a third
test checks if the IoT device is synchronized with a time party. If the device refuses the downgrade and rejects any
server. If this test fails, the resulting vulnerability could non-HTTPS connections, it is considered a secure device.
make it hard to track its system logs and events, and also • Perform credentials check and brute force attacks. An-
to perform operations that require timestamps and synchro- other potential vulnerability that must be tested is the use
nization. of default credentials. As mentioned earlier, Mirai botnets
• Perform downgrading attack. This attack focuses on re- have been known to gain control over devices with default
ducing the level of cryptography used in the communi- credentials. If users are not forced to change the default
cation channels between two nodes (Alashwali and Ras- password during configuration, the resulting vulnerability is
mussen, 2018). Reducing the level of encryption used in the a severe issue. Another potential issue is when IoT devices
secure channel can result in the device sending information allow an unlimited number of false access trials. Limiting ac-
Table 4
Summary of the test cases and their expected results.
Tests Used tools Expected results
Gather information and scan Snitch, OWASP ZAP, Gathers information about the DUI’s vulnerabilities or about previous attack attempts
for vulnerabilities Wascan, Skipfish recorded in the CVE database. Wascam and Skipfish are security penetration testing
tools that recursively crawl web pages hosted in webservers. They assess security and
look for vulnerabilities such as flaws, links, email addresses and any other information
that could lead to social engineering, malware injections, etc.
Nmap scanning Nmap Lists all open ports along with their services and DUI information. DUI information
could include the operating system running on the device, its version number, etc.
Check Secure Sockets Layer TL S-proper, SSL Scan and Compares the HTTPS certificate signature to the database. This reveals information about
certificate Nikto tools the certificate such as the encryption used, the generation date, etc.
Check asynchronous Wireshark If the device fails to synchronize with the NTP server during multiple connection
connection with a time requests, it is considered vulnerable.
server
Downgrade Attack SSLStrip, Ettercap, If the device refuses the HTTP connection/request, then it is not vulnerable. If the device
Better-cap accepts an HTTP request (instead of HTTPS), it is vulnerable to this kind of attack.
Credentials check and brute Python Script Attempts to authenticate user by sending many usernames and passwords. If the device
force attacks doesn’t detect the attack or if the password is found, the device is vulnerable to this
kind of attack.
Brute force attack on Dirb and DirBuster Lists directories that are accessible without authentication, indicating that the device is
directories vulnerable.
Bypass basic HTTP Web browser plugin (HTTP Sends misconfigured http header to check for possible configurations that may give
authentication headers access.
Inject XSS and SQL SQLmap, Manual If XSS or SQL injection attempts successfully reveal hidden information, the device is
commands vulnerable.
Check firewalls WAFWoof Checks whether or not firewall is used
Check exploits Metasploit and Armitage Reports any attacks and vulnerabilities in the IoT device found by Metasploit.
Analyze communication Wireshark, Manually If control packets are sent between the user machine and the DUI in clear text without
between IoT device and user encryption, the device is vulnerable.
machine
Check requested external IP Wireshark, manually If the device attempts to connect to malicious servers, it is considered vulnerable.
addresses
Disassemble mobile Dex2jar If the dissembled mobile application contains hard-coded credentials, it is considered
application vulnerable.
Firmware check Binwalk Outdated firmware is usually vulnerable. The firmware is therefore checked to ensure
that the device is using the latest version.
Hardware analysis UART This test attempts to dump firmware from the hardware using UART in order to obtain
root shell and access sensitive information
cess trials prevents brute force attacks. These are all aspects form an attack. Existing exploits on devices similar to the
that we can test using a simple python script. DUI can be checked using Metasploit and Armitage tools.
• Conduct brute force attack on directories. If the DUI is • Analyze communication between the IoT device and the
hosting a web server, this server could have multiple di- user machine. In this task, we intercept the communication
rectories. Even if it has credentials, it’s possible that not between the IoT device and the user’s machine. First, traf-
all directories will be protected. To check if any directories fic will be generated by using a mobile application (or the
are left without credentials, the testbed uses a dictionary to browser, if the device contains a web server) to control the
conduct a brute force attack using Dirb and DirBuster tools. IoT device. This allows us to check if communication occurs
• Bypass basic HTTP authentication. Some web servers use in clear text, and whether the device is vulnerable to replay,
HTTP basic authentication to obtain user credentials. HTTP impersonation or modification attacks. In addition, this task
requests can use POST and GET methods. If servers are detects if any credentials are sent in clear text.
weakly configured, they may bypass HTTP authentication re- • Check requested external IP addresses. In this test, the
quests that have HTTP methods other than GET/POST. As a testbed will report any attempt by the DUI to connect to
result, private data may be exposed or non-authenticated malicious IP addresses.
users may gain access. • Disassemble mobile application. Breaking down the mo-
• Inject XSS and SQL commands. If the DUI hosts a web bile application can give hints about control packet creation
server with an HTML interface, it could be vulnerable to XSS and expose secret information. Applications can slow down
and SQL injection attacks. This can be checked using tools reverse engineering by using obfuscation techniques, which
such as SQLmap that examine the parameters of an HTTP raises the security level in smartphone applications.
GET request to inject SQL commands. If the web server is not • Check firmware. Outdated firmware is usually vulnerable. If
protected against this type of attack, the server’s SQL service vendors do not enforce updates on an IoT device’s firmware,
may expose critical information. the device may be compromised. Analyzing firmware can
• Check firewalls. Some web servers have firewalls that pro- highlight the existence of backdoors, hardcoded admin cre-
tect them from network attacks. The firewall of the DUI web dentials or command injection vulnerabilities. Analyzing
server can be tested using a WAFWoof tool. firmware requires experience in reverse engineering.
• Check exploits. As shown in the literature review, re- • Analyze hardware. Some IoT device vendors don’t give pub-
searchers are interested in revealing the vulnerabilities of lic access to device firmware. An alternative method is ex-
different types of IoT products, and many CVEs are reported tracting the firmware from the IoT device. By disassembling
every day. Some CVEs are also publicized with a python or a the device, the printed circuit board (PCB) can be checked
bash script that takes advantage of the vulnerability to per- to find universal asynchronous receiver-transmitter (UART)
Algorithm 1 As shown in Algorithm 1, once the operator chooses one or

Automated testbed process.
more devices to be tested, the testbed assesses each one individ-
Require: DUI; Testing device; ually in turn. To test each IoT device, the testbed first excludes all
Ensure: DUI is configured with wireless network of the testbed IoT devices from the network other than the DUI. The testing mod-
1: DUI connect to the wireless network
ule then launches some initial test cases, including an extensive
2: Testbed check device information in Database
3: if not found then Nmap test to check network activity and report open ports. Based
4: Reject the device connection request on the results of these preliminary tests, the testing module will
5: return 0 determine whether or not there is a web server hosted in the IoT
6: Accept connection, allow device to be in the network device. Based on this data, the testing module will launch the cor-
7: Testbed launch Nmap on ports 80, 443, 8080
responding tests as shown in Fig. 6.
8: for Nmap results in port (80, 443, 8080) do
9: Check services on the port In non-web server cases, a replay attack is used to replay con-
10: if port has webservices then trol packets after a period of time. The control packets contain the
11: DUI = webserver commands that affect the status of the IoT device.
12: else
Fig. 7 shows the updated testbed GUI and its functionalities.
13: DUI = host
14: end if Users can choose to test multiple devices, which will be listed in
15: end for the left panel. The test updates will be shown in the middle panel:
16: if DUI = webserver then the upper part shows the test logs, while the lower table lists test
17: results = webserver_tests() summaries and results. In the right panel, the user can see net-
18: else
work traffic inside the WLAN, as well as traffic to and from the
19: results = host _tests()
20: end if DUI. In addition, the testbed lists the last connections attempted by
21: report= Generate_Report(results) the DUI. Using the proposed automated testbed architecture, vul-
22: return report nerability assessments are conducted on multiple IoT devices. In
Section 5, we discuss the use of the testbed on a wireless camera
and a smart bulb.
ports or other serial ports. If ports are found, a PC/laptop can
be connected to the IoT device to analyze its binary image 5. Automated Testbed Implementation and Discussion of
and extract its credentials, i.e. a physical tampering attack. Results
In this phase, the security of several IoT devices was assessed In this section, the proposed automated testbed architecture is
manually by using the above test cases. For an example, we will used to conduct vulnerability assessments on a wireless camera
detail the assessment of two devices: a medical gateway and a and a smart bulb, thereby demonstrating its capabilities.
wireless camera. Both devices host a webserver, but the medical
gateway leverages HTTPs for communication while the wireless 5.1. Wireless Camera Assessment
camera uses HTTP. The detailed test report for the two devices is
shown in Appendix 1. A wireless camera can send live video feeds/streams wirelessly
During the manual security assessment, the tested devices are over the internet. It can also save records locally. Cameras usually
grouped into two sets: devices that contain a web server and de- host web servers, allowing users to view live feeds and control
vices that act as hosts, connecting to a cloud or a server. The de- the camera. Many wireless camera vendors provide mobile apps
vices that host web servers can be recognized by examining the that simplify and control operations. Like other IoT devices, wire-
services available in port 80, 8080 or 443. The Nmap tool is capa- less cameras can be vulnerable on their own, but the addition of
ble of recognizing the services on the ports, as it has an extensive hosted web servers and mobile applications increase security risks.
database of service signatures. The devices can therefore be cate- IoT devices that host web servers can be attacked using the
gorized as webserver or host-based according to the Nmap results same tools used to attack standard web servers, such as XSS, SQL
for the services hosted in port 80, 8080 or 443. The devices that injection attacks, command injection, brute force attacks on direc-
host a web server can be attacked using the same mechanisms as tories/credentials/port services, etc. The resistance and defense ca-
those used against email servers and web servers. However, IoT de- pabilities of web servers hosted on IoT devices are weaker than
vices are much weaker than the regular web servers due to their standalone web servers, increasing the probability of a successful
limited power and computing capabilities, which affects their se- attack. We therefore included many penetration tests to check web
curity capabilities. server vulnerability.
An automated IoT testbed is required for this step, as it can de- To demonstrate the wireless camera security testing scenario,
tect the vulnerabilities of a group of different IoT devices automat- the steps in Fig. 8 are followed. The wireless camera is contacted to
ically without the need of human intervention. be connected to the local network. If the testbed system software
detects the camera, it tries to authorize and identify the device and
retrieves saved information from its database. Once accepted, all
4.2. Phase 2- automated testing phase traffic generated in the testbed—especially traffic originating from
the device—is monitored and analyzed, as are the device’s exter-
Automating IoT vulnerabilities assessments can be a challeng- nal connections. The fingerprints of all ports are checked with the
ing task due to the limitations of IoT devices, as explained earlier. Nmap tool to determine whether or not the device hosts a web-
Based on the experiments conducted in Section 4.1, we propose server. As the camera hosts a webserver on port 80, it is catego-
methods with different security testing scenarios for different IoT rized as a “device with embedded webserver”. The testbed runs a
devices. These scenarios will run automatically using the system predefined list of tests to check open ports and discover any web
in Fig. 1. The tests are to be conducted with minimal user inter- server vulnerabilities. Each test assesses a specific security aspect.
vention. As shown in Fig. 1, all modules work simultaneously at For example, the SQL injection test uses the SQLmap tool, which
the back end, while the GUI shows the testbed status and related injects an SQL statement into the HTML page of the web server. If
results. The various steps of the automated testing process are as the webserver executes the statement, the device is considered to
follows: be vulnerable. Similarly, the device’s SSL, firewall and certificates
Fig. 6. Tests launched for web server DUI vs non-web server DUI.
Fig. 7. Graphical user interface of the testbed.
Fig. 8. Testing for wireless camera assessment by the testbed software.

Table 5
Testbed report for wireless camera.
Test case Status Additional information Results discussion
Check Requested IPs Not Vulnerable Details of each IP are During the test, the device did not connect to any
saved malicious IP addresses; therefore, the device passed the
test. The results of each IP address request have been
exported in a separate file.
Device Sync with NTP Not Vulnerable - The device was found to be in sync with NTP server;
therefore, the DUI passed the test.
Scan Directories Not Vulnerable Details are saved As no web server directory was found to be open without
authentication, the device passed the test.
Check Firewall Vulnerable No WAF detected The testbed did not find any firewalls in the web server;
therefore, the DUI failed this security test.
Authentication in plain Vulnerable User: Pass found Authentication in plain text: When the DUI used an HTTP
text authentication mechanism, the authentication
information (Username: Password) was sent in clear text
without encryption. This is a very severe vulnerability, as
an attacker could control the device as an admin using
those credentials.
Extensive Port Scan Vulnerable - In this test, port 80 (HTTP and HTTPS) was found to be
open on the device, as well as port 23 (telnet) and 21
(FTP server). The fact that ports 21 and 23 were open
means that the device was more prone to attacks. The
testbed therefore reported that the device failed this
particular test.
Nitko Test Vulnerable Vulnerable to The Nikto web assessment tool was used to assess the
cross-site request DUI. It reported some severe vulnerabilities. Therefore,
forgery and downgrade the device failed the test.
attack
Check Certificate Vulnerable No HTTPS The DUI did not use a proper certificate in its
communications, and port 443 was found to be open and
not secured. Therefore, the device failed the test.
Check SSL Vulnerable No HTTPS The DUI did not use SSL.
SQL Injection Not Vulnerable Details are saved In this test, tools such as SQLmap are used to check if the
device is vulnerable to SQL injection. However, the DUI
used HTTP authentication rather than an HTML page and
no SQL server were found. Consequently, device was not
vulnerable to SQL injection, and it passed the test.
Table 6
Testbed report for the smart bulb.
Test case Status Additional information
Check Requested IPs Not Vulnerable Details of each IP are saved

Exploit Scan Not Vulnerable Details are saved
Replay attack – UDP Vulnerable ..
Extensive Nmap scan Not Vulnerable ..
Verification of asynchronous connection with time server Vulnerable ..
are checked. Some scripts use different approaches to determine if XSS, as long as HTTPS protocol is used in communications instead
the device is vulnerable or not. For example, the “device sync with of HTTP.
NTP server” test entails scanning all NTP packets in the device’s
communications to determine whether or not it is synchronized
with the NTP server. Each test case checks a specific characteristic 5.2. Smart bulb assessment
of the device and reports if the device passed or failed this secu-
rity check. Finally, once all the tests are done, all results will be A smart bulb is an IoT device controlled by UDP packets. It re-
reported in a word document as shown in Fig. 4. ceives controlling commands directly from users via a dedicated
Table 5 lists the test results generated by the proposed testbed application or through a server or cloud. Information is sent us-
from the wireless camera security assessment. Each test checks ing UDP or TCP packets, which are usually encrypted or ciphered.
one vulnerability. If the vulnerability is found, the report indicates However, if the messages are not secure, the bulb may be vulnera-
“Vulnerable” for that particular test. If the test found no vulnerabil- ble to replay attacks. For this reason, we test such devices against
ity in a given domain, it is listed as a “Not Vulnerable”. If a device replay attacks and packet fabrication.
receives “Not Vulnerable” for all tests, it means that no weak point We tested a smart bulb controlled by a mobile application with
was found, and the device is not vulnerable to the tests specified. our IoT security testbed. Only five tests were applicable, as the bulb
Some tests generate detailed reports in the reporting module that did not have many open ports. The testbed started by checking IP
must be reviewed by an operator, as shown in the “Additional in- addresses requested by the DUI, scanning for smart bulb exploits,
formation” column in Table 5. A column was added to the table to replaying UDP packets, performing an Nmap scan and checking
discuss the results. asynchronous connections with the time server. Conversely to the
From the test results, one can conclude that the wireless cam- multiple tests run specifically for server host devices such as the
era is vulnerable to attack, as it sends authentication credentials in smart camera, the only test uniquely dedicated to non-web server
clear text with no encryption. However, its use of an HTTP authen- devices is the replay UDP packets test. This is because the smart
tication mechanism means that it is not prone to SQL injection and bulb receives control commands through UDP packets.
The report generated from the smart bulb tests can be found in We believe that an adequate testing architecture—one that is
Table 6. The report lists a test as “Vulnerable” if an attack is suc- comprehensive enough to manage the abovementioned challenges
cessful; if the attack is unsuccessful, the test is listed as a “Not Vul- and able to handle the evolving complexity of the IoT ecosystem—
nerable”. The results show that the device is vulnerable to replay is yet to be developed. It will be interesting to see what devel-
attacks, as it applied the commands received without checking the opments take place in that direction. However, in designing our
sender’s MAC address. testbed, we think that we have taken a step in the right direc-
tion in helping to solve this difficult problem. The modular nature
6. Conclusion and future research of our testbed and the ability to easily add new tests and change
existing ones gives it the flexibility it needs to stay relevant as a
With the recent exponential increase in the use of IoT devices, security solution and to keep up with the demands of the growing
security breaches associated with these devices are also on the IoT ecosystem.
rise. IoT device security testing is needed before the devices can be Future work will include additional automated test cases and
used by the public. Assessing the security of IoT devices is difficult scenarios that tackle different aspects of IoT device security. More
due to the wide variety and functionality of IoT devices. Although IoT devices need to be analyzed in order to increase the scope of
many research studies have explored IoT security assessment, there our IoT testbed test case database. We are also looking forward to
is an urgent need for extensive analysis and testing for vulnerabil- employing artificial intelligence to improve our methods for ana-
ities, and it is clear that these tasks should be automated. The goal lyzing IoT devices and their vulnerabilities (Tables A.1 and A.2).
of this research is to propose a new IoT security testbed architec-
ture, and to present an automated IoT testbed to analyze IoT device Funding
security gaps.
Various penetration and security testing tools are leveraged to This research was funded by Dubai Electronic Security Center
assess vulnerabilities in IoT devices. The proposed framework also (DESC) and the University of Sharjah.
secures the testbed, authenticates all devices used by the testbed
and encrypts all communication between them. Furthermore, it Declaration of Competing Interest
records and logs all events that occur during the tests and gen-
erates reports informing the user if each test was passed or failed. No conflict of interest exists.
The results provide data to inform the feasibility of practical ex-
periments to assess common threats against these IoT devices. Two Acknowledgments
devices were successfully tested by our IoT testbed.
One of the biggest challenges in this domain is the exploding We are grateful to the Dubai Electronic Security Center (DESC)
number of IoT devices being used, the great variety of IoT devices for funding this research project. We also express gratitude to the
and protocols, and the lack of standardization in the field. This OpenUAE Research and Development Group for their support. The
coupled with IoT devices interacting with each other greatly in- authors thank part-time research assistant Omar Gouda, Eng., for
creases available attack vectors and the possibility of zero-day at- his technical support in building the test scripts.
tacks, making it very hard for security experts and security testing
tools to accurately assess the security level of different IoT devices. Appendix
Table A.1
Extensive analysis phase: first device - medical gateway.
Test case Description Test result Notes
Check SSL certificate Tools test the existence of SSL certificate and gain Not vulnerable SSL certificate uses OpenSSL and get TLS 1.2.
weakness more information.
Downgrade attack Force use of HTTP over HTTPs. Not vulnerable Downgrading the communication from HTTPs
to HTTP doesn’t work. The device refuses the
connection request.
Break the password Attempt to brute force the password. Not vulnerable The process takes a very long time.
Multiple logins at the same Attempt to login as admin using different devices at Vulnerable The device doesn’t reject the second access,
time the same time. nor does it notify admin of the existence of
another admin.
Directory access List directories that are accessible without Not vulnerable No directories are open.
authentication.
HTML analysis Check vulnerabilities in html code. Not vulnerable No HTML
Inject JavaScript in the URL Injecting JavaScript commands in the URL can give Not vulnerable The test is not applicable for this device.
indirect access to information.
SQL injection in HTTP Use SQL injection in HTTP requests to gain Not vulnerable The test is not applicable for this device.
request unauthorized access to saved data in the server’s
database.
Bypass base authentication Send misconfigured HTTP header to check if Not vulnerable The device doesn’t respond to misconfigured
misconfigurations exist, which might give access to HTTP requests.
authorized information.
Firewall information Tool to check the firewall used. Not applicable The web server rejects all connections.
Check Metasploit / Armtage Metasploit / Armtage checks if an attack is possible Not vulnerable No exploits
for possible exploits against the device.
Key installation attack The KRACK breaks the WPA2 protocol by forcing Vulnerable The device uses another layer of encryption,
(KRACK)– Proof of concept devices to reuse nonce during WPA2 handshake. as it uses TLS.
Optional encryption effects The attack tests if confidential information (i.e. admin Vulnerable The admin has the option of using HTTP or
password) is exposed. HTTPS in the configuration page. Once it is
chosen, credentials are sent in clear text.
Table A.2
Extensive analysis phase: second device – wireless camera.
Test case Description Test result Notes
Multiple logins at the same Attempt to log in as admin using different devices at Vulnerable The device doesn’t reject the second access,
time the same time. nor does it notify the admin with the
existence of another admin.
Multiple access attempts Try multiple passwords, which results in multiple Vulnerable DUI doesn’t block attempts, which can lead to
failed attempts. brute force or dictionary attack.
Breaking the password Attempt to get the password using dictionary attack. Vulnerable As the size of the password increases, the
time it takes to break the password increases.
Directory access Check for directories that are accessible without Not vulnerable No directories found to be accessible without
authorization. authentication.
HTML analysis Check vulnerabilities in HTML code. Not vulnerable No HTML
Inject JavaScript in URL Injecting JavaScript commands in the URL can give Not vulnerable The test is not applicable for this device.
indirect access to information.
SQL injection in HTTP Injecting SQL requests in HTTP to gain unauthorized Not vulnerable The test is not applicable for this device.
request access to data saved in the server database.
Bypass the base Send misconfigured HTTP header to check if Not vulnerable The device doesn’t respond to misconfigured
authentication misconfigurations exist, which might give access to HTTP requests.
authorized information.
Firewall information Tool to check Firewall used. Not available The web server rejects all connections.
Check Metasploit / Armitage Metasploit / Armitage will check if attacks are Not vulnerable No exploits are found.
for possible exploits possible against the device.
Key installation attack The KRACK breaks WPA2 protocol by forcing devices Not vulnerable The device doesn’t reuse nonce.
(KRACK)– Proof of concept to reuse nonce during the WPA2 handshake.
Man in the Middle (MITM) The attack tests if confidential information (i.e. admin Vulnerable The device doesn’t use HTTPs. Device
attack password) is exposed. credentials are sent in clear text with no
encryption during MITM attack.
Deauthentication attack This attack tests if the camera can be disabled from Vulnerable The device is disassociated from the network
the wireless. successfully.
Obtaining firmware This tests if the firmware of the IP camera is found in Applicable The firmware of the wireless camera is found
online resources. in online resources.
Reverse engineering This test attempts to dump firmware from the Vulnerable The camera is accessed through the UART. All
hardware using UART in order to obtain root shell to files have been sent to another PC by using
access sensitive information. FTP server for later revision. Attackers are
also able to write in the memory of the
camera and change the password.
Cross domain attack The attack tests if the camera has a file containing Vulnerable Both firmware versions (1.02 and 1.16) are
weak or improper configurations. vulnerable to this attack.
References Demetriou, S. et al., “Guardian of the HAN: thwarting mobile attacks on smart-home
devices using OS-level situation awareness,” arXiv:1703.01537, 2017.
Adjih, C., et al., 2015. FIT IoT-LAB: a large scale open experimental IoT testbed. Denning, T., Kohno, T., 2013. Empowering consumer electronic security and privacy
In: Proceedings of IEEE World Forum on Internet of Things, WF-IoT 2015, choices: Navigating the modern home. Symposium on Usable Privacy and Secu-
pp. 459–464. rity (SOUPS).
Alashwali, E.S., Rasmussen, K., 2018. What’s in a downgrade? A taxonomy of down- Denning, T., Kohno, T., Levy, H.M., 2013. Computer security and the modern home.
grade attacks in the TLS protocol and application protocols using TLS. In: In- Commun. ACM 56 (1), 94.
ternational Conference on Security and Privacy in Communication Systems, Fernandes, E., Jung, J., Prakash, A., 2016. Security analysis of emerging smart home
pp. 468–487. applications. In: Proceedings of 2016 IEEE Symposium on Security and Privacy,
Alghamdi, T.A., Lasebae, A., Aiash, M., 2013. Security analysis of the constrained ap- SP 2016, pp. 636–654.
plication protocol in the Internet of Things. In: Future Generation Communica- Fernandez, E., Pelaez, J., Larrondo-Petrie, M., 2007. Attack patterns: a new foren-
tion Technology (FGCT), 2013 Second International Conference on, pp. 163–168. sic and design tool. In: IFIP International Conference on Digital Forensics,
Ammar, M., Russello, G., Crispo, B., 2018. Internet of Things: a survey on the security pp. 345–357.
of IoT frameworks. J. Inf. Secur. Appl. 38, 8–27. Gegick, M., Williams, L., 2005. Matching attack patterns to security vulnerabilities
Arias, O., Member, S., Wurm, J., Hoang, K., Jin, Y., 2015. Privacy and security in inter- in software-intensive system designs. ACM SIGSOFT Softw. Eng. Notes 30 (4), 1.
net of things and wearable devices. IEEE Trans. Multi-Scale Comput. Syst. 7766 Gelenbe, E., Domanska, J., Czàchorski, T., Drosou, A., Tzovaras, D., 2018. Security for
(2), 99–109. internet of things: the SerIoT project. In: 2018 International Symposium on Net-
Bachy, Y., et al., 2015. Smart-TV security analysis: practical experiments. In: Depend- works, Computers and Communications (ISNCC), pp. 1–5.
able Systems and Networks (DSN), 2015 45th Annual IEEE/IFIP International Gupta, B.B., 2018. Computer and Cyber Security: Principles, Algorithm, Applications,
Conference on, pp. 497–504. and Perspectives. CRC Press.
Badve, O., Gupta, B.B., Gupta, S., 2017. Reviewing the security features in contempo- Gyory, N., Chuah, M., 2017. IoTOne: Integrated platform for heterogeneous IoT de-
rary security policies and models for multiple platforms. In: Handbook of Re- vices. In: 2017 International Conference on Computing, Networking and Com-
search on Modern Cryptographic Solutions for Computer and Cyber Security, munications, ICNC 2017, pp. 783–787.
pp. 479–504 no. May. Hale, M.L., Lotfy, K., Gamble, R.F., Walter, C., Lin, J., 2018. Developing a platform to
Berhanu, Y., Abie, H., Hamdi, M., 2013. A testbed for adaptive security for IoT in evaluate and assess the security of wearable devices. Digit. Commun. Netw.
eHealth. In: Proceedings of the International Workshop on Adaptive Security, Hernandez, G., Arias, O., Buentello, D., Jin, Y., 2014. Smart nest thermostat : a smart
p. 5. spy in your home. Black Hat USA 1–8.
Cao, P., Badger, E.C., Kalbarczyk, Z.T., Iyer, R.K., Withers, A., Slagell, A.J., 2015. To- Ho, G., Leung, D., Mishra, P., Hosseini, A., Song, D., Wagner, D., 2016. Smart locks:
wards an unified security testbed and security analytics framework. In: Pro- lessons for securing commodity internet of things devices. In: Proc. 11th ACM
ceedings of the 2015 Symposium and Bootcamp on the Science of Security, Asia Conf. Comput. Commun. Secur. - ASIA CCS ’16, pp. 461–472.
pp. 1–2. Huraj, L., Simon, M., Horák, T., 2018. IoT measuring of UDP-based distributed re-
Chernyshev, M., Baig, Z., Bello, O., Zeadally, S., 2018. Internet of Things (IoT): re- flective DoS attack. In: 2018 IEEE 16th International Symposium on Intelligent
search, simulators, and testbeds. IEEE Internet Things J 5 (3), 1637–1647. Systems and Informatics (SISY), pp. 209–214.
Chistiakov, S. “Secure storage and transfer of data in a smart lock system,” 2017. Jerkins, J.A., 2017. Motivating a market or regulatory solution to IoT insecurity with
Classen, J., Wegemer, D., Patras, P., Spink, T., Hollick, M., 2018. Anatomy of a vul- the Mirai botnet code. In: 2017 IEEE 7th Annual Computing and Communication
nerable fitness tracking system: dissecting the Fitbit cloud, app, and firmware. Workshop and Conference, CCWC 2017, pp. 1–5.
Proc. ACM Interact. Mobile Wearable Ubiquitous Technol. 2 (1), 5. Kim, T.H.-J. Bauer, L. Newsome, J. Perrig, A. and Walker, J. “Challenges in access right
Cyr, B., Horn, W., Miao, D., Specter, M., 2014. Security analysis of wearable fitness assignment for secure home networks.,” in HotSec, 2010.
devices (fitbit). Massachusets Inst. Technol. 1. Kolias, C., Kambourakis, G., Stavrou, A., Voas, J., 2017. DDoS in the IoT: Mirai and
other botnets. Computer (Long. Beach. Calif). 50 (7), 79.
Ling, Z., Liu, K., Xu, Y., Jin, Y., Fu, X., 2017. An end-to-end view of IoT security Wurm, J., Hoang, K., Arias, O., Sadeghi, A.R., Jin, Y., 2016. Security analysis on con-
and privacy. In: GLOBECOM 2017-2017 IEEE Global Communications Conference, sumer and industrial IoT devices. In: Proceedings of the Asia and South Pacific
pp. 1–7. Design Automation Conference. ASP-DAC, pp. 519–524 25–28–Janu.
Ling, Z., Luo, J., Xu, Y., Gao, C., Wu, K., Fu, X., 2017. Security vulnerabilities of internet Xu, H., Xu, F., Chen, B., 2018. Internet protocol cameras with no password protec-
of things: a case study of the smart plug system. IEEE Internet Things J. tion: an empirical investigation. In: International Conference on Passive and Ac-
Ly, K., Jin, Y., 2016. Security studies on wearable fitness trackers. In: 38th Annual In- tive Network Measurement, pp. 47–59.
ternational Conference of the IEEE Engineering in Medicine and Biology Society, Ye, M., Jiang, N., Yang, H., Yan, Q., 2017. Security analysis of Internet-of-Things: a
p. 32816. case study of august smart lock. In: Computer Communications Workshops (IN-
Memos, V.A., Psannis, K.E., Ishibashi, Y., Kim, B.G., Gupta, B.B., 2018. An efficient al- FOCOM WKSHPS), 2017 IEEE Conference on, pp. 499–504.
gorithm for media-based surveillance system (EAMSuS) in IoT smart city frame- Zanella, M., Andrea, Nicola, Bui, Angelo, Castellani, Lorenzo, Vangelista, Zorzi, 2014.
work. Futur. Gener. Comput. Syst. 83, 619–628. Internet of things for smart cities. IEEE Internet Things J. 1 (1), 22–32.
Miettinen, M., Marchal, S., Hafeez, I., Asokan, N., Sadeghi, A.-R., Tarkoma, S., 2017.
IoT Sentinel: automated device-type identification for security enforcement in Omnia Abu Waraga received her bachelor’s degree (with
IoT. In: Distributed Computing Systems (ICDCS), 2017 IEEE 37th International honor) in computer engineering from University of Shar-
Conference on, pp. 2177–2184. jah, UAE in 2017. Currently, she is persuading her master’s
Moody, M., Hunter, A., 2016. Exploiting known vulnerabilities of a smart thermo- degree in computer science in the same university. She is
stat. In: Privacy, Security and Trust (PST), 2016 14th Annual Conference on, also a research assistant in OpenUAE Research and Devel-
pp. 50–53. opment group. She has interests in Internet of Things se-
Morgner, P. Mattejat, S. and Benenson, Z. “All your bulbs are belong to us: investi- curity, vulnerability assessment and artificial intelligence.
gating the current state of security in connected lighting systems,” arXiv:1608. Omnia is a mentoring coordinator in ArabWIC UAE chap-
03732, 2016. ter, member of IEEE and an event organizer in Google De-
Murad, G., Badarneh, A., Quscf, A., Almasalha, F., 2018. Software testing techniques veloper Group Sharjah branch.
in IoT. In: 2018 8th International Conference on Computer Science and Informa-
tion Technology, CSIT 2018, pp. 17–21.
Oren, Y., Keromytis, A.D., 2014. From the aether to the ethernet-attacking the
internet using broadcast digital television. In: USENIX Security Symposium,
Meriem Bettayeb received her bachelor’s degree (with
pp. 353–368.
first honor) in computer engineering from University of
Prokofiev, A.O., Smirnova, Y.S., Surov, V.A., 2018. A method to detect Internet of
Sharjah, UAE in 2017 and received her master’s degree in
Things botnets. In: Young Researchers in Electrical and Electronic Engineering
computer engineering with honor in the same university
(EIConRus), 2018 IEEE Conference of Russian, pp. 105–108.
in 2019. Currently, she is a research assistant in Open-
Ronen, E., Shamir, A., 2016. Extended functionality attacks on IoT devices: the case
UAE Research and Development group. She has interests
of smart lights. In: Security and Privacy (EuroS&P), 2016 IEEE European Sympo-
in Internet of Things security, firmware analysis, artifi-
sium on, pp. 3–12.
cial intelligence and Blockchain technology. Meriem is a
Sachidananda, V., Toh, J., Siboni, S., Bhairav, S., Shabtai, A., Elovici, Y., 2017. Let the
mentoring and event coordinator in ArabWIC UAE chap-
cat out of the bag: a holistic approach towards security analysis of the inter-
ter, member of IEEE and an event organizer in Google De-
net of things. In: Proceedings of the 3rd ACM International Workshop on IoT
veloper Group Sharjah branch.
Privacy, Trust, and Security, co-located with ASIA CCS 2017, pp. 3–10.
Seralathan, Y., et al., 2018. IoT security vulnerability: a case study of a Web cam-
era. In: Advanced Communication Technology (ICACT), 2018 20th International
Conference on, pp. 172–177. Qassim Nasir is currently an associate professor in Uni-
Siboni, S., et al., 2018. Security testbed for Internet-of-Things devices. IEEE Trans. versity of Sharjah since 2009. He received his B.Sc., M.Sc.,
Reliab. 68 (1), 23–44. and Ph.D. degrees from the University of Baghdad, Iraq.
Siboni, S., Shabtai, A., Elovici, Y., 2018. Leaking data from enterprise networks using He was working with Nortel Networks, Canada, as a
a compromised smartwatch device. In: Proceedings of the 33rd Annual ACM senior system designer and then as a senior firmware
Symposium on Applied Computing, pp. 741–750. system designer. His current research interests are in
Sivaraman, V., Chan, D., Earl, D., Boreli, R., 2016. Smart-phones attacking telecommunication and network security, CPS, IoT, drones
smart-homes. In: Proceedings of the 9th ACM Conference on Security & Privacy and GPS jamming. Dr. Qassim has published over 90 ref-
in Wireless and Mobile Networks, pp. 195–200. ereed conferences, journals, book chapter, and technical
Stergiou, C., Psannis, K.E., Kim, B.G., Gupta, B., 2018. Secure integration of IoT and reports. He holds professional certificate such as CISSP
cloud computing. Futur. Gener. Comput. Syst. 78, 964–975. and Cisco trainer. He was visiting professor at Helsinki
Tabrizi, F.M., Pattabiraman, K., 2016. Formal security analysis of smart embedded University of Technology, Finland, during the summers of
system. In: Proc. 32nd Annu. Conf. Comput. Secur. Appl., pp. 1–15. 20 02-20 09. Dr. Qassim is a Co-coordinator of OpenUAE
Tekeoglu, A., Tosun, A.S., 2016. A testbed for security and privacy analysis of IoT Research & Development Group.
devices. In: Mobile Ad Hoc and Sensor Systems (MASS), 2016 IEEE 13th Inter-
national Conference on, pp. 343–348. Manar Abu Talib has interest in software engineering
Tewari, A., Gupta, B.B., 2017. A lightweight mutual authentication protocol based software measurement, software quality and testing, ISO-
on elliptic curve cryptography for IoT devices. Int. J. Adv. Intell. Paradig. Inder- 27001 for Information Security and OpenSource Software.
science Publ. 9 (2–3), 111–121. Dr. Manar was involved in developing the Arabic version
Tewari, A., Gupta, B.B., 2018. Security, privacy and trust of different layers in Inter- of ISO-19761 (COSMIC-FFP measurement method). She
net-of-Things (IoTs) framework. Futur. Gener. Comput. Syst. published +40 refereed conferences and journals, involved
Ur, B., Jung, J., Schechter, S., 2013. The current state of access control for smart de- in +200 professional and research activities and super-
vices in homes. Workshop on Home Usable Privacy and Security (HUPS). vised 30 capstone projects. Dr. Manar is a Co-coordinator
Ur, B., Jung, J., Schechter, S., 2014. Intruders versus intrusiveness: teens’ and par- of OpenUAE Research & Development Group and the In-
ents’ perspectives on home-entryway surveillance. In: Proceedings of the 2014 ternational Collaborator to Software Engineering Research
ACM International Joint Conference on Pervasive and Ubiquitous Computing, Laboratory in Montreal, Canada. Manar is the ArabWIC VP,
pp. 129–139. Google WTM Lead, an executive member in UAE IEEE Sec-
Willingham, T., Henderson, C., Kiel, B., Haque, M.S., Atkison, T., 2018. Testing vul- tion and the UAE representative for the COSMIC-FPP Edu-
nerabilities in bluetooth low energy. In: Proceedings of the ACMSE 2018 Confer- cation Committee.
ence, p. 6.

Computers & Security: Omnia Abu Waraga, Meriem Bettayeb, Qassim Nasir, Manar Abu Talib

Uploaded by

Copyright:

Available Formats

Computers & Security: Omnia Abu Waraga, Meriem Bettayeb, Qassim Nasir, Manar Abu Talib

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Computers & Security: Omnia Abu Waraga, Meriem Bettayeb, Qassim Nasir, Manar Abu Talib

Uploaded by

Copyright:

Available Formats

Computers & Security 88 (2020) 101648

Contents lists available at ScienceDirect

Computers & Security

Design and implementation of automated IoT security testbed

1. Introduction The concept of smart cities is emerging as a result of the perceived

Ref. Year Summary Products tested Tools Attacks Results

Ref. Year Summary Products tested Tools Attacks Results

Fig. 1. Structure of the proposed IoT Testbed.

• Control test modules and test sequencing

3.1. . Testbed structure

Our testbed uses a modular architecture, whereby every part

• Interface Module: This module acts as an I/O interface. It

Fig. 3. Communication between testbed modules.

Research phases Set up Expected result Methodology

Fig. 4. Sample of report generated by the IoT testbed.

Fig. 5. Points of weakness in IoT device communications.

Tests Used tools Expected results

Algorithm 1 As shown in Algorithm 1, once the operator chooses one or

Fig. 7. Graphical user interface of the testbed.

Fig. 8. Testing for wireless camera assessment by the testbed software.

Test case Status Additional information Results discussion

Test case Status Additional information

Check Requested IPs Not Vulnerable Details of each IP are saved

Test case Description Test result Notes

Test case Description Test result Notes

You might also like