VISCR: Intuitive & Conflict-free Automation for Securing the Dynamic Consumer IoT Infrastructures

TL;DR

VISCR is a vendor-independent engine that simplifies and secures IoT automation by translating heterogeneous policies into a conflict-free, graph-based system, detecting violations, and proposing improvements efficiently.

Contribution

VISCR introduces a novel tree-based abstraction and graph translation approach for conflict-free policy enforcement in consumer IoT infrastructures, handling heterogeneous vendor specifications.

Findings

VISCR detected all known violations and uncovered new ones in a large IoT app dataset.

It significantly reduced analysis time compared to existing tools, enabling real-time policy updates.

VISCR effectively infers and proposes new policies for conflict resolution in IoT environments.

Abstract

Consumer IoT is characterized by heterogeneous devices with diverse functionality and programming interfaces. This lack of homogeneity makes the integration and security management of IoT infrastructures a daunting task for users and administrators. In this paper, we introduce VISCR, a Vendor-Independent policy Specification and Conflict Resolution engine that enables conflict-free policy specification and enforcement in IoT environments. VISCR converts the topology of the IoT infrastructure into a tree-based abstraction and translates existing policies from heterogeneous vendor-specific programming languages such as Groovy-based SmartThings, OpenHAB, IFTTT-based templates, and MUD-based profiles into a vendor-independent graph-based specification. Using the two, VISCR can automatically detect rouge policies, conflicts, and bugs for coherent automation. Upon detection, VISCR infers new policies and proposes them to users as alternatives to existing policies for fine-tuning and conflict-free enforcement. We evaluated VISCR using a dataset of 907 IoT apps, programmed using heterogeneous automation specifications in a simulated smart-building IoT infrastructure. In our experiments, among 907 IoT apps, VISCR exposed 342 of IoT apps as exhibiting one or more violations. VISCR detected 100% of violations reported by existing state-of-the-art tool, while detecting new types of violations in an additional 266 apps. In terms of performance, VISCR can generate 400 abstraction trees (used in specifying policies) with 100K leaf nodes in <1.2sec. In our experiments, VISCR took 80.7 seconds to analyze our infrastructure of 907 apps; a 14.2X reduction compared to the state-of-the-art. After the initial analysis, VISCR is capable of adopting new policies in sub-second latency to handle changes.

Tables

Table 1. Table 1 . Policy conflict examples in consumer IoT Infrastructures.

	Eco-system	Goal	Policy Intents of the IoT Administrator
P1	Campus	Safety, Privacy	Allow video feeds from camera to be sent to fire-safety admins in event of fire alarm.
P2	Campus	Security	Cameras for active monitoring is turned OFF between 9 PM and 7AM. Cameras are turned ON only when motion is detected.
Conflict: Policies P1 and P2 leads to potential security & safety violation in smart campus. When video feed is shared with fire-safety staff, the video feed is interrupted by the camera’s idle-time event which turns OFF the camera.
P3	Home	Safety	Between 10 PM and 7 AM open the main door to kids and guests only with authorized user’s approval (e.g., parents).
P4	Home	Safety	In case of a fire-alarm event, initially warn users, and then open the windows and doors to allow residents to exit safely.
Conflict: Concurrent activation of policies P3 and P4 in a smart home leads to a potential safety violation. In case of a fire alarm after 10 P.M., the IoT automation keeps the door locked due to policy P3, preventing kids from leaving and fire-safety officers from entering.

Table 2. Table 2 . List of keywords, attributes, operators and symbols used in VISCR policy specification syntax.

Type	Symbol	Definition
Policy specification keywords	location{}, devices{}, device-type{}, device-vendors{}, parent{}, traffic-type{}, source-node{}, target-node{}, source-state{}, target-state{}, etc.,	Keywords for capturing policy attributes and the properties of the IoT infrastructure.
Sequence & Precedence Operators	$>>$ (serial or precedence), $\left|\right|$ (parallel), $\to$ (flow / action sequence)	Operators to specify the sequence of operations to be carried out in policy.
Conditional Operators	$!$, $=$, , $>$	Operations used to specify dynamic conditions in the policy.
Composition Operators	policy-add ($+$), policy-remove ($-$)	Operators for adding and removing policies from the existing list of policies.
Action attributes / Keywords	iot-commands-action, $=>$ (ALLOW), $!=>$ (DENY)	Attributes or keywords used to specify the actions to be taken in the policies.

Table 3. Table 3 . Example list of Smart building policies ( S 1 subscript 𝑆 1 S_{1} - S 16 subscript 𝑆 16 S_{16} ).

Policies	Smart Building Policy Description
$S_1$	Any time fire is detected, turn on sprinklers and cameras, and shut down all locks (doors and windows)
$S_2$	Any time water leak is detected on office walls, cut the water supply
$S_3$	From 10PM to 7AM keep the outer doors and windows locked
$S_4$	From 6PM to 11PM keep the bedroom1 window unlocked or open
$S_5$	From 8PM to 9PM set the thermostat to 65∘F in bedrooms (kid)
$S_6$	Between 6PM to 10PM (i.e., till 11PM) keep the main doors unlocked
$S_7$	If main doors and windows are open for more than 5 minutes, turn OFF the heating/cooling in that room to prevent energy wastage
$S_8$	If motion is detected then turn the camera ON
$S_9$	If outside humidity is 40% and $>$50%, make sure outer doors and windows are locked while maintaining humidity between 40 – 50% inside.
$S_{10}$	When outside temperature is between 60-75∘F open the windows and turn OFF cooling
$S_{11}$	From 10PM to 7AM if any of the outer doors and windows are unlocked, trigger the alarm and SMS notify
$S_{12}$	From 9AM to 9PM set the thermostat to 74∘F (parent)
$S_{13}$	Turn bedroom II Camera OFF (or no access) after 10PM (kid)
$S_{14}$	If building temperature rises above 95∘F, lock all windows and reset the thermostat to 65∘F
$S_{15}$	In case of rain and humidity 40% and $>$50% close the windows
$S_{16}$	Keep Camera ON in all rooms and access to it at any time (parent)

Table 4. Table 4 . Smart building conflicts, bugs and violations detected by VISCR . For simplicity few conflicts are reported for the policies described in Table 3 .

Policy Conflict	Conflict Description	Conflict Type
$S_1$, $S_2$	An incident where fire is detected by smoke alarm ($S_1$), sprinkler is triggered this can be flagged as a water leakage ($S_2$), which results is cutting down water supply interrupting functionality of sprinkler. Thus, resulting in a fire spread.	Static
$S_1$, $S_3$	When fire is detected between 10PM and 7AM by smoke alarm ($S_1$), all doors and windows are unlocked (open). With $S_3$ both exterior door and all windows must be locked (close) during this time. This can result in exterior doors and windows toggling from locked or unlocked resulting in unintended behavior.	Static, Loops
$S_1$, $S_{14}$	If temperature raises above 90∘F, it will enforce that all windows must be locked and thermostat be set to 65∘F ($S_{14}$). Conflicts with temperature raised due to fire event ($S_1$).	Static
$S_9$, $S_{10}$	With overlapping state between $S_9$ and $S_{10}$, i.e, it’s humid and also temperature is between 60-82∘F, in such situation windows can toggle between locked and unlocked.	Static
$S_5$, $S_6$, $S_7$	Between 7PM and 9PM the outer door and windows are locked, thus trigger for both $S_5$ and $S_7$ are valid as a result system will toggle between turning off thermostat and setting it to 65∘F. Similarly, $S_6$ can further intervene due to time overlap and can result in chain and again forming a loop.	Chain, Loop
$S_7$, $S_{10}$	When temperature outside is 60 – 75∘F, $S_{10}$ opens the windows, which can possibly trigger $S_7$ given exterior doors are unlocked too. This policy chaining might result in unintended temperature conditions inside home.	Chain
$S_3$, $S_4$	Rogue behaviour as $S_3$ is set by parent and $S_4$ is set by a kid for a bedroom1 window’s opening.	Rogue
$S_5$, $S_{12}$	Rogue behaviour as $S_{12}$ is set by admin1 (or parent) and $S_{13}$ is set by admin2 (or kid) on bedroom1 in setting thermostat.	Rogue
$S_{13}$, $S_{16}$	Rogue behaviour as $S_{13}$ is set by parent and $S_{16}$ set by kid in accessing kid’s room Camera after 10PM.	Rogue
$S_5$, $S_{12}$	Gap in automation between 9PM – 9AM, where thermostat condition is not specified and conflict during 8PM – 9PM.	Gap, Static
$S_{14}$	Gap as condition is not specified for temperature less than 95∘F (i.e., between 74∘F to 95∘F).	Gap
$S_{10}$, $S_{15}$	When it is both raining and temperature between 60 – 75∘F, conflicting actions arise i.e., undecidable if windows should be opened or closed	Potential Violation

