Assessing smart light enabled cyber-physical attack paths on urban infrastructures and services

Abstract

Internet-of-Things (IoT) extends the provision of remotely managed services across different domains. At the same time, IoT devices primarily designed for home environments may also be installed within the premises of critical urban environments, such as government, banking and corporate domains, without proper risk evaluation. In this paper, we examine the effect of cascading attacks triggered by the integration of vulnerable smart lighting systems in critical domains. In particular, we utilise known vulnerabilities of smart lighting systems to demonstrate the potential risk propagation on popular installation domains found in smart cities and urban infrastructures and services. Based on validated vulnerabilities on popular off-the-shelf smart lighting systems, we set up realistic proof-of-concept connectivity scenarios for various urban infrastructures and domains. Using these scenarios, we evaluate the risk of cascading attacks, by applying a targeted risk assessment methodology for identifying and assessing IoT-enabled attacks.

Keywords:

• Internet of things
• smart lights
• risk assessment
• smart cities
• IoT-enabled cyber-physical attack paths

1. Introduction

Machine-to-Machine interoperability enhanced with Artificial Intelligence (AI) synthesise physical and digital worlds by introducing cyber-physical objects, known also as “smart things”. Nowadays, most IoT devices are equipped with wireless network interfaces, sensors and ample processing power, which enable them to interact with one another and be remotely managed via cloud, Internet-facing Application Programming Interfaces (APIs). Cheap and easy to deploy IoT devices, such as smart lighting systems, are incorporated within hospitals, supply chain, factories, power generation and distribution as well as highly populated public areas (e.g. stadiums, street lighting). As a result (Stellios et al., 2018), attackers may utilise existing as well as zero-day vulnerabilities to trigger cyber or cyber-physical attacks that may be hard to identify based on traditional threat modelling and risk assessment methodologies.

Smart lighting systems mainly consist of Light Emitting Diode (LED) or Organic LED (OLED) luminaires equipped with sensing capabilities (e.g. ambient light, acoustic, ultrasonic, infrared, location), wireless network interfaces, (e.g. Ethernet, WiFi, Z-Wave, ZigBee Light Link - ZLL) and mobile applications which communicate with cloud services via specific protocols (e.g. If-This-Then-That – IFTTT) to assure interoperability and autonomous operation (Mi et al., 2017). Due to their low production cost, smart lights are considered one of the most widespread IoT technologies. They can be remotely managed via smartphone applications that utilise local and/or remote connectivity through cloud services. Popular manufacturers such as Apple, Amazon and Google utilise control-over-voice command interface (Apple's HomeKit – Siri, Amazon's Echo – Alexa and Google Home) to remotely control IoT devices, smart lighting systems included, with near-future capabilities to incorporate real-time luminosity and spectrum self-adjustment functionality.

The deployment of such systems leads to the reduction of energy consumption, visual comfort, safety, remote control and adaptability in various environments. Applications of smart lighting become more and more diversified to include, among others, commercial, outdoor/public and industrial lighting. According to a report by LEDinside (Huang, 2018), the global smart lighting market reached close to 4.6 billion United States (US) dollars in 2017 with an annual growth rate of 95% whereas industrial and commercial lighting accounted for 60% of the global smart lighting market. Although industry has imposed more strict requirements on smart lighting systems mainly due to safety concerns and business continuity requirements, many of these systems are being managed via external controllers and, in most cases, are directly and/or indirectly connected to the same networks with Supervisory Control and Data Acquisition (SCADA) systems. The latter increases the significance of these IoT devices since, the need for remote management, functionality features and existing vulnerabilities can act as an enabler for adversaries that target Industrial Control Systems (ICS).

IoT-enabled attack paths in urban infrastructures and services. As presented in Stellios et al. (2018), air-gaped, digital and cyber-physical systems can be attacked on cyber and physical level by exploiting a vulnerable IoT device or service that is either interconnected or simply installed in physical proximity with the target system. Depending on the installation site, attacks on smart lighting systems can attract diverse types of adversaries, ranging from security enthusiasts up to nation-state and organised cybercrime. Previously analysed Proof-of-Concept (PoC) scenarios (Ronen et al., 2016; Ronen & Shamir, 2016) proved that by abusing and/or extending the features of a smart lighting system, adversaries may launch a series of cyber or cyber-physical attacks against Information and Communication Technology (ICT) systems.

Risks of such attacks can be easily overlooked, since, they depend heavily on the organisation under study, the systems in proximity/connectivity and the type of the attack. For example, real attacks in recent past, that included a plethora of seemingly unimportant, interconnected IoT devices, caused unavailability on Internet services (Herzberg et al., 2016). Similarly, verified vulnerabilities found in smart lighting systems (e.g. CVE-2020-6007) may result on network infiltration attacks of high impact, depending on their installation domain. Smart lights can be used as an enabler for several attack scenarios including data exfiltration, ransomware campaigns, disruption of organisations business' processes, harm patients by inducing epileptic seizures (Ronen & Shamir, 2016) or trigger car accidents by manipulating public traffic lighting systems (Cerrudo, 2015; Ronen et al., 2016).

Motivation. In our previous work (Stellios, Mokos, et al., 2021), we performed a hands-on security analysis for popular, off-the-shelf smart lighting devices. Our goal there was to verify the current state of security in typical smart lighting systems. However, besides the direct attacks against the smart lighting systems themselves, their increased connectivity and their physical proximity with a plethora of critical systems in an urban environment, creates various cyber-physical attack paths. Our motivation in this paper is to identify and assess potential risks that stem from vulnerable smart lighting systems installed in various critical urban domains.

Contribution. In this paper, we assess the cascading risk of attack paths enabled by vulnerable smart lighting systems installed in urban environments. In particular:

• We utilise the vulnerabilities of smart lighting systems identified in Stellios, Mokos, et al. (2021) to apply attack path analysis, based on the IoT-enabled risk assessment methodology of Stellios, Kotzanikolaou, et al. (2021). Since our analysis is based on verified vulnerabilities of existing smart lighting systems, we identify realistic attack path scenarios and we assess the risk propagation on popular installation domains such as public lighting infrastructures, corporate and home environments.

• In addition, we identify and analyse potential threat agents for different urban domains, based on their underlying capabilities and motives, to assess the likelihood of occurrence for various attack scenarios.

• Finally, we propose potential mitigation strategies that may be applied to reduce these cascading risks.

Paper structure. In Section 2, we present relative research regarding attack vectors of smart lighting systems and IoT-enabled cyberattacks on smart cities. Then, in Section 3 we apply our IoT-enabled risk assessment methodology in realistic scenarios that involve smart lighting systems installed in popular domains of a smart city environment and we examine the underlying security risk. In Section 4, we analyse our findings and propose possible mitigation strategies whereas in Section 5 we discuss the efficacy of our approach and the limitations of our work. Finally, Section 6 concludes the paper.

2. Related work

Smart lighting systems can be used to assist various every day urban activities such as traffic congestion avoidance, inform us for available parking spaces, warn us about road accidents, monitoring of street lamp power cables and even help us protect ourselves in pandemic outbreaks. For example, Akhavan et al. (2021) demonstrated how IoT-enabling technologies can be used in pandemic outbursts to trace potential contacts among COVID-19 patients via passive wireless interactions (e.g. via Bluetooth) among mobile devices. But all these amenities come with a cost: privacy and security concerns have been raised mainly due to the ever-growing collection of personal identifiable information as well as high-severity vulnerabilities discovered in IoT-enabled systems. Recent research literature has focused on mitigating these risks: Wu et al. (2022) propose a pseudonymisation system suitable for traffic density monitoring systems; Zheng et al. (2022) overview potential applications and future challenges of Federated learning (FL); a mechanism that combines certificateless message authentication and blockchain incentives is proposed by Zhang and Xu (2022) to address security and privacy issues in Vehicle ad-hoc Networks (VANETs). Attacks on smart lighting systems have also been studied recently, since, they are considered one of the most pervasive IoT-enabled technologies in urban environments.

2.1. Attacks on light emitting devices

Security and privacy concerns against light emitting devices have been raised in the recent past. Xu et al. (2014) showcased how the emanations of changes in light can be used to reveal actual television programs. The researchers were able to identify the content being broadcasted among a reference library of tens of thousands of videos within a few seconds. In Maiti and Jadliwala (2019, 2020) a series of privacy attacks were examined via audio-visualising and video-visualising systems, including the exfiltration of potentially sensitive information by exploiting infrared light sensors/actuators. Schwittmann et al. (2016) and Schwittmann et al. (2017) demonstrated that by exploiting the ambient light sensor of a user's smartphone/smartwatch, it is possible to determine what the user is currently watching on TV. Ferrigno and Hlaváč (2008) were able to retrieve the AES keys by capturing the light (photons) emitted from a micro-controller, using picosecond imaging circuit analysis.

