Deployment Optimization of IoT Devices through Attack Graph Analysis

TL;DR

This paper presents a method to optimize IoT device deployment by analyzing augmented attack graphs that consider device location and communication, aiming to enhance network security and utility.

Contribution

It introduces an attack graph-based approach with heuristic optimization to improve IoT deployment security, considering physical location and communication capabilities.

Findings

Augmented attack graphs effectively quantify IoT deployment impact on security.

Heuristic search accelerates optimization of IoT deployment.

Optimized deployment improves network security and utility.

Abstract

The Internet of things (IoT) has become an integral part of our life at both work and home. However, these IoT devices are prone to vulnerability exploits due to their low cost, low resources, the diversity of vendors, and proprietary firmware. Moreover, short range communication protocols (e.g., Bluetooth or ZigBee) open additional opportunities for the lateral movement of an attacker within an organization. Thus, the type and location of IoT devices may significantly change the level of network security of the organizational network. In this paper, we quantify the level of network security based on an augmented attack graph analysis that accounts for the physical location of IoT devices and their communication capabilities. We use the depth-first branch and bound (DFBnB) heuristic search algorithm to solve two optimization problems: Full Deployment with Minimal Risk (FDMR) and Maximal Utility without Risk Deterioration (MURD). An admissible heuristic is proposed to accelerate the search. The proposed method is evaluated using a real network with simulated deployment of IoT devices. The results demonstrate (1) the contribution of the augmented attack graphs to quantifying the impact of IoT devices deployed within the organization on security, and (2) the effectiveness of the optimized IoT deployment.

Tables

Table 1. Table 1. Results (average over 40 executions)

Problem	DFBnB			Random Deployment
	Risk Score (std)	Devices Deployed (std)	Time (min)	Risk Score (std)	Devices Deployed (std)
FDMR	1229 (239.41)	6 (0)	36.20	1494.46 (370.82)	6 (0)
MURD	1032 (0)	4.40 (1.13)	3.88	1538.95 (364.74)	4 (0)

Equations

$$G_{depl}=(N_p,N_e,N_f,E,M,g),$$

$$E\subseteq (N_p\times N_e)\cup (N_e\times (N_e\cup N_f)),$$

$$R(depl)=(OptLen(G_{depl})),OptCnt(G_{depl}))$$

$$OptLen(G_{dep{l}_x})>OptLen(G_{dep{l}_y})\vee$$

$$[OptLen(G_{dep{l}_x})=OptLen(G_{dep{l}_y})\wedge$$

$$OptCnt(G_{dep{l}_x})<OptCnt(G_{dep{l}_y})]$$

$$\underset{dep{l}_{full}}{\mathrm{argmin}}\{R(dep{l}_{full})\}$$

$$\underset{depl}{\mathrm{argmax}}\{|R(depl)|:R(depl)=R(dep{l}_{empty})\}$$

$$h_{FDMR}(dep{l}_n)=\underset{d\in D}{\mathrm{argmin}}\{R(dep{l}_d)\in Table(dep{l}_n)\}$$

$$h_{MURD}(dep{l}_n)=|R(dep{l}_d)\in Table(dep{l}_n):R(dep{l}_d)=R(dep{l}_{empty})|$$

Full text

Attack graphs, Internet of Things, IoT deployment, Optimization, Short-Range Communication

††copyright: rightsretained††journalyear: 2019††copyright: acmlicensed††conference: 12th ACM Conference on Security and Privacy in Wireless and Mobile Networks; May 15–17, 2019; Miami, FL, USA††booktitle: 12th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec ’19), May 15–17, 2019, Miami, FL, USA††price: 15.00††doi: 10.1145/3317549.3323411††isbn: 978-1-4503-6726-4/19/05††ccs: Security and privacy Distributed systems security††ccs: Security and privacy Mobile and wireless security

1. Introduction

It is estimated that by 2020 more than 20 billion IoT devices will be deployed in the world  (Meulen, 2017). Most IoT products are not equipped to deal with security and privacy risks, which can turn them into the weakest link of organizational networks. The risk of IoT devices to the security of an organization is underestimated in many cases when an organization’s IT department relies solely on network separation to isolate IoT devices from other IT assets. Such an approach disregards some of the unique properties of IoT devices, such as light or sound emissions, various sensors, and diverse communication protocols such as NFC, Bluetooth, ZigBee and LoRA, in addition to standard Wi-Fi. The advanced capabilities of IoT devices can be exploited by an attacker for lateral movement within an organization, shoulder surfing, and more, making them a valuable asset for an attacker.

With respect to hardening IoT security, most prior research focuses on the security of individual IoT devices (Roman et al., 2011; Liu et al., 2012; Zhang et al., 2014), the security of an IoT protocol (Vaccari et al., 2017; Zillner, 2015; Morgner et al., 2016; Wright, 2009; Ronen et al., 2017), or the the security of a network that consists solely of IoT devices (Huang et al., 2014; Skarmeta et al., 2014; Zanella et al., 2014; Ge and Kim, 2016) (see Section 3.1 for more details). To the best our knowledge, there is no previous related research aimed at identifying the optimal (security risk-wise) deployment of devices within the physical space. The location of an IoT device within an organization can have unintended effects on the network topology such as bridging between networks through short-range communication protocols (see Sections 2.2 and 2.3). We use the following example to demonstrate the problem.

Example 1.1.

Assume, for example, an office with two conference rooms and a kitchen (Figure 1). Each conference room has a computer ($COMP1$ and $COMP2$) connected through Wi-Fi to two different VLANs ($VLAN1$ and $VLAN2$ respectively). $COMP1$ also has Bluetooth. A smart refrigerator in the kitchen is connected to $VLAN3$ and has Internet connectivity. All other IoT devices in the office are connected to $VLAN3$ as well. The office purchased two televisions ($TV1$ and $TV2$) to replace the old projectors in the conference rooms. Both televisions are connected to $VLAN3$ via Wi-Fi; TV1 is also equipped with Bluetooth.

Should we install $TV1$ in Conference Room 1 and $TV2$ in Conference Room 2 or vice versa? To answer this question assume, for example, that unbeknownst to the organization, a sophisticated malware has managed to infect one of the computers in the organizational network. Further, assume that the malware is equipped with the necessary exploits to hop between devices in the office. If $TV1$ is placed in Conference Room 1, the attacker could take advantage of the fact that both $TV1$ and $COMP1$ have Bluetooth and create an attack path to the refrigerator. However, if $TV1$ is placed in Conference Room 2 this attack path will no longer be available to the attacker.

