Consumer, Commercial and Industrial IoT (In)Security: Attack Taxonomy and Case Studies

Internet of Things (IoT) devices are becoming ubiquitous in our lives, with applications spanning from the consumer domain to commercial and industrial systems. The steep growth and vast adoption of IoT devices reinforce the importance of sound and robust cybersecurity practices during the device development life-cycles. IoT-related vulnerabilities, if successfully exploited can affect, not only the device itself, but also the application field in which the IoT device operates. Evidently, identifying and addressing every single vulnerability is an arduous, if not impossible, task. Attack taxonomies can assist in classifying attacks and their corresponding vulnerabilities. Security countermeasures and best practices can then be leveraged to mitigate threats and vulnerabilities before they emerge into catastrophic attacks and ensure overall secure IoT operation. Therefore, in this paper, we provide an attack taxonomy which takes into consideration the different layers of IoT stack, i.e., device, infrastructure, communication, and service, and each layer's designated characteristics which can be exploited by adversaries. Furthermore, using nine real-world cybersecurity incidents, that had targeted IoT devices deployed in the consumer, commercial, and industrial sectors, we describe the IoT-related vulnerabilities, exploitation procedures, attacks, impacts, and potential mitigation mechanisms and protection strategies. These (and many other) incidents highlight the underlying security concerns of IoT systems and demonstrate the potential attack impacts of such connected ecosystems, while the proposed taxonomy provides a systematic procedure to categorize attacks based on the affected layer and corresponding impact.


I. INTRODUCTION
The number of Internet of Things (IoT) devices keeps increasing. By the end of 2030, the number of connected devices is expected to reach 24.1 billion, compared with around 500 nected medical devices, and smart cars, but also smart cities, transportation systems, manufacturing industries, and critical infrastructures. The severity of IoT attacks depends on the targeted system, the compromised asset (e.g., mobile phone, medical device, or smart grid controller), and the information stored or utilized for the asset's operation and control. Most, if not all, IoT ecosystems such as IIoT [8], Internet of Energy [9], Internet of Medical Things [10], military IoT [11], etc., have underlying hidden or unknown vulnerabilities that can have diverse consequences if they are successfully exploited by malicious threat actors, such as nation states and advanced persistent threat (APT) adversaries. Although previous works have underlined the security implications of IoT devices [12]- [15], in this work, we systematically review IoT security from three major sectors, i.e., (i) consumer, (ii) commercial, and (iii) industrial. The rationale for this distinction stems from the diverse operational requirements, implicit security constraints, mission criticality, and potential outcomes in the event of a compromise targeting the respective IoT sectors. In the following, we provide definitions for each one of the three IoT sectors.
IoT devices, irrespective of their application or operating environment, are responsible for monitoring, controlling and enhancing system connectivity and performance. In terms of fundamental security objectives, IoT device operation needs to ensure the confidentiality of the sensed measurements, safeguard the information integrity of stored or intransit data, and grant access only to authorized users/parties [16]. Although, security investigations revolve around the confidentiality-integrity-availability (CIA) principle, the order in which security objectives are prioritized differs significantly depending on the IoT sector. For instance, the confidentiality of the data residing in consumer IoT devices is of most importance for the device users. On the other hand, in a smart city deployment, for instance, the availability of the respective IoT nodes arises as the most important objective. In industrial automation environments including critical infrastructure, e.g., nuclear plants, the integrity of the sensed data and availability of system resources are of utmost significance since they can lead to uneconomical plant operation or even catastrophic incidents.
Due to the interoperability, heterogeneous architectures, and distinct security objectives of IoT devices and the sector in which they are installed, comprehensive security studies are required to address and evaluate vulnerabilities (on every layer of the IoT stack) and identify potential attack entry points. Towards contributing to this task, in this paper, we propose an attack taxonomy factoring the unique structures and operational constraints of IoT ecosystems. Furthermore, we report nine IoT-based attack incidents, three for each of the attacked IoT sectors, i.e., consumer, commercial, and industrial. We explain the attack vectors that adversaries can potentially exploit to mount their attacks as well as the impacts on the system operation. Based on our proposed taxonomy, we demonstrate how these IoT attacks can be mapped to their respective categories and discuss potential mitigation strategies.
The rest of the paper is organized as follows. Section II discusses related work and introduces our proposed IoT attack taxonomy. Section III describes real-world incidents, adversarial attack paths, and mitigation strategies for cyberattacks in consumer, commercial, and industrial IoT deployments.
Section IV discusses open challenges and research directions in the field of IoT security. Finally, Section V concludes the paper and summarizes the lessons learned from the attack incidents and provides directions for future improvements in the field of IoT security.
II. IOT ATTACK TAXONOMY Many diverse technologies such as wide-area networks, data analytics, security platforms, and operating systems are involved in the IoT spectrum, and as a result, a plethora of the reported attacks targeting IoT devices are directed to such technologies [17]. Attack taxonomies can assist in investigating IoT attacks, focusing on the layer where an attack is materialized overcoming drawbacks related to attack classification methods focusing on specific device-or technologyinduced vulnerabilities. In this part, we review existing IoT taxonomies and introduce our proposed layered classification while illustrating how real-world IoT cyberattacks can fit into our taxonomy. We survey prominent papers in the IoT security field published in top-tier journal and conferences from 2015-2020, emphasizing in articles that consist of different IoT taxonomies. The literature review was conducted by querying research databases of digital libraries such as IEEEXplore, ACM Digital Library, and Elsevier ScienceDirect, as well as accessible web search engines and websites such as Google Scholar and ResearchGate. We used search keywords as the ones from the Index Terms of the paper. The filtering results were managed based on the content of each article. A list of common attacks along with their description and example literature is presented in Table I. The described attacks and threats Things (IoT) and cyber-physical systems (CPS) [18].
are a subset of those existing in security studies [18], i.e., attacks on sensor devices, actuators, computing components, communications, and feedback. Table I elaborates on attack methods utilized as part of real-world examples presented in Section III. A more comprehensive tree diagram of attacks and threats on IoT and cyber-physical systems (CPS) from literature is shown in Fig. 2.

A. Related Work
Different attack categorizations within the IoT landscape exist in literature. For instance, there exist works demonstrating how to leverage the attack layer (e.g, application, network, physical, etc.) [15], the attacker behavior [14], or both [4], in order to construct IoT attack classifications. In the following paragraphs, we provide a short survey of the existing literature discussing security issues within IoT and and various attack taxonomies.
In [28], the authors review the existing strategies for IoT security and privacy, and utilize their taxonomy to elaborate various concerns and solutions. Their classification is decomposed into three layers, the information, connectivity and application layers. Each one of these three layers is comprised of two sub-parts, namely the sensors and software, connectivity and software, people and connectivity, correspondingly. Taking into consideration the various technologies involved in each layer, the paper presents the security goals and discusses concerns which could potentially adversely impact such security objectives.
Considering objects characteristics as the different factors between IoT applications, the authors in [29] present a taxonomy where privacy and security are the main focal points. The object characteristics are automation, intelligence, storage, and processing. The taxonomy is segregated into three dimensions, where each dimension analyzes object characteristics, privacy, or security concerns and emphasizes the inter-dependencies and interrelations between them.
In [14], the authors present an IoT attack taxonomy considering attacks from different application fields. The three domains being discussed are smart homes, healthcare, and transportation. The presented comparative attack analysis includes attack targets, weaknesses, and techniques. The analysis investigates attacks which target the exchanged data between nodes or their routing intelligence, data theft through fake websites, and attacks compromising the network infrastructure leading to abnormal or unresponsive states. The attack taxonomy consists of eight categories and aims to enhance security awareness during IoT development as well as provide security analysts with a risk knowledge-base.
The device property category reflects the attack impact and is divided into the low-end class, where low power devices act as the adversary (e.g., smartwatches), and the high-end class which includes powerful devices (e.g., laptops) attacking the IoT systems. The second attack category considers the access level of the attack. It can either be passive (e.g., eavesdropping) or active (e.g, replay attacks). The adversary location and attack strategy categories consider an insider or outsider attacker, and whether the attack will impede the physical or logical functioning of the devices, respectively. The information damage level category relates to the data integrity of the measurements of IoT devices. Based on how the attacker can exploit this information (e.g., interruption, eavesdropping, alteration, fabrication, message replay, manin-the-middle attacks, etc.), the corresponding damage on the system can be evaluated. Host-based attacks examine the identity that compromises the system, which could either be a user, a vulnerable software, or a hardware-based compromise. The last two attack categories of this taxonomy focus on protocols: protocol-based attacks include protocol-related exploitations (e.g., adversaries acting as genuine users and causing abnormal protocol operations while targeting the availability of the network devices) from insider and outsider attackers, and communication protocol stack which includes attacks targeting the TCP/IP layers (e.g., physical → jamming, data link → collision, network → spoofing, transport → flooding, application → clock skewing).
A brief overview of security risks in IoT and potential mitigation countermeasures is presented in [4]. The authors provide a taxonomy of the security requirements in IoT along with a taxonomy based on the vulnerabilities and potential attacks targeting the communication layers. Additionally, the paper investigates IoT security mechanisms encountered in commercial applications of various protocols (i.e., ZigBee, BLE, 6LoWPAN, and LoRaWAN) and analyzes the security posture of the IoT devices integrating them. The attack taxonomy consists of seven categories based on the communication architecture in IoT as described in [30], and the exploitations used by attackers based on [31]. The edge layer category includes attacks such as side channel attacks, hardware trojans, and denial-of-service (DoS) attacks. The objective of Replay attack [19], relay attack (forwards message without recording it) [20], reflection: attacking the challenge response part of the communication.
Man-in-the-middle Getting in the middle of a communication between two parties who believe that they are directly communicating with each other.