Covert channels can occur when sources of electromagnetic, acoustic, thermal and/or optical wavelength are used as transmitters to create communication channels (Zhou et al., 2018). Ronen and Shamir (2016) proved that the exfiltration of potentially sensitive data from air-gaped systems is possible by creating a covert channel through the fast flickering of the light bulb whereas Zhou et al. (2018) managed to create a covert channel of an air-gaped system by exploiting the infrared interface. In Guri and Bykhovsky (2019), researchers achieved similar results by exploiting security cameras with infrared modules whereas Guri et al. (2016) managed to exfiltrate data via invisible to human eye, low contrast and/or fast flickering images. Similarly in Costin (2016), researchers managed to abuse the functionality of normal/Infrared LEDs to create hard-to-identify, optical covert channels and/or even disturb the normal operation of nearby visual equipment via Denial-of-Service (DoS) and jamming attacks. Ronen et al. (2016) proved that is possible to take over a large number of smart lighting systems via a self-propagation infection process by infecting just one smart lamp from a distance whereas in Sikder et al. (2019) researchers investigated the possibility of triggering events in a smart home environment by manipulating smart lighting system's presence sensors.

2.2. Vulnerability analysis of smart lighting systems

Several vulnerabilities of smart lighting systems have been discovered in Morgner et al. (2016) and Dhanjani (2013). Popular IoT devices, including a WeMo switch, were examined in Apthorpe et al. (2017) for leaking sensitive data to outsiders, Internet Service Providers (ISP) included. Via Domain Name Service (DNS) queries and relative network data streams they managed to identify the actual type and state of an IoT device. Do et al. (2018) analysed threats and security vulnerabilities of LIFX 1000¹ series and a Belkin WeMo switch² for three specific types of adversaries. The researchers examined specific capabilities such as passive and active eavesdropping (intercept and selective forwarding) as well as replay control messages (transmit and modify). Notra et al. (2014) revealed that WeMo motion sensor and switch kit do not implement network encryption and authentication, whereas easy-to-discover communication ports are enabled by default, thus making them prone to Man-in-The-Middle (MiTM) and replay attacks. Liu et al. (2019) simulated phishing attacks based on cross-site scripting by exploiting vulnerabilities found in the WeMo smartphone application and communication protocols. Furthermore, by introducing a fake emulated device, they managed to recover the WiFi password and expose personal identifiable information. In our previous work (Stellios, Mokos, et al., 2021), we assessed the security of a popular smart lighting system and we have managed to verify various vulnerabilities at embedded software, network communications, mobile application and cloud API services.

2.3. IoT-enabled cyberattacks on smart city infrastructures

Ghena et al. (2014) launch a series of attacks including Denial-of-Service (DoS), gain remote access and cause traffic congestion, by exploiting newly discovered vulnerabilities found in traffic lighting systems' controllers. Cerrudo (2015) describes security vulnerabilities and potential cyberattack scenarios on smart city infrastructure, including cyber terrorism, nation state warfare, cybercrime ransomware campaigns and hacktivist movements. Zhang et al. (2017) showcase security and privacy issues in a city's IoT-enabled systems, including privacy leakage in data sensing, privacy and availability in data storage and processing (e.g. cloud infrastructure) as well as control services dependencies and trustworthiness. Attack vectors in smart city environments are presented in AlDairi (2017). At first, the main areas of a smart city environment are defined as follows: governance, economy, people, mobility, living and environment. Then, several IoT-enabled attack vectors are examined including public and private internet connected cameras, building management systems, transport management systems such as traffic lights and road electronic signs as well as communication networks (e.g. public WiFi spots) for their potential impact. Additionally, attack scenarios such as privacy attacks, traffic jams, multiple injuries and/or fatalities are examined. Andrade et al. (2020) pinpointed as the most common types of vulnerabilities found in IoT devices installed in a smart city environment, the use of weak hardcoded credentials, the lack of secure update mechanisms, obsolete software versions, the lack of tamper-resistant hardware, the adoption of insecure communication APIs, as well as weak authentication and session management mechanisms.

3. Assessing the risk of IoT-enabled attack paths involving smart lighting systems in smart cities

To analyse the potential risks that derive from the integration of vulnerable smart lighting systems in urban environments, we examine various application scenarios in several domains (see Figure 1). Since we want to showcase risks that originate from smart lights, we only consider the attack path scenarios that are either targeting directly or use smart lighting systems to attack other critical systems. To be as realistic as possible, we considered smart light's vulnerabilities that have been confirmed in practice, such as those described in Stellios, Mokos, et al. (2021). However, we note vulnerabilities that have not been practically validated so far are also potential sources of risk.

Figure 1. A paradigm of potential targets regarding smart lighting systems in a smart city environment.

3.1. Common vulnerabilities and exposures and common vulnerability scoring system

The Common Vulnerability Scoring System (CVSS) is used to assess the severity of Common Vulnerabilities and Exposures³ (CVE) software vulnerabilities. As our underlying methodology is based on CVSS metrics, we briefly explain the notation used in these documents. For further details, we refer to FIRST.Org (2019). Software vulnerabilities in CVE/CVSS are defined based on exploitability and impact factors. The former include: the Attack Vector (AV) (i.e. where should an attacker be placed to be able to exploit the vulnerability) with possible values (N)etwork, (A)djacent network, (L)ocal and (P)hysical; the Attack Complexity (AC) with values (L)ow or (H)igh; the Privileges Required (PR) with values (N)one, (L)ow or (H)igh; the User Interaction (UI) with values (N)one or (R)equired; and the Scope (S) with values (U)nchanged or (C)hanged. Impact metrics consist of Confidentiality (C), the Integrity (I) and the Availability (A) impact, in the scale of (N)one, (L)ow or (H)igh.

3.2. Methodology walkthrough

To examine the cascading risks enabled by vulnerable smart lighting systems, we are going to apply the IoT-enabled risk assessment methodology proposed in Stellios, Kotzanikolaou, et al. (2021) on various urban sectors described in Figure 1. In this section, we briefly describe the underlying methodology while for a detailed description we refer to the original work. The main goal is to assess the risk of attack paths that are IoT-enabled, i.e. the attack paths are enabled (or amplified) due to the existence of cyber and physical interactions between IoT systems and other systems. The assessment of the cascading IoT-enabled risks is divided into four main phases: the interaction modelling, the interaction assessment, the construction of the attack paths and the attack path assessment phase.

According to Stellios, Kotzanikolaou, et al. (2021), an interaction between two systems (nodes) is a directional relation where a node x, called the source node, has some “influence” on another node y, called the destination node, due to their physical proximity and/or cyber connectivity. Various cyber and physical interaction types are defined. Cyber interactions are defined based on the network distance and the control that the source node has on the destination node. Physical interactions rely on the physical proximity of the source to the destination node and available interfaces, ranging from physical access, input/output and network interfaces. The detailed interaction types are briefly described in Appendix, Tables A4 and A5.

The CVSS exploitability and impact metrics are used to determine the initial (${IntCVSS}_{base}$) capabilities of x on y (see Appendix, Table A1). The latter is then modified (${IntCVSS}_{env}$) according to existing network and/or physical security controls (see Appendix, Table A2). After the available environmental information is applied to both ${IntCVSS}_{base}$ and existing vulnerability vectors of the target node (y), the cumulative vulnerability vector (${CVV}_{int}$), that represents the overall vulnerability level of each interaction, can be calculated.