The risk of potential multi-step attacks such the one described in Example 1.1 can be estimated using attack graphs (Phillips and Swiler, 1998; Ou et al., 2006). An attack graph is a model of a computer network that encompasses computer connectivity, vulnerabilities, assets, and exploits. It is used to represent a collection of complex multi-step attack paths (hereafter referred to as attack plans) and can be used to assess and quantify security risk (see Section 2.1 for more details).

In this paper, the proposed method augments attack graph analysis to account for the physical location of IoT devices and their communication capabilities. (see Section 4). Relying on the new attack graphs, we quantify the risk of adding an IoT device to a given network and show that the number of short attack paths may increase by 19% due to the deployment of only six IoT devices in a small to medium sized enterprise; short attack plans often pose the greatest threat, because they represent an attack that needs fewer resources to be executed.

We also optimize the deployment of IoT devices in order to reduce the negative security implications of such deployment (see Section 5). Two optimization problems are presented: the Full Deployment with Minimal Risk (FDMR) problem where all required IoT devices should be deployed with minimal security implications and the Maximal Utility without Risk Deterioration (MURD) problem where the maximal number of IoT devices should be deployed without increasing the security risk of the network. We use depth-first branch and bound (DFBnB) heuristic search algorithm to solve both optimization problems and suggest an admissible heuristic function to accelerate the search. Our experiments show that optimal deployment of IoT devices can reduce the number of possible attack plans by 18% (see Section 6).

2. Background

2.1. Attack Graphs

An attack graph is a model of a computer network that encompasses computer connectivity, vulnerabilities, assets, and exploits (Phillips and Swiler, 1998; Ou et al., 2006). Attack graphs are used to represent collections of complex multi-step attack scenarios traversing an organization from an initial entry point to the most critical assets. By analyzing the attack graph, a security analyst can assess the risks of potential intrusions and devise effective protective strategies. The attack graph analysis methodology contains three main stages: (1) network and vulnerability scanning, (2) attack graph modeling, and (3) attack graph analysis.

In the first stage, the Nessus vulnerability scanner (Beale et al., 2004) is used in order to map the vulnerabilities of all of the hosts in the organization. Connectivity between the hosts can be identified manually by system administrators based on the organizational network topology and firewall configurations. Nessus, Nmap, or other network scanners can aid in the connectivity assessment process.

Network connectivity and vulnerability reports are processed by MulVAL (Ou and Govindavajhala, 2005) to generate an attack graph representation in planning domain definition language (PDDL). An attack graph consists of privilege nodes, exploit/action nodes, and fact nodes. In an attack graph, a privilege node represents the information gained or the access privileges that the attacker obtains (represented by triangles in the graph). An exploit/action node represents the action the attacker needs to exploit a vulnerability (represented by ovals). The edges of exploit nodes are for preconditions and postconditions of the exploit. A fact node represents a network condition that needs to exist in order for the attacker to exploit the vulnerability (represented by rectangles). To gain a privilege, an attacker needs to execute one of the actions leading to it (logical OR). To use an exploit, the attacker needs all of the privileges and the facts that lead to the exploit (Logical AND). An exploit node needs all of these preconditions leading to it to be executed, and once executed, the attacker gains all of the postconditions the exploit node leads to (Ou et al., 2006; Sawilla and Ou, 2008; Ammann et al., 2002; Noel and Jajodia, 2014).

Example 2.1.

Figure 2 presents an abstract attack graph of the situation described in example 1.1. At the top of the figure, two fact nodes (nodes 1 and 2) that represent two facts of the system can be seen (green rectangles). Access between $COMP1$ and $TV1$ can only created if these two conditions exist, as can be seen from the blue oval, which represents an exploit node (node 3). This access allows the attacker to use the Bluetooth connectivity of $TV1$, as represented by the orange diamond (node 4), meaning that the attacker can obtain control of $TV1$ via $COMP1$.

Following the construction of an attack graph, the graph’s PDDL representation can be used as a domain model for variety of planners. A typical task is finding the optimal attack plan or estimating the likelihood of a successful attack given the attack graph of an organization (Singhal and Ou, 2011; Wang et al., 2008; Noel and Jajodia, 2014). Consequently, attack graphs can be used for hardening network security through a variety of attack graph optimizations (Islam and Wang, 2008; Abadi and Jalili, 2006; Polad et al., 2017; Noel et al., 2003).

2.2. Security in the Internet of Things

Traditional security solutions such as firewalls, IDSs, anti-viruses, and software patches are not suitable for IoT devices. The three major reasons for this are (Yu et al., 2015): (1) Types of policies: a single app may use several IoT devices, communicating explicitly (e.g., via Wi-Fi or Bluetooth) or implicitly (e.g., an IoT light bulb can be triggered by an IoT light sensor). The outcome is a complex and dynamic network which can be hard to secure using a single security policy (e.g., with firewalls). (2) Signatures and anomalous behavior recognition: some security methods store anomalies and signatures on the device to recognize and detect threats. Due to the diversity of IoT devices and manufacturers, these methods will be inadequate, mainly because of the constant need to update and maintain the device to support these tools. (3) Enforcement mechanism: IoT devices have low computation abilities, low power consumption, and do not run full-fledged operating systems. Most common security methods need all of the above to operate and therefore are impractical to implement on IoT devices. (4) Unsupported devices: the longevity of IoT devices can lead to deployed devices that vendors no longer support. In that way, vulnerable devices (with default passwords or unpatched bugs) can remain in the organization.

Moreover, the competitive IoT device market compels vendors to try and get their products out as fast as they can, prioritizing functionality and the user experience, and ignoring the security aspect. In general, most products hardly deal with security and privacy risks, making them the weakest link in terms of security and the target of attackers interested in breaking into networks and harming systems or leaking information (Yu et al., 2015). Thus, despite the fact that security was recognized as a central issue of the IoT market as early as 2011 by Bandyopadhyay et al.  (Bandyopadhyay and Sen, 2011), it still continues to remain a challenge today.

2.3. Short Range Communication Protocols

When connecting a device to a network it is possible to use two categories of networking technologies. The first and simplest category is to connect using standard existing network technologies such as Wi-Fi and Ethernet. The second category is to connect using different wireless technologies that are more suitable for some devices, e.g., technologies that are more appropriate for devices that require low energy consumption protocols. These protocols are short-range communication protocols, due to their requirement for short proximity in order to perform a connection.

Currently, in the second category there are several communication methods that can be used, including: ZigBee, Z-Wave, Powerline, Bluetooth 4.0, and other radio frequency protocols, but no standard protocol exists. Both Z-Wave and ZigBee are considered secure, but implementation flaws and manufacturer mistakes make them vulnerable (Barcena and Wueest, 2015).