Table 5. Table 5 . Bugs and Violations detected on smart building IoT infrastructure dataset DS-1 . % of policy violations and bugs along with the

Security Analysis	% IoT App Violations	% False Positives
Compile time conflicts	6.6	0
Potential run-time violations	7.9	1.8
Gap analysis	10.4	1.3
Rogue Policies	3.8	0
Access violations	1.6	0
App sanity checker (SC)	4.2	0.7
Loops & chains	3.2	0
Overall	37.7	3.8

Equations

$$\text{Minimize }A\text{ subject to: }A\ge K_i\forall i=1,\dots ,N.$$

Full text

††copyright: none

1. Introduction

The adoption of the Internet of Things (IoT) has led to an explosion in the number of devices integrated into consumer IoT infrastructures (e.g., “smart homes”, “smart campus”, and “smart cities”)  (gartner-future-smart-home, ; gartner_2020, ). The heterogeneity of these infrastructures poses two major challenges in developing and enforcing policies across them:

• $(1)$

Coherent Policy Expression: Today, IoT device vendors support web and mobile-based apps, wide range of IoT automation frameworks, and specification languages (openhab, ; apple_iot_homekit, ; groovy_smartthingsapps, ; mud_spec, ; decouple_ifttt, ) that allow users and administrators to program their IoT infrastructures. However, directly capturing the high-level automation (or policy) intent of IoT administrators, using these vendor-specific IoT apps, is a challenging task as it requires administrators of the IoT infrastructure to manually decompose their high-level intents into device-specific rules prior to installation onto IoT infrastructures.

• $(2)$

Conflict-free Enforcement: Consumer IoT infrastructures are programmed by multiple administrators having complex roles and varying levels of skill, which may include novice smart-home users (e.g., parents, kids), smart-campus or smart-city administrators (e.g., HVAC admins, fire-safety admins). Configuring conflict-free automation in such multi-administrative environments is a tedious process.

Recent studies independently underscore the need for new access control and policy frameworks to address specifically the security goals of IoT ecosystem (rethink_acls_iot, ; soteria, ; celikiotguard, ). These solutions are designed to identify violations in IoT device ecosystems with homogeneous programming specifications, which does not apply to contemporary consumer IoT deployments that commonly involve devices using diverse vendor-specific APIs and heterogeneous programming specifications. Furthermore, existing tools either rely on model checking for static analysis of IoT automation programs to detect the conflicts (soteria, ), or require IoT automation code to be instrumented for detecting run-time violations (celikiotguard, ). Existing tools and techniques also leave a wide spectrum of automation bugs and conflicts undetected. For example, gap in automation due to lack of expertise among administrators, rogue policies on infrastructures that the user does not control, violations that might arise due to loops among automation rules, and other potential run-time violations are some of the key issues left unaddressed by the existing automation frameworks (discussed in §5).

In this paper, we introduce “VISCR”, a new intent-based IoT policy automation framework. For effectively accommodating the automation rules and policies that are specified in the existing IoT infrastructure using heterogeneous programming specification languages, VISCR builds vendor-independent graph-based specification model. VISCR translates the IoT automation programs specified using groovy-based programs for smarthings (groovy_smartthingsapps, ), OpenHAB-based rules (openhab, ), MUD-profiles (mud_spec, ) and IFTTT-based applets (decouple_ifttt, ) into vendor-independent graph-based specifications (§ 4.1). In addition, VISCR allows administrators of an IoT infrastructure to directly and succinctly capture their dynamic automation use-cases and policy intents in a vendor-independent manner using simple and intuitive graph-based abstractions and specification mechanism (§ 4.3). VISCR uses these graphs to detect bugs and conflicts across policies that could otherwise go undetected using existing model checking-based tools (soteria, ; celikiotguard, ). These include: ($a$) static compile-time conflicts, ($b$) gap in the automation, ($c$) conflicts due to loops among automation rules, ($d$) code sanity bugs, ($e$) access violations, and ($f$) rogue policies.

VISCR supports PRECEDENCE operator, for automatically resolving the conflicts, while unresolved conflicts are forwarded to appropriate IoT users or administrators for manual resolution. The policy reconciliation engine decomposes the composed conflict-free policy graph into set of device-specific rules for enforcement onto actual devices (e.g., IoT devices, IoT Gateways) as IoT apps and ACL rules. In addition, VISCR infers new policy and propose it to IoT users for fine-tuning the existing policies, while addressing the security and safety violations that arise among the policies (§5.3.4). We evaluate VISCR on a simulated smart-building IoT infrastructure with 907 apps. VISCR detected a wide range of bugs i.e., $\approx$37.7% of IoT apps are reported for one or more conflicts and bugs compared to $\approx$8.4% of static compile-time conflicts detected with existing model checking-based tool (soteria, ) while incurring less than 3.8% false positives. We discuss the resultant conflicts and bugs detected by VISCR and their categories in §6.

In summary, our paper makes the following key contributions:

• $\bullet$

We design VISCR, a vendor-independent graph-based policy specification mechanism that translates automation rules and policies specified using heterogeneous programming specification languages into vendor-independent graph-based policies. We carry out security analysis of VISCR to evaluate the code sanity and detect bugs present in the code. We develop intuitive policy specification mechanism using tree-based abstractions that allows users to directly capture the vendor-independent graph-based policies for automation and policy specification (§4).

• $\bullet$

VISCR detects bugs and conflicts that arise among the policies represented in vendor-independent graph-based specification and resolve them using PRECEDENCE operation for conflict-free enforcement. We developed techniques to automatically infer new policies for proposing it to user for fine-tuning the existing rules (§5).

• $\bullet$

We evaluate VISCR using 907 IoT apps (i.e., both vetted and unvetted) in a simulated smart building infrastructure with real world automation use cases reported by IoT users and administrators in their IoT infrastructures and compare with existing techniques (§6).

2. Background and Motivation

A wide variety of automation frameworks and specification languages are supported by vendors for automating IoT infrastructures (groovy_smartthingsapps, ; openhab, ; apple_iot_homekit, ; decouple_ifttt, ; mud_spec, ). Such heterogeneity makes programming the IoT infrastructure a challenging task.

In addition, the presence of multiple administrators111For example, the smart home automation rules and policies are specified by the members of the family (e.g., parents, kids, guests), while smart campus and enterprise IoT infrastructures are managed by different types of IoT administrators such as HVAC, fire-safety, utilities & energy, and infrastructure (or building) administrators. in IoT infrastructures with different roles & responsibilities further complicates the situation resulting in conflicts and errors among IoT infrastructure automation. Hence, the heterogeneity, and lack of a unified policy-specification in multi-administrative IoT infrastructures forces administrators to independently develop automation policies and exchange their policies offline. Such independently-developed policies, which are often exchanged offline are manually inspected for detecting the conflicts and violations. For effectively automating the IoT infrastructures and governing the communication among its devices following policies are required:

Trigger- & Action-based Rules: Automation rules that allow the administrator to specify policies on a set of devices that perform some action in response to an event (e.g., ). Example of programming specification mechanisms used for these type of policies includes SmartThings Groovy-based rules (groovy_smartthingsapps, ), OpenHAB-based rules (openhab, ), IFTTT-based applets (decouple_ifttt, ), and Apple HomeKit (apple_iot_homekit_swift, ).

ACL-based Policies: ACL-based policies restrict the type of communication the IoT devices are permitted, during normal and abnormal states, within the IoT ecosystem. Examples include MUD-based profiles (mud_spec, ) and traditional IP-based filtering rules.

2.1. Intuitive Policy Specification

IoT infrastructures are typically managed by multiple administrators, each of them responsible for the management of a specific group of devices. For effectively capturing policy intents from multiple administrators, a policy framework should support following capabilities: ($i$) Ability to logically group devices in accordance with the policy requirements of each of the administrator. For example, the IoT administrators handling cameras of BLDG1 and BLDG2 of the campus network should have abstractions that logically group the devices belonging to those locations; ($ii$) Provide isolation among administrators while exposing only the necessary abstractions required for policy specification avoiding rogue policies from being specified. For example, a fire-safety administrator should not be exposed to other IoT infrastructure details (e.g., cameras, HVACs etc.) unless cross-device policy specification is required.

Currently, it is challenging to provide logical isolation across different policy administrators and the devices they administer, which motivates the need for fine-grained abstractions and logical grouping of IoT devices as shown in Figure 6. Similarly, as shown in Figure 1, using heterogeneous automation specification languages in the IoT infrastructures is prone to errors due to administrator’s lack of expertise in programming (openhab_missing_quotes, ; openhab_missing_if_braces, ; smartthings_errors_community, ; ifttt_errors_community, ; applehomekit_errors_community, ).