To reduce false-positive attack scenarios, the exploitability factor AV and impact metrics are utilised to determine the validity of each interaction since, we are interested in determining whether an adversary has the required network, logical and/or physical access to reach the target device and that she is capable of inflicting the minimum required amount of damage to remotely control it. Additionally, CVSS exploitability metrics such as AV, AC, PR and UI are utilised to determine: (i) the required network, logical and physical access, skills and user interaction for an attack to be successful and (ii) the characteristics of each adversary type such as the available access (AV:N/A/L/P, skill-set (AC:L/H), privileges (PR:N/L/H) and user interaction capabilities (UI: N/R). For example, an disgruntled worker as presented in Table 10 is considered someone of low skill-set (AC:L), basic access rights (PR:N/L) and capable of interacting physically or logically with other corporate users (UI:R). On the other hand, adversaries of a cyber criminal group can usually access only Internet-exposed infrastructures and services (AV:N), are considered of high skill set (AC:L/H), can utilise their expertise to acquire elevated access rights on target systems (PR:N/L/H) and/or can launch spear phishing campaigns to achieve their goals if necessary (UI: N/R).

Table 1. Device list with corresponding physical and network characteristics.

		Physical
ID	Device	Location	Type	Network/Interface	R/F(*)	Internet access
1	Smart lights	Bank	Internal	Net 1/WiFi/Zigbee	2.4 GHz	✓
2	E-banking servers	Bank	Protected	Net 2/Ethernet	N/A	x
3	Smart lights	Pharmaceutical	Internal	Net 4/WiFi/Zigbee	2.4 GHz	x
4	Corporate server	Pharmaceutical	Protected	Net 5/Ethernet	N/A	x
5	Smart lights	Government	Internal	Net 6/WiFi/Zigbee	2.4 GHz	✓
6	Cloud ICT	Government	Protected	Net 7/Ethernet	N/A	x
7	Smart lights	Home	Internal	Net 8/WiFi/Zigbee	2.4 GHz	✓
8	Workstation	Home	Internal	Net 8/WiFi	2.4 GHz	✓
9	Smart lights	Public Stadium	External	Net 9/WiFi/Zigbee	2.4 GHz	✓
10	Alarm System	Public Stadium	External	Net 9/WiFi	2.4 GHz	✓
11	Smart lights	Public Lighting	External	Net 10/WiFi/Zigbee	2.4 GHz	✓
12	Workstation	Bank	Internal	Net 3/Ethernet	N/A	x

(*) Radio frequency.

Table 2. Access rules and internet connectivity for networks in scope.

NetID	1	2	3	4	5	6	7	8	9	10	Int
1	N/A	x	✓	x	x	x	x	x	x	x	✓
2	x	N/A	x	x	x	x	x	x	x	x
3	x	✓	N/A	x	x	x	x	x	x	x
4	x	x	x	N/A	✓	x	x	x	x	x
5	x	x	x	x	N/A	x	x	x	x	x
6	x	x	x	x	x	N/A	✓	x	x	x	✓
7	x	x	x	x	x	x	N/A	x	x	x
8	x	x	x	x	x	x	x	N/A	x	x	✓
9	x	x	x	x	x	x	x	x	N/A	x	✓
10	x	x	x	x	x	x	x	x	x	N/A	✓

NetID: Network ID, N/A: Not applicable, Int: Internet access.

Table 3. PoC paradigm's interaction tuples.

Source*	Target*	IntType**	Source Int	Target Int	Int list level
1	Human	P2 (Disable)	Luminaire	Eye	1
1	Human	P2 (Flicker)	Luminaire	Eye/Receiver	1
1	12	C4	WiFi	Ethernet	1
12	2	C6	Ethernet	Ethernet	1
3	Human	P2 (Disable)	Luminaire	Eye	1
3	Human	P2 (Flicker)	Luminaire	Eye/Receiver	1
3	4	C4	WiFi	Ethernet	1
5	Human	P2 (Disable)	Luminaire	Eye	1
5	Human	P2 (Flicker)	Luminaire	Eye/Receiver	1
5	6	C4	WiFi	Ethernet	1
7	Human	P2 (Disable)	Luminaire	Eye	1
7	Human	P2 (Flicker)	Luminaire	Eye	1
8	6	C6	WiFi	Ethernet	1
9	Human	P2 (Disable)	Luminaire	Eye	1
9	Human	P2 (Flicker)	Luminaire	Eye	1
9	10	P3(Jamming)	WiFi	WiFi	1
9	10	P3(Jamming)	ZigBee	WiFi	1
9	10	C1	WiFi	WiFi	1
11	Human	P2 (Disable)	Luminaire	Eye	1
11	Human	P2 (Flicker)	Luminaire	Eye	1
1	12	C4	WiFi	Ethernet	2
7	8	C1	WiFi	WiFi	2

(*):Device ID $\to$ Table 1, (**):Interaction types $\to$ Tables A4 and A5, Int: Interaction.

Table 4. Existing CVSS vectors (vulnerabilities) for each device in scope.

	CVSS vulnerability vectors (Base)
	Exploitability					Impact
Device ID	AV	AC	PR	UI	S	C	I	A
1,3,5,7,9,11	Network	Low	None	None	Unchanged	High	High	High
2	Local	Low	None	None	Unchanged	High	High	High
4	Network	Low	None	None	Unchanged	High	Low	None
6	Adjacent	Low	None	None	Unchanged	High	High	None
8	Adjacent	Low	None	None	Unchanged	High	High	High
10	Adjacent	Low	None	None	Unchanged	Low	Low	Low
12	Network	Low	None	None	Unchanged	Low	Low	Low

AV,AC,PR,UI,S,C,I,A: See Section 3.1

Table 5. Environmental information regarding PoC network/physical layer security controls.

	Network cyber-physical security control level
Layer	1	2	3	4	5	6	7	8	9	10
Cyber	Low	High	Mod	Mod	Mod	Low	Mod	Low	Low	Low
Physical	Low	Low	Low	Low	Low	Low	Low	Low	Low	Low

Mod: Moderate.

Table 6. The computed ${CVV}_{int}$ for each assessed interaction tuple (environmental).

	${CVV}_{int}\left(Environmental\right)$
	Exploitability					Impact
Int. Tuple	AV	AC	PR	UI	S	C	I	A
$12\to 2$	Network	High	None	None	Unchanged	Low	Low	Low
$3\to 4$	Network	High	None	None	Unchanged	High	Low	None
$5\to 6$	Adjacent	High	None	None	Unchanged	High	High	None
$8\to 6$	Network	High	None	None	Unchanged	High	High	High
$7\to 8$	Adjacent	Low	None	None	Unchanged	Low	Low	Low
$9\to 10$	Adjacent	Low	None	None	Unchanged	Low	Low	Low
$9\to 10$*	Adjacent	Low	None	None	Changed	None	Low	Low
$9\to 10$**	Adjacent	Low	None	None	Changed	None	High	High
$1\to 12$	Network	Low	None	None	Unchanged	Low	Low	Low

(*): P3 (Jamming) Zigbee $\to$ WiFi, (**): P3 (Jamming) WiFi $\to$ WiFi.AV,AC,PR,UI,S,C,I,A: See Section 3.1.

Table 7. Level-1 attack paths.

Level-1 attack paths
Level-1 Int. tuple	Source $\to$ Target interface	Interaction type
1 $\to$ human	Luminaire $\to$ Eye	P2 (Disable)
1 $\to$ human	Luminaire $\to$ Eye/Receiver	P2 (Flicker)
3 $\to$ human	Luminaire $\to$ Eye	P2 (Disable)
3 $\to$ human	Luminaire $\to$ Eye/Receiver	P2 (Flicker)
3 $\to$ 4	WiFi $\to$ Ethernet	C4
5 $\to$ human	Luminaire $\to$ Eye	P2 (Disable)
5 $\to$ human	Luminaire $\to$ Eye/Receiver	P2 (Flicker)
5 $\to$ 6	WiFi $\to$ Ethernet	C4
7 $\to$ human	Luminaire $\to$ Eye	P2 (Disable)
7 $\to$ human	Luminaire $\to$ Eye	P2 (Flicker)
9 $\to$ human	Luminaire $\to$ Eye	P2 (Disable)
9 $\to$ human	Luminaire $\to$ Eye	P2 (Flicker)
9 $\to$ 10	WiFi $\to$ WiFi	P3 (Jamming)
9 $\to$ 10	ZigBee $\to$ WiFi	P3 (Jamming)
9 $\to$ 10	WiFi $\to$ WiFi	C1
11 $\to$ human	Luminaire $\to$ Eye	P2 (Disable)
11 $\to$ human	Luminaire $\to$ Eye	P2 (Flicker)

Table 8. Level-2 attack paths.

Level-2 attack paths
Level-2 $\to$ Level-1 interaction tuples	Source $\to$ Target interface	Interaction types
1 $\to$ 12 $\to$ 2	WiFi $\to$ Ethernet $\to$ Ethernet	C4 $\to$ C5
7 $\to$ 8 $\to$ 6	WiFi $\to$ WiFi $\to$ Ethernet	C1 $\to$ C6

Table 9. Businesswise impact for smart lighting systems for each installation domain.

Device type	ID	Impact	Interaction type
Smart lights	DevID 1	BI	D/I(M)	D/I(M), DE	D(M)	DE,R
		LvL	Mod	H	L	H
	DevID 3	Impact	D/I(M)	D/I(M), DE	D(M)	DE,R
		LvL	Mod	H	L	H
	DevID 5	BI	D/I(M)	D/I(M), DE	D(M)	DE,R
		LvL	Mod	H	L	VH
	DevID 7	BI	D/I	D/I	D	DE,R
		LvL	VL	VL	VL	VH
	DevID 9	BI	D/I/F(M)	D/I/F(M)	D(M)	DE,R
		LvL	VH	H	Mod	–
	DevID 11	BI	D/I/F(M)	D/I/F(M)	D(M)	DE,R
		LvL	H	H	L	–

(M): Multiple, D: Discomfort, I: Injury, F: Fatality, DE: Data Exfiltration, R: Ransomware.

-: Not Applicable BI: Businesswise Impact, LvL: Impact Level.

VH: Very High, H: High, Mod: Moderate, L: low, VL: Very Low.

Table 10. Applicable adversary profiles and their corresponding characteristics.

Adversaries	Capabilities	Physical access	Motives	Resources
Activist	AV:N,A,P/AC:L/PR:N/UI:N	External	1,2	Limited
Disgruntled Worker	AV:N,A,L,P/AC:L/PR:N,L/UI:N,R	Internal	1,2	Limited
Business Competitor	AV:N/AC:L/PR:N,L/UI:N	External	1,3	Significant
Cyber Criminal Group	AV:N/AC:L,H/PR:N,L,H/UI:N,R	External	3,4,5	High
Cyber Terrorist	AV:N,A,L,P/AC:L,H/PR:N,L,H/UI:N,R	External/Internal	1,2,4,5	High
Nation State	AV:N,A,L,P/AC:L,H/PR:N,L,H/UI:N,R	External/Internal/Protected	1,2,4,5	Very High

Motivation: 1, Harm Reputation; 2, Damage/Disable equipment; 3, Financial Gain; 4, Harm Humans; 5, Extract Information.

During the first phase of the methodology (which we apply in our test scenario in Section 3.3), the cyber and physical interactions between all the IoT and ICT systems under assessment are defined, based on a predefined set of cyber and physical interaction types. Then, throughout the second stage (applied in our scenario in Section 3.4), all the interactions defined in the previous phase are assessed to examine the combined vulnerability level for each interaction. As defined previously, the overall vulnerability level of an interaction is represented by the Cumulative Vulnerability Vector (${CVV}_{int}$).

The attack path formation process takes place in the third phase (Section 3.5). Each of the assessed (valid) interactions is utilised to produce complex attack vectors. The latter are constructed by combining the direct, Level-1 interactions (Table 7) with other Level-n, n $\ge$ 2, interaction lists to create multi-hop attack paths. Then the businesswise impact is calculated by taking into consideration (Table 9).

Finally, during the fourth phase (presented in Section 3.6), for each attack path, the vulnerabilities of the point-of-entry device are examined and the corresponding attack scenarios are created. In particular, the vulnerabilities of the initial node are combined with the vulnerability level of all the interactions that exist in the attack path, to define the Cumulative Vulnerability Vector for all Attack Path (AP) scenarios $CVV(\mathcal{A}\mathcal{P},AV)$, AV ∈ [N,A,L,P]. This, in turn, means that the number of attack scenarios of an attack path depends heavily on the type and multitude of existing vulnerabilities of the initial node.

To define the threat level for each attack path, various threat agents are modelled and the corresponding characteristics of each applicable threat agent are matched with the exploitability characteristics of $CVV(\mathcal{A}\mathcal{P},AV)$, $\mathrm{\forall }AV\in \left[N|A|L|P\right]$. Then, the risk is defined by using the risk calculation matrix (see Table 12).

Table 11. Businesswise threat level (likelihood of occurrence) and applicable attack vectors for each installation domain per adversary type.

	Attack vector (AV)/likelihood (L)
	Bank		Pharmaceutical		Government		Home		Stadium		Public lighting
Adversary type	AV	LvL	AV	LvL	AV	LvL	AV	LvL	AV	LvL	AV	LvL
Activist	N	Low	N	Mod	N	Mod	–	–	N,A	VL	N,A,P	VL
Disgruntled Worker	N,A,L,P	Low	N,A,L,P	Low	N,A,L,P	Low	–	–	N,A,L,P	VL	–	–
Business Competitor	N,A	Mod	N,A	Mod	–	–	–	–	–	–	–	–
Cyber Criminal Group	N,A	VH	N,A	High	N,A	High	N	Mod	N,A	Low	N,A,P	VL
Cyber Terrorist	N,A	Low	N,A	Low	N,A	Mod	N,A	VL	N,A,P	Mod	N,A,P	Mod
Nation State	N,A,L,P	Mod	N,A,L,P	High	N,A,L,P	High	N,A,L,P	VL	N,A,L,P	Low	N,A,L,P	Low

AV: Attack Vector (P/L/A/N), LvL: Threat level (likelihood of occurrence), –: Not Applicable, Mod: Moderate, VL: Very Low, VH: Very High

Table 12. Risk calculation matrix for assessing $Risk(Threat,\mathcal{A}\mathcal{P})$ by combining $Vuln(Threat,AP)$, $Likelihood(Threat,\mathcal{A}\mathcal{P})$ and $Impact(Threat,\mathcal{T})$, as defined in Equation (4(4) $Risk(Threat,\mathcal{A}\mathcal{P})=Likelihood(Threat,\mathcal{A}\mathcal{P})\otimes Vuln(Threat,\mathcal{A}\mathcal{P})\otimes Impact(Threat,\mathcal{T})$(4) )

Risk Level
	Impact Level
	Very Low					Low					Moderate					High					Very High
	Threat Level
Vulnerability Level	VL	L	Mod	H	VH	VL	L	Mod	H	VH	VL	L	Mod	H	VH	VL	L	Mod	H	VH	VL	L	Mod	H	VH
Low	VL	VL	L	L	Mod	VL	L	L	Mod	Mod	L	L	Mod	Mod	Mod	L	Mod	Mod	Mod	Mod	Mod	Mod	Mod	Mod	H
Medium	VL	L	L	Mod	Mod	L	L	Mod	Mod	Mod	L	Mod	Mod	Mod	Mod	Mod	Mod	Mod	Mod	H	Mod	Mod	Mod	H	H
High	L	L	Mod	Mod	Mod	L	Mod	Mod	Mod	Mod	Mod	Mod	Mod	Mod	H	Mod	Mod	Mod	H	H	Mod	Mod	H	H	VH
Critical	L	Mod	Mod	Mod	Mod	Mod	Mod	Mod	Mod	H	Mod	Mod	Mod	H	H	Mod	Mod	H	H	VH	Mod	H	H	VH	VH

Risk Level $\to$ VL: Very Low, L: Low, Mod: Moderate, H: High, VH: Very High

3.3. Phase 1: interaction modelling

Modelling all potential cyber and physical interactions between the target(s) and all the devices in scope requires specific information regarding the examined devices. In particular, datasets with the devices' inputs, outputs, network interfaces and the corresponding networks, moving parts and/or capabilities (if any) along with their corresponding active ranges and physical location. Furthermore, the available network structure with its cyber-physical characteristics, including logical and physical access rules, must first be defined.

To be as realistic as possible and at the same time, to depict the current threat landscape, we consider simplified versions of realistic scenarios. In particular, we consider several installation domains ranging from home environments, public areas and buildings up to corporate and government institutions. An overview of the PoC installation domains, devices, networks and physical location are depicted in Figure 2. In particular, we have included the following scenarios:

1. A systemic monetary institution (e.g. banks): The smart lighting system is installed within the bank's premises and can communicate with the Internet (e.g. via UPnP network service) with the administrators network, but has no direct access to the bank's server.

2. A pharmaceutical company: The smart lighting system is installed within the company's premises, is isolated from the Internet but can communicate with the server sub-network.

3. A government cloud infrastructure: The smart lighting system is installed within the building, can communicate with the Internet as well as with the G-cloud's management network.

4. A smart home environment (remote working scenario): The smart lighting system can communicate with the Internet and is installed in the same network with a mobile workstation that has admin access to G-Cloud infrastructure.

5. A sports stadium facility: The smart lighting system can communicate with the Internet and is installed in the same network with an vulnerable IoT-enabled alerting system.

6. It is part of the public lighting infrastructure: The smart lighting system is massively installed to several public areas (streets, parks, etc.) and is managed remotely via the Internet.

Figure 2. PoC scenario regarding devices, networks and physical location.

We also consider that all smart lighting systems have Internet access via UPnP protocol (enabled by default), with the exception of the pharmaceutical company environment. All devices' characteristics and network access are presented in Tables 1 and 2 respectively. To showcase risks that stem out from smart lighting systems, we only examine interactions of the latter with predefined targets and not with the other IoT and ICT devices themselves (as in a full risk assessment scenario), with the exception where logical access between such devices exists (this involves the interaction types C2, C3, C5 and C6).

In addition, we consider that the home user corresponds to an public servant, who remotely administers via a Virtual Private Network (VPN) service, a government cloud infrastructure (interaction type C6). Similarly, a bank executive officer has remote access to financial systems of a monetary institution (defined as device with ID 12 in our scenario).

Based on the above scenarios and the cyber/physical interaction types defined in Stellios, Kotzanikolaou, et al. (2021) (see Appendix, Tables A4 and A5), we can now construct all potential interaction tuples (source, target, interfaces, interaction type) among the smart lights and target systems. The whole process utilises a recursive algorithm that first constructs all the “direct” cyber-physical interactions with the predefined targets and then all the intermediate cyber interactions between the devices in scope themselves. The output of this phase is a structured list containing Level-1,Level-2,…,Level-n interaction tuples. In our case, all the applicable interactions are defined in Table 3.

3.4. Phase 2: interaction assessment

An ${IntCVSS}_{base}$ vector represents the initial (base) capabilities of an adversary for each interaction. In particular, by assuming that a device x interacts with a device y based on a cyber (C1-C6), or physical (P1-P3) interaction type, the corresponding ${IntCVSS}_{base}$ capability vector defines the implied capabilities that device x (or an adversary controlling x) has on device y, due to their interaction type. A brief summary is presented in Appendix, Table A1, while we refer to Stellios, Kotzanikolaou, et al. (2021) for detailed information. During our previous work (Stellios, Mokos, et al., 2021), ${IntCVSS}_{base}$ vectors were constructed based on the discovered vulnerabilities/security misconfigurations of the smart lighting system under evaluation, in a CVSS-like structure (see Appendix, Table A3). These vectors are properly adjusted to depict the minimum required capabilities of an adversary in order for the attack to be successful. The individual impact metrics (Confidentiality$|$Integrity$|$Availability) have been properly modified to depict the severity of the vulnerability and/or security misconfiguration on the device. This in turn, can be used to determine whether an attack may result in a full or partial compromisation of the device which can then be used to attack the target system, or as a pivot point to propagate to the actual target.

To assess the vulnerability level of each interaction, the existing vulnerabilities of the target system are first utilised to form single ($SingleCVSS$, AV:N/A) or combined (chained) vulnerability vectors ($ChainedCVSS$) – Equation (1(1) $ChainedCVSS=[AV:[N|A],max(AC),min(PR),max(UI),max(S),max(C,I,A\left)\right]$(1) ). (1) $ChainedCVSS=[AV:[N|A],max(AC),min(PR),max(UI),max(S),max(C,I,A\left)\right]$(1) The available environmental information regarding existing security controls on network and physical layer, for each installation domain, is then applied to all available CVSS vectors as defined in Appendix, Table A2. After the environmental transformation process is complete, the transformed single and chained CVSS vectors are utilised to form the Cumulative Vulnerability Vector (${CVV}_{Int}$), which represents the overall vulnerability level of each interaction.

By examining the CVSS-like vectors (see Appendix, Table A3) of the specific smart lighting system, one can infer that various attack vectors are characterised with Low Attack Complexity. That in turn enables a diverse group of adversaries, ranging from activists and disgruntled workers up to cybercriminal groups and nation state adversaries, to use this IoT device for attacking critical systems, services, or even people. In addition, for the majority of the CVSS vectors, the privilege requirements metric is set to None (an unauthenticated adversary can trigger the vulnerability), and the attack vector metric is mostly set as N since, in most cases the attack can be launched from public networks, Internet included. For example, a firmware downgrade attack can potentially be launched from the Internet, since the cloud server that hosts the firmware files utilises the http protocol and the device does not implement any check on firmware versioning. Moreover, network infiltration can take place when the adversary is in proximity with the network interface of the target system (Kayas et al., 2020) or even from the Internet. The latter is possible due to the fact that UPnP protocol, which connects the smart lighting systems to the cloud API servers, is enabled by default⁴${}^{,}$⁵.

By taking into consideration all the above information, we can define a vulnerability CVSS vector for the smart lighting system used in our PoC scenario (device IDs 1,3,5,7,9,11). This CVSS vector, which represents a worst-case scenario where an attacker manages to combine several of the aforementioned vulnerabilities, is defined in (2(2) $\left[\mathrm{A}\mathrm{V}:\mathrm{N}\mathrm{e}\mathrm{t}\mathrm{w}\mathrm{o}\mathrm{r}\mathrm{k},\mathrm{A}\mathrm{C}:\mathrm{L}\mathrm{o}\mathrm{w},\mathrm{P}\mathrm{R}:\mathrm{N}\mathrm{o}\mathrm{n}\mathrm{e},\mathrm{U}\mathrm{I}:\mathrm{N}\mathrm{o}\mathrm{n}\mathrm{e},\mathrm{S}:\mathrm{U}\mathrm{n}\mathrm{c}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d}/\mathrm{C}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d},\mathrm{C}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h},\mathrm{I}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h},\mathrm{A}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}\right]$(2) ). (2) $\left[\mathrm{A}\mathrm{V}:\mathrm{N}\mathrm{e}\mathrm{t}\mathrm{w}\mathrm{o}\mathrm{r}\mathrm{k},\mathrm{A}\mathrm{C}:\mathrm{L}\mathrm{o}\mathrm{w},\mathrm{P}\mathrm{R}:\mathrm{N}\mathrm{o}\mathrm{n}\mathrm{e},\mathrm{U}\mathrm{I}:\mathrm{N}\mathrm{o}\mathrm{n}\mathrm{e},\mathrm{S}:\mathrm{U}\mathrm{n}\mathrm{c}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d}/\mathrm{C}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d},\mathrm{C}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h},\mathrm{I}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h},\mathrm{A}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}\right]$(2) The factor S:Changed (C) represents the cases where a vulnerability directly affects another target device (e.g. a vulnerability on the device allows to jam the target's communications). Finally, as described in the previous paragraphs, exploitability (AV, AC) and impact (CIA) metrics can be modified according to the environmental information of each installation domain.

In Table 4, we define the initial (base) vulnerability CVSS vectors for all devices in scope.

Depending on the installation site, environmental information such as network security controls and security requirements can modify the individual exploitability and impact metrics of the ${IntCVSS}_{base}$ vector as well as the existing vulnerabilities of the target device (FIRST.Org, 2019). Table 5 depicts the corresponding cyber and physical security level for each network in scope whereas Table A2 in Appendix displays the effect on cyber and physical interactions due to network and/or physical security controls. For physical interaction types, we consider the physical security control level as Low on all installation sites. After applying the environmental information, the ${IntCVSS}_{env}$ can be combined with the existing single or chained CVSS vulnerabilities to form the cumulative vulnerability vector ${CVV}_{int}$ of each interaction.

To summarise, the interaction assessment phase involves the following main steps:

1. Equation (1(1) $ChainedCVSS=[AV:[N|A],max(AC),min(PR),max(UI),max(S),max(C,I,A\left)\right]$(1) ) is used to chain different vulnerabilities that may exist on the target system.

2. The result of vulnerability chaining regarding the smart lighting system used in our scenario is shown in Equation (2(2) $\left[\mathrm{A}\mathrm{V}:\mathrm{N}\mathrm{e}\mathrm{t}\mathrm{w}\mathrm{o}\mathrm{r}\mathrm{k},\mathrm{A}\mathrm{C}:\mathrm{L}\mathrm{o}\mathrm{w},\mathrm{P}\mathrm{R}:\mathrm{N}\mathrm{o}\mathrm{n}\mathrm{e},\mathrm{U}\mathrm{I}:\mathrm{N}\mathrm{o}\mathrm{n}\mathrm{e},\mathrm{S}:\mathrm{U}\mathrm{n}\mathrm{c}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d}/\mathrm{C}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\mathrm{d},\mathrm{C}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h},\mathrm{I}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h},\mathrm{A}:\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}\right]$(2) ).