Cryptanalysis attacks
The process of analyzing available data to decrypt a message.

Side channel attacks
Attacks based on data gained from the implementation of a system, e.g., electromagnetic field, power consumption.
Hardware trojans Malicious modifications to the design of integrated circuits. Combinational trojans, sequential trojans [22].

Covert attacks
The attacker alternates the input of a system and at the same time manipulates the output keeping attack effects undetected.

Sleep deprivation
The rapid exhaustion of the device's power source (e.g., battery) by forcing it to operate an action making it infeasible to enter power-saving mode.

Clock skewing
The clock skew is compromised by a slight adjustment of the timestamps making the time sequence change speed causing errors in timestamp-based applications.

Spoofing
When an entity/program deceives someone else about its identity.

Attacks targeting system reputation
A node on the system gets physically tampered or inserted to act maliciously.

Malware
Malicious software.
Worm: replicates itself to spread, Adware: throws adds, Virus: replicates itself, modifies software, injects code, Trojan: disguises as genuine program [19]. Data and command integrity attack Alternates, creates, and manipulates false data to a system, network, packet.
Denial-of-Service (DoS) Making users unable to access the resources of a device, network, system.
Command and control attacks (C&C or C2) An attacker controls a computer/device by sending commands to it [27]. Malware injection [20], botnet, command injection.

Social engineering
The attacker deceives an authorized user to provide classified information.
attacks in this category is to either jam the communication channels using radio waves and device packages tampering, or to drain the power source of IoT devices by forcing them to be constantly active (e.g., discharge the batteries of IoT nodes). The access/middle layer category includes network attacks such as eavesdropping, packet injection, routing attacks, spoofing attacks, packet-redirection and packet-drop attacks.
Application layer attacks target the software of IoT devices (e.g., authentication routines, adversarial examples on machine learning algorithms [32], etc.).
The work in [4] considers also attacker exploitation paths and distinguishes them in four categories. The ignoring the functionality category assumes an adversary being able to exploit IoT device features to connect to the local area network (LAN). Reducing the functionality attacks aim to block or limit the device functionalities, while misusing the functionality attacks opt to operate the device in an incorrect or unauthorized way. The last category describes extending the functionality attacks, where the IoT device, despite its intended operational objective, is also used to perform an alternative task, e.g., an alarm sensor being also used as a tracking device disclosing the victims' location. Furthermore, the authors provide a qualitative comparison between various IoT devices and their corresponding employed technologies in terms of information, access and functional levels.
In [15], a taxonomy is proposed categorizing the threats of IoT systems while mapping which security goals are being targeted by each attack. The taxonomy of the attacks is based on the IoT layer, the violated security goals, as well as the knowledge and capabilities of the attacker. The categorization of attacks consists of cyber-physical, middleware, and application attacks, mapping availability, authenticity, accountability, integrity, confidentiality, and access control as the violated goals of any attack. The cyber-physical layer represents the various sensors and actuators deployed in a system and interacting in real-time with the 'outside world' (e.g., other IoT devices) while making decisions and operating autonomously. Thus, cyber-physical category attacks could target both the hardware and the software of a device. Attacks in this category include, among others, sleep deprivation, physical attacks where an adversary damages the actual device, jamming and covert attacks. The middleware serves as the connecting link between the cyber-physical and application layer. For instance, the middleware simplifies the exchange of information between IoT devices and supports interconnections between devices manufactured by different vendors. Attacks in the middleware category target the transported information in terms of routing, addressing and data manipulation, as well as the mechanisms operating in this layer. Example attacks are sybil, DoS, sinkhole, and cryptanalysis-type of attacks. The last layer is the application layer which collects and processes data from the physical-layer while provisioning various system workflows (e.g., data processing, graphical interfaces). Application layer attacks, such as phishing, DoS, malicious updates, cryptanalysis and privilege escalation attacks aim to disrupt system services.
A comprehensive survey of false data injection attacks (FDIAs) detection algorithms is presented in [20]. FDIAs are attacks which manipulate the system measurements -in a congruous way -to adversely impact the system operation while avoiding triggering any intrusion detection mechanisms. The authors classify various attacks according to the targeted layer and the way they were performed, and conclude with their proposed taxonomy. The taxonomy consists of four categories. Cyber-based attacks refer to incidents occurring on the cyber-layer such as code manipulation, command manipulation, malware injection, FDIAs, sleep deprivation, etc. Network-based attacks are materialized exploiting virtual network access to a system, without affecting the software, firmware or physical communication link. Such attacks include, among others, DoS, black/grey hole, FDIAs, etc. In communication-based attacks, an adversary targets directly the physical layer of the communication either by damaging it or by modifying the exchanged information. Such attacks could be GPS spoofing, relay attacks, FDIAs, and channel jamming. The last attack category describes physical-based attacks which target the physical integrity of various devices either via tampering or damaging. Other attacks within this class exploit electromagnetic waves or target the emanations of the system (e.g., light, sound heat, etc.); referred also as emission security attacks. Although the paper demonstrates a taxonomy for CPS-based attacks, it is still relevant and applicable for IoT architectures due to the similarities encountered between CPS and the IoT sector, especially in terms of security [33].
In [19], an IoT attack classification is presented. For each attack category, the authors discuss the corresponding vulnerabilities and countermeasures as well as real-world attack examples. Moreover, the authors present how blockchain technologies are employed in IoT and IIoT environments provisioning security solutions for different sectors, i.e., IoT → healthcare, IoT →vehicular ad-hoc networks (VANET), IIoT → supply chain, IIoT → smart grid. An IoT/IIoT security taxonomy is demonstrated along with traditional and blockchain-based security solutions. The domain of physical attacks is comprised by attacks where the adversary can have physical access to the IoT system. Attacks under this category are tampering attacks, malicious code injections, radio frequency interference/jamming, fake node injections, sleep denial attack (or sleep deprivation), side channel attacks, and permanent DoS (PDoS) [34]. Network attacks occur when the IoT network is manipulated inhibiting the IoT system's nominal operation. Typical network attacks are RFID spoofing [35], RFID unauthorized access, routing information attacks, selected forwarding [36], sinkhole, wormhole, sybil, man-in-the-middle, replay, DoS, and distributed DoS (DDoS) attacks. In software attacks, an adversary exploits the associated software or security vulnerabilities of IoT systems such as viruses, worms, trojan horses, spyware, adware and malware. The last category considers data attacks which target the data exchanged in IoT systems between the cloud infrastructure, servers, and databases serving as computation storage resources. Data attacks are performed through data inconsistencies, unauthorized access, or data breaches. The attack classification is designed to help IoT/IIoT security analysts determine potential attacks in their respective domain. Additionally, the demonstration of blockchain solutions emerge as efficient ways to overcome the discussed attacks.
Evidently, a great variety of attack taxonomies within IoT ecosystems already exists in the literature. However, each one of the related works investigates IoT attacks under the prism of different security/attack objectives and utilizes diverse criteria for the attack classifications. Some attack classes are extensively discussed and supported by multiple attack paradigms, while others are vaguely described mainly focusing on the attack's target without providing realistic attack examples (e.g., information damage level, host-based) [14]. Despite existing work providing real-world examples of attack incidents [4], [19], [20], such papers fail to delineate the attacks in a meticulous way, report in which category these incidents should be allocated, and justify the reasons for such classifications. In our taxonomy, we account for the fact that these incidents could not be sufficiently categorized into a single attack class. Notably, adversarial paths overlapping various categories are common and in many cases different attack paths exist that can induce the same impact. Table  II summarizes the taxonomies from related work along with the one we present in this paper. In order to illustrate the practicality of our attack taxonomy, in Section III, we discuss real-world attack incidents and map them accordingly. Such real-world attack incidents exemplify the similarities between attacks existing in different IoT deployments (e.g., consumer, commercial, industrial) but also highlight the disastrous effects that some attacks can have in certain operation field contexts stressing the fact that IoT security should be an essential requirement.