$\blacksquare$ Research Goal: The aforementioned challenges motivate the need for an intuitive graph-based specification mechanism that is vendor-independent and allows IoT administrators to easily capture their policy intents while avoiding the steep learning curves with existing automation specification languages.

2.2. Conflict Detection & Resolution

Policy intents of an IoT administrator are implemented using discrete automation rules configured onto each device using the mobile or web-based user interfaces, and automation specification languages (groovy_smartthingsapps, ; openhab, ; mud_spec, ; samsung_ifttt, ). The existing consumer IoT ecosystem lacks means to effectively detect the conflicts, bugs and violations that arise among the policies (i.e., captured independently by each of the administrators using heterogeneous specification languages) and reconcile them onto each of the IoT devices.

Recent studies have demonstrated that major vulnerabilities in the IoT infrastructure are commonly due to simple human errors and lack of expertise in policy configuration (iot_vulnerability1, ; iot_vulnerability2, ; openhab_missing_quotes, ; openhab_missing_if_braces, ). As highlighted in Table 1 & Table 4, there are range of automation bugs, policy conflicts and violations (e.g., gap in automation, potential run-time conflicts, and code sanity bugs) that could go undetected with existing conflict detection techniques (celikiotguard, ; soteria, ; pga_sigcomm15, ). Let us consider following policy conflicts:

Policy Conflict 1: Consider for example two policies P3 and P4 with conflicting actions in opening main door (Table 1). In case of a fire alarm after 10 P.M., (both policies P3 and P4 are activated) the current IoT automation keeps the door locked due to policy P3, preventing users from leaving and fire-safety officers from entering. Proactively detecting such conflicting actions resulting in safety violations in compile-time is a challenging task.

Policy Conflict 2: As shown in Table 1, policies P1 and P2 result in run-time violation. When video feed is shared with fire-safety staff, the video feed is interrupted by the camera’s idle-time event which turns OFF the camera interrupting the video feed from being shared, leading to safety violations. A major concern with such policies is that they are activated in response to an event received from one or more sensors. Such violations are difficult to be proactively detected and resolved in compile-time as the asynchronous inactivity counter is triggered, which depends on environmental conditions, (i.e., time and motion sensing).

$\blacksquare$ Research Goal: The aforementioned examples demonstrate the need for collaboration across administrators of IoT infrastructures for charting out their policies and manually resolving conflicts that arise among their policies before enforcing them onto the IoT infrastructure. Thus, a fundamental requirement for any IoT-based policy framework is to effectively handle the dynamic characteristics of IoT infrastructure, automatically adapt to such dynamic changes and enforce a new set of policies by proactively detecting and resolving conflicts that might arise at run-time.

3. VISCR System Design

To address the limitations of existing IoT automation and policy framework, we make case for unified intent-based policy framework that provides vendor-independent policy specification and conflict-free policy enforcement mechanisms for IoT infrastructures.

3.1. Overview

As shown in Figure 2, the automation rules captured using various vendor-specific automation and policy specification languages (groovy_smartthingsapps, ; decouple_ifttt, ; openhab, ; mud_spec, ) are provided as input to the code sanity and graph generation module ( 2 ). As a first step, VISCR analyses IoT automation programs to detect sanity bugs present in it (Section 4.2). After the initial sanity analysis is performed, VISCR translates the IoT programs (i.e., specified using heterogeneous specification languages) into vendor-independent graph-based specifications. VISCR maintains mapping between the IoT programs, associated device configurations, and graph-based policies as policy mappings, which is used in policy enforcement i.e., for reconciling composed policy graph to device-specific rules, as discussed in Section 5.3.4.

For translation of vendor-specific automation rules to vendor-independent graph-based policies we have built necessary lexing and parsing grammar (.g4), and mapping (.map) files specific to each of the automation specification language with ANTLR (§4.1).

To enhance usability of our policy framework, VISCR also supports a graph-based policy specification user interface ( 3 ) i.e., with simple drag-and-drop option to input policy entities using the tree-based infrastructure abstractions supplied to each of the administrator. This allows IoT users and administrators to easily and intuitively capture their policy intents in a vendor-independent manner without any need to learn multiple IoT automation programming languages. The IoT infrastructure details (i.e., tree-based IoT infrastructure abstractions) necessary for specifying the policies are automatically derived from the existing IoT infrastructure and its cloud data sources ( 1 ).

In the next step, these vendor-independent graph-based policies (from
2 &
3 ) are supplied as input to the vendor-independent conflict detection and resolution engine (VICE) for detecting conflicts, violations and bugs among them these policies. Especially, VICE detects rogue policies ( 4 ) that are configured by policy administrators who are not authorized to specify automation rules or policies on any specific portion of the IoT infrastructure (Section 4.3.2). Further, in the next step the policies that are detected for rogue policies are provided as input the policy composition engine (i.e., conflict detection and resolution engine
5 ), as shown in Figure 3. Policy composition engine uses precedence mechanism for automatically resolving the conflicts among the policies. Unresolved conflicts and bugs are reported to the administrators of IoT infrastructure for manual resolution.

The composition engine send the composed policy graph to the security analysis module for further inspection of violations ( 6 ), which detects following types of conflicts and bugs among the policies that makes infrastructure vulnerable and prone to errors (Section 5.3): ($i$) gap in the automation that could make infrastructure vulnerable, ($ii$) loops that exist among automation rules, ($iii$) access violations, and ($iv$) potential conflicts that could arise in run-time.

The VISCR’s policy inference engine ( 7 ) automatically infers policies specific to each of the conflicts and propose it to users for fine-tuning the existing policies (Section 5.3.4). The policies that are fine-tuned are once again composed for detecting the conflicts ( 4 ). Finally, the identified composed conflict-free policy graphs, and policy mappings are sent to the policy reconciliation module ( 8 ) for enforcing the policies as device-specific rules. Finally, the vendor-specific configurations and reconciled IoT apps are generated as outcome of the reconciliation module for installing conflict-free rules on to the IoT infrastructure.

3.2. Usage Scenario & Threat Model

VISCR’s intended use is within consumer IoT infrastructures, which includes smart home, smart campus, smart city IoT infrastructures, and enterprise networks. Though, the VISCR’s architecture is generic enough to accommodate Industrial IoT, but it is out of scope considering different use case scenarios and requirements in industrial ecosystem. VISCR aims to proactively reduce the conflicts among policies, violations and bugs that arise in automating the IoT infrastructures. VISCR provides necessary isolation across users or administrators by delegating their roles and responsibilities through supply of dedicated Infrastructure abstraction tress, through which the policies could be specified. In case of conflicts that arise among the policies of different administrators the policies are enforced only after the resolution is made and according to the precedence of its administrators. VISCR’s policy inference mechanism proposes new policies that allows users or administrators to fine-tune their IoT ecosystem or resolve the bugs that exist among its policies. The firmware bugs and vulnerabilities are out of scope of this work.

Under this usage scenario, we adopt simple and realistic threat model. We trust the IoT devices and its firmware. Hence, we assume that the IoT administrators or users are either novice or could be malicious. We expect skilled administrators can craft policies that could make network vulnerable. Similarly, the novice user’s lack of skills could result in IoT infrastructure automation that might result in gap in the automation, which could make network vulnerable. Our threat model considers the conflicts that arise in IoT infrastructures programmed using following programming specification languages such as IFTTT-based Applets, Groovy-based SmartThings, OpenHAB programs and MUD-profiles. Other programming specifications such as Apple HomeKit and other programming specifications are out of scope and will be supported by the VISCR framework as part of its future work.

In our threat model, we assume that a subset of IoT users and administrators who program the IoT ecosystem could be malicious. We attempt to address issues that arise from flaws in the implementation of IoT programs as well as vulnerabilities introduced by malicious users. VISCR proposes to use pessimistic approach by which administrators can program for safety policies from specific users and for specific set of devices and their capabilities are given higher precedence compared to security and privacy policies of others. Though the precedence is completely programmable, but, it solely depends on users ability to correctly use it, which could at times mask the conflicts. Hence, precedence operator need to be used diligently by administrators for auto-resolving the conflicts that are detected by VISCR, which could otherwise be safely resolved manually by users.

4. VI Specification & IoT App Analysis