3. The overall (cumulative) vulnerability level (${CVV}_{int}$) of each interaction is calculated based on (i) the single and chained vulnerabilities of the destination node and (ii) the corresponding ${IntCVSS}_{env}$ vector (Appendix Tables A1 and A2).

4. The validity of each interaction is assessed by applying the AV and impact threshold criteria (C/I/A $\ge$ Low ∀ Level-n, n $\ge$ 2) on ${CVV}_{int}$, for all intermediate interaction tuples as described in Section 3.2. Regarding direct (Level-1) interactions with the target system, only the AV criterion is examined. Valid cyber-physical interaction tuples among IoT and ICT devices are depicted in Table 6.

3.5. Phase 3: attack path construction

To calculate all the potential attack paths, the assessed (valid) interactions of the previous phase are fed to a recursive algorithm. In particular, assessed Level-1 interaction tuples are considered as Level-1 attack paths by definition. Then, each Level-2 interaction tuple is combined with all the applicable Level-1 attack paths to form multi-step (e.g. Level-2) attack paths. The process continues until all the interaction tuples of all available interaction lists are exhausted. Similarly to phase 1 (Section 3.3), the output of this phase is a list of lists that contains all applicable attack paths. Since we only focus on examining the introduced risks from smart lighting systems, we select a subset of those attack paths where the smart lighting system is either the target system or acts as an enabler (point-of-entry device). Tables 7 and 8 present the applicable Level-1 and Level-2 attack paths respectively.