In our research, we focus on ZigBee and Bluetooth, since they are ones of the most common wireless technologies used to connect IoT devices. First, we start with the ZigBee protocol, which guarantees low power consumption and a two-way, reliable, wireless communications standard for short-range applications. It is open-source and has advantages such as easy deployment and global usage.

The ZigBee protocol was created with security considerations in mind, but consumer demand for cheap devices with long life expectancy often caused vendors to sacrifice security, which led to poor implementation of the protocol (Zillner, 2015); this, in turn, led to major security issues such as data compromising or information sniffing. (Vaccari et al., 2017). For example, Vaccari et al.  (Vaccari et al., 2017) focused on the security aspects of the ZigBee protocol. The study identified important security issues and presented an attack on the protocol which enabled the attacker to compromise the data transferring in the network. Morgner et al.  (Morgner et al., 2016) described a novel attack that shows that the ZigBee Light Link standard is insecure by design. Wright et al.  (Wright, 2009) published KillerBee, a penetration testing tool which allows ZigBee traffic to be sniffed and analyzed. Ronen et al.  (Ronen et al., 2017) found a major bug in the ZigBee protocol in Philip Hue smart lamps. They were able to perform an over-the-air firmware update, thereby infecting the lamp with a worm that can spread to any of the lamp’s neighbors.

Bluetooth was developed by a group called the Bluetooth Special Interest Group (SIG) in May 1998. Today, a lot of smartphones, sports devices, sensors, and medical devices have Bluetooth. The protocol become widely used because of its low cost and low power consumption.

In (Ryan, 2013), techniques were presented for eavesdropping on devices using Bluetooth. An extended review of Bluetooth threats and possible attacks was performed by Minar et al. , Sandya et al. and Dunnin  (Minar and Tarique, 2012; Sandhya and Devi, 2012; Dunning, 2010), and recently, Cope et al.  (Cope et al., 2017) investigated the currently available tools to exploit vulnerabilities in Bluetooth. In conclusion, many Bluetooth versions that are in use today, have a wide variety of security vulnerabilities.

In addition to the security issues, the number of communication protocols in an IoT device can also influence the security of the device. If such a device is compromised by an attacker that has hacked into one of its communication protocols, the hacker can take advantage of the compromoised device and use the other protocols as entry points to the network (Ge et al., 2017).

Of all the above, short-range communication protocols are another aspect of IoT devices that make them insecure compare to regular hosts.

2.4. Heuristic Search

Heuristic search is a family of techniques used to solve difficult problems in artificial intelligence (AI). In this case, each problem is represented by states, where each state represents the current condition of the problem. Each problem also has a starting state and one or more goal states. A search space is the environment in which a search takes place, where the purpose of the search is to find a path from the start state to one of the goal states in the search space. Each solution represents by one goal state. The quality of the solution is measured by the cost of the goal state. Search algorithms make a distinction between minimum and maximum problems. In a minimum problem, we want to find the solution with the lowest cost, and in a maximum problem the highest cost solution is desired. Most problems are minimum problems, e.g., we want the cheapest or the fastest solution. If not stated differently in this paper, we are referring to a minimum problem. In our research, we use the depth-first branch and bound algorithm (Korf, 2010; Zhou and Hansen, 2006) which uses a heuristic function to solve the problems more efficiently.

2.4.1. Heuristic

A heuristic is an estimation of the cost of the path from node $n$ to a goal node. The heuristic function is used to steer the search algorithm in the direction of the goal. In an informed way, heuristics help the algorithm guess which child out of all of the node’s children will lead to the goal.

**Admissible Heuristic. ** If, for any $n$, a heuristic function never overestimates the cost of the best path from node $n$ to a goal node, then the function is referred to as an admissible heuristic function. Note that in a maximum problem (where we want the solution with the maximum cost) it is the opposite, i.e., a heuristic function that never underestimates the cost of the best path.

In most search algorithms, one of the most important conditions for a heuristic function is that it should be admissible.

2.4.2. DFBnB Algorithm

depth-first branch and bound (DFBnB) is a depth-first search algorithm (Zhou and Hansen, 2006; Korf, 2010). The algorithm is used to navigate through the search space and find the optimal solution. During the search process, DFBnB maintains the best solution found so far. In order to perform pruning more frequently and thus accelerate the search process, DFBnB uses a heuristic function. The algorithm returns an optimal solution with linear memory space, assuming the heuristic function is admissible.

DFBnB prunes subtrees of the search space whenever the algorithm can prove that no solution can be found that is better than the incumbent solution. This solution depends on the kind of problem (i.e., minimum or maximum), which is determined by the cost of the goal state.

3. Related Work

3.1. IoT Device Deployment

There are several works regarding the deployment of IoT devices, but most of them do not consider the security aspect. For example, Huang et al.  (Huang et al., 2014) proposed a deployment scheme used to a achieve green networked IoT, while Skarmeta et al.  (Skarmeta et al., 2014) focused on privacy issues and Zanella et al.  (Zanella et al., 2014) focused on the IoT in smart cities.

Some of the research that refers to security analyzes single IoT devices but does not look at IoT devices as a deployment problem. Liu et al.  (Liu et al., 2012) tried to solve the problem of assessing the risk of a single IoT device, by proposing a dynamical risk assessment method inspired by an artificial immune system. Zhang et al.  (Zhang et al., 2014) and Roman et al.  (Roman et al., 2011) reviewed security issues in the IoT in terms of the security of each device.

There are a few works that refer to deployment and network security, but they do not take the combination of hosts (such as computers and servers) with IoT devices into consideration. Mohsin et al.  (Mohsin et al., 2017) argued that the likelihood of exploiting IoT vulnerabilities depends on the system configuration. The authors explained that various configurations derive from different devices, technologies, and connectivity, all of which serves the same goal but have different risk levels. Santoso et al.  (Santoso and Vun, 2015) presented an approach to secure smart home systems in which IoT devices are deployed, and Abie et al.  (Abie and Balasingham, 2012) introduced a risk-based adaptive security framework for the IoT in health-care systems. The research mentioned above reflects the many challenges of IoT security. In this respect, our work is unique in two ways. First, it combines the security concerns of the IoT with workstations and servers, while taking into account the possible use of one to hack the other. Second, our network model is a generic network that can be suitable for a variety of scenarios and is not specific for a particular domain.

3.2. Attack Graph Optimization

**Attack Graph Representation. ** Attack graphs have been used to estimate the security risk score of organizational networks (Singhal and Ou, 2011; Wang et al., 2008; Noel and Jajodia, 2014), however the specific characteristics of IoT devices were not considered in these articles. In all of this research, the structure of the regular IT network is analyzed, taking into account the vulnerabilities of workstations and servers. IoT devices introduce additional challenges to security risk modeling through attack graphs, such as the diverse physical locations, variety of short-range communication protocols, cyber-physical capabilities of the devices, mobility, etc.