Realizing coherent automation in existing IoT infrastructures that uses heterogeneous specification languages (i.e., multiple automation frameworks) is a challenging task, which requires administrators to analyze each of the IoT Apps for detecting the conflicts and bugs for manually resolving them. The whole procedure of manually detecting conflicts and resolving them is a tedious process and could be prone to error. Hence, we propose a vendor-independent specification engine (VISCR) that serves following key purpose: ($i$) Translates IoT automation programs and policies specified using Groovy, IFTTT, MUD, and OpenHAB-based programs into a vendor-independent graph-based specification, and ($ii$) Analyzes the IoT Apps for its sanity.

4.1. Vendor-Independent Model

As illustrated in Figure 2, Code sanity and Graph generator module of VISCR engine consumes vendor-specific IoT Apps (i.e., IFTTT-based Applets, Groovy-based SmartThings, OpenHAB programs) and translate them into vendor-independent trigger and action-based policies (as shown in Figure 7(a)). Similarly, the MUD profiles222Currently MUD-profiles are limited to support ACL-based traffic filtering rules. It does not support dynamic trigger and action-based policies yet. and translated into vendor-independent graph-based ACL policies (as shown in Figure 7(b)). This approach allows each of the functional component of VISCR i.e., composition engine to operate seamlessly on vendor-independent (VI) model. As shown in Figure 4, VISCR generates the vendor-independent (VI) graph-based policies using following key functional modules:

• $\bullet$

ANTLR parser generator: As a first step, we develop the lexer and parser grammar (.g4) files required to translate the vendor-specific IoT apps to an abstracted intermediate representation (i.e., Abstracted LISP Representation (ALR) and Abstracted Tree Representation (ATR) formats) with ANTLR module. ANTLR parser generator uses the Abstracted LISP representations (ALR) of the IoT Apps for performing the code sanity analysis (discussed in Section 4.2). Note, both the ALR and the ATR representations of IoT apps are not exposed to end users, only the outcome of VI graph generator ( 2 ) will be exposed to users and composition engine.

• $\bullet$

VI Graph generator: In the next step, automation rules represented in the Abstracted LISP syntax representation are consumed by the VI Graph-generator module to translate it to vendor-independent graph-based policies (as shown in Figure 5). We built (.map) file, which is used for maintain necessary mappings between different vendor-specific automation/policy attributes and vendor-independent graph attributes. These vendor-independent attributes (or labels) are used in the construction of final vendor-independent graph-based representation. The vendor-independent graph-based specifications outcome of VISCR ( 2 ) is captured using networkx python library for maintaining the policy graphs, required for composing the policy graphs to detect the conflicts (discussed in Section 5).

4.2. Code Sanity Analysis

Currently, IoT administrators use both the vetted and unvetted IoT apps from the market place and customize them to cater their specific automation needs. Though, Groovy-based SmartThings market apps are heavily vetted for sanity, but still there wide range of unvetted SmartThings apps that are available online for use. Directly customizing the IoT apps without effectively analyzing them or testing could lead to incoherent automation. This problem is also highly prevalent with other programming specifications such as OpenHAB and IFTTT.

The most prominent code sanity bugs that are reported today could include – Undefined & Unused variables and structures, improper If/Else closures, missing quotes, and empty If/Else blocks, and empty definition, which VISCR verifies for. For example (as shown in Figure 1), OpenHAB automation framework allows IoT programs to reference undefined variables and functions, and similarly not reference to the variables and functions that are defined in the IoT app. Though, in both the cases OpenHAB automation framework allowed IoT programs to run successfully with out reporting any compile time errors, but resulted in run-time violation or device misbehavior (openhab_missing_quotes, ; openhab_missing_if_braces, ). Other code sanity bugs that leaves IoT infrastructure vulnerable are illustrated in Figure 1. In these examples, the IoT devices are not allowed to execute action “or” did not allow the device to transition to new state, which could lead to either safety or security vulnerability in the IoT infrastructure (as highlighted in Figure 1).

VISCR detects such code sanity bugs using the ALRs provided by the ANTLR parser generator module i.e., before giving it as input to the VI graph generator module). In case of the defined-but-unreferenced variables and functions, they are reported as less severe bugs as they do not break the functional capability of the IoT infrastructure. Similarly, the Undefined-but-referenced variables and functions, and empty if blocks are reported as critical bugs by the VISCR engine as these bugs could leave gap in the automation making IoT infrastructure vulnerable.

Similarly, there are other code sanity bugs, such as improper closures in which either the if and/or else conditions are not properly closed, such improper termination of code blocks leads to unexpected code flows leading to device misbehaving. For example, missing quotes (”), and missing braces (}) as highlighted in the Figure 1 are commonly seen issues with OpenHAB and Groovy-based IoT apps, while these issues are not captured during compile time leading to run-time violations and IoT program malfunction (openhab_missing_quotes, ; openhab_missing_if_braces, ). The code sanity and the bug severity assigned to each of the IoT apps are used in later stage to further detect the potential run-time violations present in the IoT apps (discussed in Section 5.3).

4.3. Infrastructure Abstractions & Graph-based Specification

As discussed in Section 4.1, VISCR supports mechanism to translate the vendor-specific IoT Apps into vendor-independent graph-based specification. In addition, VISCR also supports simple drag and drop-based user interface that allows administrators to directly and intuitively capture their policies in a vendor-agnostic manner using nodes of infrastructure abstraction trees, as discussed below.

4.3.1. Tree-based Abstractions

The Infrastructure abstraction engine automatically builds necessary abstraction trees required for graph-based policy specification. The abstraction engine continuously churns data from local IoT infrastructure and cloud data sources of IoT devices using device and vendor-specific APIs for building the abstractions (nest_iot_cloud_apis, ; samsung_iot_cloud_apis, ). The data extracted from IoT device’s data sources as text and log messages are translated into data tables by the data-source-driver engine that we designed for each vendor’s data format.

Generation of such abstractions allow administrators to delegate the responsibility of policy specification to sub-administrators. For example, it is now possible for a global building/campus administrator to assign Floor1 and Floor2 responsibilities to different sub-administrators. Also, VISCR allows abstraction trees to be built on physical or logical grouping of device (e.g., Figure: 6(a) & 6(b)). The global administrator simply uses abstraction mappings to delegate infrastructure to each of the administrator. Depending on the assigned abstraction mappings the abstraction engine generates the abstraction trees. For example, to derive the abstraction tree shown in Figure 6(a) (i.e., list of Nest devices of BLDG1 with firmware $<$17.01 organized as per floor and type of devices), the abstraction-mapping required is:

abstraction-tree{"Nest-Firmware{<17.01}"} = location{BLDG1}.floors{}: vendor-type{Nest}.device-category{}: devices{*}

Similarly, for capturing the list of devices and their capabilities with respect to their vendor and device-types in an abstraction tree (Figure 6(b)), required abstraction-mapping is:

abstraction-tree{"Capabilities{}"} = vendor-type{}: vendor-type{}.device-category{}: devices{}: capabilities{}

Representation of Abstractions: We represent IoT infrastructure as set of infrastructure-abstraction trees, specific to each of the administrators. The root node of the abstraction tree (i.e., abstraction tree name) uniquely represents each of the abstraction tree present inside the IoT ecosystem. The leaf nodes represents set of individual devices. Each intermediate node represents different infrastructure abstractions such as device types, device vendors, location, temporal, application details. The infrastructure abstractions trees implicitly capture the boolean Union operator represented as sibling nodes in the abstraction tree. Similarly, the boolean AND operator corresponds to the relationship between the child and parent nodes of the abstraction tree. For representation, each level of abstraction is separated with “:” operator, while the constraints and conditions to be imposed on to that level is represented with a “.” operator.

VISCR supports a diverse set of abstractions, which will allow IoT administrators to capture different types of policies based on their security status, locations, vendor-type and so on. These include: ($i$) security-state abstractions, ($ii$) location-specific abstractions, ($iii$) device- or vendor-specific abstractions, and ($iv$) application-specific abstractions. Such tree-based abstractions allow administrators to intuitively capture their automation and policy requirements.

4.3.2. Graph-based Specification

As discussed in Section 4.1, VISCR engine translates the vendor-specific IoT Apps into two different types of policies: ($i$) trigger- and action-based policies, and ($ii$) dynamic ACL-based policies. In addition to this capability, VISCR also supports intuitive graph-based specification framework that allows IoT administrators to directly express their policy intents through simple drag and drop-based user interface (UI), which uses policy attributes from tree-based abstractions.

Trigger- & Action-based Policies: The trigger & action-based policies allows the administrator to capture their policy intents for set of IoT devices that perform some predefined action in response to an triggering event. Examples of such policies represented as graph-based policies are illustrated in Figure 7(a). These types of policies can be specified as complex graph-based policies or finite state automation (FSM), where each of the node captures abstractions, device names, conditions or actions. Our trigger- and action-based policy graphs have the following format: source IoT device with associated states, set of conditions, dynamic states, associated set of events and respective action/s on target IoT devices.