3.6. Attack path scenario assessment

To assess the risk for all attack paths, first we will utilise the cumulative vulnerability ${CVV}_{int}$ for all interactions that form an attack path, to compute the cumulative vulnerability of the attack path. Then, the impact on the target system, along with the likelihood of occurrence of each attack scenario are used, to assess the overall risk.

Finally, depending on their capabilities, available access and resources, the applicable threat agents are matched with the cumulative vulnerability vector of each attack path scenario, to determine the threat level. All the above metrics are then combined to define the risk value of each attack path scenario, as described below.

3.6.1. Calculating the cumulative vulnerability vector of an attack path

First, the vulnerabilities of the point-of-entry device are categorised per AV. Then, for each attack vector (AV), the existing vulnerabilities are chained (see Equation 1(1) $ChainedCVSS=[AV:[N|A],max(AC),min(PR),max(UI),max(S),max(C,I,A\left)\right]$(1) ) and validated based upon the same impact criterion presented in Section 3.4. Next, for each AV the assessed vulnerability with the maximum exploitability and impact subscore is chosen and combined with the $CVV\left(\mathcal{A}\mathcal{P}\right)$ to form the cumulative vulnerability vector for each attack scenario, denoted as $CVV(\mathcal{A}\mathcal{P},AV)$. The attack vector on each attack scenario is used to define the required network, logical or physical access of an attack path scenario and therefore the corresponding threat agents.

For Level-1 attack paths, the cumulative vulnerability vector $CVV\left(\mathcal{A}\mathcal{P}\right)$, corresponds to the ${CVV}_{int}$ as defined in Table 6. For Level-n ($n\ge 2$) attack path scenarios, each $CVV(\mathcal{A}\mathcal{P},AV)$ is calculated by applying Equation (3(3) $CVV(\mathcal{A}\mathcal{P},AV)=[\mathrm{A}\mathrm{V}:[\mathrm{N}|\mathrm{A}|\mathrm{L}|\mathrm{P}],max(\mathrm{A}\mathrm{C}),max(\mathrm{P}\mathrm{R}),max(\mathrm{U}\mathrm{I}),max(\mathrm{S}),\mathrm{L}\mathrm{e}\mathrm{v}\mathrm{e}{\mathrm{l}}_1(\mathrm{C},\mathrm{I},\mathrm{A}\left)\right]$(3) ) on all available ${CVV}_{in{t}_j},\mathrm{\forall }in{t}_j\in \mathcal{A}\mathcal{P}$. (3) $CVV(\mathcal{A}\mathcal{P},AV)=[\mathrm{A}\mathrm{V}:[\mathrm{N}|\mathrm{A}|\mathrm{L}|\mathrm{P}],max(\mathrm{A}\mathrm{C}),max(\mathrm{P}\mathrm{R}),max(\mathrm{U}\mathrm{I}),max(\mathrm{S}),\mathrm{L}\mathrm{e}\mathrm{v}\mathrm{e}{\mathrm{l}}_1(\mathrm{C},\mathrm{I},\mathrm{A}\left)\right]$(3) To summarise, Equation (3(3) $CVV(\mathcal{A}\mathcal{P},AV)=[\mathrm{A}\mathrm{V}:[\mathrm{N}|\mathrm{A}|\mathrm{L}|\mathrm{P}],max(\mathrm{A}\mathrm{C}),max(\mathrm{P}\mathrm{R}),max(\mathrm{U}\mathrm{I}),max(\mathrm{S}),\mathrm{L}\mathrm{e}\mathrm{v}\mathrm{e}{\mathrm{l}}_1(\mathrm{C},\mathrm{I},\mathrm{A}\left)\right]$(3) ) computes how vulnerable each attack path is, taking into account the vulnerability of all the interactions that form the attack path. At the same time, each attack path may have different vulnerability against adversaries having different access capabilities to the entry node of each attack path. For example, adversaries having only remote network access (AV:N), adversaries having access to the same local network with the entry node of the attack path (AV:A) and so on.