B. Proposed Taxonomy
Factoring the related work literature, we propose a taxonomy and leverage it to investigate attacks that threaten consumer, commercial, and industrial IoT ecosystems. We discuss IoT attacks which target the aforementioned three IoT domains in order to demonstrate the applicability of our taxonomy even for diverse attack scenarios targeting different system assets and aiming to compromise distinct security objectives.
Due to the ubiquity of IoT devices spanning into multiple fields, we classify IoT attacks into four categories: Device, Infrastructure, Communication and Service attacks. We opt for this classification since it provides a streamlined approach to categorize attacks in an aggregate way, overcoming the requirement to create different attack classes based on the adversarial target, compromised security objective, attacker tactics, etc. These classes are also supported by the presented real-world cyberattacks in Section III. Some attacks can fall under more than one categories depending on their threat model as well as the means they require in order to be accomplished. Malicious code injection attacks, for example, could be considered a Service attack when performed on a website, whereas if performed through a serial port of an IoT node could be regarded as a Device-type of attack. Similarly, a DoS attack may flood a Communication channel rendering data exchanges infeasible. At the same time, it could also target the Infrastructure of an IoT system by abusing the host's available resources (e.g., CPU or memory capacity) [37].
The Device category consists of attacks where an adversary aims to damage or tamper with the hardware components or the "things" of an IoT system. This type of attacks can also be referred to as perception layer attack [38], containing sensors and actuators as well as edge computing devices that could be micro-controllers, programmable logic controllers (PLCs), smartwatches, medical implants, etc. Such devices capture data from their environment physically or digitally, convert them to digital signals, and forward them to other IoT components or infrastructure through the communications channel. Attacks on the hardware and software parts of the device, either with or without physical access to the IoT device, would cause an abnormal operating condition of the IoT system, affecting the exchange of information within the device environment. Such device-type of attacks could be performed, for instance, through the exploitation of hardware ports, as is the case in node/device tampering [39], through malicious code injection leading to system dysfunction [40], hardware trojans [22], node or object jamming [39], sleep deprivation attacks [41], and remote firmware update attacks [42]- [44].
The second category of our attack taxonomy includes Infrastructure attacks that target the "back-end" of a system which is the data access layer, including data storage and data processing. The data access layer is connected with the database management which could be local or at the cloud. Edge computing includes packet content inspection, data filtering, cleanup, and aggregation mechanisms. As a result, events are generated, filtered, compared, joined in complex processes, evaluated, and aggregated. The information is then integrated according to an interface employed by the system applications. Most infrastructure attacks threaten either the physical integrity or availability of data or devices located at the edge of the network (e.g., jamming attacks). For example, compromising sensitive data through weak passwords or social engineering could lead to account hijacking attacks [45], and as a consequence to data manipulation, corruption, insertion, loss, or scavenging [46].
Communication attacks impact the broadcast and exchange of information between IoT devices. Communication attacks can target communication protocols, communication standards, communication technology, or even the communication channel which could be wireless or physical. Moreover, this category also considers attacks endangering the switching, routing, and data exchange at the network layer, protocol implementations as well as translations between different protocols. A high number of the reported IoT attacks in literature belong to this category due to the exposed communication channels and lack of sophisticated security functionalities. IoT communications can be vulnerable against a variety of attacks such as traffic analysis [39], eavesdropping [47], interception [48], etc. On the network side, an adversary could potentially arp-poison the communication endpoints and pursue a manin-the-middle attack [49], flood the network with packets causing a DoS or DDoS attack [50], or even generate network disruptions via routing information attacks. An attacker could also record sensitive information and carry out harmful attacks such as RFID cloning [51]. In such scenarios, attackers record exchanged RFID tag data, and then exploit them conducting replay attacks.
The last category in our taxonomy considers Service-type of attacks. By service, we refer to the inherent functionality and services that the system provides to users through various processes. System services include the front-end along with the IoT software that orchestrates several parts of the system in coordination with the end-users. For instance, system reports provided to users belong to the adversarial targets of this attack category. Such reports include data analytic results presented in graphical environments where users can interact and provide input information or issue control commands. Example attacks in this category are phishing attacks, social engineering [52], and control hijcacking, i.e., methods used by adversaries to

Paper
Categories Details [14] Device Property, Access Level, Adversary, Location, Attacks Strategy, Information Damage Level, Host-based attacks, Communication Stack Protocol.
Each category provides a subcategorization of attacks which often overlap with each other, e.g., access level overlaps with the information damage level. Examples are provided, but without mapping to real-world incidents. [4] Edge Layer, Access/Middleware Layer, Application Layer, Ignoring the Functionality, Reducing the Functionality, Misusing the Functionality, Extending the Functionality.
It provides security mechanisms adopted by communication protocols, however, combining communication layer and attacker behavior could cause uncertainty in classification. Examples are provided, without mapping to real-world incidents. [15] Cyber-physical layer attacks, Middleware layer attacks, Application layer attacks.
The work develops simply a naming scheme used in a taxonomy in order to correlate it with violated security goals. Examples are provided, but without mapping to real-world incidents. [20] Communication-based, Cyber-based, Network-based, Physical-based.
The taxonomy emphasizes in cyber-physical and data integrity attacks, and lacks specific IoT attacks and context. Examples are given but emphasized in false data injection attacks. Incidents are discussed but not mapped to the taxonomy.
A well-structured taxonomy with countermeasures and real-world examples. However, no comprehensive description is provided to the mapping of incidents.
We use the pillars of consumer, commercial, and industrial IoT along with real-world cases to map them with our taxonomy. Case studies are discussed for every category and potential mitigations are provided.
directly manage IoT applications [53]. Most of the attacks in this category are application layer attacks, e.g., malicious scripts, cryptanalysis attacks, exploitation of buffer overflow vulnerabilities, attempting to obtain sensitive information from the memory of the application, reverse engineering methods decompiling the executable software to find potential exploits, etc.
A conceptual diagram of the proposed IoT attack taxonomy, including popular attack targets for each of the attack categories as referred from our proposed taxonomy, is depicted in Fig. 3. In the following section, we discuss notorious IoT attack incidents derived from the consumer, commercial, and industrial sectors, and explain how they can be investigated and mapped using our taxonomy. Furthermore, we provide detailed analyses regarding the IoT vulnerabilities of each attack incident, the methods that adversaries followed to realize the attack, the resulting system impact following the successful implementation of the attack, and potential mitigation strategies which could have averted these attack cases.

III. ATTACKS USE CASES TARGETING IOT DEPLOYMENTS
In this section, we analyze real-world IoT incidents targeting the consumer, commercial and industrial domains, and describe how these attacks can be classified following our taxonomy. We elaborate on the vulnerabilities of these IoT ecosystems and discuss how adversaries exploit them in order to perform their attacks. We describe the impact of the attacks along with security countermeasures to prevent their proliferation in IoT systems. Our attack taxonomy aims to assist security analysts design secure and resilient IoT systems exposing the underlined characteristics of IoT attacks. We select use cases with diverse adversarial objectives as well as attack procedures covering the diverse and immense IoT attack surface while also highlighting the existing system vulnerabilities.