The source node represents the IoT device on which the event is received. Rest of the nodes represent conditions and state of the IoT infrastructure, except for nodes that have incoming edge with sequential ($>>$) and parallel ($||$) action operators associated with them. The sequential and parallel operators $>>$ and $||$ are used to specify the sequence of IoT-commands that need to be executed. The $+/-$ operators are used to add or remove the list of ACLs that are specific to the current state or condition.

ACL-based Policies: This type of policies either allows or restricts the communication between devices and internet according to the dynamic infrastructure states and conditions. Examples of graph-based access control policies are shown in Figure 7(b). For the trigger and action-based policy shown in Figure 7(a), we implicitly add ACLs to ALLOW traffic between Belkin CO device and other devices on which the action is enforced (i.e., Camera, Water heater, Windows, Exhaust). In reality, as the communication happens indirectly between the hub or cloud interface and the Belkin device, equivalent ACLs are added to the network.

The starting and end nodes represents the source and destination entities of policies. The edge between the source and target node captures following properties: ($i$) set of network functions through which the traffic should traverse, i.e., network function chain (NFC), ($ii$) conditions to be enforced on the traffic depending on the state, and ($iii$) actions to be taken on the traffic between the source and destination entities. With both the ACLs and trigger-action-based policies, the states and conditions are represented as nodes along the path for simplified design in the drag-and-drop-based graph specification framework. Alternatively, these could be represented as simple edge properties. The $\,\to\,$ and $-$x$\,\to\,$ arrowed-lines represents the action (i.e., ALLOW/DENY) on the traffic. The specification syntax, keywords, attributes, symbols and operators used by VISCR for processing the graph-based policies i.e., ACL-based policies and trigger and action-based policies are discussed in Section 4.3.3.

4.3.3. Graph-based Policies Specification Syntax

An equivalent specification syntax is required for capturing each of these graph-based policies in the backend. For example, in the ACL-based policy specification syntax, the permissions to communicate between source and target nodes is specified using action attributes $=>$ (i.e., ALLOW) and $!=>$ (i.e., DENY) symbols. The sequence of network functions through which the traffic from a specific source node should traverse to reach the target node or the sequence of actions to be taken is specified using the sequential or parallel operators (e.g., Firewall $>>$ DPI, FW $||$ LB, Exhaust$=$ON $>>$ ExhaustSpeed$=$High). Note that the sequence and parallel operators are used for traversal of a set of middleboxes in the case of ACL-based policies. In case of trigger-action-based policies, it is used to represent the sequence of actions. Also, in the trigger-action-based policy specification syntax, actions are captured using the iot-commands-action keyword.

VISCR allows duplicate node names to be captured as part of same or different policy abstraction trees, which could lead to discrepancies when policies are specified using these nodes. To overcome this problem, we maintain the root nodes names of policy abstraction trees be unique across the IoT infrastructure. We use the “parent” keyword to uniquely identical nodes across different abstraction trees. The $\,\to\,$ operator is used with parent to define the path of the source entity from its parent. For example, following reserved keywords are used to group set of devices device-types{“Cameras”}, vendor-types{“Nest”}, location{“BLDG1$\,\to\,$Floor1”}, and smoke_co_alarm_state {“emergency”}. Other keywords, operators, and symbols used in VISCR are listed in Table 2. For the trigger and action-based illustrated in Figure 7(a) the equivalent syntax is shown in Figure 8(a). Similarly, for the ACL-based policies illustrated in Figure 7(b), the equivalent policy specification syntax is shown in the Figure 8(b).

5. Graph Composition & Security Analysis

Manually detecting and effectively resolving the compile-time conflicts and run-time violations among automation policies even in small-scale IoT deployments is an arduous and error-prone process. Hence, VISCR effectively addresses this challenge in this section.

5.1. Rogue policies

VISCR’s abstraction trees and graph-based specification allows the administrators to specify the policies explicitly using the abstraction trees exposed to each of the IoT users or administrators. This approach of isolating and assigning explicit infrastructure abstractions to each admin, allows VISCR to prevent admins from specifying policies on the infrastructure they do not own. However, it should be noted that the policies that are directly specified using policy abstraction syntax (as discussed in Section 4.3.3) i.e., bypassing the web-based user interface provided by graph-based policy specification is also detected for rogue policies by the policy composition engine and updated to the administrators as violations.

For detecting rogue policies in syntax-based policy specification, the policy composition engine extracts the source and target nodes from the specified policy specification syntax and verifies if both the nodes belongs to the policy abstraction trees owned by that administrator. If the policy attributes used in the policy specification are part of the abstraction trees assigned to that admin, then the policies are allowed to perform actual policy composition to further detect other conflicts and violations (discussed in Section 5.3). The policies violating this step is reported as rogue policies.

5.2. Graph-based Composition

The policy composition in VISCR seeks to provide the following capabilities: ($i$) proactive composition of policies for detecting conflicts in compile time rather than detecting at run time, ($ii$) automatic resolution of conflicts using precedence mechanism, and ($iii$) incremental composition that allows trigger-action policies to adapt to the environment at runtime. However, allowing run-time policy composition imposes stringent latency constraints. Hence, policy composition time has to be minimized.

VISCR’s policy composition procedure involves following key steps. First, the normalization step brings all the policies specified by various administrators, using different abstraction trees, to a common abstraction level for identification of contradictory and duplicate policies. The second step, finds contradictions among normalized policies by running composition engine and resolves the conflicts using precedence rules. Unresolved conflicts are flagged to the administrator.

5.2.1. Proactive & Incremental Composition

The goal of policy composition mechanism is to produce conflict-free composed policy graph (example shown in Figure 9) that is derived by composing together overall vendor-independent graph-based policies (i.e., either generated from IoT apps or specified directly by policy administrators). In the final composed graph, the source and target entities represent the devices or group of devices onto which policies are executed. The edges capture the set of conditions for policy activation and the corresponding actions.

As a first step of policy composition, VISCR’s normalization mechanism identifies the common abstraction level to which all policies specified by administrators need to reduced for conflict detection. If policies are specified using abstraction nodes at different levels of an abstraction tree, composing policies without normalization is an infeasible task. For example, consider two policies specified using the abstractions BLDG1 and Floor2 (homogeneous abstractions) or using BLDG1 and NestCams (heterogeneous abstractions). Here, we do not know if the Floor1 node and Nest node have any relation (i.e., subset, superset, or overlapping hosts or devices) for composing them together into a single policy graph. We resolve this issue by ($a$) automatically deriving relations across non-leaf nodes of different abstraction trees and maintain these relations as mappings i.e., capturing the details of set of devices or hosts that belongs to each of these nodes of abstraction trees, and ($b$) choosing an optimum level to which the nodes used in the policy specification need to be normalized.

Normalization: A naive normalization approach is to bring all the policies to the bottom most level, i.e. leaf node level which captures the device-specific details for performing composition. This approach increases complexity along two dimensions: ($i$) It brings down all policies to the bottom most level even though very small number of policies might need it, exponentially increasing the composition times, and ($ii$) normalizing all the source and destination policy nodes to bottom most level (i.e., to the level of leaf nodes) also increases the enforcement complexity, due to increase in the number of rules required to enforce the policies. Therefore, VISCR finds an intermediate level i.e., Enforcement Level (ELevel) for each policy abstraction tree for effectively normalizing the policies. The enforcement level (ELevel) is chosen in such a way it would allow the policy enforcement engine to directly compile/translate these composed policies to enforceable rules.

Mathematically, we represent the choice of enforcement level in the following way. Let $K_{i}$ be the abstraction level using which a policy $P_{i}(i=1,\ldots,N)$ is specified. Then, policy $P_{i}$ can be normalized any abstraction level $A_{i}\geq K_{i}$. Thus, we aim to normalize to a level $A$ such that $A\geq A_{i}\,\forall i=1,\ldots,N$. However, the number of nodes increases with an increase in $A_{i}$. Thus, our objective is to choose the minimum value of $A$ that satisfies the above set of constraints, i.e.

[TABLE]

Algorithm 1 describes the graph-composition algorithm, which accepts: ($i$) a list of graph-based policies that are normalized, and ($ii$) an empty graph as input, which is used for storing the composed policy graph. Each of the input policy is composed with the graph for conflict identification and resolution. The list of input policies are iteratively checked for an identical or conflicting policy. First each policy’s source node is compared with the source nodes of the composed policy graph. Next, the target node of the input policy is compared with the target nodes of the composed policy graph. Finally, the conditions and action attributes present along the edge of the input policy are compared with the edge attributes of the composed policy graph. In this process, the composed policy graph is updated with non-conflicting policy attributes.