Besides the vulnerability calculation, Equation (3(3) $CVV(\mathcal{A}\mathcal{P},AV)=[\mathrm{A}\mathrm{V}:[\mathrm{N}|\mathrm{A}|\mathrm{L}|\mathrm{P}],max(\mathrm{A}\mathrm{C}),max(\mathrm{P}\mathrm{R}),max(\mathrm{U}\mathrm{I}),max(\mathrm{S}),\mathrm{L}\mathrm{e}\mathrm{v}\mathrm{e}{\mathrm{l}}_1(\mathrm{C},\mathrm{I},\mathrm{A}\left)\right]$(3) ) will also be utilised for the likelihood and the impact assessment. First, the impact metrics of the relevant $CVV(\mathcal{A}\mathcal{P},AV)$ are fine-tuned for the target of the attack path, as described in Section 3.6.2. Then, the exploitability metrics of $CVV(\mathcal{A}\mathcal{P},AV)$ are compared against the capability vectors of possible adversaries, to examine if each adversary is capable to exploit the cumulative vulnerability of the attack path or not. If the answer is positive, the likelihood for each adversary is computed, as described in Section 3.6.3. Finally, all the above values will be combined to compute all the possible risk combinations for each attack path (described in Section 3.6.4), while the highest possible risk value is maintained.

3.6.2. Calculating the businesswise impact

To assess the risk for each attack path, the businesswise impact must first be identified and calculated. Each impact metric (C/I/A) of the relevant $CVV(\mathcal{A}\mathcal{P},AV)$ is fine-tuned for the actual target of the attack path. Since we focus on cyber as well as cyber-physical interactions, we consider the impact due to network connectivity (interaction types C1 and C4), logical access (interaction types C2, C3, C5, C6) and physical proximity (interaction types P2 and P3). In particular, we consider direct impact to humans (discomfort, injury and/or fatality) due to deactivation and/or flickering of the luminaire. Additionally, we take into account the combined impact on air-gaped systems, as a result of network interconnectivity and functionality features of the smart lighting system which can be extended so as to create a covert channel and ultimately exfiltrate confidential information, as described in Ronen and Shamir (2016).

For example, the impact of installing a smart lighting system in a corporate environment such as a major pharmaceutical company, may range from moderate-impact attack scenarios where an attacker may choose to disable the smart lighting systems of a corporate building to disrupt business processes and cause use discomfort and/or injuries, up to potential high-impact, data exfiltration scenarios where vaccine formulas are leaked from otherwise air-gaped corporate servers due to networks interconnectivity as well as smart lights' vulnerabilities and functionality features. Furthermore, installing vulnerable smart lighting systems in public infrastructures, such as a sports stadium, may result in catastrophic consequences, including multiple injuries and even deaths, in the case where the attack is combined with other IoT-enabled systems such as a remotely managed alerting system (e.g. trigger the alarm and disable all lights in stadium during the evacuation process). Table 9 represents the businesswise impact of smart lighting systems, in a worst-case scenario approach, for all installation domains. For the impact scale, we utilise the scale/context as presented in National Institute of Standards and Technology (NIST) (Ross, 2012).

3.6.3. Calculating threat likelihood level

For each available attack scenario, different types of adversaries are matched based on their capabilities. In particular, the exploitability metrics of $CVV(\mathcal{A}\mathcal{P},AV)$ are compared against the capability metrics of potential adversaries, to examine whether an attacker is capable to trigger an attack path scenario or not. Then, for each adversary that meets the aforementioned criteria the likelihood of occurrence can be calculated. In Table 10, we present a list of common adversary types and their corresponding characteristics such as capabilities, access, motives and available resources. In addition, the corresponding attack vectors and businesswise threat level (likelihood of occurrence) are defined in Table 11, for each adversary type and installation domain. The threat level has been estimated by taking into consideration both generic and/or sector-specific threat intelligence sources such as threat reports from security organisations (e.g. ENISA Threat Report in Lella et al. (2021), NIST) and security companies (Kurtz, 2021; Levy, 2021) as well as cyber security incidents found on security-related websites.

3.6.4. Calculating risk level

By combining the vulnerability (Section 3.6.1), impact (Section 3.6.2) and threat values (Section 3.6.3) with the assessment formula in Equation (4(4) $Risk(Threat,\mathcal{A}\mathcal{P})=Likelihood(Threat,\mathcal{A}\mathcal{P})\otimes Vuln(Threat,\mathcal{A}\mathcal{P})\otimes Impact(Threat,\mathcal{T})$(4) ), the risk for each attack path scenario can be defined for all applicable threat agents. The risk for all combinations is derived based on the risk matrix shown in Table 12. The risk matrix follows a context and scale similar to NIST risk definition standards (Ross, 2012), where numerical values are fist assigned to the sub-criteria and are then combined to output a qualitative risk value in the scale $[\mathrm{V}\mathrm{e}\mathrm{r}\mathrm{y}\mathrm{L}\mathrm{o}\mathrm{w},\dots ,\mathrm{V}\mathrm{e}\mathrm{r}\mathrm{y}\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}]$, as described in Stellios, Kotzanikolaou, et al. (2021). (4) $Risk(Threat,\mathcal{A}\mathcal{P})=Likelihood(Threat,\mathcal{A}\mathcal{P})\otimes Vuln(Threat,\mathcal{A}\mathcal{P})\otimes Impact(Threat,\mathcal{T})$(4)

4. Result analysis and mitigation strategies

4.1. Result analysis

A total of 90, smart light enabled, attack path scenarios were created during the attack path scenario assessment phase, 24 of which were cyber (27%) and 66 cyber-physical (73%). Due to the high-value/criticality of most targets in scope, 38% of all attack scenarios were characterised as Very High and 27% High impact. In addition, scenarios of Medium (18%), Low (11%) and Very Low (7%) impact corresponded to direct cyber-physical attack paths on corporate and home environments (e.g. cause discomfort and/or injuries to employees and families). Four typical examples that demonstrate Very High impact, cyber/cyber-physical attack scenarios are presented in Figure 3. Two cyber attack scenarios involving cyber criminals and nation state adversaries against a bank and a government cloud infrastructure respectively, and two cyber-physical: a terrorist attack against a crowded stadium and a sophisticated data exfiltration attack against a major pharmaceutical corporation.

Figure 3. Examples of Very High impact, cyber and cyber-physical attack path scenarios.

19% of Very Low and 39% of Low probability attack scenarios mainly correspond to activists and disgruntled workers whereas Medium likelihood scenarios were spread evenly among all threat agents. As expected, threat agents such as cyber criminals and nation-state were responsible for 16% of the most likely to happen attacks (13% High -- 3% Very High).