In this paper, we augmented the attack graph model of an organization to consider locations and short-range communication of IoT devices, and we used the augmented attack graph model to optimize the deployment of IoT devices throughout the organization.

**Risk Score. ** Wang et al.  (Wang et al., 2008) suggested an overall network security score by combining individuals’ vulnerabilities regarding their relationship in attack graphs. Singhal et al.  (Singhal and Ou, 2011) defined the risk score as the likelihood of an attack which was derived from the likelihood of individual exploits. Noel et al.  (Noel and Jajodia, 2014) described four families of metrics for measuring security risk in attacks graph. Every family was represented by one entry in a four-dimensional vector. The Euclidean norm of this vector was used as the overall risk score. Gonda et al.  (Gonda et al., 2017) computed the number of shortest plans in a planning graph derived from an attack graph as a way to measure the security of the network, and Swiler et al.  (Swiler et al., 2001) computed the set of near-optimal shortest paths to identify the most exploitable components in the network. Polad et al.  (Polad et al., 2017) used an attack graph to estimate the security of the network as the cost of the attack path that led to the goal.

All the above risk scores can be used to optimize the IoT deployment once the attack graph definition has been augmented to take into account the IoT device specifications. In this paper, we adopt Gonda’s approach to measure network security and combined it with Polad’s method, to include the length of the shortest plans, as well as their quantity (see Section 4.3).

Optimization Problems. Security risks can be reduced by patching vulnerabilities. However, it is not always possible to patch all vulnerabilities at once due to operational costs (patching often requires significant downtime). A variety of low cost network hardening approaches can be used to prioritize the vulnerabilities (e.g., (Noel et al., 2003; Jun-chun et al., 2011)). Islam et al.  (Islam and Wang, 2008) argued that most of these methods are not scalable. They proposed heuristic algorithms to accelerate the patch optimization. Abadi et al.  (Abadi and Jalili, 2006) used the ant colony optimization algorithm to detect a minimum critical set of exploits. Polad et al.  (Polad et al., 2017) examined the effect of adding fake vulnerabilities in an attack graph and used combinatorial optimization in order to find optimal assignment of these vulnerabilities. Almohri et al.  (Almohri et al., 2016) used sequential linear programming in attack graphs to find the optimal placement of security products (e.g., a host-based firewall) across a network. The authors used a probabilistic model which uses Bernoulli and transformed the attack graph into a system of linear and nonlinear equations. Noel et al.  (Noel and Jajodia, 2008) used attack graph to optimize the placement of intrusion detection system (IDS) sensors to allow monitoring malicious activity on critical paths.

In this paper we present a different optimization problem of optimizing the set of IoT devices to be deployed throughout an organization with minimal implications to the network security.

3.3. IoT in Attack Graphs

Very little work has been performed on attack graphs that consist of IoT devices. The first research performed in this area was conducted by Ge et al.  (Ge and Kim, 2016) who used attack graphs in conjunction with IoT devices. However, the network used consisted only of IoT devices, most of which were the same kind of device. The network topology was fixed, small, and relatively uncomplicated. The authors proposed a framework for IoT device security modeling with the aim of presenting all possible attack paths in the network, evaluating the security level, and assessing the effectiveness of different defense strategies.

In a later work, Ge et al.  (Ge et al., 2017) noted that some IoT devices use more than one communication protocol. The writers argued that if such a device is compromised by hacking into one of the communication protocols, the hacker can take advantage of it and use the other protocols as entry points to the network. The paper used HARMs (hierarchical attack representation models), which are models of attack graphs used, to improve scalability (Hong and Kim, 2012). The authors presented a real scenario and showed how an attacker can take advantage of it. In the scenario, some devices have both Wi-Fi and ZigBee communication protocols. Also present are smart devices such as a tablet and TV that can connect to a Philips Hue lighting system (Hue Bridge) by Wi-Fi. This lighting system also has ZigBee which allows it to control smart light bulbs in the house. By exploiting the tablet that runs the Hue application, an attacker can gain control of the Hue Bridge system and use it to control all of the smart lights. The authors noted that the lighting hub can consist of any other smart hub, and the scenario can also be used to hack into any smart device, not only light bulbs.

Yiğit et al.  (Yiğit et al., 2019) proposed COBANOT, a heuristic-based cost and budget aware network hardening solution for IoT systems which uses compact attack graphs (Chen et al., 2010). This work is the first to use attack graphs in IoT systems for network hardening. However, their experiment included a small-scale attack graph that only consists of IoT devices. In addition, none of the unique characteristics of IoT devices, such as different protocols, mobility, physical proximity, etc. were considered.

Our research focuses on networks that combine all kinds of hosts and IoT devices. Also, our network’s size is larger than the networks used in the research mentioned above.

4. IoT Attack Graphs

4.1. IoT Deployment

In a typical organization, all hosts (workstations and servers) are connected to the organizational network via a wired or wireless connection. Let $H=\{h_{1},h_{2},\ldots,h_{z}\}$ be the set of hosts that are part of the organization network.

In addition to the regular hosts, the organizational network may contain IoT devices. Let $D=\{d_{1},d_{2},\ldots,d_{m}\}$ indicates the set of unique IoT devices. Each IoT device $d_{i}$ has a unique identifier (usually an IP address).

IoT devices differ by their purpose and capabilities. For example, a refrigerator is capable of maintaining a low temperature while a smart TV is capable of showing high definition movies. We group IoT devices by type, e.g., refrigerator, TV, camera, smoke detector, etc. $T=\{t_{1},t_{2},\ldots,t_{n}\}$ is the set of all the IoT device types. We denote a set of all devices that are of type $t$ as $D(t)$ and a single device type $d$ as $t(d)$. We assume that every IoT device is part of just one group.

Some IoT devices can only be deployed in specific predefined designated locations. For example, the kitchen is typically the designated location for a refrigerator, while large TV screens or projectors are found in meeting rooms. Some IoT devices such as cameras or smoke detectors may be deployed in many different locations throughout an organization.

Definition 4.1 (Locations).

$L=\{l_{1},l_{2},\ldots,l_{b}\}$ indicates the set of unique location spots where IoT devices can be deployed. We denote the set of locations where an IoT device of a specific type $t\in T$ can be deployed as $L(t)\subseteq L$. In every location spot only one type of IoT devices can be deployed, meaning, $L(t)$ is defined such that the intersection of each pair of $L(t_{i})$ sets are empty, $\cap_{t\in L(t)}=\emptyset$. Because a location spot must be associated with some type of IoT devices, the union of $L(t)$ is equal to $L$, $\cup_{t\in L(t)}=L$