The algorithm attempts to resolve conflicts by checking whether a precedence rules exists for any of the policies. Duplicate policies are tracked separately and discarded from composition. If it finds a conflicting policy that cannot be resolved with precedence, the policy is dropped from the graph (Lines 11-13) and notified to administrator. If it finds that the source node and the destination node both exist and no conflicts are possible, the policy is then added to the graph (Lines 14-16). Otherwise, it creates new nodes and then adds the policies as edges to the graph (Lines 17-23).

To analyze the algorithmic time complexity, we need to evaluate the cost of iterating over the complete list of policies ($L$), and adding them to the composed Graph $G$. With the addition of each policy to the composed policy graph $G$, the composition engine checks for the existence of conflicts. The major time complexity of the algorithm lies with the iteration of the policies O($L$) over the list of all source nodes $L_{s}$ in the composed graph $G$, and then comparing the policy’s source node $s(p)$ to composed graph’s source nodes $S(G)$. $L_{e}$ is the list of edges for which the edge-properties overlap with the policy’s edge among the overlapping source nodes. Also, $L_{t}$ is the list of target nodes of the edges of $s(p)$ that actually overlaps with the target node of the policy $p_{i}$. Therefore, the overall worst-case complexity is: $O(L*L_{s}*L_{e}*L_{t})$.

For reducing the composition complexity we employ hashing mechanism and caching technique: ($i$) the $m$ host entries of $s(p)$ are hashed as key-value pairs and the host entities of $S(G)$ are looked up in the hash for the existence of the $n$ hosts, reducing baseline complexity will be reduced to: $O(L*L_{s}*(m+n))$. ($ii$) caching the comparison calculation outcome as key-value pairs ($s(p)$:$S(G)$) in hash table reduces the overall baseline complexity to $O(L*L_{s})$.

5.2.2. Precedence

Precedence rules are used to resolve conflicts among competing policies specified at different levels. Administrator-level precedence evaluation is based on the scope of authority of the policy author. For example, a campus-level administrator in a smart campus may be granted precedence over a building administrator; Action-level precedence allows for explicit prioritization in action invocation. For example, for IoT traffic’s ACL-based policies, Drop $>$ Allow $>$ Quarantine $>$ Redirect can be used as the precedence hierarchy. Similarly, in the case of trigger-action-based policies, when the smoke detector is in fire-alarm state, the action turn OFF heating is given higher precedence than turn ON heating. Custom precedence enables policy attributes (e.g., user, device type, device state) to be associated with precedence.

When two policies (P1 and P2) conflict, the nodes and edges of the policies are decomposed into the set of subset nodes that requires the least number of edges to represent conflict-free policies (for optimizing the number of rules required for enforcement). Based on precedence, the overlapping nodes that result in conflict are removed and the edge specific to the policy with highest precedence is retained.

5.2.3. Incremental Updates

The dynamic characteristics of the consumer IoT infrastructure demand that the policy framework be agile in enforcing new set of rules to IoT devices. Since complete policy composition consumes time, up to a few minutes, efficient re-composition techniques are required for rapid policy response. Hence, we use incremental policy composition to ensure an expedient response to dynamic conflicts that arise in the network. The composition engine recomposes only the updated set of policies with the whole set of composed policies. Updating a policy from the composition graph involves first deleting the policy from the graph, and then inserting a modified version. Deleting a policy requires one to remove the edges that belong to the policy from graph. However, the composition procedure might have removed portions of other policies that had a higher precedence during conflict resolution. Hence, these lost portions must be returned.

Incremental policy composition reduces the time to react to dynamic state changes and enforce new rules under the following scenarios: ($i$) Scenario 1: New polices are added or removed from the IoT infrastructure; ($ii$) Scenario 2: IoT infrastructure changes (e.g., device location updates, new devices added or existing devices removed); and ($iii$) Scenario 3: IoT device-state changes (e.g., from normal to compromised). Also, for run-time composition VISCR enumerates all the possibilities to pre-calculate the possible outcomes. Hence, for run-time enforcement VISCR simply identifies the outcome specific to the event and simply executes it, which can be carried out in sub-second latency, much faster than incremental composition.

5.3. Security Analysis & Policy Enforcement

In this section, we describe about how we use the graph-based composed policy graph to perform security analysis for detecting the bugs and violations. We discuss about the conflict-free policy enforcement by reconciling policies to device-specific rules and automatic policy inference.

5.3.1. Gap Analysis

Gap in the automation could leave the IoT infrastructure in a state that is either unstable or unpredictable in its behavior. Such dangling state could make IoT infrastructures vulnerable to attacks. For example the policies $S_{5}$, $S_{12}$ and $S_{14}$ shows the gap in the automation with respect to its temporal and temperature conditions (as described in Table 4). It is evident from these policies that during 8PM –9PM (conflict) 9PM – 9AM (Gap) the thermostat’s temperature settings could not be effectively predicted. As listed in Table 4, similar automation gap could be visible in other types of policies specific to its spatial, security states and other environmental conditions. Therefore, identifying the gap in automation is key step towards detecting the potential bugs that might arise in the IoT infrastructure during run-time.

The VICE module traverses through the final composed policy graph to identify the missing states or conditions for which the policies are not captured (as shown in Figure 9). This is achieved by enumerating and verifying if the policies exist for all the possible temporal, spatial and security conditions (e.g., states captured as part of abstraction tree’s leaf nodes such as shown in Figure 6(d)), which helps in identifying potentially missing policies i.e., gap in automation. For example, the possible security states of IoT infrastructure could be Normal, compromised, monitoring and quarantine (Figure 6(d)). By identifying the missing states and their associated policies using the abstractions tree as reference, we can effectively detect the gap in automation.

The completeness of the gap analysis depends on the abstraction engine’s ability to extract all the possible states, conditions and infrastructure details captured as part of the abstraction tree. For example, the temporal, spatial and security abstractions that are auto-generated by the abstraction engine could be verified by user for its correctness, allowing the administrator to add the missing states as leaf nodes to the abstraction trees.

5.3.2. Loops in Automation

In general detecting chains and loops within the automation rules is essential to detect the potential conflicts and violations that might arise during run-time, which are rather challenging to be detected at policy compile time. From the composed policy graph, we detect the loops as follows: ($i$) We check for existence of paths with in a composed policy graph that has more than one trigger and action pair (i.e., chaining among policies). ($ii$) Check if any of the actions along the path triggers back any of the events with in the chain. ($iii$) Check if any of the actions along the path triggers any of the events with in the chain resulting in taking different action, which results in ambiguity and continuous toggling of states and actions. Loops among the policies with continuously toggling actions are marked as conflicts, while the identified policy chains are marked for potential violations (e.g., policies $S_{5}$, $S_{6}$, $S_{7}$ and $S_{10}$ in Table 4). These policies when realized together will result in either unintended behavior, continuous toggling of actions or might result in unsafe state i.e., leaves door locked or opened during unanticipated instance of time resulting safety violations or sets unintended temperature conditions in home.

5.3.3. Potential Conflicts

Existing tools lacks support for proactively detecting the policy violations that might arise during run-time. Consider for example policies $S_{10}$ and $S_{15}$, which results in run-time violations. These two policies does not have any thing in common except the actions taken by them i.e., $S_{10}$ closes windows in case of specific outdoor temperature, while $S_{15}$ opens the windows in case of raining and humidity. Therefore, identifying the run-time conflicts is a challenging task with such policies. As a straw-man solution one could mark all the policies that has conflicting actions and lack of specific temporal attributes among these policies as potential violation. Such approach will result in generating vast false positive. Exposing large number of false positives to novice smart home users could prevent them from using the automation framework, rendering these tools useless.

Therefore, it is essential to identify a means by which the potential violations are “proactively” detected and fine-tuned to avoid run-time violations. To identify potential run-time violations VISCR, checks for mutually exclusiveness333Two policies are mutually exclusive, when no two events, conditions or states among these policies are not related to each other or can co-exist i.e., occur at the same instance of time. among the policies. For detecting potential run-time violation, we build relation among all the events, states and environmental conditions that are part of the IoT infrastructure and cluster the events. By clustering the events, states and conditions, we will be able to effectively detect if parameters among any two policies are mutually exclusive or not. To achieve this, we encode our policies (multi_label_binarizer, ) (i.e., captured as policy tuple: ¡source-node, source-state, edge states/conditions, target-node, target-state, actions¿) and use k-means clustering with elbow method (k-means_clustering_states, ) for effectively clustering different types of triggering conditions and associated states. If the policy states and conditions are not mutually exclusive (i.e., on the basis of cluster distance) and pose conflicting actions are considered to generate potential violations during run-time.