A. Incidents Targeting Consumer IoT Devices
Consumer IoT devices exist in various aspects of our everyday lives due to the plethora of capabilities they feature. Typical examples of consumer IoT devices include smartphones, smart watches, indoor and outdoor cameras, etc. In the following subsections, we discuss three consumer IoT attacks covering voice assistant devices, baby monitoring cameras, and botnets affecting consumer products along with the inherent vulnerabilities of each attack scenario, system impact, and potential mitigation plans to overcome such unfavorable situations.
1) Case Study 1 -Voice Assistant : The introduction of voice assistance on smartphones thrusted the emergence of home assistants. However, the wide adoption of IoT home assistants (e.g., Google assistant, Amazon echo, etc.) was accompanied by a new set of vulnerabilities. For instance, researchers, at the Security Research Labs (SRL) [54], managed to mount attacks on home assistants exploiting device vulnerabilities, compromising their operation, and intruding user privacy. The researchers developed specific software frameworks able to leverage implementation bugs and eavesdrop users or plant sophisticated phishing attacks [55]. The vendors name the aforementioned software "skills" and "actions", for Amazon Echo and Google Assistant, correspondingly. Although ethical hacking approaches, such as [54], demonstrate the feasibility of these types of attacks, malicious users could also follow similar methods. In Fig. 4, we illustrate the attack methodology targeting smart home assistants. Attackers, before mounting their attack, must first bypass Google's or Amazon's preliminary security review, once they upload their custom-built applications to the corresponding app-stores. Once this security check is successfully evaded, adversaries would prompt users to update the newly installed application; however, they need to ensure that this update would not trigger any security mechanism or initiate a secondary application review process (from Google or Amazon). Following the application update, harmful features could be also ported to the assistant devices enabling Service attacks by imitating other trustworthy apps, request for security credentials, overhear user conversations, or perform other types of identity-theft related attacks. Apart from Service attacks, the loss of user data confidentiality can also lead to Infrastructure-aimed attacks, e.g., account hijacking to access and modify confidential user data, or Communication-based attacks via spoofing the voice assistance features or accessing the user home network.
To delude users into thinking that the newly installed application features are not working properly, researchers at SRL strategically changed the welcome message of the named application while demonstrating that the security mechanisms can be evaded. The new message would include a sequence of unpronounceable characters (e.g., " ? . " or "U+D801, dot, space"), since this would create an artificial silent delay leading users into believing the application might have encountered some bug. Immediately after the pause, the device would ask the user for the password since "critical security updates" needed to be installed in the device. Despite that some users might be skeptical in sharing their security credentials, still many would fall victims to this sophisticated phishing attack. Following the same procedure, i.e., leveraging the same sequence of characters to create this fake silence effect and using the "skill" software framework, the SRL researchers were able to "selectively wake up" the voice assistant devices using specific trigger words, e.g., password, to eavesdrop the following communication. This eavesdropping attack was demonstrated using the Google Home assistant, enabling attackers to receive a comprehensive log of the users' conversations.
It is evident that user data privacy is the most important principle for the security and privacy related to consumer electronics products, and the one that seems the most overlooked according to the SRL study. Given how easily attackersleveraging voice assistant vulnerabilities -could steal user credentials or perform account hijacking attacks, the SRL researchers suggest that any new application feature should be extensively reviewed every time it gets updated from the corresponding app-store. Additional countermeasure suggestions are, provided in detail in [54], advocating that silent messages, unpronounceable characters, as well as keywords should be handled diligently, impeding adversaries aiming to build exploits from such context-sensitive details.
2) Case Study 2 -Baby Monitoring Cameras: Popular consumer electronics devices, especially in families with newborns, are baby monitoring cameras (BMCs). In 2018, a family in South Carolina realized that their BMC was operating suspiciously; their skepticism was validated since their device was indeed compromised [56]. The security analysis by SEC Consult led to the identification of a multitude of vulnerabilities for the underlined BMC [57]. For instance, TCP ports 554 and 5000 could be exploited without authentication from anyone with access to the BMC's local network. Although local access is by no means granted apriori, this constraint can be bypassed if unsuspicious users fail to protect their home networks, making every connected device vulnerable to adversaries. Additionally, the BMC furnishes a defaultenabled peer-to-peer (P2P) cloud feature which streams the unencrypted captured video to the cloud, thus further increasing the device threat surface. Furthermore, the default password, a common practise for consumer IoT electronics, is neither device-specific nor randomly generated. Last, the BMC features two universal asynchronous receiver-transmitter (UART) interfaces which grant complete administrator control, via a root shell, to anybody who can acquire physical access to the device.
Inspecting the reported vulnerabilities, the BMC is evidently insecure since it can be targeted by any type of attack ranging from the Device category, e.g., by exploiting the exposed UART ports, all the way to the Service category, e.g., via the default-enabled P2P streaming features. The security analysis of the specific device demonstrated that attackers could exploit the BMC's P2P cloud feature to compromise the device and violate users' privacy [57]. By scanning for valid device IDs with default credentials, adversaries are able to connect, a Service category attack, to the camera and spy on victims. In this respect, it can be seen as an Infrastructure-based attack (access to cloud recordings) which could be materialized through traffic analysis and packet eavesdropping.
Even though the primary target of this event remains the users' privacy, other factors should not be overlooked. The default credentials usage for example as illustrated in Fig. 5, can lead to possible attacks targeting the Service aspect of the device as well, locking authorized users out, or providing adversaries with access to customer local networks via the compromised devices. Researchers, manufacturers, and service providers, in their efforts to safeguard customer security, prompt users to change default credentials, disable features which are not being used, patch their devices with the latest firmware updates, and ensure that encrypted traffic is enabled. Although these countermeasures cannot deter determined adversaries, they can significantly reduce the potential entry points for attacks.
3) Case Study 3 -The Mirai Botnet: Although cyberattacks targeting single consumer IoT devices can have significant consequences to the user's data privacy, as was the case with voice assistants and BMCs, disruptive attacks targeting multiple IoT devices at large have also been reported. We refer to this type of attacks compromising and controlling multiple connected devices as botnet attacks. A well-known example of such attack incident, targeting mainly consumer electronic IoT devices, is the Mirai botnet, initially discovered by the MalwareMustDie non-profit security organization in August 2016 [58]. However, the first generalized Mirai attack occurred in September of the same year, infecting 65,000 devices during the first 20 hours of operation and with a total of 600,000 compromised devices by the end of the Mirai malware's lifecycle (February 2017).
The Mirai botnet attack was noticed when OVH, a cloud computing company, and Krebs on Security, a blog website investigating cybercrime stories, fell victim to a Distributed Denial-of-Service (DDoS) attack. The attack renders the enterprise networks unresponsive by overflowing them with artificial traffic saturating the network bandwidth. More specifically, in the Krebs case the traffic peaked at approximately 623 Gbps. The botnet victims included game servers, anti-DDoS providers, telecommunication firms, political websites, and some suspicious sites hosted in Russia [59].
The Mirai attack procedure includes an initial scan for potential victims using pseudo-random IPv4 network addresses; once a device is found, a Telnet or SSH connection is attempted using 10 username and passwords pairs randomly selected from a preconfigured list of 62 credentials. If the authentication succeeds and the connection is established, the botnet sends the connection credentials to the report server, which enables a loader which infects the victim with a device-specific malware. The aim of the malware is to remain undetected by antivirus programs, thus it deletes the corresponding downloaded binary and masks the malicious process name to hide its existence. Additionally, it blocks any other processes related with similar infections, or other Mirai variants. The infected device is then remotely managed by the control server, enabling the attacker to launch a DDoS attack while scanning for new vulnerable devices concurrently. Fig. 6 illustrates the Mirai botnet operation, as was prescribed in the source code published by its developers in September 2016, with the initial first victims of the incident.
As mentioned above, in order to successfully deploy a Mirai botnet attack, a significant number of controlled devices is required. To acquire access to these vulnerable IoT devices, first an IPv4 network address scan is performed. This step, which can be portrayed as Communication category attack, targets such devices since they have a much higher probability to use default or non-randomized credentials. With password cracking techniques (e.g., dictionary attacks, rainbow tables, brute-force attacks, etc.) belonging to the Service attack class, many IoT devices were successfully compromised. Then the malware binary was installed, handling full device control to the attacker. Finally, the Mirai botnet can also be seen as an Infrastructure type attack, given that the recipients of these DDoS attacks were mainly enterprise networks belonging to the infrastructure fabric.
The consumer IoT devices mainly targeted by Mirai were IP cameras, digital video recorder (DVRs), printers, and routers. This corresponds to an approximate cost of $13.50 per device for consumers, and around $4, 207.03 per hour that the network bandwidth is overflown with traffic [60]. The impact is much higher for Domain Name System (DNS) providers who should have invested in DDoS countermeasures and network resource redundancy. Mirai evolved and diverged into thousands of variants; some of them are more immune to detection mechanisms, others leverage different protocols or dictionaries to deploy the attack. The Mirai botnet stopped expanding after the arrest of its creators, who, in order to atone for their committed cybercrimes, contributed in the development of the counter-IoT botnet honeypot "WatchTower" [61]. Regarding the mitigation and avoidance of botnet attacks, the authors of [59] highlight the importance utilizing randomised pass-word in consumer electronics devices. Furthermore, avoiding default network configurations, and applying Address Space Layout Randomization (ASLR) -which prevents exploits of memory vulnerabilities -can also inhibit such attacks. Automatic updates under secure frameworks are encouraged, alongside notification alerts when suspicious behavior is detected (e.g., unexpected network traffic). Finally, the adoption of immune-to-fragmentation attacks operating systems and by extension withdrawal and upgrade of outdated systems can impede the proliferation of botnet attacks.