Organizations may have constraints about the deployment of IoT devices. We defined two main constraints for a device type $t$. The first one is the number of locations (out of the total locations available) that need to contain a deployed device of that type. For instance, there are four possible locations for cameras in the hallway, but the organization only needs to deploy two of them. The second constraint is the number of devices there are of each type. For instance, for one location in which a refrigerator can be deployed, there are three possible refrigerators that the organization can purchase.

Definition 4.2 (Location Constraint).

Let $C$ be the set of all constraints. $C(t)$ is a three-tuple that represents a constraint for a type $t$, $C(t)=(L(t),n(t),D(t))$.

$L(t)$ is the set of locations that an IoT device of a specific type $t$ $\in$ $T$ can be deployed (as defined in Definition 4.1).

$n(t)$ is the number of locations that needed to be deployed out of all locations in $L(t)$.

$D(t)$ is a set of all IoT devices that are of type $t$.

An example of a constraint can be derived from example 1.1. Suppose the organization has three possible locations in which a TV can be deployed ($L(TV)=\{l_{TV_{1}},l_{TV_{2}},l_{TV_{3}}\}$) but only needs to deploy a TV in two of these locations ($n(TV)=2$). In addition, there are four different televisions that can be deployed ($D(TV)=\{d_{tv1},d_{tv2},d_{tv3},d_{tv4}\}$). Formally, constraint $C(TV)$ would be defined as follow:

$C(TV)=(\{l_{TV_{1}},l_{TV_{2}},l_{TV_{3}}\},2,\{d_{tv1},d_{tv2},d_{tv3},d_{tv4}\})$.

Assume that at most one IoT device can be deployed in each location $l\in L$. The deployment of IoT devices is defined as a function $depl:D\rightarrow L\cup\{\bot\}$ which maps every device to a particular location. The special non-location symbol $\bot$ signifies that a device is not deployed. We say that a deployment is valid if it does not violate the constraints specified in Definition 4.2.

Definition 4.3 (Valid Deployment).

Let $depl:D\rightarrow L\cup\{\bot\}$ be a deployment of IoT devices. $depl$ is valid if $\forall_{d\in D},depl(d)\in L(t(d))\cup\{\bot\}$.

We denote $depl_{full}$ as a deployment that satisfies all constraints $C$ and $depl_{empty}$ as an empty deployment with no IoT devices deployed. Note that the condition $n(t)\leq|D(t)|$ should be satisfied for full deployment to exist.

Many IoT devices deployed within an organization’s premises will likely be able to communicate with nearby hosts via short-range communication (SRC) protocols such as ZigBee, Bluetooth, ad hoc Wi-Fi, etc. Some hosts within the organization may also support SRC protocols, which could allow the adversary to hop between networks.

Definition 4.4 (Short-Range Communication).

We define a set of short-range communication protocols $SRC=\{p_{1},p_{2},\ldots\}$. Let $src:D\cup H\rightarrow 2^{SRC}$ be a function that maps an IoT device or a host to the subset of SRC protocols that it supports.

In the remainder of this paper we will use the term device to refer to both IoT devices and hosts.

Any two devices connected via a SRC protocol must reside within a certain distance from each other (i.e., the communication range). For example, let $d\in D$ be some IoT device that supports SRC protocol $p\in SRC$, and let $h\in H$ be some host that supports the same protocol. If $d$ is deployed in location $l$ and $h$ resides within the communication range of $l$, then $d$ may communicate with $h$ and vice versa.

Definition 4.5 (Location Range).

We define the $range:L\cup\{\bot\}\rightarrow 2^{D\cup H}$ of a particular location as the set of hosts that may communicate with an IoT device deployed there.

It is important to note that $range(l),l\in L$ is an estimation based on the radio specification of different IoT devices. The actual set of devices in range of IoT device deploy in location $l$ may vary depending on the power of the radio, obstacles, interference, etc.

For the ease of discussion we ignore the protocol type and the specifications of the devices in Definition 4.5. The definition of $range$ can be augmented with this additional information without modifications to the algorithms presented. Please note that a device can be in the range of several locations and that no devices are in the range of the non-location $\bot$ (i.e. $range(\bot)=\emptyset$).

4.2. Attack Graph Definition

The potential locations of IoT devices and SRC protocols are integrated in the attack graph analysis methodology after the scanning stage and before attack graph modeling. For every possible deployment of IoT devices, that will be considered during the course of the optimization, we augment the connectivity map of devices to include the hypothetical connections between any IoT device $d\in D$ deployed in location $depl(d)$ and all devices in the range of $d$ : $range(depl(d))$.

Once the connectivity between all devices has been defined, we use the standard MulVAL framework to generate an attack graph that considers some given deployment of IoT devices. Each deployment has a different attack graph, depending on the devices deployed. If no IoT device is deployed the deployment is empty ($depl_{empty}$), and the attack graph is simply the original attack graph of the organization.

We adopt the attack graph definition introduced by Ou et al.  (Ou et al., 2006).

Definition 4.6 (Logical Attack Graph).

Let $depl$ be a deployment of IoT devices in an organization. The logical attack graph $G_{depl}$ is a tuple:

[TABLE]

where $N_{p}$, $N_{e}$, and $N_{f}$ are the sets of privilege nodes, exploit nodes and fact (leaf) nodes, respectively, and $E$ is a set of directed edges

[TABLE]

There are two types of edges in an attack graph. An edge $(e,p)\in E$ from an exploit node $e\in N_{e}$ to a privilege node $p\in N_{p}$ means that the attacker can gain privilege $p$ by executing exploit $e$. In order to gain a privilege, an attacker needs to execute one of the exploits leading to it.

An edge $(f,e)\in E$ from a fact node or a privilege node $f\in N_{f}\cup N_{p}$ to an exploit node $e\in N_{e}$ means that the node $f$ is a precondition to executing the exploit $e$. For example, a fact node could be a vulnerability in the Bluetooth protocol that can be exploited if the attacker is in the Bluetooth range of the vulnerable device. In order to execute an exploit, the attacker needs all of the privileges and facts that lead to the exploit.

In this paper, in contrast to the definition introduced by Ou et al.  (Ou et al., 2006), the edge orientations follow the direction of the implied logical operation.

Next, we define the term attack plan. For that purpose, we changed the notations from Gefen et al.  (Gefen and Brafman, 2012) slightly, as follows:

$pre(e)=\{v\in N_{p}\cup N_{f}|(v,e)\in E\}$ are all of the preconditions of node $e$.

$obt(p)=\{e\in N_{e}|v\in N_{p}\&(e,v)\in E\}$ is the set of exploits that lead to privilege node $p$ (the set of privileges the attacker obtained).

An attack plan is a sub-graph $G_{depl}^{\prime}$ of some attack graph $G_{depl}$ that represents a scenario in which the attacker manages to reach the goal, namely $g\in G_{depl}^{\prime}$. Therefore, in an attack plan all of the preconditions of an exploit $e\in G_{depl}^{\prime}$ are satisfied, and each privilege $p\in G_{depl}^{\prime}$ is obtained by an exploit.

Definition 4.7 (Attack Plan).

Let $AP(G_{depl})$ be all of the attack plans of graph $G_{depl}$. Each attack plan $G_{depl}^{\prime}\in AP(G_{depl})$ needs to satisfy these three conditions:

• •

$g\in G_{depl}^{\prime}$

• •

$\forall a\in N_{e}:pre(a)\subseteq G_{depl}^{\prime}|N_{e}\in G_{depl}^{\prime}$

• •

$\forall p\in N_{p}:\exists a\in obt(p)\subseteq G_{depl}^{\prime}|N_{p}\in G_{depl}^{\prime}$

We consider the length of an attack plan as the number of nodes it contains. $OptLen(G_{depl})$ is the length of the shortest attack plan in graph $G$, a $OptCnt(G_{depl})$ indicates how many of the shortest attack plans there are in graph $G$.

4.3. Risk Score

The network security can be estimated by the Risk Score, where the higher the risk score the lower the security of the network. In an environment in which IoT devices are deployed, there are a few aspects to consider when choosing a method for computing the risk score.

First, the method needs to convey that the deployment of IoT devices may generate new attack plans. Consequently, the cost of an attack may drop and the likelihood of an attack may increase due to the additional vulnerabilities and opportunities for lateral movement that an attacker can exploit. Second, the method needs to indicate the changes in different deployments and be sensitive enough to detect the changes caused by the deployment of even a single additional IoT device.

We consider a deployment of IoT devices that reduces the number of options the attacker has for an attack. Therefore, in our work, we choose to calculate the shortest attack plans, taking their length and quantity into consideration. Gonda et al.  (Gonda et al., 2017) describes the computation of the shortest attack plans in detail. As noted by the authors, enumerating all of the attack plans is NP-hard, which means that the running time can be exponential, however, we performed this computation on several networks, and the running time was short, as can also be seen in Section 6.3.

Definition 4.8 (Risk Score).

$R(depl)$ is a tuple that represents the risk score of deployment $depl$. The first element is the length of the shortest attack plan in graph $G_{depl}$, and the second element indicates how many of the shortest attack plans there are.

[TABLE]

As mentioned above, we took two aspects of the shortest plans into consideration: the length of the plan and how many of the shortest plans there are. For example, the risk score for the scenario in Example 1.1 is $R(15,1)$, since there is only one attack plan, and this plan has all fifteen nodes in the graph (see Figure 2).

Considering only one of the above, the number of shortest plans or the length of the shortest plan, will not provide a good estimation of network security . Suppose a network has $x$ shortest plans of length $l$ to the goal. Further suppose that after deploying an IoT device, we now have a new plan of length $z$ that leads to the goal, when $z<l$. In this case, the total number of shortest plans will decrease to one ($1<x$). If we only took into account how many of the shortest plans there are, it would appear that the risk score decreased (from $x$ to one), which implies that the network is now more secure. However, adding a device does not, in itself, eliminate any plans (i.e., all of the plans that existed before the device was added still exist). Therefore, adding a device can only create new plans, and the security risk can only increase. Only considering the length of the shortest plan is also problematic, since a network with one plan of length $x$ is much more secure than a network with multiple plans of length $x$.

For each comparison of the risk scores of various deployments, we compared the length of the shortest plans, and if the shortest plans in each deployment were equal, we considered the number of the shortest plans. Intuitively, the risk increases as the possible attack plans become shorter and as more of the shortest attack plans are added.

Definition 4.9 (Deployment Comparison).

Let $depl_{X}$ and $depl_{Y}$ be two deployments of IoT devices. We say that $depl_{X}$ is superior to $depl_{Y}$, denoted as $depl_{X}\prec depl_{Y}$, if and only if

[TABLE]

[TABLE]

[TABLE]

5. Deployment Optimization Problem

In this section, we introduce the terms and notation used to define the two IoT deployment optimization problems: (1) Full Deployment with Minimal Risk (FDMR), and (2) Maximal Utility without Risk Deterioration (MURD).

FDMR Problem. Given an attack graph of an organization $G$, a set of IoT devices $D$ of types $T$, and the location constraints $C$, find the deployment ($depl_{full}$) of IoT devices such that all of the IoT devices are deployed subject to location constraints, and the risk score $R(depl_{full})$ is minimized.

Definition 5.1 (Full Deployment with Minimal Risk (FDMR) Problem).

Given the four-tuple $<G,D,T,C>$, find $depl_{full}$ such that $R(depl_{full})$ is minimized

[TABLE]

MURD Problem. Given an attack graph of an organization $G$, a set of IoT devices $D$ of types $T$, and the location constraints $C$, find the deployment that consists of the highest number of IoT devices without increasing the risk score $R$.

Definition 5.2 (Maximal Utility without Risk Deterioration (MURD) Problem).

Given the four-tuple $<G,D,T,C>$, find $depl$ such that $|R(depl)|$ is maximized and $R(depl)$ = $R(depl_{empty})$

[TABLE]

5.1. Search Space

Next, we define the search space for both FDMR and MURD. In each case, the state of the search space is organized as a binary tree where at each state a decision is made either to deploy (left child) or not to deploy (right child) a particular IoT device in a particular location. The root state is an empty deployment where no decisions have been made yet. Every path from the root node of the search space corresponds to a set of decisions. This means that a path from the root to any state defines where some of the IoT devices are deployed and where some other IoT devices cannot be deployed. The set of left children along a path is a partial deployment of IoT devices. In this way, we consider all possible deployments, subject to location constraints.

For every node of the search space we derive the respective attack graph $G_{depl}$ and compute the risk score $R(depl)$. The goal nodes depend on the specific problem. In the FDMR problem the goal nodes include all states with a deployment that meets all of the constraints, $depl_{full}$ and the objective is to identify the goal state with the lowest risk score. In the MURD problem the goal states include all states with a deployment that has the same risk score as the initial state.

5.2. Search Algorithm