In addition, for the list of policies that are marked to generate potential run-time violations, we develop the severity metric to prioritize the reported violations, which allow administrators to fix the violations in the order of their severity. We take into consideration the lack of temporal attributes, code sanity and relations derived among states as metric (i.e., aggregated sum of weights derived from all these three factors) and uses z-score and correlation ranking mechanism to evaluate the severity ranking of any potential violation (z-ranking_statistical_engler, ; correlation_ranking_engler, ).

5.3.4. Policy Reconciliation and Inference

As discussed in Section 4.1, the policy mappings (i.e., mapping between the IoT app and the respective graph-based policy) maintained by the VISCR engine helps in effectively enforcing the policies after the conflicts are detected and resolved. The conflict-free composed policy graph along with these mappings are provided as input to the policy reconciliation engine (Figure 2). We develop APIs that effectively leverage this association and reconcile composed policy graph to device-specific IoT apps for enforcement. The policies that are directly provided as graph-based policy input to the VISCR are reconciled to device-specific rules and distributed on to network of IoT devices on the basis of: ($i$) vendor-type, ($ii$) device location, ($iii$) source devices that are generating the triggering events, and ($iv$) destination nodes on which the actions need to be enforced.

In case of multiple devices that can accommodate same rule, the rules are distributed uniformly preventing any of the IoT devices from getting overloaded (jen_rule_placement, ; adoptable_rule_placement, ). Upon choosing the right set of devices on which the rules are required to be placed, the reconciliation engine translates it device-specific rules for configuring or programming the specific device.

As a strawman solution, we infer new policies in accordance with dynamic changes in the behavior of IoT ecosystem for fine-tuning the automation. For example, a newly inferred policy that is proposed to an IoT administrator for fine-tuning the existing main door access policy (P3) is shown in Figure 10. We plan to enhance the technique to efficiently infer new policies from the IoT ecosystem and propose right set of policies to IoT administrator for fine-tuning the existing policies ‘or’ resolving the run-time violations (i.e., with reduced or no false positives) as part of our future work (§7).

6. Prototype & Evaluation

We developed the complete prototype implementation of VISCR in Python and integrated it with our VISCR policy specification dashboard. We implemented following components in VISCR:

The abstraction engine of VISCR is integrated with vendor-specific cloud data sources for extracting dynamic states and configurations of IoT devices. We developed data-source drivers for IoT devices that translates logs and text data into data tables. The data source drivers of VISCR is integrated with the Congress engine (congress_arch, ), which is enhanced to generate datalog rules required for automatically generating tree-based infrastructure abstractions based on the abstraction mappings supplied by administrators. The data-push option provided by each of the vendor’s cloud data-sources allows VISCR to capture the log messages specific to dynamic updates in the IoT network.

The graph-based policies specified using the abstraction tree nodes are translated first into equivalent vendor-independent specification syntax and ultimately into a graph dictionary. We used the networkx Python library(networkx_nxgraph, ) for capturing and building policy graphs. For visualizing graph-based policies and the composed policy graph, we built the VISCR policy specification dashboard integrated with networkx (networkx_nxgraph, ) and GraphViz library (graphviz, ). VISCR maintains necessary mapping between the IoT apps and graph-based policies, which helps the reconciliation engine to effectively translate composed graph-based policies back to IoT programs during policy enforcement (as discussed in Section 5.3.4).

The composition engine captures the policies in networkx-based graphs, runs normalization and composition algorithms to detect the conflicts and resolves them using precedence rules that are maintained as key value pairs. These conflict-free policies are further analyzed for other bugs and violations. Finally, the composed conflict-free policies are translated to enforceable rules i.e., IoT apps and device-specific configurations. The VISCR’s policy composition outcome is interfaced with the VISCR specification dashboard for fine-tuning the policies before enforcement.

6.1. Evaluation

Testbed. We used simulated smart building IoT infrastructure with 907 IoT apps or automation policies framed with 30 different types of consumer IoT devices from 8 different vendors framed for multiple floors of the building. For brevity few policies (Table 3) and simulated smart building view of single floor (shown in the Figure 11). The VISCR module is run on a Dell R710 server with 48GB RAM, 12 cores (2.6GHz) with Ubuntu 4.4.0-97-generic kernel.

Datasets. We use IoT market apps (i.e., both vetted and unvetted), extracted from vendor marketplaces, and publicly available data sources for the smart-home and smart-campus use cases (iot_test_bench, ; smart-home-data, ; smart_homedata1, ; sfo_dataset_all, ; smart-city-survey, ), also consolidated in our VISCR repository (viscr_secintent_dataset, ). We have built following three datasets for our experiments:

DS-1: We simulate a smart building IoT infrastructure (as shown in Figure 11) with multiple floors and automate it with 907 IoT apps. We use 907 Groovy-based IoT apps (i.e., homogeneous specifications) for evaluating static analysis-based technique (such as Soteria (soteria, )) and compare with VISCR. The same set of automation rules programmed with Groovy, OpenHAB, IFTTT, and MUD profiles (i.e., heterogeneous specifications) are used for evaluating VISCR. With dataset DS-1, we evaluate our policy composition engine for detecting static violations and compare it with static violation detection mechanism (e.g., Soteria). In addition to detecting static policy conflicts, VISCR also detects other type of conflicts, violations and bugs from the dataset DS-1 (as highlighted in Table 4).

DS-2: We use the smart-home, smart-campus and smart-city abstractions dataset (sfo_dataset1, ; sfo_dataset2, ; sfo_dataset3, ; sfo_dataset_all, ; smart-home-data, ) for evaluating the performance of our tree-based abstraction engine in constructing the abstraction trees.

DS-3: We have built tool to generate $\approx$20K synthetic policies emulating the dataset DS-1, using the policy abstraction trees generated from DS-2. We use random sampling technique to select the source nodes, destination nodes and edge properties (e.g., dynamic environmental states, conditions, and traffic type) from the policy-abstraction trees.

6.1.1. Policy Abstraction

We evaluate the performance of policy abstraction engine with smart city data of up to 100K devices using DS-2. We built upto 400 policy abstraction trees with four levels of abstractions using the dataset. For generating abstraction trees, the abstraction engine need to join hundreds of data tables performing thousands of table join operations. It look $<$1.2sec to generate upto 400 abstraction trees with 100K leaf nodes in parallel (Figure 12(a)). The latency performance of abstraction engine stays mostly linear considering the data join operations it performs to generate the abstraction trees. Since extracting data from the network data sources takes random times considering the network latency, we discard network latency parameter in the calculation of abstract tree generation.

6.1.2. Security analysis

We evaluate the performance of our conflict detection and resolution engine with DS-1 (i.e., 907 IoT market apps) simulated to program the smart building IoT infrastructure (as shown in Figure 11) and compare it with Soteria’s violation detection mechanism. Applying model checking, we were able to find 6.6% of the static violations across policies on DS-1, which includes both property and state violations. As shown in Table 5, VISCR on the other hand was able to find $\sim$37.7% of violations within same IoT apps in DS-1. Importantly, VISCR detected 100% of the violations captured by the static analysis technique such as Soteria. Among the 37.7% of IoT apps VISCR reported 10.2% of IoT apps that has more than one violations. Importantly, different class of violations reported by VISCR is illustrated with examples in Table 4.

In addition, VISCR identifies following major types of conflicts and violations: ($i$) gap in automation due to the inability of users to completely realize the use-case scenario resulted in 10.4% of total IoT apps being violated with 1.3% false positives; ($ii$) code-sanity and programming errors in temporal and spatial policies as well as policies involving specific values (e.g., temperature, humidity, time, space) resulted in 4.2% of violations with 0.7% false positives, where the undefined references are upto 1.1% and unused structures are upto 2.1% of policies; ($iii$) policies that results in access violations due prolonged access to resources beyond the specified period of time counted upto 1.6% of IoT apps; ($iv$) rogue policies that are implemented by administrators who are not authorized to specify policies on portion of IoT infrastructures that they should not be enforcing rules (with 3.8% of total IoT apps violated); ($v$) potential run-time violations that are detected from the policies, which includes 7.9% of total violations; and ($vi$) finally, detected 3.2% of loops among the automation rules that resulted in the unintended and unsafe environmental conditions. Overall, VISCR was able to detect the above discussed violations and bugs with less than 3.8% of false positives or low intensity bugs such as Unused variables or structures and potential violations.

6.1.3. Policy Composition