B. Incidents Targeting Commercial IoT Devices
In the commercial sector, the employment of distributed systems -comprised by interconnected devices which collect, process, and analyze data autonomously before transmitting them to central processing units -has been widely endorsed in diverse operational scenarios (e.g., smart buildings/cities, transportation, medical facilities, etc.). Along with the commercial IoT infrastructure growth, however, vulnerabilities also appear and being exploited by malicious adversaries. In this part, we discuss three commercial IoT attacks covering avionic systems, vehicles, and healthcare medical devices.
1) Case Study 4 -Aircraft Avionics: Avionic systems are prominent examples of commercial IoT architectures in which any malicious attack would result in disastrous effects. In 2018, an unprotected server was discovered on Boeing's network which allowed download access to the avionics system provider data and code specifically crafted to run on the company's 737 and 787 passenger jets [62]. The analysis of this publicly accessible information (including reverse engineering the acquired binary files), in addition to the available literature about the network configuration and the IoT infrastructure of the aircraft models, led to uncovering vulnerabilities within the Boeing 787 aircraft system [63].
The security analysis in [63] reveals references to many insecure code functions on the Crew Information System -Maintenance System (CIS/MS) module such as strcpy, sprintf, and strcat, which can potentially cause Servicetype of attacks like integer and buffer overflows. Additionally, Infrastructure attacks could be initiated since vulnerable execution paths (e.g., unauthorized user commands) could allow for out-of-bound reads or writes as well as memory corruptions. Alarmingly, more serious vulnerabilities were discovered in some of the obtained .vex files. Examples include stack and buffer overflows, remote code execution, a vulnerable Trivial File Transfer Protocol (TFTP) server, an insecure system-call handler who could lead to privilege escalation, and Return-Oriented Programming (ROP) exploits. Based on the security analysis findings, various potential scenarios could be formed in which the discovered vulnerabilities (including zero-days) can be exploited leading to destructive attacks. Such scenarios can attain unauthorized access to the Common Data Network (CDN) which connects most of the aiplanes systems (i.e., through the Common Computing Resource Cabinets to the fuel quantity, low pressure, and lightning systems).
The IoT and communications network of a Boeing 787 consists of the following components: Leveraging the aforementioned vulnerabilities, two Communication-based attack scenarios are depicted in Fig. 7 targeting the network infrastructure of the 787 aircraft. The first scenario considers an attacker who compromises the Internet-Accessible Loadable Software Aircraft Parts (LSAP) proxy server, which was discovered that two vulnerable instances of such servers exist (including 737's and 787's data). Then the attacker through the proxy can access the data exchanged between the ground control tower and the on-board electronic distribution system of the aircraft [64], i.e., uplink/downlink requests between the ground and the plane. Another attack path leveraging the LSAP proxy server includes the use of the on-ground aircraft wireless communication Gatelink822 to access the aircraft's Terminal Wireless LAN Unit (TWLU) or the Crew Wireless LAN Unit (CWLU). Then, the attacker can access the IDN, through various Ethernet Gateway Module (EGM) rules, and compromise the CDN exploiting the pre-referenced vulnerabilities. The second scenario utilizes the Terminal Cellular Unit (TCU) or satellite communication links which could be exposed to the Internet (via a public IP). According to [65], this hypothesis is likely to be true granting access to the TCU. Once again, through EGM rules, the adversary can reach the CIS/MS and finally jeopardize the CDN.
For the mitigation of the reported attacks, the analysis provided in [63] proposes the use of the x86 32-bit CPU No-Execute (NX/XD) hardware mitigation, supported by the inherent hardware (i.e., Intel Pentium M 32-bit processor). Furthermore, the adoption of compiler-level mitigation for insecure functions such as strcpy, sprintf, etc. are strongly advised to prevent buffer-and stack-based overflow attacks. Finally, secure firmware updates -especially for the mission-critical subsystems, e.g., Bus Power Control Unit (BPCU), Generator Control Unit (GCU), Electronic Engine Control (EEC), Wing Ice Protection System (WIPS), etc.
-attested by integrity checks and controls need to verify the authenticity of the firmware, and inhibit the counterfeit firmware impact in the event of an attack. Although Boeing and Honeywell (the main firmware supplier of Boeing) confirmed the existence of the majority of the aforementioned vulnerabilities, they stated that such vulnerabilities cannot be exploited and security mechanisms are in place to counter them. Indeed, a catastrophic attack might not be entirely realized utilizing solely the findings provided in [63], however, "aircraft security is far from a solved area of cybersecurity research" [62].
2) Case Study 5 -Heavy-Duty Vehicles: Similar to consumer vehicles, heavy-duty commercial vehicles such as buses, trucks, trains, and tractors are integrating new technologies and features which rely on information and communication interfaces and protocols. Despite such technology integration contributes to safer and more efficient transportation as well as to comfort improvements, it also increases the potential entry points for adversaries [66]. In 2015, security researchers -by exploiting a zero-day vulnerability on the IoT-enabled entertainment system -demonstrated that vehicle systems, e.g., engine, steering, braking, etc., can be remotely and/or maliciously controlled [67]. Similarly in 2016, researchers from the University of Michigan demonstrated the existence of vulnerabilities by hacking the internal Controller Area Network (CAN) bus of both a truck and a school-bus [68]. They compromised these heavy-duty vehicles by physically connecting to their on-board diagnostics (OBD) port, and through it controlled the throttle and engine brakes, as well as the indicators for various gauges (e.g., fuel, brakes, etc.).
The compromised CAN-based standard J1939, used across a wide variety of heavy-duty vehicles, supports vehicle telematics, e.g., diagnostics, maintenance control, fuel reduction, compliance checks, etc. [69]. Specifically, telematics enable vehicles to communicate with the outer world through different telecommunication technologies; thus, potentially exploited vulnerabilities could enable granting adversaries access the vehicle's network. Through the J1939s OBD port and leveraging Vector CANoe, an industry-standard CAN analysis and simulation software tool, one can perform a variety of attacks such as packet eavesdropping and packet injection. By parsing and inspecting the obtained data (via packet eavesdropping), the Parameter Group Numbers (PGN) -which are message identifiers that control various functions of the vehicle -can be identified and manipulated. These eavesdropping and traffic analysis attacks can be classified as Communication-based IoT attacks. Exploiting the same port and utilizing the alreadycaptured packets using PEAK USB-PCAN (an alternative packet analysis utility to Vector CANoe), packet injections were successfully performed on both the school-bus and the truck, also Communication-based attacks. However, since a physical connection to the OBD port is required for this type of attacks, they fall under the category of Device attacks. Typical consequences of the CAN being compromised, can result in sudden increases of the vehicle's engine RPMs, unexpected brake engagement, and indication changes including oil pressure, service brake pressure, and other gauges. Fig. 8 illustrates the experimental compromise setup of the aforementioned CAN protocol attack. The security hazard of these attacks lies in the fact that attackers are not only able to override the driver's input, but also remove the user's ability to regulate the vehicle torque. Furthermore, attackers could disable the truck's engine breaking system when it is running below 30 mph. Both attack scenarios can lead to disastrous results threatening the safety of the passengers as well as their surroundings. Another attack case with catastrophic compromise results is the malicious modification of the brake service pressure indicator, since without such display signal drivers do not have any other means to gauge the brake air pressure and avoid emergency all-wheel lock. The authors of [68] do not suggest any specific mitigations for the described attacks. Their aim was to raise awareness and express their concerns regarding the various wireless technologies being ported to the heavy-duty vehicle industry, and highlight that vehicle security should not be overlooked. Although, there are various studies that emphasize on the prevention and mitigation of attacks targeting vehicles, using state estimation and control algorithms that can potential encounter disastrous results [70].
3) Case Study 6 -Healthcare Medical Devices: The healthcare infrastructure covers a vast part of the commercial IoT pillar. Attacks targeting medical IoT devices can range from confidentiality-type compromises (e.g.,disclosure of user medical records) to healthcare system-wide events which can harm patients' well-being. During the COVID-19 crisis, the U.S Department of Health and Human Services (HHS) reported a significant increase of 50% more cyberattack incidents targeting the healthcare industry. One contributing factor for this sheer cyberattack increase could be the fact that more than %80 of the 1.2 million IoT devices located in U.S healthcare organizations were operating using outdated OS which do not support security updates anymore [71].
In September 2020, a hospital in Germany sustained a ransomware attack and as a result was unable to admit a patient due to system access unavailability. Unfortunately, a patient in critical condition lost her life since she had to be transferred to another hospital almost 32km away. From a medical perspective, it can be argued that the distressful situation -caused by the ransomware attack -could have potentially contributed to the death of the patient. However, this speculation cannot serve as sufficient proof to legally convict the attackers for homicide [72]. The incident was initiated due to a flaw in the VPN network; hospitals are known for owning outdated vulnerable systems [73]. Furthermore, due to the integration of new devices and the expansion of the healthcare infrastructure with medical IoT devices, a rise in attacks has been observed recently [74]. The situation is further exacerbated since the majority of such medical IoT devices are typically outdated and lack potent cybersecurity features, paving the way for adversaries attempting to penetrate into these mission-critical healthcare systems [75].
Notably, in 2015, researchers developed a search engine, named Shodan, for finding exposed devices connected to the Internet, for example, exposed medical IoT devices used in the healthcare system [73]. As a result, Internet-connected medical systems were exposed on a public domain, such as anesthesia systems, cardiology systems, infusion systems, magnetic resonance imaging (MRI) machines, picture archiving and communication systems (PACS), nuclear medicine and pacemakers. The majority of these systems were inadequately protected against critical vulnerabilities like default credentials, emergency account login, Telnet-root access, FTP -Admin, SSL key password manager, etc. In essence, the systems were exposed to Communication and Infrastructure -type of attacks. The identified vulnerabilities of this incident were initially discovered between 2001 and 2013 and are included in the Common Vulnerabilities and Exposure (CVE) database, underlining the lack of cybersecurity considerations in healthcare organizations. With detailed information about the existing healthcare system and its exact location and functionality within the hospital network, attackers can exploit them to execute physical attacks and mount Device-type of attacks. Using employees data (e.g., credentials), Servicetype of attacks like phishing and spearphising bolster high probability of success. Another crucial threat however, was that the network was unprotected against the remote code execution MS08-067 vulnerability [76] of Windows XP operating systems while also being connected to the back-end of the infrastructure. In an effort to demonstrate the lack of cybersecurity countermeasures and lure adversaries, security researchers utilized honeypots to mimic the system as a target for adversaries. Honeypot machines are mechanisms that replicate the behavior of deployed vulnerable devices while also providing history and traffic logging capabilities. Using the exposed medical device characteristics (e.g., Fig. 9: Healthcare attack procedure of case study 6. models, connections, IPs, etc.), the honeypots were installed mimicking the healthcare organization architecture. Any vulnerability present in the original medical IoT device was replicated in the corresponding honeypot machine creating a digital twin of the actual healthcare network. Eventually, the "honeypot devices" were discovered by various Internet search engines and vulnerability databases. Six months later after the honeypot deployment, hackers discovered these counterfeit devices, exploited most of their vulnerabilities, gained access to various emulated medical devices and even left malware on the honeypots. Reviewing the honeypot findings, an attacker could have followed a similar approach and compromise the vulnerable internet connected medical IoT devices. Fig. 9 illustrates how an adversary could attain access to the emulated healthcare system environment. Specifically, the attack scenario could involve the following steps, (1) perform passive reconnaissance using various tools, and (2) get information about the Internet-connected devices. Then, (3) get important information regarding the devices with active reconnaissance, i.e., port scanning, a Communication attack. Using the recorded device exploits, Service-type attacks could be performed like brute force or dictionary attacks, achieving remote login access to these device via SSH or the device's web interface. Following, any other vulnerability existing in the simulated network could be exploited (FTP admin access, telnet root access, service login CVE-2009-5143). The command and control server could send commands to other systems threatening the Infrastructure, e.g., install malicious software or firmware to the medical Devices. At this point, the attacker could be assumed to have limitless capabilities due to access to the whole network system, the medical IoT devices (4), and their corresponding data. Furthermore, an attacker could also block legitimate user access to the healthcare system, potentially leading to similar events to the ransomware incident in September of 2020. It is important to note that, during the period that the honeypots were active, 55, 416 successful logins were established, 24 successful exploitations were performed (the majority of them being the MS08-067), 299 malware samples were dropped in total, and 8 HoneyCreds logins were registered. The report in [73] suggests that all healthcare organisations should check their Internet-connected IoT devices for default credentials, report identified issues to manufacturers requesting remediating actions, and incorporate cybersecurity practices in their existing systems. Most healthcare centers have machines that run outdated operating systems (e.g., Windows XP, Windows 2000, Windows 7) which lack security updates and therefore must be upgraded or replaced. The cybersecurity dimension of medical infrastructure, including commercial medical IoT devices, should be a core principle when designing and maintaining healthcare systems to evade incidents that violate data integrity and harm human safety.

