threats. Given the spread of the Internet of Things (IoT) technology, end-users have begun raising the need for configuring their smart environments. Task Automation Systems (TASs) recently emerged as tools to simplify the definition of trigger-action rules for personalizing the behavior of such devices. However, such tools do not take into account a typical aspect of IoT technologies, i.e., the security and privacy threats to which the smart devices are exposed to. This position paper describes how TASs can be extended to support end-users in the specification of trigger-action rules addressing security and privacy EMPATHY: Empowering People in Dealing with Internet of Things Ecosystems. Workshop co-located with INTERACT
EFESTO-5W
In the last years, the Internet of Things (IoT) fostered the development of the so-called smart
objects, which are digital devices embedding sensors and/or actuators, connected to the Internet,
and that communicate among them creating ecosystems of heterogeneous and distributed
services [
Despite their unquestionable benefits TASs still neglect an important aspect in the IoT
landscape, i.e., security and privacy issues. Indeed, smart objects represent an attractive target
for attackers, who might violate smart environments for manipulating data and stealing personal
nEvelop-O
information [
This position paper describes an ongoing work that aims to support end-users in defending their smart environment. To this aim, we designed and evaluated a visual paradigm for TASs that facilitates the end-users in understanding and controlling security and privacy threats. This paper reports some technical details on how TASs can implement the proposed solution.
In order to include security and privacy management capabilities in TASs, we focused on
EFESTO-5W, a TAS that provides visual mechanisms to create ECA rules characterized by
multiple events/actions and temporal and spatial constraints on events and actions [
The ID is built on top of Snort1 [
According to our proposal, it runs on a Raspberry Pi board that must be installed inside the PAN the users want to protect. The ID monitors the PAN trafic and eventually sends messages to the EFESTO-5W remote server when an attack is detected (see Figure 1).
Through the TAS, like EFESTO-5W in our case, users are given the possibility to trigger
a rule according to 6 diferent security and privacy threatening events, each one associated
with a specific attack the ID can detect. These events are the results of the previous study that
addressed two main challenges. First, since the ID natively detects several attacks (35 in the
current implementation), this high number can overload the users with too much information.
Second, the detected attacks refer to technical cybersecurity concepts (e.g., DDoS, man in the
middle, etc.), which are too complex for lay users. To address the first challenge, we performed
a card sorting study with 11 IT and cybersecurity experts to group the 35 attacks detected
by Snort according to their similarity [
End-users can thus define an ECA rule using these ID events according to the threat they want to manage, and one or more actions in response to it. Figure 2 shows an example of an ECA rule configured with EFESTO-5W. This rule is triggered when the ID detects a virus in the Hallway camera, and reacts by turning of the attacked camera.
Every time a user defines an ECA rule in EFESTO-5W, a JSON file describing the rule is
created according to the Node-RED syntax, since Node-RED is used in EFESTO-5W as rule
engine [
If the ID device detects an attack, it sends the attack details to the MQTT broker; the latter, in turn, notifies the MQTT node of the Node-RED flow (which represents the rule in EFESTO-5W). Then, the node checks if this attack is the one defined by the user in the rule. For example, to check if the triggered event of the ID is “Someone is attacking one of your smart devices...”, in the node there is the following code:
In this code, the msg.payload includes the details of the attack received through the MQTT broker. To verify whether the attack is the one defined in the rule event, the classname attribute of the payload is compared with all the labels representing the ID event. Indeed, as we already explained above, the ID device can detect 35 attacks but they were grouped in 6 events, each one including similar attacks whose name is reported in a label. If the attack detected by the ID device is the same of one of the labels related to the event specified in the rule, the rule is triggered. This architecture is general enough to be implemented in every TAS. Of course, while in EFESTO-5W the ID device is represented by a Node-RED node, in other TASs it must be coded according to the specific solutions adopted to develop the tool, but the MQTT guarantees a strong decoupling between the ID device and the specific TAS.
In this position paper, we presented a solution to help users defend their smart environment thanks to the use of a specific smart device, the Intrusion Defender, whose monitor capabilities can be leveraged by using a TAS. In addition, we also reported some technical details about the integration of TASs and the ID device.
As future works, we are going to refine the 6 events provided by the ID device, according to
the results of the study presented in [
This work has been supported by the Italian Ministry of Education, University and Research (MIUR) under grant PRIN 2017 “EMPATHY: Empowering People in deAling with internet of THings ecosYstems” (Progetti di Rilevante Interesse Nazionale – Bando 2017, Grant 2017MX9T7H).