For our heuristic search, we used the DFBnB algorithm (as described in Section 2.4). The heuristic function will described later in this section. As we mentioned above, each state in our search tree has two children (left and right). In one, we added an IoT device to the deployment in a certain location, and in the other, we did not allow the IoT device to be deployed in that location. In practice, each state has various options regarding which IoT devices to deploy. We randomly chose one device ($d$) and one location ($l$) where $d$ can still be deployed and generate two children: deploy $d$ at $l$ and do not deploy $d$ at $l$. For the left child corresponding to the deploy decision, we generate a new attack graph and recalculate the risk score and the value of the heuristic function. We do not calculate the risk score for the right (do not deploy) child, as this child’s risk score did not change, since the risk score depends only on the deployed devices.

Heuristic Function. In order to calculate the heuristic functions, we created a table of risk scores $Table(depl_{n})$ which contains the risk scores for each IoT device in each possible location. In other words, we simulate the deployment of a single IoT device each time. For each deployment, we update the table, removing the IoT device that was deployed or not allowed to be deployed. If the length of the shortest plan is shorter than the length of the shortest plan of the initial state, the heuristic’s value in the table is zero.

Definition 5.3 (FDMR Heuristic Function).

For the FDMR problem, the heuristic function underestimates the lowest possible change in risk in every subtree. Then, whenever the risk score of the best full deployment found so far is lower than the risk score of any full deployment that can be found within a subtree, that subtree is pruned.

For FDMR, let $h_{FDMR}(depl_{n})$ be the heuristic of $depl_{n}$. $h_{FDMR}(depl_{n})$ is the minimal $R(depl_{d})$ and $R(depl_{d})\in Table(depl_{n})$.

[TABLE]

Intuitively, $h_{FDMR}$ underestimates the risk score because (1) individually each deployed device increases the risk according to $Table(depl_{n})$, but (2) together multiple deployed devices may result in attack plans that were not accounted for yet.

Definition 5.4 (MURD Heuristic Function).

For the MURD problem, the heuristic function overestimates the highest possible change in the number of IoT devices that can be deployed without increasing the risk. Then, whenever the number of devices deployed according to the incumbent solution found so far is larger than the number of devices that can possibly be deployed by continuing to search a subtree, that subtree is pruned.

We want to deploy the highest number of IoT devices possible, hence the heuristic function counts the number of IoT devices in $Table(depl_{n})$ with the same risk score as the root state. Let $h(depl_{n})$ be the heuristic of $depl_{n}$. $h_{MURD}(depl_{n})$ is the number of devices with a risk score equal to initial state $R(depl_{empty})$, such that

$|R(depl_{d})=R(depl_{empty})|$ and $R(depl_{d})\in Table(depl_{n})$.

[TABLE]

Intuitively, $h_{MURD}$ overestimates the number of devices that can be deployed because (1) any IoT device that increases the risk according to $Table(depl_{n})$ cannot be deployed, and (2) even if individually a set of deployed devices does not increase the risk score, together they may result in an attack plan that was not available before.

6. Evaluation

We conducted experiment for each one of the problems we wish to solve: finding the full deployment with minimal risk (FDMR), and finding the maximal utility without risk deterioration (MURD). For both problems, we used the suggested DFBnB algorithm with the heuristics described in Section 5.2.

6.1. Data Preparation

To evaluate our proposed method, we conducted a set of experiments using an attack graph that was derived from a real organization network.

Organization Network. The network of the organization is a real network consisting of $24$ hosts which was used by Gonda et al.  (Gonda et al., 2017). The network of the organization was scanned using Nessus Scanner, and then MulVAL was used to generate the attack graph based on the scanning results. Figure 3 depicts the connectivity of the hosts in the network, derived from the VLAN topology. Each node represents a host, and an edge indicates a connection between two hosts.

An organization can have more than one host that it wishes to protect, and this is translated to multiple targets for the attacker. To simplify things, all target hosts are connected to an abstract $goalHost$, and the goal of the attack graph is to execute code in this host. Executing code on the $goalHost$ proves that the attacker managed to control one of the targeted hosts that led to the goal. As part of the experimental setup we assume that the organization is free from inside adversaries and that the potential attacker is located on the $Internet$. The attack graph has a host that represents the Internet. Detailed information on the scanning process is provided in (Gonda et al., 2017).

Simulating IoT Devices. The network of the organization used in the experiment does not include any IoT devices. Therefore, we opt to simulate the IoT devices, their communication protocols, and the constraints required for their deployment. We simulated three IoT types (detector, refrigerator, camera), nine different IoT devices (four detectors, two cameras, and three refrigerators), and eight locations for the deployment of IoT devices.

In the simulation, the organization would like to deploy three detectors for which there are four possible locations, one camera for which there are two possible locations, and two refrigerators for which there are two possible locations. Therefore, a total of six IoT devices needed to be deployed.

Formally, as defined in Definition 4.2, the location constraints in our simulation are defined as follows:

$C(detector)$ = $(\{l_{det_{1}},l_{det_{2}},l_{det_{3}},l_{det_{4}}\}$,$3$,$\{d_{det1},d_{det2},d_{det3}$,$d_{det4}\})$

$C(camera)=(\{l_{cam_{1}},l_{cam_{2}}\},1,\{d_{cam1},d_{cam2}\})$

$C(refrigerator)=(\{l_{ref_{1}},l_{ref_{2}}\},2,\{d_{ref1},d_{ref2},d_{ref3}\})$

Using permutation111Permutation $P^{n}_{k}$ mean that for $n$ items, we want to find the number of ways $k$ items can be ordered. and combination,222Combination $C^{n}_{k}$ is a selection of $k$ items from a collection of size $n$, such that the order of selection does not matter. we can calculate the total number of options in the search space.

$C^{4}_{3}P^{4}_{3}\cdot C^{2}_{1}P^{2}_{1}\cdot C^{2}_{2}P^{3}_{2}=2304$

Meaning, there are $2304$ possible deployments.

Simulating Short-Range Communication. We simulated two short-range communication protocols (ZigBee and Bluetooth) and randomly divided them between all IoT devices and hosts so that 75% of the hosts have Bluetooth and 20% number of them have Zigbee, and 40% of the IoT devices have Bluetooth and 90% of them have Zigbee.

Simulating Vulnerabilities. In order to create potential attack plans that include IoT devices, we simulated existing vulnerabilities that can be exploited as follows. For each IoT device and for each host, in addition to its known vulnerabilities (from the scanning performed), we created a vulnerability based on the protocol used.

Simulating Physical Location of Hosts. The actual physical location of the real hosts was unavailable. The location of the hosts is important in order to simulate the proximity of the IoT devices to the host, and consequently create potential attack plans involving the IoT devices. Therefore, we randomly divided the hosts among the eight simulated location ranges. Note that a host can be in proximity to more than one IoT device.