C. Incidents Targeting Industrial IoT Devices
IIoT systems combine industrial control systems (ICS), IoT, and IT/OT technologies. As a result, IIoT systems can harness advanced networking capabilities, allowing them to operate efficiently in a distributed fashion while also being monitored and controlled from remote and dispersed locations. However, these connected features can also arise as the "weak links". Thus, if such connected IIoT systems are not properly secured, adversaries can exploit them leveraging remote connections through the Internet or by penetrating industrial networks [77]. Attacks can also be performed by compromising industrial personnel accounts and misusing their privileges [78]. Such incidents have been reported in many industrial facilities, where IIoT systems can either be targeted directly by attackers (e.g., IIoT device attacks), or they can be compromised as a result of the interconnected nature of IIoT and IT systems (e.g., attacks propagating from the IT infrastructure to IIoT devices). In this part, we discuss three IoT attacks derived from the industrial domain, which if not properly managed, could have caused disastrous consequences and even cost human lives. Specifically, we present attack incidents of ransomware, unauthorized access to water treatment facilities, and modify control logic type of attacks in petrochemical plants.
1) Case Study 7 -Ransomware -WannaCry: In May 2017, the ransomware WannaCrypt, also known as WannaCry, infected around 230, 000 computing systems globally. Wan-naCry encrypted the files of the infected machines requesting a $300 ransom in order to provide users with access to the encrypted documents. If the ransom was not paid withing a certain time frame, the price was first raised to $600, and if the user still refrained to cooperate, WannaCry would proceed and delete the data permanently after three days. Among the first victims of WannaCry were a Spanish mobile company as well as thousands of National Health Service (NHS) hospitals and surgeries across the United Kingdom. The ransomware spread beyond the European borders infecting numerous computer systems globally [79].
Pharmaceutical manufacturing companies like Merck, automotive corporations like Nissan and Renault, food manufacturers like Modelez, and many other industrial facilities were infected with WannaCry rendering their computer systems unresponsive and compromising their facilities [80]. In 2018, a variant of WannaCry targeted TSMC's Integrated Circuit (IC) fabrication facilities. TSMC supplies IC chips to many technology companies such as Apple, Qualcomm, Nvidia, and AMD.
The ransomware caused operational downtime that directly affected TSMC's production lines, resulting in approximately $170 million cost [81]. Although industrial facilities were not the main target of WannaCry attacks, industrial systems were affected due to their dependency on information technology (IT) systems, and specifically unpatched Windows machines. Furthermore, WannaCry could spread through enterprise networks affecting any connected device, regardless of being part of the IT or operational technology (OT) infrastructure [80]. The incorporation of IIoT within OT/IT infrastructures, despite enabling industrial systems operators to monitor and control facilities operations, also expands their vulnerability surface to malware with disastrous consequences, as demonstrated in the TSMC case. The situation is further exacerbated since many of IIoT devices are expanding their capabilities incorporating OS to achieve multitasking, improve security, and enhance communication due to their lack of interoperability [82], rendering them prominent targets for malware attacks with disastrous consequences.
The life-cycle of ransomware consists of the following stages: (i) deployment, (ii) installation, (iii) destruction, and the (iv) command-and-control (C&C) stage [83]. WannaCry leverages the MS17-010 vulnerability of Windows OS during its deployment phase [84], and uses the "Eternalblue" exploit to install the "DoublePulsar" backdoor implant tool for the malicious code injection and execution [85]. MS17-010 allows remote code execution in vulnerable Windows machines if an attacker sends a specific message to a Microsoft Server Message Block 1.0 (SMBv1). SMB is a client-server Application/Presentation layer protocol which enables users request access to resources on a server (i.e sharing files, opening or editing files, using printers and ports) [86]. Then, WannaCry injects the binary file launcher.dll through the exploit and the backdoor. WannaCry then exploits the SMB driver srv2.sys to attain access to the compromised devices and send the malicious payload. The launcher.dll file, which is only being executed in memory leaving no traces (on the disk), serves as the loader for the executable, mssecsvc.exe file. Thereafter, the launcher.dll runs the executable as a regular system process, and the second phase of ransomware begins.
During the installation phase, the target system is analyzed by the malware to determine if it is an actual computer or a virtual machine, and then a hardcoded domain name is queried. Notably, this specific domain name served as a killswitch allowing the attacker to remotely execute or terminate the malware. If the domain name was responding, this would signal WannaCry to terminate. However, if the domain name was not responsive, the second part of the installation phase continued planting the tasksche.exe. This executable file manages the resource loading for the malware, and the encryption environment establishment. While the mssecsvc.exe manages the mssecsvc2.0 service for either the "dropper" phase which is the creation of the taskche.exe file or the infection process. The infection process involves the exploitation of the SMB protocol; by broadcasting packages to the connected network is able to identify vulnerable devices (through their open port 445). If such devices exist in the After the setup phase, the launcher.dll along with other auxiliary files are sent to infect the new victim. At the taskche.exe file path, a new directory is created where the essential files for the attack are extracted. These files contain, among others, the instructions for the decryption of the user files, the target address, and the routing (via onion) information for the ransom exchange between the attacker and the infected user. The purpose of onion routing is because such protocols use the concepts of proxy redirection and layered mixed-key cryptography to hide the routing requests from the participants of the network except the originator, the infected machine, of the request. In other words, it provides anonymity for attackers and protects them from traffic analysis that could lead to their discovery [87].
At the destruction phase, WannaCry uses cryptographic algorithms for the encryption of the victims' files. Examples of such algorithms include RSA-2048 and AES-128. After the data encryption, the device's unencrypted data are deleted, following a data wiping procedure which overwrites data with random numbers, rendering any data restoration attempt futile. At the final phase, the @WanaDecryptor@.exe user interface gets deployed and executes a TOR service for the C&C stage. The onion server supports the communication between users and the attacker, sending relevant information to the adversaries (e.g. user name, host name, data of the infected system), and displaying the "infamous red-window" with instructions for the victim requesting to pay the ransom in order to recover the files [88]. The user-friendly malware interface is made available in multiple languages and includes a tutorial demonstration permitting the decryption of up to 10 user files at no cost. WannaCry's attack path is depicted in Fig. 10. The attack starts by exploiting an OS vulnerability (MS17-010), i.e., a Service-type attack. Then, WannaCry uses the SMB protocol in a Communication-type of attack to broadcast and find vulnerable devices with a planted Doublepulsar backdoor, and eventually encrypts all the files and damages the whole Infrastructure. By extension IIoT devices that were connected to the infrastructure got out of order due to the ransomware halting the whole production. Evidently, being able to compromise almost every aspect of a system in organisations (i.e. Merck, Nissan, NHS, TSMC), it categorizes malware as one of the most threatening attacks. Malware attacks could not only impact the infected devices, but they could also propagate into the network and stealthily expand to neighbouring devices and systems and cause multilayered and system-wide compromises.
A researcher, Marcus Hutchins, while investigating the malware, accidentally activated its kill-switch. After identifying the domain to which WannaCry was registered, the researcher was able to deactivate it and disrupt its spread. Security analysts believe that the kill-switch was created to prevent malware probing in virtual sandbox environments [89]. Therefore, the modification of the malware code to utilize different domain kill-switches, enabled the generation of multiple variants of the malware such as the one that halted TSCMs production line [80].
WannaCry spread globally through phishing campaigns [79], causing economic losses estimated around $4 billion by compromising hospitals, firms, and big manufacturing and industrial facilities. To protect computer systems and underlined IT/OT infrastructure from such attacks, OS and software running on these machines should be updated regularly. Furthermore, untrusted sources (e.g., email attachments, websites, USB devices, etc.) should receive proper handling and from users for downloading, installing, or executing any software, or piece of code on the organisations' machines. Users should keep updated their security software (e.g., antivirus) [79] which can handle malware and backup their data, deploy firewall Intrusion Detection and Prevention Systems (IDS,IPS), backup their data, increase the awareness in firms for possible scamming emails, deploy proper network segmentation which can prevent such spreading and monitor any malicious behavior in the network [90].
2) Case Study 8 -Water Treatment Facilities -Kemuri: A considerable increase of cyberattacks targeting water treatment and distribution critical infrastructure has been noticed during 2020. Three attacks have been reported targeting water treatment facilities located at Israel . The first attack aimed to modify the level of chemicals used to process tap water, while the other two targeted agricultural and city water pumps, respectively. Although minor damage was caused from the aforementioned cyberattacks, Israel's government mandated water treatment facilities to enforce strict cybersecurity measures . Israel's national cyber chief stated "we can see something like this aiming to cause damage to real life and not to IT or data " [91]. Water and Wastewater Sector (WWS) is considered as one of the most targeted lifeline infrastructure [92]; thus, WWS is treated as a matter of national security. This conjecture is validated by the numerous cyberattack incidents targeting WWC which have been reported in the past years all over the world. Namely, fifteen such incidents are reported in [93], including crypto-jacking, ransomware, backdoor deployment, and physical attacks from adversaries with diverse objectives, capabilities, and motives.
One of the many incidents against the WWS, occurred in 2016 at an undisclosed water utility, commonly referred to using the pseudonym Kemuri Water Company (KWC) [94]. The KWC, after hiring a security firm to perform proactive cybersecurity assessment of their water supply and metering systems, was informed that various vulnerabilities existed in their systems. After thorough investigations, the security company found IP addresses of state-sponsored hacktivists in the facility's traffic reports and possible unauthorized access to the KWC subsystems along with a series of unexplained valve manipulation patterns. After the forensics examination, further evidence was discovered in the KWC infrastructure indicating exfiltrations of 2.5 million unique records as well as manipulation of the chemical flow rates [93], similar to the incident in April 2020 at a water treatment facility [91]. Specifically, the water district's endpoint OT systems were outdated running old OSs. For instance, many critical IT/OT operations were operating on a single AS400, an IBM application system built in 1988 designed for small and intermediate-sized firms [95]. The AS400 system was provisioning the following functionalities, (i) operating as the SCADA platform, (ii) a router for the various KMC connected networks, (iii) controlling hundreds of PLC devices for the water valve and flow control applications, (iv) hosting the personally identifiable information (PII) and billing information of the water utility customers, and (v) storing the firms financial statements. In addition, the AS400 system was exposed to the Internet. The internal IP address and the admin credentials for the payment application webserver were stored in a plaintext .ini file, enabling access to adversaries. Furthermore, SQL injection vulnerabilities were discovered in the KWC payment portal [96], in which multiple factor authentication was not required [97].
The attack path for the KWC incident is illustrated in Fig. 11. The attackers exploited the limited security of the remote user login application, breaching the PII system and getting access to the client payment information [97]. In particular, the authors in [96], report that the initial compromise was indeed performed through the payment portal leveraging SQL injection and phishing attacks, which correspond to Servicetype attacks according to our proposed attack taxonomy. Next, the attackers leveraging the information within the plaintext .ini file of admin credentials for the web server, logged into the AS400 system. Granted access to the AS400, the attackers were able to seize about 2.5 million records from the PII database. Also, adversaries through the AS400 could impair the PLC management routines, threatening the overarching KWC Infrastructure including PLCs, SCADA control signals managing water flow valves, chemical mixtures ratios, etc. As a result, the attackers could have tampered with the amount of chemicals intended for the water supply and handicapped the KMC water treatment and production capabilities resulting in operational downtime along with significant delays for the water reserve replenishment. Such PLC malicious modifications are considered Device-type of attacks since they can directly affect the limits, set-points, and control strategies of actuators coordinating the industrial processes.
The identification of remote connection vulnerabilities from the investigation was addressed by terminating the account management front-end while any outbound connectivity from the AS400 was blocked as well. KWC was advised to replace legacy systems in order to conform to state-of-the-art security practises and standards, and patch the ones that can still support security updates. AS400 was identified to be the single-point-of-failure as most processes were centralized around it. A segregated network architecture of distributed nature could alleviate such issue. The user authentication mechanisms should be strengthened along with secure storage practises for user credentials. Additionally, intrusion detection and prevention schemes leveraging the data generated from IoT devices inside the facility's network could be deployed, as an additional layer of defense, to preemptively probe for anomalous patterns and mitigate future breaches [98].
Critical infrastructure compromises such as the described incident at the water facility of KWC, could not only impact the utility operation on the financial sector, but also jeopardize people safety and health, e.g., if customers are supplied with contaminated water. In the KWC case, attackers penetrated through the IT infrastructure delivering the attack payload on the OT endpoints and tampering with the facility's management and water quality. The KWC attack incident demonstrates that industrial facilities, and especially critical infrastructure, must enforce security strategies and standards while accounting for their cyber-physical nature and crosslayer attack propagation via IIoT components.
3) Case Study 9 -Modify Control Logic -Triton/TRISIS/HatMan: Similar to the malicious code injection and code modification attacks encountered in IoT systems, attacks in IIoT environments often target PLCs and are referred to as control logic modification attacks [99]. In IIoT devices, the programmable code is typically written in ladder logic, functional block diagram (FBD), or other PLC programming languages, instead of high-level languages, e.g., C/C++, used in other embedded IoT devices. Another notable distinction of IIoT devices is that they coordinate physical processes, often in real-time, by controlling actuators on industrial equipment based on sensors input. The TRITON attack launched in 2017 targeted a petrochemical plant and belongs to this type of control logic modification attacks. The severity of TRITON is depicted by the fact that is often referred as "the world's most murderous malware" [100].
In the TRITON incident, attackers targeted the Safety Instrumented System (SIS) workstation which is responsible for maintaining the nominal operation of the ICS, issue warnings, or even stop the process if safety limits are violated. After the attackers gained remote access to the SIS workstation, the TRITON malware was deployed to reprogram the connected IIoT controllers [101]. Additionally, adversaries modified the firmware of critical PLCs, manipulated legitimate processes, and installed a Remote Access Trojan (RAT) enabling them to access frequently the ICS infrastructure while hiding their existence. The potential attack path that adversaries exploited to mount their attack is demonstrated in Fig. 12. Fortunately, the attack failed without causing any physical harm to the personnel working on-site, or severely damaging the facility. The attack accidentally triggered an automatic shutdown causing a minor disruption to the plant, notifying the system operators to investigate the incident. Although in this occurrence the attackers "helped" identify the attack before more serious events jeopardizing human lives occurred, the stealthiness and sophistication of the attack justifiably alarmed the ICS industry [102].
TRITON, TRISIS or HatMan 1 attack targets Schneider Electric Triconex SIS controllers communicating using the TriStation protocol. Although the entry point of TRISIS is still not determined, the authors of [102] believe that the attackers attackers exploited stolen credentials via phishing campaigns or through malicious insiders in order to access and compromise the SIS engineering workstation. We can classify such type of attacks aimed at IIoT systems as Service or Device attacks. As a result, the attackers were granted access to the process control network in which supervisory human machine interfaces (HMI) monitor the plant's distributed control systems and engineering workstations [103]. Then the SIS TriStation was infected with an x86 executable, named trilog.exe, which mirrored a TriLogger application and was the main actor of the attack. The counterfeit TriLogger was able to to record, playing back, and analyze or maliciously modify high-speed operating data from Triconex controllers [105]. The malware was programmed to bypass whitelist filtering and, by tweaking monitoring mechanisms, allowed the execution of specified software. TRISIS utilized a set of sub-modules stored in an archive (library.zip) containing standard Python libraries as well as some modules (e.g, TsHi.pyc, TsBase.pyc, TsLow.pycm) with capabilities to process, manipulate controls, and directly communicate with PLCs. By leveraging the aforementioned scripts, the plant Infrastructure was stealthily compromised. For example, one of the scripts included in the trilog.exe file search for vulnerable firmware on certain controllers. Since the ICS systems work with triple redundancy, i.e., the three endpoints of the system should perform identically before any changes can be applied, a failure to program or update three PLCs concurrently triggers an alarm. This makes the vulnerable firmware script crucial since it has to maintain the triple redundancy principle at all times.
Moreover, the attackers, by reverse engineering the communication protocols used between the workstation and the controllers, were also able to mimic legitimate workstations and perform Communication-based attacks. In the scenario which the PLCs were in programming mode, which is activated using a physical key allowing firmware updates, malicious commands and/or backdoors can be injected into the plant communication network. The attacked PLCs were meticulously programmed to hide any traces indicating a firmware update while the memory payload existed for a limited time. Next, a RAT was installed on the controllers (Device), granting attackers with ad-hoc access. Notably, utilizing inject.bin and imain.bin files, the trilog.exe could construct a payload consisting of controller logic byte-codes and malicious functions able to bypass controller code-checking mechanisms. Considering that, privilege escalation on the controllers could be performed, granting adversaries with full access to the memory of the Triconex platform. Exploiting two zero-day vulnerabilities, i.e., CVE-2018-7522 [106] and CVE-2018-8872 [107], attackers gained elevated privileges on the controllers and executed arbitrary codes at the PLCs of the SIS system via the compromised TriStation.
If the TRITON attack was successful in 2017, one of the following two scenarios would likely occur; either an operational plant shutdown or the plant would operate in an unsafe state [103]. The first scenario would cause a falsepositive trigger with an unexpected shutdown while the system would not be in a "dangerous" state and eventually expose the attack after the analysis of the occurrence. The second scenario would allow the system to operate under unsafe conditions and concurrently continue to function properly endangering many cyber-physical components of the facility along with the employees of the facility, inhibiting situational awareness and rendering the deployed safety mechanisms purposeless. The plant shutdown would mainly cause financial losses during the offline time, and would require specific procedures in order to start the whole system without damaging any physical equipment. In the unsafe operational state scenario, besides the economic losses, the production line, the physical equipment, or even the safety of plant personnel could be jeopardized. The attackers of TRISIS while connected to the compromised system, wrote accidentally into a PLC memory location using a wrong format, leading two of the three controllers to operate abnormally. The triple redundancy was not full-filled and that caused an immediate safety system shutdown and by extension the discovery of the attack.
Among the suggestions to avoid similar incidents include segregating safety system networks from process control and information networks by maintaining them isolated, and keeping the TriStation terminals locked into cabinets while allowing only connections to the safety network. Proper physical controls should be in place for avoiding any unauthorized access to critical operations. For example, Triconex controllers could require a physical key in order to program them. Also, the changes of the key states should be audited issuing alerts when the PLCs are set in programming mode. Additional security suggestions include the use of unidirectional gateways, blocking bidirectional network connections for applications requiring information from the SIS. Furthermore, the implementation of access control and application whitelisting could be required for any user or service attempting to reach the SIS through the Internet. Any mobile data exchanged method (i.e. USB flash drive, external Hard Drive) should be scanned prior connecting to the TriStation terminals, and devices that have been connected to other networks should undergo a proper digital sanitizing to detect any malicious software that they may have and could endanger the system. Finally, monitoring of the ICS network traffic for any suspicious activity (i.e abnormal behavior in the network, IP white listing) must be performed regularly [101], [103].
Attack Mapping Discussion: The discussed attack use cases targeting IoT architectures in consumer, commercial, and industrial environments are summarized in Table III. It is important to reiterate that most of the described attacks can be attributed to more than one attack taxonomy category. Hence, in Table III, we demonstrate not only the classification of each IoT case study to the corresponding category, but also the attack pertinence (if any) to the rest of the attack categories. In more detail, the circles underneath each attack category indicate the relevance of each case study to a specific category. A white circle indicates no relevance at all, while a totally black circle designates the complete alignment of the case study to this specific category.
IV. OPEN CHALLENGES The rapid penetration of IoT devices along with the diversity, heterogeneity, and the multitude of applications that IoT  [109]. Although such policies can help improve the security of newly manufactured IoT devices, already deployed systems could still be vulnerable to attacks initiated from default credentials. Therefore, security awareness of end-users is crucial for compliance to such nondefault factory password policies. • The low cost of many IoT devices is a double-edged sword. On one hand, it drives their rapid penetration, but on the other hand, it should not be prioritized above the devices' security. As presented in case study III-A3, thousands of devices from all IoT pillars -with the majority of them belonging to the consumer IoT domain -were compromised. Most of those IoT devices are inexpensive products which we use on a daily basis, such as printers, routers, IP cameras, etc., that lack fundamental security protections. Thus, IoT manufacturers should balance security performance and low cost and strive to produce secure devices before deploying them to the market. Future-proofing IoT devices by providing software updates to overcome the discovered vulnerabilities also proves challenging, since it introduces significant costs for IoT suppliers. For instance, many mobile phone suppliers discontinue issuing software support updates to their devices after 3-5 years. Evidently, issuing updates to low-cost IoT devices can become cost-prohibitive. In addition, depending on the application field of IoT platforms updating them can also be impractical since it might require specialized personnel with on-site or physical access. • The computational power of IoT devices can also introduce security challenges. For example, sophisticated encryption and authentication mechanisms might not be supported by resource-limited, low cost or even disposable IoT nodes. Legacy protocols lacking encryption are often widely used in IIoT (e.g., Modbus). In addition, industrial systems could use specific tailor-made protocols -as it was in the case of TriStation in III-C3, for which there is no public information detailing their structure. The security by obscurity concept, relying on the secrecy of the protocol details, does not provide any formal security for the underlined protocol, and should be avoided especially in mission-critical deployments. On the other hand, hardware security schemes such as cryptographic processors, physical unclonable functions (PUFs), HMACs and random key generators arise as viable alternatives due to their low overhead and cost [110], [111]. However, the main disadvantage of hardware security mechanisms is that they need to be incorporated during the IoT device design phases. Retrofitting them to legacy or deployed devices is often infeasible [112].
• Even in the cases where IoT nodes are equipped with sufficient computational power and data processing units, security challenges still exist. The proliferation of smart IoT sensors is popularizing machine intelligence and learningbased methods in many critical CPS [113], [114]. The rise of learning-based schemes is accompanied by important security challenges: it creates an incentive among adversaries to exploit potential vulnerabilities of the algorithms. The success of artificial intelligence and machine learning has been thwarted by adversarial attacks such as decision-time and data poisoning, which tend to introduce vulnerabilities into the learning process [115]- [117]. We need to revisit the challenging problem of developing secure and robust learningbased algorithms utilized in IoT networks. In addition, it is of paramount importance to start providing a thorough security assessment of existing learning-based techniques targeting the identification process of IoT node faults and the detection of malicious attacks. This could allow researchers to develop learning-based techniques by fusing domain-aware knowledge of the underlying IoT system nature into the learning model. The security-enhanced and robust mechanisms -in the presence of motivated and sophisticated adversaries -should still be efficient for realistic implementation in IoT applications. Towards improving effectiveness, federated and reinforcement learning schemes can utilized in order for the the training to be performed on distributed data residing on intelligent electronic devices of the IoT network [118]. • The amount of data aggregated by IoT devices requires moderation and secure handling. IoT manufacturers could regulate the amount of data that their devices collect, and implement security and access control mechanisms to protect the confidentiality and access to user information. At the same time, users should be aware of the data collected by IoT devices (e.g., cookies, geolocation data, etc.), allowing them to decide whether they want their activity to be monitored, proactively protecting their security and privacy. Identifying the minimum amount of data required to enhance user experience, while effectively securing them from malicious adversaries is another obstacle that future IoT devices will have to overcome. Extreme caution should be exercised when interacting and storing user medical data (as discussed in III-B3), since adversaries have targeted healthcare organizations in multiple occasions.
As the penetration of IoT devices in our everyday lives continues to increase, it becomes imperative to identify the associated technical, economic and regulatory challenges, and to develop impactful solutions to ensure compatibility with the existing technological advancements and a smooth transition to secure, reliable, and resilient future CPS. A multitude of aspects should be considered when facing the challenging task of securing IoT-related assets. Apart from the threats posed to the IoT application domain, to services delivery continuity, safety and, in general, management risk, having improved security awareness for the weakest part of an IoT ecosystem is critical. Thus, humans' psychological flaws should be regarded as an organic part of the IoT security equation.
V. CONCLUDING REMARKS In this paper, we demonstrate an attack taxonomy architecture designed with real-world IoT attack incidents in mind. We divide our attack taxonomy into categories and map IoT attacks to their corresponding attack class (Table III). Furthermore, we disclose the underlined security vulnerabilities of the investigated IoT attacks and propose potent countermeasures which -if enforced -can subvert such vulnerabilities from commencing to full-blown attacks. Additionally, we examine three different IoT domains, i.e., the consumer, commercial and industrial sectors, given their diverse operational objectives and constraints, e.g., asset security, real-time operation, device life-cycles, etc. For each sector, we dissect three realworld attack incidents delineating the vulnerabilities and attack paths that adversaries exploited to mount them and map them to our taxonomy. We provide mitigation strategies and security recommendations to overcome the discussed attacks, as well as potential future attacks targeting similar IoT devices, operating in similar ecosystems while harboring similar vulnerabilities. Our attack taxonomy enables the systematic investigation of attack clusters (i.e., device, infrastructure, communication, service) instead of specific attacks -overcoming the requirement to singularly investigate every newly encountered attack -thus, expediting security retribution.
Although the impact of IoT attacks can range depending on the targeted IoT device and the operational environment, certain vulnerabilities exist in a variety of IoT systems, e.g., default credentials, lack of network segregation, etc., regardless of the application sector. These critical vulnerabilities, which span the IoT spectrum, require specific handling and precise remediation. IoT device vendors, protocols, and users alone cannot safeguard the security of IoT ecosystems, thus unified security policies need to be implemented to enhance the security of consumer, commercial and industrial systems. Following this policy-oriented approach, researchers have proposed frameworks which can enhance the security of commercial IoT systems [119]. Furthermore, tech firms have also joined this effort to modernize the IIoT sector (due to its mission-critical objectives), hardening IIoT against cyberattacks, improving its resilience and safeguarding its operations [120], [121]. Moving forward, synergies between the academia, the industry along with state and nation-wide policy enforcing mechanisms are necessary to improve the overall security posture of the constantly-growing IoT systems. The unexpected influx of connected devices due to the COVID-19 pandemic accentuated the need for consolidated security practices [122]. As a result, the European Union (EU) immediately issued security strategies and policies in order to regulate and enforce security measures. The architectural heterogeneity, distributed, and interconnected nature of IoT systems practically prohibits the development of a be-all and end-all security solution. However, leveraging the accumulated experience and knowledge of security engineers and scientists from the academic community and the industry arises as a good approach to safeguard the IoT. The consolidated effort of security policy makers and security researchers can help even the security battlefield by effectively dealing with existing vulnerabilities, and impeding the propagation of newly discovered zero-days before they develop into threats or attacks. Alireza Jolfaei received the Ph.D. degree in Applied Cryptography from Griffith University, Gold Coast, Australia. He is the Program Leader of Master of IT in Cyber Security at Macquarie University, Sydney, Australia. His main research interests are in Cyber and Cyber-Physical Systems Security. He has participated in several projects involving different aspects of Cyber Security. On these topics he has published over 60 papers appeared in journals, conference proceedings, and books. Before Macquarie University, he has been a faculty member with Federation University Australia and Temple University in Philadelphia, PA, USA. He has received multiple awards for Academic Excellence, University Contribution, and Inclusion and Diversity Support. He received the prestigious IEEE Australian council award for his research paper published in the IEEE Transactions on Information Forensics and Security. He served as the Chairman of the Computational Intelligence Society in the IEEE Victoria Section and also as the Chairman of Professional and Career Activities for the IEEE Queensland Section. He has served as the associate editor of IEEE journals and transactions, including the IEEE IoT Journal, IEEE Sensors Journal, IEEE Transactions on Industrial Informatics, IEEE Transactions on Industry Applications, IEEE Transactions on Intelligent Transportation Systems, and IEEE Transactions on Emerging Topics in Computational Intelligence. He has served as a program co-Chair, a track Chair, a session Chair, and a Technical Program Committee member, for major conferences in Cyber Security, including IEEE TrustCom. He was the General Chair of the 6th IEEE International Conference on Dependability in Sensor, Cloud, and Big Data Systems and Applications (DependSys 2020) in Fiji. He is a Distinguished Speaker of the Association for Computing Machinery (ACM) on the topic of Cyber Security and a Senior Member of the Institute of Electrical and Electronics Engineers (IEEE).
Muhammad Khurram Khan is currently working as a Professor of Cybersecurity at the Center of Excellence in Information Assurance, King Saud University, Kingdom of Saudi Arabia. He is founder and CEO of the 'Global Foundation for Cyber Studies and Research' (http://www.gfcyber.org), an independent and non-partisan cybersecurity thinktank in Washington D.C, USA. He is the Editorin-Chief of 'Telecommunication Systems' published by Springer-Nature with its recent impact factor