A Cybersecurity Threat Profile for a Connected Lighting System

Abstract

In anticipation of improved energy performance and cost savings, cities and building owners are increasingly considering “smart lighting initiatives” that aim to convert their collection of simple luminaires (i.e., lighting fixtures) into an intelligent connected lighting system (CLS) capable of remotely monitoring energy consumption and fault conditions, and possibly implementing adaptive lighting schemes. The U.S. Department of Energy (DOE) has set an national goal of tripling the energy efficiency and demand flexibility of the buildings sector by 2030, relative to 2020 levels 1. It is forecast that connected lighting systems can contribute to that goal by delivering 125 TWh of annual energy savings by 2035 2, equivalent to the annual output of 50 typical (500 MW) power plants. However, these energy savings and the DOE goal are put at significant risk if connected technologies are not adopted due to real or perceived cybersecurity concerns. Connected IoT devices such as these have historically been rife with vulnerabilities which sometimes put security considerations secondary to functionality and operability. What are the cybersecurity threats that will impact these systems, as formerly banal luminaires transition into intelligent connected devices that collect information about themselves, their surrounding environment, and possibly us? In this paper we analyze a threat profile performed on a fault-detection use case for streetlights. A threat profile establishes security requirements, justifies security measures, yields actionable controls, and effectively communicates risk to stakeholders. This effort provides critical information for making threat-based decisions to increase security at a reasonable cost, and can effectively be used by development teams, software architects, and managers to make cybersecurity a part of their ongoing culture of awareness, training, and prevention. This leads to more secure systems and better-understood security. On-premise, cloud, and hybrid architectures with different authentication mechanisms were modeled and later categorized using the Microsoft STRIDE framework. An analysis of the recommended controls for each threat was performed to determine which controls could and should be put in place by manufacturers or third-party suppliers, and which controls need to be left up the end-user to implement. Fifty-seven threats were identified. Among our key findings: (1) 65% (37/57) of the threats did not involve the luminaires, but rather the other components needed to communicate with and manage them; (2) 63% (36/57) of the threats could have been mitigated through manufacturer-implemented defensive techniques or “controls”; and (3) 23% (13/57) of the threats were dependent on the network configuration. Recommendations based on the results of this work are made to key stakeholder groups. Notably, lighting technology developers are advised to address all threats that can be reasonably controlled with baked-in technology solutions (e.g., encryption or authentication controls), and employ some form of secure supply chain management and tracking where other parts (e.g., sensors, microprocessors) of a luminaire must also be built and manufactured with the proper security controls in place. Developers should also review threats involving assets not developed in-house to understand how connectivity with other devices will affect their product during system operation and determine if a compensating control for a defense-in-depth strategy will be needed. Finally, those interested in deploying CLS should compare the differences between cloud and on-premise models to determine which is more suitable for their needs and the abilities of their security team.