The composition cost depends on following two factors: ($i$) the number of attributes or states used and in the IoT apps, and ($ii$) the number of IoT apps. In this experiment, we perform composition with increasing number of IoT apps (i.e., in subset of 100 apps in each iteration) and capture its composition latency. We keep number of attributes constant at $\sim$30 in this experiment (i.e., the IoT apps or automation use-cases are chosen only specific to these attributes). For example, temperature is considered as an attribute, while the subcategories (e.g., high, low, different levels) of the attribute are still considered as part of the same temperature attribute. We observed that VISCR took $\sim$80.7 seconds to compose 907 apps, while using model checking (i.e., such as technique used in Soteria) took approximately 14.2$\times$ more time to run, which took $\sim$1147 seconds to detect the conflicts (Figure 12(b)).

In the next experiment, we evaluate performance of conflict detection engine with increasing number of attributes and constant number of IoT apps (i.e., 907). With increase in the number of attributes, the composition (i.e., conflict detection) cost of both the approaches increased. VISCR took 231 seconds to compose 907 IoT apps and 100 different attributes, while Soteria took $\sim$3140 seconds, which is $\sim$13$\times$ more time required to detect conflict (Figure 12(c)).

Following are the vital factors that contribute to improved performance (i.e., reduced conflict detection time with our graph-based composition) compared to Soteria: ($i$) The complex SAT formulation resulting in enumeration of all possible states required to detect the static violations. ($ii$) Our approach optimizes the composition cost by parallelizing the translation procedure (i.e., translation of IoT apps to vendor-independent graph-based specification); ($iii$) With graph-based composition, we incrementally verify the source nodes and if the overlap exists then further into edge and target properties. This results in avoiding unnecessary comparison operation resulting in improved composition cost with our approach. and ($iv$) Finally, the graph-based composition mechanism generates the composed graph islands (i.e., policy graphs that are completely independent), when once a policy is detected as conflicting with one of the policy graph island, the policy is marked as conflicting avoiding comparison with other nodes with in the same composed graph and other graph islands. In addition, to provide fair comparison, we ran VISCR with 907 groovy-based apps, our composition engine took $<$92.1 seconds to compose these apps.

As VISCR also support incremental composition (i.e., to support dynamic changing IoT infrastructure), we evaluate the performance of the incremental composition as follows. We compose 907 IoT apps and generate the composed policy graph. We then randomly choose 100 IoT apps each time and change its attributes and allow it to incrementally recompose. From our experiments, it is evident that for recomposing 10 IoT app programs took $<$2.1 seconds, while recomposing 100 apps took $\sim$16.3 seconds. In normal working conditions of any IoT infrastructure, it is expected to have fewer than 10 IoT app change at any instance of time.

Finally, we evaluate the performance of VISCR with large scale synthetic dataset (DS-3) to emulate the smart city IoT infrastructures with $\sim$20K graph-based policies. We composed 20K graph-based policies by choosing the source and target nodes of the policies at different levels of abstraction trees i.e., choosing nodes at depth level 1 – level 4 of abstraction tree. We run this experiment for multiple iterations to capture the average composition engine latency. For depth level = 1, the composition cost is much higher than when policy abstracts are chosen at level 4 as the nodes are chosen more towards leaf node level results in much lesser normalization cost. Therefore, 90% of the time our tool took $<$760 seconds to compose 20K policies specified at level 1. Similarly for composing the policies specified at level 4 VISCR took $<$300 seconds.

7. Discussion & Limitations

As part of future work, we plan to develop a more comprehensive drag-and-drop graphical interface that will allow users to express a broader range of policies. We also plan to conduct a user study that allows us to effectively evaluate the expressibility of VISCR.

VISCR’s tree-based abstraction engine, builds abstraction trees, which are required for specifying the graph-based automation rules or policies. The abstraction engine relies on existing IoT vendor cloud data sources and network information base (e.g., DHCP server DB, network resource DB). However, the lack of information across data sources could result in incomplete abstraction trees and policy specifications. Hence, as part of our future work, we plan to explore machine-learning-based models to fill such information gaps.

VISCR partly supports the IoT device capabilities, which are required for translating the IoT apps into graph-based specifications. Currently, VISCR supports vendor-independent graph-based specifications for four different types of automation specification languages (groovy_smartthingsapps, ; openhab, ; decouple_ifttt, ; mud_spec, ). We plan to support other specification mechanisms such as Apple HomeKit (apple_iot_homekit, ) and add more device capabilities to VISCR in our future work. Our framework provides necessary APIs that will make adding new vendor-specific automation framework much easier and seamless (as discussed in Section 4).

Automatic inference techniques have previously been explored in the context of static code analysis for detecting bugs in systems and web applications (engler2001bugs, ; pixy_static_analysis_tool, ; mining_temporal_specs_error_detection, ) and for reverse engineering protocols (prospex_kirda_proto_reverse_engg, ). Similar techniques have also been used for detecting bugs and vulnerabilities in network configurations (understand_bgp_misconfig, ; misconfiguration_peerpressure, ). We plan to explore techniques to automatically infer IoT policies from a variety of sources including the existing automation rules, IoT traffic, IoT firmware, and IoT companion apps.

8. Related Work

Intent-based Policy Frameworks. Intent-based policies are well studied in the domain of enterprise networks  (policy_based_nw_mgmt, ; simplifying_nw_admin, ). However, they provide limited flexibility in policy specification, while handling complex and heterogeneous IoT devices. To overcome these limitations in enterprise scenarios, recent works propose the creation high-level intent-based languages, compilers and conflict detection mechanisms  (netkat, ; Frenetic, ; practical_declarative, ; composing_SDN, ; merlin, ; taxonomy, ; maple, ; propane, ; intent_virtualization, ; hierarchial_policies, ; robotron, ; ravel, ; scenario_based, ; opendaylight_grouppolicy, ; network_intent_composition, ; alpaca, ), and new SDN programming paradigms  (Boulder, ; participatory_networking, ; sdn_applications, ). Prior efforts to develop graph-based policy specification mechanisms (PGA (pga_sigcomm15, ), Janus (janus, ), LMS (lms, )) have focused on enterprise networks. However, these graph-based policy frameworks do not effectively handle dynamic trigger and action-based policies required by IoT devices. Hence, we propose to develop an intuitive graph-based policy framework that handles dynamic trigger and action-based policies and supports vendor-agnostic specification models to seamlessly accommodate different types of IoT programs including Groovy, OpenHAB, IFTTT, and MUD profiles.

Conflict-Detection & Verification with Dynamic IoT Policies. Verification and testing of dynamic policies for middleboxes are well-studied problems (snap, ; flowtest, ; buzz, ; flowtags, ; sfc_checker, ; automatic_synthesis, ; sla_verifier, ; improving_nw_mgmt, ). Unlike our work, prior studies do not address the dynamic group-based policy requirement of IoT infrastructures to handle safety, security, and privacy policies. Recent efforts have attempted to use formal verification techniques and static taint tracking to verify the correctness of deployed automation policies in homogeneous IoT environments (soteria, ; iotmon, ; iot2_verify, ; iot_policy_confict_planning, ; saint_atc, ). Similarly, recently proposed works highlighted the need for novel access control models and policies to secure IoT infrastructures (Schuster:situational_acl_ccs2018, ; rethink_acls_iot, ). However, existing IoT infrastructures are dynamic with diverse IoT devices, programmed using heterogeneous programming frameworks, that make static-verification techniques ineffective. Also, a few recent studies that focus on identifying the policy conflicts arising in complex smart-city infrastructures (cityguard, ; watchdog, ) do not deal with security or privacy issues. Similarly, Soteria (soteria, ), developed an intermediate representation for Groovy-based IoT polices and used model checking on it to verify the properties. We propose to build a vendor-independent model, that allows automation rules or policies, specified using multiple commodity IoT apps to be translated into vendor-independent policy-specification graphs for robust and proactive conflict detection and resolution.

9. Conclusion

Emerging consumer IoT infrastructures are characterized by a growing number of heterogeneous devices. VISCR provides a unified policy engine that allows for conflict-free policy specification and enforcement in IoT infrastructure. VISCR achieves this by unifying policy abstractions, automatically extracting IoT infrastructure topology and converting diverse policy languages such as Groovy-based SmartThings, OpenHAB, IFTTT-based templates, and MUD-based profiles into a vendor-independent graph-based specification. These abstractions enable VISCR to detect rouge policies, bugs, and conflicts. They also allow for easier specification and efficient composition of dynamic policy intents, from users and administrators. In a dataset of 907 IoT market apps with a mix of Groovy, OpeHAB, IFTTT, and MUD-based policies, VISCR detected conflicts in 342 apps and provided resolution mechanism to it in under 81 seconds and can adapt new policies with sub-second latency.