As far as Vulnerability level is concerned 93% of all attack path scenarios were identified as High (55%) or Critical (38%), even in cases where the environmental network security controls were defined as High (bank's server farm internal network). This is mainly due to the fact that high-severity vulnerabilities were found both on smart lighting systems and targets in scope.

Riskwise, the majority (67%) of all assessed scenarios were categorised as of Moderate risk (51% cyber-physical and 16% cyber), 27% as High (16% cyber-physical and 11% cyber) and 14% as Low (7% cyber-physical and 7% cyber). All of the above are depicted in Figure 4. Further analysis of the results (see Figure 5) revealed that regarding the risk profile of each threat agent, cyber criminals correspond to the highest percentage (46%) of the High risk attack scenarios followed by nation-state (29%) and cyber terrorists (17%), for cyber as well as cyber-physical attack scenarios. This is mainly due to the fact that their capabilities satisfy most of exploitability requirements and are more likely to attack (higher probability) than the other threat actors, in most domains in scope.

Figure 4. The distribution of the risk levels for both cyber as well as cyber-physical attack path scenarios.

Figure 5. Threat agents' risk profile for both cyber as well as cyber-physical attack path scenarios.

The fact that disgruntled workers were responsible for 17% of Low and 22% of Medium risk attack scenarios does not mean, in any case, that these risks that can be overlooked, since, in most cases, corresponded to High/Very High impact attack scenarios. For example, a disgruntled public servant that works as an administrator at a government's central ICT infrastructure can have significant impact on several mission-critical applications and services (e.g. taxation/COVID-19 vaccination applications) especially if no proper security countermeasures exist and no business continuity plans are in place.

Finally, business competitors and activists were accountable mainly for Medium/Low risk and only for a small (4% each) portion of High risk attack scenarios. On the other hand, the fact that limited resourced, low-skilled adversaries are capable of triggering High risk attack path scenarios can be considered an alarming finding depending on the organisation type.

4.2. Mitigation strategies

Mitigation strategies on the aforementioned risks can vary significantly among installation domains. Smart lighting systems installed in critical environments (e.g. within a corporation's data center, in a crowded public infrastructure) must undergo an extensive security testing in hardware, networks, I/O interfaces and application/cloud API services prior to installation to any secure environment whereas security assessments must be repeated at regular intervals. In Table 13, we present several security controls with the attack vector(s) that they mitigate as well as the corresponding network, hardware and software layer(s) in which they can be applied.

Table 13. Security controls appropriate for IoT devices such as smart lighting systems, categorised by the attack vector(s) that each security countermeasure can mitigate and the layer(s) that they can be applied.

	Attack vector				Layer
Security control	Net	Logical	Physical	InProx	Net	H/W	ES	App	Cloud
Encryption	✓	✓	✓	✓	✓		✓	✓	✓
Authentication	✓	✓	✓	✓	✓	✓	✓	✓	✓
Integrity	✓	✓	✓		✓	✓	✓	✓	✓
Isolation	✓		✓	✓	✓
Authorisation	✓	✓	✓	✓	✓		✓	✓	✓
Tamper-resistant casing			✓			✓
Intrusion detection alerting systems	✓		✓	✓	✓	✓
Device's state monitoring						✓		✓
Network segmentation	✓				✓
Electromagnetic radiation shielding				✓
Log monitoring and analysis -- SIEM	✓	✓			✓			✓	✓
Code signing -- secure boot process			✓				✓	✓
Disable debug interfaces			✓			✓
Trusted Platform Module chips			✓			✓
Security updates							✓	✓	✓
Code obfuscation		✓	✓				✓	✓
Secure Software Development		✓					✓	✓	✓

Net: Network, InPox: In Proximity, H/W: Hardware, ES: Embedded Software, App: Applications.

4.2.1. Mitigating risks due to network access

Cross-domain good practices, to reduce risks stemming from cyber interaction types C1 and C4 may include network services and interfaces evaluation (e.g. UPnP, Bluetooth, NFC, ZigBee, Z-Wave) and proper network segmentation and/or isolation, especially in the case of wireless IoT networks. Additionally, strong encryption schemes combined with robust authentication/authenticity and integrity mechanisms must be in place to inhibit most adversary types from launching several high-impact network attacks (e.g. replay, spoofing). In particular, best practices for the assessed smart lighting system in urban environments may include disabling the controller's UPnP network protocol, ensuring that security on Wi-Fi network interfaces is always on (e.g. WPA2) and make sure that communications with cloud servers are either disabled or utilise the latest versions of Transport Layer Security (TLS).

4.2.2. Mitigating risks due to logical access

Addressing risks due to logical access cyber interaction types (C2/3, C5/6) in diverse domains of an urban environment is a much more daunting task, to begin with. Remote management of critical systems, which has been on the rise due to the pandemic of COVID-19, must be submitted under exhaustive security evaluation and proper security controls must always be in place. Security countermeasures may include, among others, remote systems' access via VPN services, full systems audit on remote endpoints, logs analysis with centralised Security Information and Event Management (SIEM) systems, multi-factor authentication schemes and strict endpoint security rules. On the other hand, application auditing, database firewalling and anomaly detection/prevention systems can also be used to mitigate risks from insider threats such as executive stuff and software developers.

4.2.3. Mitigating risks due to physical access

Authorisation rules must be in place for all internal areas of an corporate environment and proper characterisation of security zones must be in place. Smart lighting systems must be placed into protective cases especially when they installed unattended, in public areas, to resist physical tampering. In particular, access to internal/protected areas of an organisation (e.g. data centres) must be properly controlled and monitored via the use of keycard-controlled doors, biometric identification mechanisms, closed-circuit television cameras and motion detectors. Physical isolation of critical systems with smart lighting systems should extend to include locations of network equipment and cabling of both power and network, as well as other building automation systems necessary for the system's operation.

4.2.4. Mitigating risks due to physical proximity

Appropriate mitigation techniques on physical interaction types (P2/P3) are equally difficult if not harder to implement, when compared to logical and/or network interaction types, mainly due to diversity of interfaces and functionality features of smart lighting systems. Exposed network and/or physical interfaces (e.g. sound), luminosity and proximity sensors as well as vulnerable functionality features of luminaires (e.g. remotely adjustment of luminosity levels) must be thoroughly examined in order to determine whether they pose a threat to the organisation under study and deactivation of these interfaces and features must be imposed if security concerns are raised. For example, to mitigate jamming attacks on physical network layer due to shared spectrum with a smart lighting system (e.g. Wi-Fi / ZigBee with WirelessHART 2,4GHz), physical isolation and/or electromagnetic radiation shielding (Faraday cages) may be necessary.

4.2.5. Security controls applied on hardware/embedded software

To mitigate hardware integrity attacks, tamper-resistant cases with self-checking intrusion/detection mechanisms must exist to prevent unauthorised access to the internal components of an smart lighting system. Additionally, alerting systems can be used to notify administrators and remote operators for potential physical attacks on smart lighting systems (e.g. theft, device replacement, hardware tampering). Embedded software security countermeasures may include, among others, trusted execution environments (e.g. via code signing -- secure boot process) as well as the adoption of integrated instead of separate memory chips. The latter in conjunction with the lack of debugging interfaces can ensure that attempts aiming at retrieving sensitive information directly from the board components will result in damaging the chip thus destroying any data it contains. Additional use of security features such as embedded code obfuscation and Trusted Platform Module chips (TPMs) can be also utilised to impede access to sensitive information of an IoT device (e.g. source code, encryption keys, hardcoded passwords). Vendors of smart lighting systems should avoid reusing hardcoded passwords among different devices and platforms (in our case just 4 passwords over 1.400 firmware files of diverse IoT products) as well as privileged accounts (root user) for all services on IoT devices. Vendors should also ensure that IoT appliances do not run on obsolete software and security updates are delivered timely and securely (e.g. via X.509 digital certificates). Additionally, proper informative signs on the IoT casing and/or systemic alerts should exist to ensure that the customer is aware of the exact time period, after which, the IoT device is no longer supported from the official manufacturer.

4.2.6. Security controls on application software and cloud services

The development of smart lighting control applications should incorporate security-by-design – secure software development methodologies including strong authentication/integrity mechanisms (e.g. code signing), code obfuscation to resist reverse engineering techniques and least privilege principle enforcement on all layers (application database, web).

4.2.7. Governance frameworks and security standards

Governance frameworks, guides and legislation initiatives regarding security and data privacy are also considered as a step in the right direction. The guide 'Cyber Security for Lighting Systems' ,⁶ released from US Department of Energy, showcases cybersecurity risks that are associated with light fixtures and common lighting controls/strategies, including common types of attacks on such systems. Among others, the guide proposes the adoption of wired instead of wireless communications protocols with proper network security controls, and the use of strong authentication and encryption mechanisms such as Advanced Encryption Standard (AES) algorithm with a minimum length of 128-bit encryption key, especially in cases where wireless deployment of such systems cannot be avoided. Moreover, a series of standards (UL 2900) that helps improving the security of IoT devices by providing measurable criteria for the testing of network-connected devices that send, store or transmit data has been developed from the American National Standard Institute (ANSI) with the UL 2900-1 focused on cybersecurity of smart lighting systems. Finally, the adoption of transparent, open standards rather than proprietary technology, guarantees that any potential vulnerabilities can be identified and addressed on time by the security community.

5. Discussion and limitations

While existing RA methodologies are able to identify and assess most cyber attack scenarios they fail to discover complex, IoT-enabled, cyber-physical attack vectors. Similarly, related research work such as in Agadakos et al. (2017) come with several limitations, including computational constraints due to the exponential growth of the multitude of attack paths and the introduction of a large amount of false-positives, mainly due to the lack of validation mechanisms. In this work, we managed to showcase risks that stem out from smart lighting systems installed in popular domains of an urban environment by utilising our recent work regarding a hands-on security assessment on a popular smart lighting system (Stellios, Mokos, et al., 2021) and our IoT-enabled RA methodology (Stellios, Kotzanikolaou, et al., 2021).

From the result analysis presented in Section 4.1, we can infer that 66 (73% of total) attack scenarios were cyber-physical. In particular, cyber-physical attack scenarios were accounted for the majority of high-risk (16% of total) category, 51% were of moderate risk whereas a mere 7% were characterised as low risk. This in turn unveils the risks involved when insecure IoT devices such as smart lighting systems are installed in corporate domains and public infrastructure. Additionally, it substantiates the contribution of this work since, until now, these hard-to-identify, complex attack vectors have not been properly identified and assessed. Typical paradigms of high-impact, cyber-physical attack scenarios involve a remote adversary that targets a pharmaceutical corporation; the attacker initially takes advantage the physical proximity with a smart lighting system's wireless interface (e.g. via wardriving/warflying techniques) to infiltrate the organisation; then via indirect connectivity manages to propagate to the actual target; finally by exploiting the smart light's functionality features (Ronen & Shamir, 2016) she manages to create a covert channel and ultimately exfiltrate valuable corporate secrets of an otherwise 'isolated' critical system. Similarly, a cyber terrorist can utilise Internet connectivity and exploit existing vulnerabilities of an alarm and a smart lighting system installed in a public sports stadium, to cause multiple injuries and/or fatalities (see Figure 3).

Since our analysis is based on the IoT-enabled RA methodology of Stellios, Kotzanikolaou, et al. (2021), this work inherits the limitations of the underlying methodology. In particular, our attack path analysis does not examine possible physical interactions among intermediate nodes; only direct physical interactions with the target system have been modelled. In addition, we have not modelled additional types of interactions that may exist beyond cyber and physical ones, such as logical interaction types. An additional limitation that should be noted is that, as most risk assessment methodologies, the results of an assessment are bound to the current vulnerability state. Thus periodic re-assessment should be run, if new vulnerabilities and/or attack vectors are discovered, to cope with the fast evolution of the threat landscape. Finally, since, the smart light vulnerabilities that were used as input correspond to the vulnerability assessment of a specific model (Stellios, Mokos, et al., 2021), our analysis does not include interaction types and attack vectors that may rely on vulnerabilities that may exist in other similar models (e.g. vulnerabilities on proximity or luminosity sensors).

6. Conclusion

In this paper, we extended our work in Stellios, Mokos, et al. (2021) to analyse the cascading effect of smart lighting vulnerabilities in various environments. By utilising the risk assessment methodology presented in Stellios, Kotzanikolaou, et al. (2021), we have identified and assessed risks that stem from smart lighting systems, installed in popular urban infrastructures and services. In particular, by combining cyber and physical interaction types with the appropriate threat actors and by utilising functionality features and existing vulnerabilities of a specific smart lighting system, we managed to identify and assess complex, yet realistic, high-impact cyber-physical attack path scenarios.

Intuitively, obvious mitigation actions such as the isolation of the organisation's internal networks from the internet can mitigate most interconnectivity attack paths. However, in many cases they are hard to implement, mainly due to operational requirements (e.g. control from an remote operator, interdependences among ICT/IoT systems). The latter can also give a false sense of security, since, an adversary can create a covert channel by exploiting the functionality features of a smart lighting system. To help prioritise mitigation actions, in Section 4.2, we have proposed several security countermeasures, and we have grouped them based on the attack vector they can mitigate.

Risks from public lighting systems are usually overlooked since no real, high-profile attacks exist. But as the deployment of these systems grows, it becomes more crucial and therefore more valuable. As modern cities embracing technology at a rapid pace, smart lighting systems can be expected to become more and more integrated with other building management systems such as Heating, Ventilation, and Air Conditioning (HVAC) and alerting systems and other IoT-enabled infrastructure automation components. Ultimately, this means that smart lighting systems will be an even more tempting target for a variety of threat agents in the near future.

Glossary

AC Attack Complexity (CVSS metric). 6,14

APIs Application Programming Interfaces. 1

AV Attack Vector (CVSS metric). 4–11, 20

ChainedCVSS Chained Vulnerability Vector. 14

CVE Common Vulnerabilities and Exposures. 6

CVSS Common Vulnerability Scoring System. 6,7,9,14

CVV Cumulative Vulnerability Vector of an interaction / attack path. 7,8,9,14,15,16

IFTTT If-This-Then-That interoperability service. 2

IntCVSS The base/environmental Interaction Vulnerability Vector. 7,14,15,27,28

IoT Internet-of-Things. 1–7,14,17,20,23,24,27,28

LED Light Emitting Diode. 1

OLED Organic Light Emitting Diode. 1

PR Privilege Requirements (CVSS metric). 4,7,9,14,28

SingleCVSS Single Vulnerability Vector. 14

UI User Interaction (CVSS metric). 6,7

ZLL ZigBee Light Link. 1,7,8,10,28

Disclosure statement

No potential conflict of interest was reported by the authors.

Additional information

Funding

This work has been partly supported by the University of Piraeus Research Center [VAT Registration Number: EL 090037284 91].

Notes

1 https://www.lifx.com/

2 https://www.belkin.com/us/smart-home/c/wemo/

3 https://cve.mitre.org/

4 https://www.checkpoint.com/defense/advisories/public/2020/cpai-2019-1605.html/

5 https://nvd.nist.gov/vuln/detail/CVE-2020-12695

6 https://www.energy.gov/sites/prod/files/2018/06/f52/cyber_security_lighting.pdf

Appendix. Supplementary tables

Table A1. Defining the implied capabilities for each cyber-physical interaction type as a CVSS vector.

		Exploitability metrics					Impact metrics
	Type	AV	(M)AC	PR	UI	S${}^{\ast }$	(M)C	(M)I	(M)A
${IntCVSS}_{base}$	C1	A	H	N	N	U	N	N	N
	C2	A	H	L	N	U	L	L	L
	C3	A	H	H	N	U	H	H	H
	C4	N	H	N	N	U	N	N	N
	C5	N	H	L	N	U	L	L	L
	C6	N	H	H	N	U	H	H	H
	P1	P	H	N	N	U	N	L	L
	P2	A	H	N	N	U	L	L	L
	P3	A	H	N	N	U	N	L	L
${IntCVSS}_{env}$		(M): These metrics can be environmentally modified (see Table A2)

Table A2. Proposed network/physical environmental modifiers for ${IntCVSS}_{env}$ vector according to the corresponding network/physical security control level.

		Impact modifiers
Network/physical security controls	(M)AC	M(C)	M(I)	M(A)
Not defined/Weak	H $\to$ L	No effect	No effect	No effect
Moderate	H	No effect	No effect	No effect
Strong	H	H $\to$ L	H $\to$ L	H $\to$ L
		L $\to$ N	L $\to$ N	L $\to$ N

Table A3. $IntCVSS$ vectors representing the required capabilities and impact metrics for all applicable attack scenarios as defined in Stellios, Mokos, et al. (2021).

			${IntCVSS}_{base}$
	Attack type	Status	AV	AC	PR	UI	S	C	I	A
IoT Control device	Firmware Extraction	Confirmed	P	L	N	N	C	H	N	N
	Firmware Downgrade	Plausible	N	L	N	N	C	L-H	L-H	L-H
	Firmware Modification	Plausible	P	H	N	N	C	H	H	H
	Device system access	Plausible	P	L	N	N	C	H	H	H
Cloud API servers	Access sensitive information	Confirmed	N	L	N	N	C	H	N	N
	Waterhole attack	Plausible	N	H	N	N	C	H	H	N
	API manipulation	Plausible	A	ND	N	N	C	L	L	L
	session hijacking	Confirmed	A	L	N	N	C	L-H	L-H	L-H
	API exchaustion	Confirmed	N	L-H	N	N	C	N	N	L-H
	XSS / SQL injection etc.	Plausible	N	L-H	N	N	C	L-H	L-H	L-H
	Server-side Man-in-The-Middle attacks	Plausible	N	L-H	N	N	C	L-H	L-H	N
Device's ZigBee Network	De-Auth attacks	Confirmed	A	L	N	N	C	N	N	H
	Passive Sniffing	Confirmed	A	L	N	N	C	L-H	N	N
	Replay attacks	Confirmed	A	L	N	N	C	L-H	L-H	N-H
	DoS Attacks	Confirmed	A	L	N	N	C	N	L	L
	Gain Network Access	Confirmed	A	L	N	N	C	L	N	N
Device's WiFi Network	De-Auth attacks	Plausible	A	L	N	N	C	N	N	H
	Passive Sniffing	Confirmed	A	L	N	N	C	L	N	N
	Replay attacks	Plausible	A	L-H	N	N	C	L-H	L-H	N-H
	DoS Attacks	Confirmed	A	L	N	N	C	N	L	L
	Gain Network Access	Confirmed	N	L	N	N	C	L	N	N
Device's Mobile Application	Reverse engineering	Confirmed	N	L	N	N	C	L-H	L-H	N
	Dynamic analysis	Confirmed	N	L	N	N	C	L-H	L-H	N
	Application rights abusal	Plausible	L	L-H	L	N	C	L-H	L-H	N-H
	Application modification	Confirmed	N	L	N	N	U	L-H	L-H	N-H
	Client-side Man-in-The-Middle attacks	Confirmed	A	L	N	N	U	L-H	L-H	N

AV: P, Physical; L, Logical access; A, Adjacent/Proximity; N, Remote network access. AC/PR/UI/S/CIA: N, None; L, Low; H, High; ND, Not Defined.

Table A4. Cyber interaction types: A cyber interaction $(x\to y)$ may belong to $\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}$ C1–C6, based on the connectivity and the logical access of x to y.

	Logical access
Connectivity	None (no explicit access)	Low (user-level)	High (admin-level)
L2 (Local) Network	C1	C2	C3
L3 (Remote) Network	C4	C5	C6

Table A5. Physical interactions based on the proximity between devices. The implied capabilities of the source node on the target system may involve physical tampering, manipulation of I/O interfaces or manipulation of shared-band network interfaces.

Type	Description	Interface	Examples
P1	Physical proximity (x may use a moving part and/or moving capabilities to physically reach y)	Remotely controlled moving parts or devices	Robotic arm, crane, wheeled device, drone
P2	Wireless I/O proximity (x is in range with a wireless I/O interface of y)	Audio, Visual, Optical interfaces	Line-of-sight (LiDAR, IR), audio / video interfaces
P3	Networks' proximity (x and y at different networks that are in range)	Different, but shared-band wireless interfaces	e.g. 802.11.x and 802.15.x operate at 2.4 GHz