Handling a trillion (unfixable) flaws on a billion devices: Rethinking network security for the Internet-of-Things
Tianlong Yu†, Vyas Sekar†, Srinivasan Seshan†, Yuvraj Agarwal†, Chenren Xu‡ †Carnegie Mellon University, ‡CECA Peking University
ABSTRACT Interac0on/control!over! Launchpad!for!deep!and! physical!environment! ! scalable!a;acks! The Internet-of-Things (IoT) has quickly moved from the ! ! realm of hype to reality with estimates of over 25 billion ! ! devices deployed by 2020. While IoT has huge potential for societal impact, it comes with a number of key security Privacy!leaks! challenges—IoT devices can become the entry points into IoT!Challenges! critical infrastructures and can be exploited to leak sensitive Tradi0onal!IT! ContextBdependence! information. Traditional host-centric security solutions in Policies! Sta0c,!PerBhost! CrossBdevice!interac0ons!! today’s IT ecosystems (e.g., antivirus, software patches) are Simple!honeypots! Device/Vendor!diversity! Learning! fundamentally at odds with the realities of IoT (e.g., poor Few!configura0ons! CrossBdevice!interac0ons! vendor security practices and constrained hardware). We ar- Host!Patch/An0virus! Device!constraints! Enforcement! gue that the network will have to play a critical role in se- Perimeter!Appliances! Deep!access!to!a;acker! curing IoT deployments. However, the scale, diversity, cy- Figure 1: IoT security challenges and how/why conven- berphysical coupling, and cross-device use cases inherent to tional IT security approaches are found wanting IoT require us to rethink network security along three key dimensions: (1) abstractions for security policies; (2) mech- While IoT has huge potential, it also comes with its share anisms to learn attack and normal profiles; and (3) dynamic of challenges. Most vendors only deal with parts of the IoT and context-aware enforcement capabilities. Our goal in this ecosystem and, typically, their priorities have been providing paper is to highlight these challenges and sketch a roadmap novel functionality, getting their products to market soon, to avoid this impending security disaster. and making them easy to use. Unfortunately, security and privacy risks have not received as much attention. Since IoT Categories and Subject Descriptors devices will typically be embedded deep inside networks, C.2.0 [Computer-Communication Networks]: General- they are attractive attack targets and may become the “weak- security and protection; C.2.1 [Computer-Communication est link” for breaking into a secure IT infrastructure [17], or Networks]: Network Architecture and Design-distributed for leaking sensitive information about users and their be- networks haviors [18]. These are not hypothetical concerns as several actual attacks have already been reported. For example, IoT General Terms devices were used as bots to launch DDoS or spam [3], smart Security, Design meters were hacked to lower utility bills [15], and handheld scanners were compromised to enter logistics firms [6]. 1 Introduction Today’s IT security ecosystem, which relies on a combi- The Internet-of-Things (IoT) has quickly moved from hype nation of static perimeter network defenses (e.g., firewalls to reality; Gartner, Inc. estimates that the number of de- and intrusion detection/prevention systems), ubiquitous use ployed IoT devices will grow from 5 Billion in 2015 to 25 of end-host based defenses (e.g, antivirus), and software Billion in 2020 [4]. Like other disruptive technologies, such patches from vendors (e.g., Patch Tuesday), is fundamen- as smartphones and cloud computing, IoT holds the potential tally ill-equipped to handle IoT deployments (Figure 1). for societal scale impact by transforming many industries as Specifically, the scale, heterogeneity, use cases, and device well as our daily lives. and vendor constraints of IoT means that traditional ap- proaches fall short along three key dimensions: • Types of policies: IoT devices can interact with other de- Permission to make digital or hard copies of all or part of this work for vices via explicit channels (e.g. a single app may use mul- personal or classroom use is granted without fee provided that copies are tiple IoT devices) or implicitly by affecting the physical not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to world around them (e.g., an IoT light bulb may trigger republish, to post on servers or to redistribute to lists, requires prior specific an IoT light sensor). Thus, compromised IoT devices can permission and/or a fee. affect both applications that use them explicitly as well HotNets ’15 November 16–17 2015, Philadelphia, PA USA Copyright 2015 ACM 978-1-4503-4047-2 ...$15.00. as applications with implicit or indirect cross-device de- Row Device Device Num. Vulnerability Device Cross-device policies Typical Example 1. Avtech Cam 130k exposed account/password If Nest Protect detects smoke, NEST Protect 188 2. TV Set-top box 61k exposed access then turn Philips hue lights on. 3. Smart Refrigerator 146 exposed access Turn of WeMo Insight if SmartThing Wemo Plugin 227 4. CCTV Cam 30k (by IP) unprotected RSA key pairs shows no body is at home. 5. Traffic Light 219 no credentials Activate your Manythings Camera Scout Alarm 63 6. Belkin Wemo >500k (estimated) open DNS resolver, use for DDoS if Alarm is Triggered. 7. Belkin Wemo >500k (estimated) exposed access, bypass app Table 2: Cross device policy examples. Table 1: Examples of Known IoT Vulnerabilities. pendencies. The result is that the security for an IoT de- teractions. Finally, we present the issues in using current ployment are likely to be complex and dynamic since they enforcement mechanisms and highlight the requirements for depend on both physical (e.g. environmental parameters) IoT security. and computational (e.g., the state of other related devices) 2.1 Motivating Scenarios contexts. IoT Vulnerability Cases: Table 1 lists a small subset of • di- Learning signatures and anomalous behaviors: The IoT device vulnerabilities found from SHODAN [14] and versity of IoT devices and vendors inevitably means that other sources. The examples come from different types of traditional approaches of discovering attack signatures IoT devices, including: cameras (Row 1 and 4), Set-top box (e.g., honeypots) will be insufficient and/or non-scalable. (Row 2), Smart Appliance (Row 3), Traffic light (Row 5) Furthermore, there might be implicit dependencies where and Smart Plugs (Row 6 and 7). The first three cases are device interactions are indirectly coupled through the en- examples where the devices have hardcoded default user- vironment. Thus, we need new mechanisms to learn sig- name/passwords (“admin/admin” for Avtech cameras) or de- natures and infer such cross-device dependencies to in- vices with open IPs, ports and protocols that can be accessed form security policies. (Row 2 and 3). The fourth example is a CCTV setup with • Enforcement mechanisms: Since IoT devices operate unprotected RSA key pairs in the firmware image for ≈30K deep inside the network, traditional perimeter defenses devices [20]. Here, an attacker can gain access to the devices are ineffective. At the same time, IoT devices typically and mount more complex attacks on the internal networks, do not run full-fledged operating systems, require low- turn on/off devices, or compromise the privacy of individ- power consumption and are resource constrained. More- uals. To date, these vulnerabilities remain unpatched. The over, the longevity of these devices means that vulnerable traffic light vulnerability (Row 5) allows unfettered access of devices (e.g., default passwords, unpatched bugs) remain 219 traffic lights, enabling an attacker to change traffic lights deployed long after vendors cease to produce or support and even cause accidents [14]. The last two examples (Row them. Thus, traditional host- or device-centric mecha- 6,7) are vulnerabilities in the popular Belkin Wemo line of nisms (e.g., antivirus, patches) are impractical to expect smart home products. The Wemo devices run a open DNS in an IoT world. Finally, given that the environment and resolver which was used to mount a DDoS attack. The sec- device behaviors can change rapidly, we need to rapidly ond vulnerability allows open access to the devices across reassess and update the system’s security posture. Unfor- the Internet (not just on the LAN), which means that their tunately, today’s security enforcement schemes stem from data (power usage) be accessed and they can even be turned a static mindset and cannot handle such dynamics. ON/OFF remotely. In summary, these anecdotes suggest that Rather than chase the hopeless goal of IoT devices that vulnerable IoT devices can create a significant threat to the are secure-by-construction, we need pragmatic “bolt-on” so- security of our networked infrastructures and compromise lutions for securing IoT that acknowledge the realities of the privacy of individuals. marketplace (e.g., existing devices, poor software practices, Cross-device dependencies: Like typical network de- patch unavailability) and the practical challenges associated vices, IoT devices can communicate explicitly with each with IoT (e.g., resource or software constraints). Unlike other. For example, a networked thermostat (e.g., NEST) traditional IT ecosystems where host-based detection and can control the air-conditioning system in a smart home. prevention are prevalent, we believe that the device and However, unlike traditional devices, IoT devices can also ecosystem limitations of IoT will need the the network to be coupled through the physical environment leading to (re)emerge as the key vantage point for enforcing security implicit dependencies. For instance, a temperature sen- policies. In the rest of the paper, we elaborate on the chal- sor can be connected to a service like IF-This-Then-That lenges with respect to policies, policy learning, and enforce- (IFTTT) [7] to open windows to cool down a space when ment and discuss preliminary ideas for rethinking network the air-conditioning is not active. Thus, an attacker could security for IoT. compromise the smart plug (e.g., Belkin Wemo) to turn off the air-conditioner in a room and trigger a temperature in- 2 Motivation and Overview crease, which would, in turn, cause the the windows to open To highlight some of the security challenges in IoT, we first and create a physical security breach. Such cross-device de- present a number of reported IoT vulnerabilities, and the pendencies are quite common. Table 2 shows the number number of devices affected, from known public databases. of cross-device dependencies [7] and typical cases for three Next, we describe the challenges with cross IoT device in- widely used IoT devices: NEST Protect [9], Wemo Insight Challenge!1:!! Admin! ture to the current operating context of different devices and Expressive!way!to!specify!policy! the environment. IotSec!Control!Pla.orm! Figure 2 shows a high-level vision of our IoT security ar- Events!from! Dynamically!! chitecture called IoTSec. While our approach and ideas are devices!and!μmbox!! launch!μmbox!! ! quite general, we focus on residential and commercial IoT ! 2 ! deployments. IoTSec envisions customized µmboxes (mi- ! cro network-security functions) that act as security gateways ! for each IoT device. A logically centralized IoTSec con- Tunnel!traffic!! Challenge!3:!! troller monitors the contexts of different devices and the op- to/from!devices! Customized! Scalable,!responsive,!and! Challenge!2:!! μmbox! erating environment and generates a global view for cross- efficient!enforcement! Learning!signatures/interacKons! device policy enforcement. Based on this view, it instanti- Figure 2: High-level vision of IoTSec ates and configures individual µmboxes and the necessary Switch [1] and Scout Alarm [13].1 To mitigate potential at- forwarding mechanisms to route packets to these µmboxes. tacks, we need to reason about normal behaviors, and, thus, This vision is quite general and can naturally support a range need systematic mechanisms to discover and express such of IoT management models; e.g., directly connected devices dependencies. vs. IoT hubs [12] vs. smartphone-controlled [7]. To enable Broken Enforcement Mechanisms: Traditional enforce- immediate deployment, we assume the enterprise has a well- ment mechanisms are unlikely to be effective in IoT deploy- provisioned on-premise cluster with a pool of commodity ments for a number of reasons. First, there are no host- server machines. In a home scenario, we envision an up- based defenses (e.g., antivirus) solutions due to resource graded version of an IoT router (e.g., Google OnHub [5]) constraints on these devices and the lack of a common pro- with compute capabilities. Each IoT device’s first-hop edge gramming environment or operating systems. For exam- router or wireless access point (AP) is configured to tunnel ple, even antivirus systems for embedded systems, such as packets to/from the device to the cluster or an IoT router. Commtouch Antivirus [2], require 128 MB RAM, while Given this high level vision, there are three key outstand- most IoT devices use single-thread microcontroller (8051, ing challenges: (1) An expressive way to specify the types MSP430, ATMEL series) with ≤ 2 MB RAM. Second, un- of policies to enforce (Section 3); (2) How can we learn sig- like traditional IT devices, IoT devices lack effective auto- natures of malicious attacks and patterns of normal (cross- mated software updates. The current process of patching device) behavior to inform these policies (Section 4); and IoT vulnerabilities is via manual firmware updates, and that (3) How to implement scalable, responsive, and efficient en- too per device/vendor. Unfortunately, due to the longevity forcement mechanisms (Section 5). of IoT devices, software updates will likely be unavailable (e.g., vendor may not support updates or no longer exist) or 3 Policy Abstractions be too late to prevent early exploits. Third, existing network In this section, we discuss why existing policy abstractions, security mechanisms largely stem from a static perimeter- e.g. firewall rules or IoT management protocols, are not ex- defense mindset (e.g., IDS and firewall at the gateways). pressive enough to handle the types of security and safety With vulnerable IoT devices embedded deep inside networks properties for the scenarios described in Section 2. Then, and dynamic behaviors that change with operating context, we present an expressive-but-inefficient finite state machine such classical approaches quickly become ineffective. (FSM) policy abstraction that captures key environmental, 2.2 System Overview cross-device, and security contexts. We end with open chal- lenges. From the examples in the previous section, we can general- ize two key observations for securing IoT: (1) host-based ap- 3.1 Strawman solutions proaches are ineffective and we need to depend on network- To motivate the problem, consider two natural strawman based solutions, since IoT devices contain significant num- solutions, one each from the traditional (IT) network and bers of unpatched vulnerabilities and have limited resources; the IoT domains. In traditional IT security, a simple pol- (2) traditional static perimeter defenses are unable to secure icy abstraction used by firewalls and IDSes, is a set of IoT devices, since these devices are deployed deep inside the Match → Action pairs, where the Match predicate is typ- network, with their physical and computational context con- ically specified in terms of packet headers (L3-L4 ACLs) or stantly changing. To enforce security policies based on the payloads (e.g., IDS). More advanced policies also include dynamic context, we envision a new software-defined ap- connection state State, Match → Action; e.g., a stateful proach to IoT security, where we can: (a) rapidly develop firewall allows incoming traffic if an outgoing connection and deploy novel network defenses tailored to IoT use cases was established earlier. These abstractions do not work in and (b) dynamically customize the network’s security pos- the IoT context because: (a) the security-relevant behavior 1NEST Protect is a smoke and carbon monoxide alarm. Wemo 2Other settings (e.g. drones, automotive IoT, autonomous vehicles, Insight Switch is a smart plug that monitors energy usage. Scout is process control systems) are outside the deployment scope we con- a next-generation home alarm. sider here as they entail different connectivity infrastructures. for IoT depends on environmental context which is missing tection and signature detection rules that need to be applied (e.g., a thermostat controlling the HVAC system is normal if in this specific case. By construction, this policy abstraction the user is present and anomalous otherwise); and (b) there is expressive and can capture the necessary environmental are potential cross-device interactions that impact security context and security-relevant context of the device, as well (e.g., policy for the smart oven depends on the state of the as cross-device interactions. fire alarm). To see this policy abstraction in action, let us revisit In the IoT domain, IF-This-Then-That (IFTTT) [7] is a our example in Figure 3, and formally specify the policy popular abstraction, supporting recipes such as “If smoke for each state. For instance, when the FireAlarm’s back- 3 emergency, set lights to red color” or “If Sighthound de- door is accessed , the state becomes S = {CFireAlarm = tects a person at home when I’m away set light to red suspicious,EFireAlarm ,CWindow ,EWindow }, then the pol- color” [7]. While these capture cross-device interactions, icy enforcement is to block any “open” message sent to the they have three fundamental security limitations. First, they window actuator to stop potential break in. do not capture the security-relevant context of devices (e.g., While this is an expressive abstraction, there are two ob- are these unpatched). Second, they assume recipes are in- vious open questions. First, with respect to the enforcement dependent, which can either lead to conflicts or safety viola- logic (Section 5), this brute-force enumeration may not be tions. For instance, in our example both the smoke alarm and practical as the number of devices and states scale. Second, the Sighthound rules could be active simultaneously leading the state explosion makes it difficult to check for potential to ambiguity. Third, it is tedious for users to reason about policy conflicts or correctness issues [33]. We believe that possible device interactions and their effects, leading to in- in practice it might be possible to prune and collapse this gi- complete specifications that can be exploited by an attacker. ant FSM by exploiting some domain-specific opportunities. 3.2 Proposed approach For example, if we know that two specific device types are inherently independent, or if the intended security posture is To address the limitations of the strawman solutions, we now the same for a set of similar states, then we can potentially sketch an expressive albeit “brute force” solution to capture prune the state space. the relevant environmental context, security-relevant con- text, and cross-device interactions. First, suppose we have D 4 Learning Security Policies networked IoT devices, and each D ∈ D has a security con- i At a high level, security detection and prevention systems text C , which can take one or more values (e.g., “normal” or i rely on two standard approaches: (1) detecting the signa- “suspicious” or “unpatched”). Second, suppose we have E tures of the attack and (2) detecting anomalous behaviors environmental variables (e.g., temperature, smoke, window), that deviate from normal activity. and each variable Ej ∈ E can take one or more discrete val- ues (e.g., Temperature=High/Low, Window=Open/Closed, In case of IoT, learning signatures using simple honeypot- Smoke=Yes/No). Now, we can represent the set of possible like mechanisms will not scale with the diversity of devices states S of the system in terms of these device contexts and and deployments — we would need several thousand hon- environmental variables. In the limiting case, the total num- eypots to ensure coverage for every specific device “SKU” Q as opposed to vendor or class of device (e.g., Google Nest ber of states is combinatorial; i.e., |S| = |Ci| × |Ej|. i,j version XYZ rather than “thermostat”). One potential av- enue is to extend prior work for decloaking environment- FW* * Window security*posture* specific malware that can support multiple modes of execu- tion [23]. However, we expect the scale and diversity of IoT state* FireAlarm:*