6.2. Experimental Setup

The experiments were conducted on Hyper-V VM, with four virtual CPUs (two cores) and 8GB RAM. The setup of the experiments is as follow:

Number of Executions. In order to strengthen the validity of our results, we executed the experiment forty times, using a different host location each time. In other words, we simulated the physical location of hosts forty times. The results in the next section are the average results of all executions.

Evaluation Measures. We computed two measures: the first is the execution time, and the second is the risk score of a suggested IoT deployment (for the FDMR use case) or the number of deployable IoT devices (for the MURD use case). The evaluation measures were averaged over the all of the executions. The execution time is important, since this can be a weak point, as one of the difficulties in attack graphs and solutions that are based on attack graphs is execution time.

Random Deployment. For comparison, we also ran both problems randomly as a baseline. This scenario represents an organization that randomly deploys IoT devices, without considering the security aspect. That is to say, for the FDMR problem we randomly deployed all IoT devices five times and took the average risk score of all the deployments. In the MURD problem, each time we added a device randomly and computed the risk score. We started with no IoT devices deployed and continued until full deployment. We ran five times each number of devices. This random baseline was executed the same number of times as our algorithm (forty times).

6.3. Results

Table 1 presents the results. Note that the risk score only includes the number of the shortest paths ($OptCnt(G_{depl})$). The length of the shortest paths in all of the results presented is $29$.

Full Deployment with Minimal Risk (FDMR). Full Deployment with Minimal Risk(FDMR). In the FDMR problem, the average risk score of all runs is $1229$, an increase of 19% compared to the risk score without any IoT devices which is $1032$. The algorithm took an average of $36$ minutes to run, which is a reasonable amount of time and provides an indication of its feasibility on a larger scale.

Maximal Utility without Risk Deterioration (MURD). In the MURD problem, the average number of IoT devices that can be deployed without affecting the security risk is $4.40$. This number means that, on average, four to five devices can be deployed without any change in the risk score. It took the algorithm an average of $3.88$ minutes to compute, which is also a reasonable time.

Random Deployment. In FDMR, the average risk score was $1494$, which is an increase of 44% from the initial state. We can see that randomly deploying IoT devices leads to less safe network, compared to the increase of only 19% when using our algorithm.

In the MURD problem, the average risk score of deploying four IoT devices is $1538$. We chose four devices because with our algorithm we managed to deploy an average of $4.40$ devices without influencing the security of the network. This result is also much higher than the basic risk score of $1032$, with no IoT devices deployed. The average risk score of other numbers of devices can be seen in Figure  4 (in grey), where we present the average risk score of deployments with each number of devices, ranging from zero (empty deployment) to six (full deployment).

Running Time. The average time for the algorithm to solve the FDMR problem was $36$ minutes, and for the MURD problem less than four minutes. In addition, the average time it took to compute the risk score in all of the executions on both problems was less than a second ($0.95$ seconds), and the average time to calculate the heuristic was $2.85e^{-5}$ seconds. It took $23$ seconds, on average, to compute the heuristic table before the start of the algorithm. These measurements are very low and practical, suggesting that the algorithm can run on additional networks.

Additional Results. We investigated the trade-off between the allowed risk of the IoT deployment and the maximal number of IoT devices that can be deployed. Figure 4 further emphasizes the difference between random and optimal deployment of IoT devices. On one hand, 4-5 randomly deployed IoT devices increase the number of possible attack plans by  50%. On the other hand the same number of IoT devices can be deployed with insignificant risk deterioration. We can also see from Figure 4 that the difference between optimal and random deployment strategies diminishes as we try to deploy six IoT devices.

Figure 5 illustrates the challenge in finding the safest deployment of IoT devices. The graph presents the cumulative distribution of the risk scores of all deployments in one execution. The $x$-axis is the cumulative risk score, and the $y$-axis is the percentage of deployments for which the risk score is less than $x$. As can be seen, 50% of the deployments have a risk score lower than $1458$. Moreover, only $16$ deployments (0.7% of all deployments) are optimal, with a risk score of $1134$, i.e., the chances of a random selection to choose an optimal deployment in that execution was $0.007$.

The risk score of an optimal deployment may change when new vulnerabilities are discovered, leading to potentially inferior deployment. To conclude the experimental evaluation we tested the robustness of the optimal deployment of an arbitrary execution from the FDMR problem, with risk score of $1134$. We perturbed vulnerabilities of 10% and 20% of the devices in the network by discarding all current vulnerabilities of the chosen devices and randomly assigning new vulnerabilities as described in Section 6.1. This process was repeated 10 times. The average risk score of the optimal deployment after changing 10% and 20% of the vulnerabilities varied by 1%-10% in both directions. Some times the risk of the optimal deployment increased and some times it dropped. Overall the changes in the risk of the optimal deployment due to perturbation of the vulnerabilities were not statistically significant.

7. Conclusion and Future Work

We present a novel method for suggesting the optimal deployment (in terms of the security risk) of a set of IoT devices within an organization. In order to accomplish this, we augmented the conventional attack graph to include short-range communication protocols inherent to IoT devices. To the best of our knowledge, this is the first work that takes the physical location of devices and different communication protocols into account.

We demonstrated the importance of planning a deployment of IoT devices by solving two scenarios, approaching them as an optimization problem. We proposed a novel method for evaluating the risk of IoT device deployment using an augmented attack graph, and used the proposed method to address these two scenarios. Our results revealed the potential risk in deploying IoT devices in organizations and showed that randomly deploying devices can greatly affect the security of the organization’s network. We solved the two scenarios on a real organization with a small to medium sized network, with a running time of less than an hour.

Our algorithm, and in particular, our heuristic approach, assumes that the potential risk of two deployed devices is greater than or equal to the sum of their individual risk scores. Any method of risk calculation that satisfies this assumption can be used in the algorithm. The method of risk score calculation used in this paper has some limitations. It does not take the cost of different exploits into account, which can be a major consideration for an attacker. As a result, the method does not capture the heterogeneity and homogeneity of vulnerabilities along an attack path. In addition, the method only considers the shortest paths, but an attacker can choose a longer path, for various reasons.

Future work may extend the current research in the following directions. First, it is desirable to increase sizes of the attack graph that can be optimized by providing more accurate heuristic functions. In addition, the optimization methods proposed in this paper should be tested with variety of risk scores that encompass the true cost of the attack, the probability of the attack success, or both. Finally, cyber-physical capabilities of IoT devices as well as their unique functionalities should be incorporated into an extended model.