1

Security Policy Enforcement forNetworked Smart Objects

Sabrina Sicari∗‡, Alessandra Rizzardi∗, Daniele Miorandi§, Cinzia Cappiello†, Alberto Coen-Porisini∗∗Dipartimento di Scienze Teoriche e Applicate, Universita degli Studi dell’Insubria,

via Mazzini 5 - 21100 Varese (Italy)§U-Hopper srl, via A. da Trento 8/2, 38122 Trento, Italy

†Politecnico di Milano, Piazza Leonardo da Vinci 32, 20133 Milano, Italy‡Corresponding author

Email: {sabrina.sicari; alessandra.rizzardi; alberto.coenporisini}@uninsubria.it,daniele.miorandi@u-hopper.com, cinzia.cappiello@polimi.it

Abstract—In the Internet of Things (IoT) heterogeneoustechnologies concur to the provisioning of customizedservices able to bridge the gap between the physical anddigital realms. Security, privacy and data quality areacknowledged to represent key issues to be tackled inorder to foster the large-scale adoption of IoT systemsand technologies. One instrumental aspect concerns theability of the system to preserve security in the presenceof external attacks. In such a scenario, the integrationof a flexible IoT middleware, able to handle a largenumber of data streams and of interconnected devices,with a flexible policy enforcement framework is neededand presented in this paper. The proposed solution aimsto ease the management of interactions across differentrealms and policy conflicts. Its effectiveness is validatedby means of a lightweight and cross-domain prototypicalimplementation.

I. INTRODUCTION

The Internet of Things (IoT) [1] represents a visionof future technological ubiquity, where the ability ofdevices to connect to a global infrastructure enablesto bridge the gap between the physical and digitalrealms. The diffusion of the IoT paradigm would allowthe implementation and the diffusion of innovative andcustomized services in several applications fields. Froma technological point of view, the term ‘things’ is usedto denote various physical everyday objects that em-bed electronics (e.g., wireless sensor nodes, actuators,RFIDs, and so on) to make them smart and suitableto be part of a global networked infrastructure. From alogical point of view, an IoT system can be characterisedas a collection of smart devices which interact on acollaborative basis to fulfill a common goal, acquiringdata from and acting upon the environment they are in.

In such a context, security & privacy represent crit-ical requirements, which can hinder the large scaleadoption and diffusion of IoT applications [1] [2] [3][4] [5] [6]. Traditional security countermeasures andprivacy solutions cannot be directly applied to IoTscenarios due to various reasons, including, but notlimited to, energy and computing constraints, scalability

etc. Moreover, adaptation and self-healing play a keyrole in IoT infrastructures, which must be able toface sudden and unexpected changes in the operationalenvironment. Accordingly, privacy and security issuesshould be treated with a high degree of flexibility [7][8]. Together with the conventional security solutions,there is also the need to provide built-in security in thedevices themselves (i.e., embedded) in order to pursuedynamic prevention, detection, diagnosis, isolation andcountermeasures against successful breaches [9].

Security and privacy are two pillars for ensuring theeffectiveness of IoT services, the third one being dataquality. IoT services should provide correct, completeand updated information: in some scenarios indeederrors or missing values might have critical impact onactions or decisions [10]. Keeping in mind the crucialrole of the satisfaction of these security, privacy anddata quality requirements, it is important to remarkthat in IoT context the number of violation attemptsis high [2]. In other words, in order to deal withthe huge amount of critical situations typical of thesharing approach of IoT paradigm, it is fundamentalto adopt well-defined enforcement mechanisms able tosuccessfully tackle them. Furthermore, IoT deploymentsare characterized by a high degree of heterogeneityin terms of architectures and technologies, so that asuitable security framework should be highly flexiblein order to adapt to various deployment features.

In order to address such emerging issues, in this workwe propose to integrate an existing flexible and dis-tributed IoT middleware, called NetwOrked Smart ob-jects (NOS) [11], with a policy enforcement framework.More in detail, the extended middleware has to provide apolicy enforcement system able to manage the resourcesin a secure way and to handle attacks and violationattempts. NOS is represented, in a previous work, as asecurity-and quality-aware system architecture [12], andis based upon the concept of a computationally powerfulsmart nodes’ layer acting as a distributed database ableto manage IoT-generated data. The basic idea underpin-ning NOS is of bringing processing, security and data

2

qualification closer to the actual data sources. To easethe development of applications and the managementof such a system, in [11], the NOS middleware hasbeen designed and prototyped. It includes provisioningfor users and applications to dynamically specify thelevels of security and data quality suitable for their ownpurpose.

However, the original NOS architecture does notdefine supporting mechanisms for: (i) controlling theaccess of both users and data sources; (ii) the dataprovision to users. An enforcement system would allowto overcome such limitations. As regards the enforce-ment mechanisms, few efforts are currently made bythe scientific community [2] [13]. To the best of theauthors’ knowledge, no specific enforcement solutionfor IoT is currently available, although it is essential toensure a safe deployment of IoT paradigm. To addresssuch shortcoming, in this paper we propose a policyenforcement system specifically tailored to IoT, ableto manage the interactions among the involved entitiesunder well-defined policies. The proposed solution isable to guarantee data quality, security and privacy alsoin the presence of policy violation attempts.

The paper is organized as follows. Section II reviewsthe relevant state of the art. Section III presents the NOSarchitecture, with a specific focus on data managementaspects. Section IV describes the proposed enforcementframework. Section V and VI present the prototyp-ical implementation of the NOS policy enforcementframework and its validation, in order to demonstratethe feasibility of the proposed approach in a real IoTcontext. Section VII concludes the paper and providessome hints for future works.

II. RELATED WORKS

The most crucial challenge in building an IoT systemlies in the lack of common, standardised and interop-erable software frameworks. In order to fill this gap,the scientific community has started several interestingresearch initiatives. For example, in recent years, theavailability of web service solutions has provided acommon frame for building systems able to leverage theservices of another one according to the principles ofService Oriented Architectures (SOA). Service-orientedCommunications (SOC) technologies emerged as a wayto manage web services by creating a virtual networkand adapting applications to the specific needs of usersrather than forcing users to adapt to the availablefunctionality of applications [14] [15]. Although thedecision of adopting SOA architecture in IoT is sharedby the majority of scientific community, at the momentthe state of the art in this area is mostly limited toresearch and innovation activities [16] [17] with limitedcommercial uptake.

Furthermore, due to the very large number of hetero-geneous technologies normally co-existing within IoTdeployments, several middleware layers are employedto enforce the integration and the security of devices

and data within the same information network. Withinsuch middlewares, data must be exchanged respectingstrict protection constraints. Moreover, in middlewaredesign and development, different communication pro-tocols shall be supported: while many smart devicescan natively support IPv6 communications [18] [19],existing deployments might not support the IP protocolwithin the local area scope, thus requiring ad hoc gate-ways and supporting middlewares [20]. Recent workson IoT middlewares are: VIRTUS [21], which relieson the open eXtensible Messaging and Presence Pro-tocol (XMPP) to provide secure event-driven commu-nications; Otsopack [22] and Naming, Addressing andProfile Server (NAPS) [23] are data-centric frameworksbased on HTTP and REpresentational State Transferinterfaces. We differentiate from them since: (i) [21]focuses only on the application of an authenticationsystem and on securing the communication channel bymeans of encryption mechanisms; (ii) [22] and [23] ad-dress, respectively, ambient intelligence in constrainedenvironments and resources naming management, with-out dealing with security issues.

Many relevant activities have taken place within theframework of EU R&D actions. The FP7 COMPOSE(Collaborative Open Market to Place Objects at yourService) project [24] aims to design and develop an openmarketplace, in which data from Internet-connectedobjects can be easily published, shared and integratedinto services and applications. The basic concept un-derpinning such an approach is to treat smart objects asservices, which can be managed using standard service-oriented computing approaches and can be dynamicallycomposed to provide value-added applications to endusers.

The iCORE project (iCORE) [25] aims to empowerIoT with cognitive technologies and is focused on theconcept of virtual objects (VOs). VOs are semanticallyenriched virtual representations of the capabilities/re-sources provided by real world objects. Through theinception of VOs it becomes possible to easily re-useInternet-connected objects through different application-s/services, also supporting their mash-up into compositeservices. VOs provide a unified representation for smartobjects, hiding from the application/service developerslow-level details as well as from underlying technologi-cal heterogeneity. They also provide a standardised wayto access objects’ capabilities and resources. One keyelement in the iCORE project is the use of advancedcognitive techniques for managing and composing VOsin order to improve IoT applications and better matchuser/stakeholder requirements. The considered applica-tion scenarios include ambient assisted living, smartoffice, transportation and supply chain management.

A dynamic architecture for services orchestration andadaptation has been proposed in IoT.EST (Internet ofThings Environment for Service Creation and Testing)[26]. The project defines a dynamic service creationenvironment that gathers and exploits data from sen-sors and actuators that use different communication

3

technologies and formats. Such an architecture dealswith different issues such as composition of businessservices based on re-usable IoT service components,automated configuration and testing of services for“things”, abstraction of the heterogeneity of underlyingtechnologies to ensure interoperability.

Focusing on semantic web services, the Ebbits project[27] designed a SOA platform based on open pro-tocols and middleware, effectively transforming everysubsystem or device into a web service with semanticresolution capability. The goal is to allow businessesto semantically integrate the IoT into mainstream en-terprise systems and support interoperable end-to-endbusiness applications.

Finally, security, privacy and trust issues are ad-dressed by the uTRUSTit [28] and the Butler [29]projects. The former one is a project integrating the userdirectly in the trust chain, guaranteeing transparency inthe underlying security and reliability properties of theIoT. If successful, uTRUSTit aims to enable systemmanufacturers and system integrators to express theunderlying security concepts to users in a comprehen-sible way, allowing them to make valid judgments onthe trustworthiness of such systems. Butler aims toallow users to manage their distributed profile allowingdata duplication and identities control over distributedapplications. The final purpose is to implement a frame-work able to integrate user dynamic data (i.e., location,behaviour) in privacy and security protocols.

Besides security and privacy levels, which meansability to guarantee confidentiality, integrity andanonymity requirements, in order to allow a real dif-fusion of IoT paradigm also data quality has to beaddressed. As regards data quality, several scientificpublications recognize its pivotal role in the IoT re-search landscape. In [30], authors claim the need of con-trolling data sources to ensure their validity, informationaccuracy and credibility. Data accuracy is also coveredin [31], where the authors observe that the presence ofmany data sources raises the need to understand thequality of data. In particular, they state that the dataquality dimensions to consider are accuracy, timelinessand the trustworthiness of the data providers. Anomalydetection techniques are widely employed to removenoise and inaccurate data in order to improve dataquality. The huge number of data sources is considereda positive aspect for data fusion mechanisms and forthe provisioning of advanced services. Besides temporalaspects (i.e., currency) and data validity, a related workadds another important dimension such as availability[32], with focus on pervasive environments. Authorsdefined new metrics for the cited quality dimensionsin the IoT environment and evaluate the quality of thereal-world data available on an open IoT platform. Theyshow that data quality problems are frequent and theyshould be addressed or, at least, users should be awareof the poor quality of the data sources being used.

The definition of security and data quality policiesmay be not sufficient for satisfying the requirements

of an IoT system, because violation attempts shouldalso be considered. This requires the inclusion of policyenforcement mechanisms, which define how the systemshall reach in such cases. More in detail, policies are op-erating rules which need to be enforced for the purposeof maintaining data order, security, and consistency. Thepolicy enforcement assures that the security tasks canonly be fulfilled if they are in accordance with the un-derlying security policies, consulting the policy decisioncomponent and deciding whether to allow an entity toperform an operation on a system resource. This aspectis poorly covered in existing literature, which mostlyfocuses on how to manage policy enforcement.

[33] presents a simulation environment for variouspolicy languages, such as WS-Policy (Web Services-Policy) and XACML (eXtensible Access ControlMarkup Language), used in different systems. Low-level enforcement mechanisms may indeed vary fromsystem to system. Thus, it is difficult to enforce a policyacross domain boundaries or over multiple domains.Before applying policies across domain boundaries, itis desirable to know which policies can be supportedby other domains, which are partially supported, andwhich are not supported. For example, in a health-care environment, the cooperation and communicationamong pharmacies, hospitals and medical schools areessential. They have their own policy enforcementmechanisms to protect their own proprietary data andpatients records. The problem is that there are lots ofcollaborations and communications among these actors,therefore a cross-domain policy enforcement becomesan essential component. However, in most cases, thesedomains use different policy languages. When a newinteraction or communication is required between twoseparate domains, we do not know how many rules fromone domain can be enforced by current enforcementmechanisms. So in most cases, the technical depart-ments from these two domains have to work togetherto evaluate whether or not it is possible to maketheir systems interoperating. The same problem alsoexists in social networking environment (e.g., Facebook,Linkedin). Most existing social networking sites haveprivacy configurations based on their own enforcementmechanisms. When two social networking sites or twohealthcare domains need to communicate or collaboratewith each other, they have to rebuild or reconfiguretheir systems to make sure these activities are consistentwith their own and their partners policies. In [33] asimulation environment is proposed, using semanticmodel mapping and translation for policy enforcementacross domain boundaries by means of the Web On-tology Language (OWL), which can be used to modelboth policy languages and enforcement mechanisms.Therefore, a configurable middle-level component ispresented for the mapping process among such differentdomains.

In [34] the languages regarding the definition ofobligations and policies are classified into two cate-gories. On the one hand, there are policy enforcement

4

languages, which generally simplify the specificationand interpretation of policies; however, they lack theformal semantics needed to allow the verification of thepolicies themselves by means of formal proofs. On theother hand, there are policy analysis languages, whichallow the formal policies analysis and the expressionof a large variety of obligations. In [34], the authorsintroduce a policy language which aims at combiningthe advantages of both approaches. Formalizing policyenforcement has several advantages: it reduces the gapbetween the specified policies and their deployment,thus it ensures that the policies are correctly applied inthe system. To formalize policy enforcement, the targetsystem should be modeled and then the effects of theapplication of the policies should be described. More indetails, policies are enforced using reference monitors,and a set of active rules specifies that a set of actionsshould be executed after the detection of some events,if some conditions are met. However, such a languagedoes not provide the operational semantics needed todynamically enforce and manage obligations in a policymanaged system.

In [35] a novel access control framework, namedPolicy Machine (PM), is proposed. It is composed bythe following basic entities: authorized users, objects,system operations, and processes. Users may be eitherhuman beings or system users; objects specify systementities which are controlled under one or more poli-cies (e.g., records, files, e-mails); operations identifythe actions that can be performed on such resources(e.g., read, write, delete); finally, users submit accessrequests through processes. Policies are grouped inclasses according to their attributes and, therefore, anobject may be protected under more than one policyclass, and, similarly, a user may belong to more thanone policy class. In such a way, PM is a general purposeprotection machine, since it is able to configure manytypes of access control policies, and it is independentfrom the different operating systems and applications;users need to login only to PM in order to interact withthe secure framework. [35] demonstrates the PM abilityto express and enforce the policy objectives of RBAC[36], Chinese Wall [37], MAC and DAC models [38].Moreover, PM is able to face many Trojan horse attacks,to which DAC and RBAC are vulnerable.

[39] and [40] introduce a semantic web frameworkand a meta-control model to orchestrate policy reason-ing with the identification and access of informationsources. In open domains indeed enforcing context-sensitive policies requires the ability to opportunisticallyinterleave policy reasoning with the dynamic identi-fication, selection, and access of relevant sources ofcontextual information. Each entity (i.e., user, sensor,application or organization) relies on one or more agentsresponsible for enforcing relevant policies in responseto incoming requests. The framework is applicable to anumber of domains where policy reasoning requires theautomatic discovery and access of external sources.

[41] introduces a formal and modular framework

allowing to enforce a security policy on a given con-current system. In fact, one of the important goals ofthe software development process is to prove that thesystem always meets its requirements. To deal withthis problem, two different approaches are proposed.The former is a conservative enforcement: the programshould be terminated as soon as it violates the secu-rity policy even if the current run could be partiallycompleted. The latter is a liberal enforcement: theexecution of the process is not aborted if it could bepartially satisfied. With this approach, more propertiesare enforced than with the conservative one, but theprogram may terminate without fully satisfying thesecurity policy. Therefore, the conservative enforcementwill generate false negatives, while the liberal enforce-ment will generate false positives and no one of themreach the desired result. In [41] an extended versionof Algebra for Communicating Process (ACP) [42],designed for specifying concurrent systems behaviour,and Basic Process Algebra (BPA) language for thespecification of security policies are used. To achieve thegoal, ACP is enhanced with an enforcement operator,whose actions run in parallel with the system, in orderto monitor the requests and the satisfaction of the relatedpolicies.

[43] provides an overview of network security, se-curity policies, policy enforcement and firewall policymanagement systems. As far as policy enforcement isconcerned, it proposes to use security services suchas authentication, encryption, antivirus softwares andfirewalls in order to protect the data confidentiality,integrity, and availability. In contrast, the authors of [44]present a framework able to prove whether the codeimplementing access control respects access controlpolicy specifications.

Expressing security policies to govern distributedsystems is a complex and error-prone task. Becauseof their complexity and of the different degrees oftrust among locations in which code is deployed andexecuted, it is challenging to make these systems se-cure. Moreover, policies are hard to understand, oftenexpressed with unfriendly syntax, making it difficultfor security administrators and for business analysts tocreate intelligible specifications. In [45] a HierarchicalPolicy Language for Distributed Systems (HiPoLDS) isintroduced; it has been designed to enable the specifi-cation of security policies in distributed systems in aconcise, readable and extensible way. HiPoLDS designfocuses on decentralized execution environments underthe control of multiple stakeholders. It represents policyenforcement through the use of distributed referencemonitors, which control the flow of information amongservices and are in charge of putting into action thedirectives output by the decision engines. For example,an enforcement engine should be able to add or re-move security metadata such as signatures or messageauthentication codes, encrypt confidential information,or decrypt it when it is the case. [45] does not specifyhow the distributed system behaves and manages policy

5

reconfiguration (e.g., if a reboot is required).The authors of [46] state that the application logic,

embodied in the system components, should be sepa-rated from the related policies. Therefore, they proposean infrastructure which can enable policy, representinghigh-level (i.e., user) or systems entities, able to drivethe system functionality in a distributed environment.To this end, a middleware, able to support a secureand dynamic reconfiguration and to provide a policyenforcement mechanism across system components, isintroduced. However, neither a case study nor a workingimplementation is presented.

Summarizing, there are no available solutions ableto handle both security & privacy and data qualityrequirements in IoT environments at the same time.In fact, [33] and [46] mainly address cross-domainpolicy issues, [34] and [45] focus on a policy languagedefinition, [35], as well as [39] and [40], enforces onlyaccess control policies, [41] and [43] are about a formalproof of the correct behavior of a system with not welldefined security rules. A first attempt to consider boththe issues is presented in [10], [12] and [11]. In the first,a general UML conceptual model for IoT architectureis defined, while in the second one a high level designof such an architecture is detailed. In the third, a realimplementation of the architecture is presented, which,in this work, is integrated with an enforcement engineable to manage the defined policies and the interactionsamong the involved entities. Note that the identificationof the enforcement solutions suitable for the specificIoT context is fundamental, finding a suitable tradeoffbetween the guarantee of security, privacy and data qual-ity issues and the computing efforts. The enforcementframework proposed in this paper aims to fill this gap.

III. ARCHITECTURE AND PROTOTYPE

In a generic IoT system we can identify two mainentities: (i) the nodes, heterogeneous devices (e.g.,RFID, NFC, sensors etc.) which generate data (ii) theusers, who interact with the IoT system through servicesmaking use of IoT-generated data, typically accessingthem by means of a mobile device (e.g., smartphone,tablet) connected to the Internet (through, e.g., WiFi,3G, Bluetooth). The NOS layer has been introducedin [11] in order to process such a huge amount of datacloser to the sources and to better serve the user interms of quality and security. NOSs are networked smartnodes without strict constraints in terms of energy andcomputational capabilities. They have self-organizingfeatures and can be deployed where and when needed,in a distributed manner; through their interface withenterprise platforms and IoT enabling technologies, theycan be used to extend existing software platforms,making them able to interact with the physical worldfollowing well-defined templates and rules. In general,a NOS would act as a gateway with built-in processingcapabilities, able to manage a number of IoT datasources. Multiple NOSs may co-exist, each of them

serving a subset of the IoT devices present in theenvironment.

A high-level architecture of NOS is presented inFigure 1 [12]. In the remainder of this section wepresent the various components in detail.

NOSs aim to handle in near real-time the largeamount of data coming from heterogeneous IoT devices.Following a bottom-up analysis of the architecture, westart from the southbound NOS interface, which areused by NOS to collect data from IoT devices. NOSsare able to deal with both registered as well as non-registered sources. NOSs provide a specific REST end-point for handling source registration. The informationrelated to the registered sources is put into the storageunit named Sources. Registered sources may specify anencryption scheme for their interactions with NOSs. Foreach incoming data unit, the NOS extracts the followingfields: (i) the data source, which describes the kindof node (e.g., sensor node, actuator, RFID); (ii) thecommunication mode, that is, the way in which the datais collected (e.g., discrete or streaming communication);(iii) the data model in use, which represents the type(e.g., number, text) and the format of the receiveddata; (iv) the data itself; (v) the timestamp registeringwhen the data arrived to NOS. HTTP is assumed tobe used for communication among the NOS and thedata sources. Since the received data are of differenttypes and formats, NOSs initially put them in the RawData collection. Data in such collection is periodicallyprocessed, in a batch way, according to the two-phasesscheme shown in Figure 1. Data goes through the DataNormalization and Analyzers phases in order to obtaina uniform representation of data, including, as specifiedin the following, metadata useful for optimsing andcustomising the service provision.

First, the data stored in Raw Data is put in the formatspecified in Figure 2 by the Data Normalization moduleand stored in the Normalized Data unit. This representsa sort of pre-processing phase in which the unnecessaryinformation is removed from the data (where the ‘unnec-essary’ depends on the specific application domain) anda uniform representation thereof is built; at this stage,security and quality metadata fields are still empty.Then, a second module, consisting of a set of Analyzers,periodically extract such data from the Normalized Datastorage unit and elaborates it in terms of security anddata quality properties). Such an analysis implies thatthe data are annotated with a set of metadata (i.e., ascore for each security and quality level). A samplesemantic description of the data content is shown inFigure 2. The data thus processed is ready to be usedfor providing services to the interested users. Therefore,in order to achieve such a goal, the NOSs layer can beconnected to IP-based networks (i.e., Internet, intranet).

The assessment of security and quality levels arebased on a set of rules stored in a proper format inanother NOS storage unit, named Config. It is worthremarking that such rules are not the subject of thiswork, since the focus of this paper is on the enforce-

6�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

��������

����� �����

� � ��

�� ����������

������������

������

����

������� ������

�

�����������

������

�� �������

��� � �

���� ������� � �

� � ����� ��� �����

� � �����

��������

������ �� � ������!����

�������"#���

�����

������

�� � ��������

$����%

��&�

����������� ������

#� ������� ������

����

����������������

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

� � �����

Fig. 1: System Architecture

ment mechanism. Config contains all the configurationinformation required for the correct management of theIoT system (including, e.g., how to calculate qualityproperties, which attacks or security countermeasures toconsider etc.). Rules in the Config store can be dynam-ically configured at runtime by system administratorsconnecting remotely to the NOS over a secure connec-tion (e.g., HTTPS, SSL) without the need to re-start theNOS services. The usage of a secure communicationprotocol is required in this case, as the policy adopted bythe NOS for processing the IoT data has to be protectedagainst external attacks. In this article we do not covermonitoring and event reporting (e.g., registered sources,source behavior, NOS performances, service utilization,occurred violations) aspects, yet it is understood thatthey should be included as in any operational system.Given the distributed nature of NOS a viable solutionis represented by the popular ELK (Elastic, Logstash,Kibana) stack 1.

Analyzers query the Config store to retrieve a list ofthe operations they are intended to carry out. How-ever, we remark that the assignment of security andquality scores provides a handle for letting the users

1https://www.elastic.co/webinars/introduction-elk-stack

filter directly by themselves the data processed byNOS according to their personal preferences. In fact,the choice to provide a score for each security anddata quality dimension makes our approach extremelyflexible and able to adapt to very different applica-tion scenario requirements. For example, there existapplication scenarios (e.g., factory floor automation)in which only data with a high level of integrity andconfidentiality shall be used, but there is no interest tosatisfy privacy requirement. Another application domainmay aim to provide a service characterized by error-free data and high confidentiality scores; therefore thedata to be selected are those provided by sources ableto satisfy these requirements. Such a feature makesour solution suitable for adoption in different contexts.In many situations indeed no description neither aboutthe sources nor the acquired data may be availablea priori; at the moment this requires labour-intensivesearch and selection of which data sources to use.Our approach automates such a task, leaving to thesystem administrator to define scoring policies and tothe service provider to specify the requirements on thedata to be used. The ability to support an automaticreasoning about data quality and security is what makes

7

our approach able to deal properly with the scale andheterogeneity of IoT contexts.

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

���������������

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

� �������������

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

Fig. 2: NOS data format

NOS’ northbound interface is based on the Mes-sage Queue Telemetry Transport (MQTT) protocol. Itconsists of a publish/subscribe mechanism, which aimsto make the processed data available for interestedapplications and/or users. In fact, the system allows boththe registration of users and of external applications,which authenticate to NOS and then make requests tothe services made available by the NOS itself. In caseof application registration, multiple users may registerto such an application, instead of registering to NOS.

MQTT is a lightweight publish/subscribe connectivityprotocol [47] specifically addressed for resource con-strained devices. In IoT context, it is widely used toenable communications among devices using a pub-lish/subscribe messaging approach. An MQTT client,as that contained in NOS, exchanges messages usingan MQTT broker by means of publications and sub-scriptions to a topic. Such a mechanism is adopted tosupport interactions among services and IoT devices.In particular, each NOS has a module in charge ofassigning the corresponding topic to data and, then, tosend them to a MQTT client (module Publish Datain Topics in Figure 1). The assignment of the topicsdepends on the application domain and is out of thescope of this work, but it may need the definition of anontology able to represent the semantics of the managedresources. In general, topics are multi-level structuresseparated by a forward slash similar to a directory struc-ture. An example of a topic for publishing temperatureinformation of a sensor with identifier sensorId could besensor/temperature/sensorId. Note that subscribers mayregister for specific topics at runtime and NOS providesa mechanism for dynamic subscription e unsubscriptionto the topics. The MQTT client (Client MQTT in Figure1) publishes messages to a MQTT broker.

In our prototypical implementation, which is openlyaccessible at https://bitbucket.org/alessandrarizzardi/nos.git we have used the Mosquitto [48] open-sourceMQTT broker, Node.JS platform [49] and MongoDB[50] for the data management part. In our implementa-tion, NOS modules interact among themselves throughRESTful interfaces. This allows us to add new modulesor modify the existing ones at runtime, since they areable to work in parallel in a non-blocking manner.

The non-relational nature of MongoDB allows the datamodel to evolve dynamically over time.

IV. POLICY ENFORCEMENT

In order to effectively manage the available resourcesand to handle possible violation attempts, NOSs haveto be provided with a set of well-defined policies,specifying the behaviour and the actions to be takenin a given situation. Accordingly, a fundamental roleis played by the enforcement framework integrated inthe NOS system, as it guarantees that the policiesspecified are correctly applied. In the NOS case, policiesrefer in particular to controlling access to IoT dataand managing communications. This comes from therequirement to protect both data resources and usersensitive information. Technically, the main challenge tobe faced is how to integrate an enforcement mechanismin the existing NOS architecture, without affecting theexisting functionality. In our approach, as shown inFigure 1, the enforcement functionality is embedded in awrapper layer, able to control the NOS operations with-out requiring major system-level modifications. In theremainder of this section we analyse the functionalityin detail.

A. Enforcement FrameworkThe enforcement framework is in charge of handling

access control and service provisioning under well-defined security and quality requirements. The frame-work is defined hereby to represent a redefinition ofaccess control and data exchange in terms of a commonset of functions and roles suitable for IoT applications.Functions and roles are dynamically configurable inorder to provide the required level of flexibility to coverdifferent application scenarios.

Conventional access control enforcement frameworksinclude a Policy Enforcement Point (PEP), a PolicyDecision Point (PDP), and a Policy AdministrationPoint (PAP) [51]. PEP is in charge of interceptingany requests of access to resources from users, and ofmaking a decision request to PDP in order to obtainthe access decision (i.e., approve or reject). Whenevera user or an application requests access to a data, thisis routed through a PEP and transferred to a PDP forevaluation and authorization decision. PDP evaluatesthe access requests against the authorization policies inorder to decide whether the request shall be accepted.To this end, the PDP refers to and queries a policiesstore. When the PDP completes the evaluation, it returnsa response to the PEP. Based on such a decision, PEPeither permits or denies access to the user/resource. Theauthorization policies are finally administered througha “centralized” PAP. The functions just described areusually performed by an application software. In ourcase, where communication is based on the MQTTprotocol, all requests are handled via the MQTT broker(as also shown in Figure 1). The architecture underlyingthe framework may comprise one ore more NOS and a

8

huge amount of nodes, which act as data sources, andusers, which act as data consumers (either directly ormediated by applications/services). Each NOS includesa PEP, a PDP and a PAP, while each user has an ap-plication representing an interface for the user personaldevice and the NOS. As far as nodes are concerned, aseparate discussion has to be made, since the systemhas to be able to deal both with registered and non-registered nodes (i.e., data sources), while users maybe directly registered to NOS or to another application,which is further registered to NOS. In the latter case,the application itself manages all the interactions withNOS and establishes the levels of security and qualityfor the data to be provided to the interested users.While, in the former case, a user, besides logs on theapplication running on his/her device using the providedGUI, opens a session, during which he/she can requestfor the services provided by NOS on the basis of theaccessible resources. All components interact with theunderlying PEP.

The structure of the presented enforcement frame-work is sketched in Figure 3. Although the figure showsonly one NOS, the framework may be executed ina distributed manner on multiple NOS, whereby eachNOS runs its own framework and a single applica-tion/service may interact with a plurality of NOSs.Therefore, the distribution of policies, their update andsynchronization have to be considered (let us recallthat this means, roughly speaking, to synchronize thecontent of the various instances of the Config storeon multiple NOSs). We assume that, in the case ofmultiple NOSs interacting with each other, all NOSswithin the same administrative domain share the samesecurity policies and each of them has its own policyenforcement component.

Our approach follows the Attribute Based AccessControl (ABAC) model [52]. In such a mechanism,both the subject who want to access or to provide theresources, and the objects (i.e., data), which representthe resources themselves, are described by means ofspecific attributes, which are used for the policies def-inition. Attributes can be based on the metadata fieldsnatively supported in our data representation and controlrules can be defined according to the specific needsof the application domain. As widely acknowledged inthe relevant literature, ABAC presents better scalabilityand flexibility than Role Based Access Control (RBAC)[53].

To ease interoperability and to actually enable theimplementation of a policy enforcement system, a pol-icy representation language has to be chosen. Giventhe large number of IoT domain applications, such alanguage has to be flexible enough to represent theanalyzed contexts both in a general-purpose and in acustomizable way. The policy language proposed inthis paper is specifically tailored to the managementof enforcement, and is written in JSON syntax, beingtherefore suitable for the integration in the databasemanagement system used in our implementation (i.e.,

MongoDB). It allows to express the whole set of policiesfor each involved entity (i.e., nodes and users). Eachof them has specific attributes, as described in thefollowing section. According to the defined attributes,each entity can be allowed to perform different actions.The system allows the runtime change of policies, whichcan be dynamically loaded in the system through theaforementioned PAP.

B. Enforcement EngineSecurity among the involved components (i.e., NOS,

users, nodes) is guaranteed through the adoption ofsuitable encryption mechanisms. Another challenge isrepresented by the identification of a minimal set ofprimitives able to specify and enforce a large varietyof attribute-based security and data quality policies.To this end, NOS are provided with an EnforcementEngine component, which is in charge of managingsuch policies for all involved entities. The EnforcementEngine implements to the PDP and PAP functionsshown in Figure 3. An important feature of the proposedpolicy framework is that the Enforcement Engine alsosupports the loading of new policies at runtime, withoutdisrupting service operations. Such a feature increasesthe flexibility of the framework and makes it particularsuitable for IoT applications, which require a highdegree of availability.

The advantage of the adopted policy-based control isthat the controlling unit of the system (i.e., EnforcementEngine) is kept decoupled from other managementcomponents (i.e., Data Normalization and Analyzersphases). As a consequence, the system administratorcan manage and change the system behaviour withoutmodifying the software or the user/node interfaces.Furthermore, the entire system is controlled by policieswhich specify the rules interpreted and enforced byEnforcement Engine. Hence, if the conditions changeor new services or applications are added, only the cor-responding policy rules have to be adapted. Within NOSall the security related tasks are executed seamlessly sothat services are not required to have explicit knowledgeof security policies.

V. IMPLEMENTATION OF THE ENFORCEMENTFRAMEWORK

In this section we present a prototypical implemen-tation of the policy enforcement framework definedin the previous section. The key component in theNOS architecture is for us the Enforcement Engine,which is in charge of ensuring that the system satisfiesthe security and quality requirements of authorizedusers/nodes. Policies are applied to two types of en-tities: data producers (in our context: IoT devices ornodes, as we term them) and data consumers (usersdirectly or applications). Six key actions for whichpolicies are specified have been identified and formallydescribed: node access control, node data transmission,node data processing, user/application access control,

9

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�������

������

�

���������

�����������

�����������

����������

���������

� ��

����

���������

������

����

���������

���������

����� ������������

���������

�������

���������

�������

������

�������

������

����

�������

�����

����������

�����

��!���

Fig. 3: Enforcement System

user/application service request, and service provision.In line with the ABAC approach used, policies are spec-ified as a set of key-value pairs, each pair representingan attribute of the corresponding policy.In our framework, a policy is composed of three mainbuilding blocks. The first one (input) defines the val-ues that the NOS expects to receive in input fromthe requesting entity (nodes or users/applications) andthat are used for evaluating the policy for a specificaction. The second one (security) defines the functionsto be executed on the provided inputs to assess thepolicy. Each function returns a value; such values arecomposed by means of the logic specified in the thirdblock (response) to define whether the request shall beaccepted or not.In our implementation, the policies are represented inJSON format and are stored in the Config storage unit.The character @ is used to indicate the value taken bythe corresponding field. In the following, we presentsome sample policy specifications.In our system three types of entities are present: users,applications and nodes. Users and applications con-sume data and they must be registered. Nodes generatedata; as explained in detail above the system acceptsalso data generated by non-registered (anonynmous)nodes. The user/application registration phase takesplace through an exchange of credentials between theuser/application and the NOS. In order to performregistration operations, a user/application must be au-thenticated with admin privileges. From the operational

perspective, we do expect that entities consuming data(i.e., users/applications) will, in most cases, be regis-tered by a system administration. When registering, anidentifier is assigned by the system to each registereduser/application, along with a function, conceived as aset of attributes used for filtering the access to resources(an example is presented in Section VI). Note thatsuch attributes and the related access permissions areestablished by a system administrator, decoupled fromNOS.

On the other hand, as already introduced in SectionIII, nodes can optionally self-register with the NOS.Note that the NOS also assigns an identifier to theregistered nodes, for which in the registration phase isspecified the signature key used for encrypting the datathey send. Such credentials are eventually exchangedbetween the node and NOS through the proper SourcesRegistration interface.

Listing 1 describes a sample version of the NodeAc-cessControl policy, which covers nodes wanting to senddata to the NOS. This policy is invoked by the NOSbefore inserting the data into the Raw Data storageunit. The Enforcement Engine verifies whether the nodeis transmitting, along with the data, the node identifierand a signature key (specified as node inputs in Listing1). The verification process is split in two branches.If the source is a registered one, the NOS receives ininput the node identifier and the signature key and canperform a registrationCheck (i.e., checking whether theidentifier is known and valid) and the signaturekeyCheck

10

(i.e, checking that the identifier and key are compliantfor the requesting node). Conversely, if the source isunknown, the key is marked as undefined by the func-tion signaturekeyUndefinedMark for the correspondingnode. In case of a non-registered node, the NOS keepstrack of the source by assigning to it a pseudo-randomidentifier at the first communication exchange; such anidentifier will be used in following interactions. Thisapproach allows a NOS to verify whether the node is anew or a known one just by looking up its identifier. IfregistrationCheck and/or signaturekeyCheck reveal thatthe credentials are not compliant with the requestingsource, then the enforcement engine prevents such anode from interacting with NOS.

Once these checks have been passed and the nodeis allowed to send data to the NOS, a pseudo-randomsession identifier is created and assigned by the ses-sionAssignment function. Data quality and security areassessed on a per-session basis.

1 { ” NodeAccessCon t ro l ” : {2 ” p o l i c y ” : ” NodeAccessCon t ro l ” ,3 ” i n p u t ” : {4 ” node ” : {5 ” i d e n t i f i e r ” : ”@NodeID” ,6 ” s i g n a t u r e k e y ” : ”@Key”7 }8 } ,9 ” s e c u r i t y ” : [ {

10 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{11 ” r e g i s t r a t i o n C h e c k ” : ”@NodeID” ,12 ” s i g n a t u r e k e y C h e c k ” : ”@NodeID , @Key”13 } ] ,14 ” v e r i f i c a t i o n U n k n o w n S o u r c e ” : [{15 ” s i g n a t u r e k e y U n d e f i n e d M a r k ” : ” u n d e f i n e d ” ,16 ” i d e n t i f i e r C h e c k ” : ”@NodeID”17 } ]18 } ] ,19 ” r e s p o n s e ” : [ {20 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{21 ” r e g i s t r a t i o n C h e c k ” : t r u e ,22 ” s i g n a t u r e k e y C h e c k ” : t r u e ,23 ” s e s s i o n A s s i g n m e n t ” : ”@NodeID , t imes t amp ”24 } ,25 {26 ” s i g n a t u r e k e y C h e c k ” : f a l s e ,27 ” a c c e s s D e n i e d ” : ”@NodeID”28 } ] ,29 ” v e r i f i c a t i o n U n k n o w n S o u r c e ” : [{30 ” s e s s i o n A s s i g n m e n t ” : ”@NodeID , t imes t amp ”31 } ]32 } ]33 }}

Listing 1: Node access control sample policy

Once the node has completed the access controlphase, then it can send data to NOS. Listing 2 high-lights the requested inputs for the corresponding policy,named NodeDataTransmission, which are: the sessionidentifier, previously assigned by the NOS to the nodeduring the access control phase; the node identifier; thedata itself and the data type. Note that at this stage nosecurity operations have been performed yet: if all therequested inputs are present (i.e., requiredInformationaction is true), the data are stored in Raw Data storage

unit (i.e., storeData action is activated for the actualnode). Data gets discarded only if the transmitting nodefails to provide the required information to the NOS(i.e., discardData action is undertaken).

1 { ” NodeDa taTransmis s ion ” : {2 ” p o l i c y ” : ” NodeDa taTransmis s ion ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” @Session ” ,6 ” i d e n t i f i e r ” : ”@NodeID” ,7 ” d a t a ” : ”@d” ,8 ” d a t a t y p e ” : ”@dt”9 }

10 } ,11 ” r e s p o n s e ” : [ {12 ” v e r i f i c a t i o n I n p u t ” : [{13 ” r e q u i r e d I n f o r m a t i o n ” : t r u e ,14 ” s t o r e D a t a ” : ”@NodeID ,@d, @dt”15 } ,16 {17 ” r e q u i r e d I n f o r m a t i o n ” : f a l s e ,18 ” d i s c a r d D a t a ” : ”@NodeID ,@d, @dt”19 } ]20 }}

Listing 2: Node data transmission sample policy

As detailed in Section III, in the NOS there areprocessing modules that periodically fetch data fromRaw Data or Normalized Data storage units and processthem. The policy invoked in this step is called Node-DataProcessing and, as shown in Listing 3, receivesin input the same values of the NodeDataTransmissionpolicy, but the action of data evaluation is enforced,before sending processed data to the publish/subscribesystem. For registered sources, the NOS performs de-cryptionData and decryptionDatatype operations, thusdecrypting the data and the corresponding data typeusing the key of the actual node. Hence, for bothregistered and non-registered sources, scoreAssessmentis executed and a score for each security and qualityproperty is assigned to the data.

1 { ” N o d e D a t a P r o c e s s i n g ” : {2 ” p o l i c y ” : ” N o d e D a t a P r o c e s s i n g ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” @Session ” ,6 ” i d e n t i f i e r ” : ”@NodeID” ,7 ” d a t a ” : ”@d” ,8 ” d a t a t y p e ” : ”@dt”9 }

10 } ,11 ” r e s p o n s e ” : [{12 ” e v a l u a t i o n R e g i s t e r e d S o u r c e ” : [{13 ” d e c r y p t i o n D a t a ” : ”@d, @NodeID” ,14 ” d e c r y p t i o n D a t a t y p e ” : ”@dt , @NodeID” ,15 ” s c o r e A s s e s s m e n t ” : ”@d, @NodeID”16 } ] ,17 ” e v a l u a t i o n N o n R e g i s t e r e d S o u r c e ” : [{18 ” s c o r e A s s e s s m e n t ” : ”@d, @NodeID”19 } ]20 } ]21 }}

Listing 3: Node data processing sample policy

Listing 4 refers to the access request from auser/application who wants to receive data from a NOS;

11

such a request is sent to the MQTT broker, which per-forms an access request to the Enforcement Engine. Thecorresponding policy, named UserAccessControl, is in-voked before sending any data to the requesting entity. Itverifies whether the user/application is registered, usingfor such a purpose the following parameters: user name,user/application identifier, signature key and a function,previously specified during the registration phase. Thepolicy verification process includes two cases. If theuser/application is registered, the NOS receives in inputthe user/application identifier, the function and the sig-nature key and can perform registrationCheck (i.e., theidentifier is known and valid for the specified function)and signaturekeyCheck (i.e, identifier, function and keyare compliant for the requesting user/application). If theuser/application is unknown, then the key is marked asundefined by the action signaturekeyUndefinedMark andthe user/application is not authorized by the enforce-ment engine to access the system. If a user/applicationtries to register with wrong credentials, for examplewith a function different from the one declared duringthe registration phase or with a different key, thenthe enforcement engine generates a negative response,alerts the user/application (see Figure 6 in Section VI)and does not allow any interactions with IoT system.Otherwise, in the case that the checks have been passed,the user/application is allowed to interact with NOS anda pseudo-random session identifier is assigned by thesessionAssignment function.

1 { ” U s e r A c c e s s C o n t r o l ” : {2 ” p o l i c y ” : ” U s e r A c c e s s C o n t r o l ” ,3 ” i n p u t ” : {4 ” u s e r ” : {5 ” username ” : ”@Username” ,6 ” i d e n t i f i e r ” : ”@UserID” ,7 ” s i g n a t u r e k e y ” : ”@Key” ,8 ” f u n c t i o n ” : ” @Function ”9 }

10 } ,11 ” s e c u r i t y ” : [{12 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{13 ” r e g i s t r a t i o n C h e c k ” : ”@UserID , @Function ” ,14 ” s i g n a t u r e k e y C h e c k ” : ”@UserID , @Key,

@Function ” ,15 } ] ,16 ” v e r i f i c a t i o n U n k n o w n U s e r ” : [{17 ” s i g n a t u r e k e y U n d e f i n e d M a r k ” : ” u n d e f i n e d ”18 } ]19 } ] ,20 ” r e s p o n s e ” : [ {21 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{22 ” r e g i s t r a t i o n C h e c k ” : t r u e ,23 ” s i g n a t u r e k e y C h e c k ” : t r u e ,24 ” s e s s i o n A s s i g n m e n t ” : ”@UserID , @Function ,

t imes t amp ”25 } ,26 {27 ” s i g n a t u r e k e y C h e c k ” : f a l s e ,28 ” a c c e s s D e n i e d ” : ”@UserID , @Function ”29 } ] ,30 ” v e r i f i c a t i o n U n k n o w n U s e r ” : [{31 ” a c c e s s D e n i e d ” : ”@UserID , @Function ”32 } ]33 } ]

34 }}

Listing 4: User access control sample policy

Once the user/application has completed the accesscontrol phase and is authenticated, then it can receivedata from NOS by activating the corresponding sub-scription to the MQTT broker. Listing 5 highlights therequested inputs for the corresponding policy, namedServiceRequest, which are: (i) a session identifier, givenby NOS to the user/application after the access controlphase (computed randomly at each access, as for thenodes); (ii) the username and the identifier; (iii) thefunction; (iv) the requested service, along with the userpreferences in terms of security and quality.

For the service invocation, as already discussed inSection III, we treat a resource as an object identified bya hierarchical name (e.g., a URI). A service is conceivedas a software able to fulfill a specific task making useof the available data. There is no direct interactionamong users/applications and NOS resources, but awell-defined programming interface is needed througha software application. Resources can be accessed byusers/applications only once they are published as objectinstances. Note that at this stage no security operationsare performed: the request is elaborated by the systemif all the inputs are valid (i.e., requiredInformationaction is true); if not, the request is discarded by theenforcement engine (i.e., requiredInformation action isfalse). The security and quality preferences are notmandatory: if they are omitted, the enforcement enginedoes not discard the request, but sets the correspondingconstraints to the lowest admissible values.

1 { ” S e r v i c e R e q u e s t ” : {2 ” p o l i c y ” : ” S e r v i c e R e q u e s t ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” @Session ” ,6 ” username ” : ”@Username” ,7 ” i d e n t i f i e r ” : ”@UserID” ,8 ” f u n c t i o n ” : ” @Function ” ,9 ” s e r v i c e ” : ” @Service ” ,

10 ” s e c u r i t y P r e f e r e n c e s ” : ” @ c o n f i d e n t i a l i t y ,@ i n t e g r i t y , @privacy , @ a u t h e n t i c a t i o n ” ,

11 ” q u a l i t y P r e f e r e n c e s ” : ” @accuracy ,@prec i s ion , @t ime l ine s s , @completeness ”

12 }13 } ,14 ” r e s p o n s e ” : [ {15 ” v e r i f i c a t i o n I n p u t ” : [{16 ” r e q u i r e d I n f o r m a t i o n ” : t r u e ,17 ” p r o c e s s R e q u e s t ” : ” @Session , @Username ,

@UserID , @Function , @Service ,@ c o n f i d e n t i a l i t y , @ i n t e g r i t y , @privacy ,@ a u t h e n t c a t i o n , @accuracy , @prec i s ion ,@t ime l ine s s , @completeness ”

18 } ,19 {20 ” r e q u i r e d I n f o r m a t i o n ” : f a l s e ,21 ” d i s c a r d R e q u e s t ” : ” @Session , @Username ,

@UserID , @Function , @Service ”22 } ]23 } ]24 }}

Listing 5: User service request sample policy

12

Finally, the ServiceProvision policy is activated aftera data request, in order to verify the matching betweenthe request itself and the requesting user/application,in terms of identifier and function, by performingserviceAccessVerification action (Listing 6). Such apolicy receives in input the same values of the Ser-viceRequest policy. Note that the parameters describingthe requested data are sent encrypted by the requestinguser/application. Therefore, the NOS has to decryptit (i.e., decryptionRequest action). From the identifier,the NOS derives the signature key of the authenticateduser/application and uses it to decrypt the message.After the verification step, the retrieveResults actionis performed. It retrieves the data corresponding tothe requested service, for which the user/applicationis allowed to access. Before sending them back, theretrieved data are filtered on the basis of the securityand quality constraints. In case there is no matchingamong the described parameters (i.e., the user with thespecified identifier and function is not allowed to accessthe requested service), the enforcement engine blocksthe data provision process and sends an error messageto the requesting entity.

1 { ” S e r v i c e P r o v i s i o n ” : {2 ” p o l i c y ” : ” S e r v i c e P r o v i s i o n ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” @Session ” ,6 ” username ” : ”@Username” ,7 ” i d e n t i f i e r ” : ”@UserID” ,8 ” f u n c t i o n ” : ” @Function ” ,9 ” s e r v i c e ” : ” @Service ” ,

10 ” s e c u r i t y P r e f e r e n c e s ” : ” @ c o n f i d e n t i a l i t y ,@ i n t e g r i t y , @privacy , @ a u t h e n t i c a t i o n ” ,

11 ” q u a l i t y P r e f e r e n c e s ” : ” @accuracy ,@prec i s ion , @t ime l ine s s , @completeness ”

12 }13 } ,14 ” s e c u r i t y ” : [{15 ” d e c r y p t i o n R e q u e s t ” : ” @Service , @UserID” ,16 ” s e r v i c e A c c e s s V e r i f i c a t i o n ” : ” @Service ,

@UserID , @Function ”17 } ] ,18 ” r e s p o n s e ” : [ {19 ” s e r v i c e A c c e s s V e r i f i c a t i o n ” : t r u e ,20 ” r e t r i e v e R e s u l t s ” : ” @Service , @UserID ,

@Function , @ c o n f i d e n t i a l i t y , @ i n t e g r i t y ,@privacy , @ a u t h e n t c a t i o n , @accuracy ,@prec i s ion , @t ime l ine s s , @completeness ”

21 } ,22 {23 ” s e r v i c e A c c e s s V e r i f i c a t i o n ” : f a l s e ,24 ” a c c e s s D e n i e d ” : ” @Session , @Username ,

@UserID , @Function , @Service ”25 } ]26 }}

Listing 6: Service provision sample policy

VI. VALIDATION AND EVALUATION

In order to verify the effectiveness of the proposedsolution, we developed a simple use case based on theusage of open IoT data feeds. In particular, we relayedon six sensors measuring weather-relevant parameters

TABLE I: Source parameters

Parameters Source 1 Source 2 Source 3 Source 4 Source 5 Source 6Authentication 1 1 0 1 0 0Security schema score 10 6 0 2 0 0Privacy schema score 10 6 0 2 0 0Timeliness 9 8 6 3 9 7Completeness 9 10 8 6 7 10Accuracy 9 7 5 6 7 10Precision 9 8 4 5 8 9

and co-located within the meteorological station in thesmall town of Campodenno (Trentino, Italy) and canbe accessed through the Trentino Open Data portal2.The measurements cover temperature, humidity, wind,energy consumption and air quality parameters.

In the experimental setup, the prototypical NOS im-plementation is deployed on a Raspberry Pi. A laptopis used to emulate the behaviour of a set of nodes,basically reading data from the aforementioned feedsand sending them to the NOS as if they came fromsix different nodes. Laptop and Raspberry communicatevia a WiFi network. The laptop runs also a simplevisualization service, which fetches, according to user-defined constraints, data from the NOS and displaysthem. User can express constraints in terms of therequired security and quality levels, including aspectssuch as confidentiality, integrity, privacy, authentication,completeness, timeliness, and accuracy, as shown in thedashboard in Figure 4. As an example, we assigned tothe six different data sources considered the security andquality scores reported in Table I.

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

Fig. 4: User Dashboard

A first analysis carried out concerns the storagecapacity required by the system for carrying out its op-erations. In this respect, it is worth recalling that NOSsdo not support persistent storage of IoT-generated data.Rather, data are temporarily cached on the NOS whilebeing processed before being submitted to the MQTTbroker. NOS has therefore to provide only a temporarystorage. When data are further pushed to or pulled from

2http://dati.trentino.it/dataset/raw-data-in-near-realtime-stazione-cmd001

13

the server which handles the topics notification to sub-scribers, data can be safely flushed from the NOS. In ourprototypical implementation, we used the in-memorycapability of MongoDB for Raw Data and NormalizedData collections, while Config and Sources databasesare persistently stored on the local hard disk. Since NOSruns on a Raspberry Pi, the maximum storage capacityfor IoT data with the actual technology corresponds to1 gigabyte (i.e., the RAM provided by Raspberry Pi 2and 3). In our implementation, we include a routine incharge of removing from Raw Data the data alreadynormalized and from Normalized Data the data alreadypublished. We measured the memory occupancy of NOSduring operations, which resulted in an average slightlyless than 7 megabyte. Such a value is only indicative,as the memory occupancy depends on a number offactors, notably: (i) the frequency of data fetching fromsources (in our example 10 packets per second); (ii) thefrequency of execution of the routines for removing datafrom non-persistent collections (in our example every 5minutes); (iii) the number of sources.

A further evaluation is performed in order to estimatethe latency introduced by NOS and the policy enforce-ment framework. Figure 5 shows the results obtainedfrom one run of one NOS prototype with the six datasources just described over a period of one hour fortwo different reading data rates (i.e., how often the NOSqueries the data sources to fetch data), 10 and 20 packetsper second, respectively. The graph shows that the meandelay is almost constant over time. Furthermore, theintroduced latency does not exceed 6.5 ms in our testcase, a promising result in terms of the ability of thesolution to deal with near real-time analysis of IoT data.

Fig. 5: Latency introduced by the NOS and the policyenforcement framework.

As regards the enforcement actions undertaken byNOS, we have analyzed: (i) the node access controlfor a registered source; (ii) the node access controlfor a non-registered source; (iii) the data transmissionfor a registered source; (iv) the data processing for aregistered source; (v) the user access control along witha violation attempt; (vi) a user service request along

with a violation attempt; (vii) a user service provision.Before sending their data to NOS, the registered

sources perform the access control operation. For ex-ample in Listing 7 is represented the policy activatedfor Source 1: the request is valid if the signature keyis compliant with the one owned by NOS. We supposethat the session identifier randomly generated by thenode identifier and the actual timestamp is 2016-03-2409:15:00 (as shown in Listings 8 and 9).

1 { ” NodeAccessCon t ro l ” : {2 ” p o l i c y ” : ” NodeAccessCon t ro l ” ,3 ” i n p u t ” : {4 ” node ” : {5 ” i d e n t i f i e r ” : ” 1 ” ,6 ” s i g n a t u r e k e y ” : ”∗∗∗∗∗ ”7 }8 } ,9 ” s e c u r i t y ” : [ {

10 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{11 ” r e g i s t r a t i o n C h e c k ” : ” 1 ” ,12 ” s i g n a t u r e k e y C h e c k ” : ” 1 ,∗∗∗∗∗ ”13 } ]14 } ] ,15 ” r e s p o n s e ” : [ {16 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{17 ” r e g i s t r a t i o n C h e c k ” : t r u e ,18 ” s i g n a t u r e k e y C h e c k ” : t r u e ,19 ” s e s s i o n A s s i g n m e n t ” : ” 1 , 2016−03−24 09

: 1 5 : 0 0 ”20 } ]21 } ]22 }}

Listing 7: Node access control - registered source

In Listing 8 the same action is presented for the non-registered Source 3; in this case the enforced action isthe tracking of the node.

1 { ” NodeAccessCon t ro l ” : {2 ” p o l i c y ” : ” NodeAccessCon t ro l ” ,3 ” i n p u t ” : {4 ” node ” : {5 ” i d e n t i f i e r ” : ” 3 ”6 }7 } ,8 ” s e c u r i t y ” : [ {9 ” v e r i f i c a t i o n U n k n o w n S o u r c e ” : [{

10 ” s i g n a t u r e k e y U n d e f i n e d M a r k ” : ” u n d e f i n e d ” ,11 ” i d e n t i f i e r C h e c k ” : ” 3 ”12 } ]13 } ] ,14 ” r e s p o n s e ” : [ {15 ” v e r i f i c a t i o n U n k n o w n S o u r c e ” : [{16 ” s e s s i o n A s s i g n m e n t ” : ” 1 , 2016−03−24 09

: 1 5 : 0 0 ”17 } ]18 } ]19 }}

Listing 8: Node access control - non-registered source

Now we suppose that the registered Source 1 trans-mits data to NOS (Listing 9). Function encr specifiesthat the parameters of the message are encrypted. Theonly difference between this node and a non-registerednode is that, in the latter case, the parameters of themessage would not be encrypted. The enforcementengine verifies whether the four requested values (i.e.,

14

session, identifier, data, datatype) are present in themessage received by NOS. If this is not the case,the NOS discards the message and, possibly, preventsother communications with the same source. Note thata message sent from a node may include also other data(which depend on the specific device) besides the onesrequested by the policy (e.g., a timestamp, a location):the policy specifies conditions on the mandatory onesonly.

1 { ” NodeDa taTransmis s ion ” : {2 ” p o l i c y ” : ” NodeDa taTransmis s ion ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” 12345 ” ,6 ” i d e n t i f i e r ” : ” 1 ” ,7 ” d a t a ” : ” e n c r ( 1 0 . 7 ) ” ,8 ” d a t a t y p e ” : ” e n c r ( dou b l e wind speed ) ”9 }

10 } ,11 ” r e s p o n s e ” : [ {12 ” v e r i f i c a t i o n I n p u t ” : [{13 ” r e q u i r e d I n f o r m a t i o n ” : t r u e ,14 ” s t o r e D a t a ” : ” 1 , e n c r ( 1 0 . 7 ) , e n c r ( do ub l e

wind speed ) ”15 }16 } ]17 } ]18 }}

Listing 9: Node data transmission

After validating such data, NOS can process them.Listing 10 shows the corresponding processing policy.

1 { ” N o d e D a t a P r o c e s s i n g ” : {2 ” p o l i c y ” : ” N o d e D a t a P r o c e s s i n g ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” 12345 ” ,6 ” i d e n t i f i e r ” : ” 1 ” ,7 ” d a t a ” : ” e n c r ( 1 0 . 7 ) ” ,8 ” d a t a t y p e ” : ” e n c r ( dou b l e wind speed ) ”9 }

10 } ,11 ” r e s p o n s e ” : [{12 ” e v a l u a t i o n R e g i s t e r e d S o u r c e ” : [{13 ” d e c r y p t i o n D a t a ” : ” e n c r ( 1 0 . 7 ) , 1 ” ,14 ” d e c r y p t i o n D a t a t y p e ” : ” e n c r (km / h wind

speed ) , 1 ” ,15 ” s c o r e A s s e s s m e n t ” : ” 1 0 . 7 , 1 ”16 } ]17 } ]18 }}

Listing 10: Node data processing

Now we suppose that the user Bob had registeredhimself to the weather service with the username Boband 473 as identifier, in order to be notified aboutthe measurements acquired in the considered area forsome monitoring actions he has to do for his employer.Therefore he registers himself with the role of Monitor.Firstly, he has to perform the access control: Listing11 describes the activated policy. We suppose that thegenerated session identifier is 13240. If the credentialsare not valid, it could be a violation attempts, thenthe enforcement engine forces the NOS to prevent userinteractions, as illustrated in Figure 6.

1 { ” U s e r A c c e s s C o n t r o l ” : {2 ” p o l i c y ” : ” U s e r A c c e s s C o n t r o l ” ,3 ” i n p u t ” : {4 ” u s e r ” : {5 ” username ” : ”Bob” ,6 ” i d e n t i f i e r ” : ” 473 ” ,7 ” s i g n a t u r e k e y ” : ”∗∗∗∗∗ ” ,8 ” f u n c t i o n ” : ” Moni to r ”9 }

10 } ,11 ” s e c u r i t y ” : [{12 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{13 ” r e g i s t r a t i o n C h e c k ” : ” 473 , Moni to r ” ,14 ” s i g n a t u r e k e y C h e c k ” : ” 473 ,∗∗∗∗∗ , Moni to r ”15 } ]16 } ] ,17 ” r e s p o n s e ” : [ {18 ” v e r i f i c a t i o n R e g i s t r a t i o n ” : [{19 ” r e g i s t r a t i o n C h e c k ” : t r u e ,20 ” s i g n a t u r e k e y C h e c k ” : t r u e ,21 ” s e s s i o n A s s i g n m e n t ” : ” 473 , Monitor ,

2016−03−24 09 : 2 0 : 0 0 ”22 } ]23 } ]24 }}

Listing 11: User access control

Fig. 6: Violation attempts of user access control

Otherwise, if the credentials are correctly verified, theuser can make the desired service requests. Listing 12shows an example of the corresponding policy invokedfor requesting the service, named Humidity and WindSpeed Real Time Measurements, along with the securityand quality constraints.

1 { ” S e r v i c e R e q u e s t ” : {2 ” p o l i c y ” : ” S e r v i c e R e q u e s t ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” 13240 ” ,6 ” username ” : ”Bob” ,7 ” i d e n t i f i e r ” : ” 473 ” ,8 ” f u n c t i o n ” : ” Moni to r ” ,9 ” s e r v i c e ” : ” Humidi ty and Wind Speed Rea l

Time Measurements ” ,10 ” s e c u r i t y P r e f e r e n c e s ” : ” 2 , 0 , 2 , 1 ” ,11 ” q u a l i t y P r e f e r e n c e s ” : ” 4 , 4 , 4 , 4 ”12 }13 } ,14 ” r e s p o n s e ” : [ {15 ” v e r i f i c a t i o n I n p u t ” : [{16 ” r e q u i r e d I n f o r m a t i o n ” : t r u e ,17 ” p r o c e s s R e q u e s t ” : ” 13240 , Bob , 4 7 3 , Monitor ,

Humidi ty and Wind Speed Real TimeMeasurements , 2 , 0 , 2 , 1 , 4 , 4 , 4 , 4 ”

18 }19 } ]

15

20 }}Listing 12: User service request

At this point, such a request has to be analyzed inorder to establish if the user is entitled to receive thedata corresponding to the service (Listing 13 representsa user which has access to requested data).

1 { ” S e r v i c e P r o v i s i o n ” : {2 ” p o l i c y ” : ” S e r v i c e P r o v i s i o n ” ,3 ” i n p u t ” : {4 ” message ” : {5 ” s e s s i o n ” : ” 13240 ” ,6 ” username ” : ”Bob” ,7 ” i d e n t i f i e r ” : ” 473 ” ,8 ” f u n c t i o n ” : ” Moni to r ” ,9 ” s e r v i c e ” : ” Humidi ty and Wind Speed Rea l

Time Measurements ” ,10 ” s e c u r i t y P r e f e r e n c e s ” : ” 2 , 0 , 2 , 1 ” ,11 ” q u a l i t y P r e f e r e n c e s ” : ” 4 , 4 , 4 , 4 ”12 }13 } ,14 ” s e c u r i t y ” : [{15 ” d e c r y p t i o n R e q u e s t ” : ” Humidi ty and Wind

Speed Real Time Measurements , 4 7 3 ” ,16 ” s e r v i c e A c c e s s V e r i f i c a t i o n ” : ” Humidi ty

and Wind Speed Rea l Time Measurements , 4 7 3 ,Moni to r ”

17 } ] ,18 ” r e s p o n s e ” : [ {19 ” s e r v i c e A c c e s s V e r i f i c a t i o n ” : t r u e ,20 ” r e t r i e v e R e s u l t s ” : ” Humidi ty and Wind

Speed Real Time Measurements , 4 7 3 , Moni tor ,2 , 0 , 2 , 1 , 4 , 4 , 4 , 4 ”

21 } ]22 }}

Listing 13: Service provision

There are two possible outcomes: (i) the user withMonitor function is allowed by the sensors data admin-istrator to access the requested measurements for themonitoring scope; (ii) the user is not allowed to accessthese data for the declared scope. In the former case,the dashboard shown to the user is the one representedin Figure 7(d); from here, the user can also changedynamically the security and quality settings as can beseen in Figure 7. If no security or quality constraint isspecified, all data is considered valid and the resultinggraphs for wind speed (in Km/h) and humidity (in %)look as in Figure 7(a). In Figure 7(b) some securityfilters are applied; in particular, the system shows to theuser only the data (i) provided by authenticated sources,(ii) for which the integrity is verified, (iii), for which thelevel of privacy and confidentiality is equal or higherthan 6. Obviously in this case some data is dropped,as it fails to meet the criteria specified by the user interms of security and quality of the data to use. Thegraph in Figure 7(c) is obtained without any constraintspecified on security, but considering valid only datascoring at least 6 in completeness and timeliness, and8 in accuracy and precision. In the latter case, it wouldbe a violation attempt, then the response of the systemis the one shown in Figure 8.

We remark that this represents only an example ofa very simple NOS application in a context charac-

terised by the analysis of real-time data. Other possibleapplications include energy management in a smarthome/smart building scenario; monitoring of businessprocesses and productive activities in real time; smartretail experiences services and, more in general, anyapplication/service where decisions (either manual orautomated) have to be taken based on IoT-generateddata. This class of applications is expected to play akey role in the adoption of IoT technologies across avariety of vertical domains.

One aspect which deserves some further clarificationsrefers to the fact that in our example we consideredone single NOS. While indeed we aim to deploy thepresented middleware in a distributed environment, froman analysis of NOS functionality it is not difficult to seethat no NOS-to-NOS coordination is strictly required.In fact, NOSs are able to: (i) independently handlethe data sources, without the need to inform the otherNOSs of their active and past interactions; (ii) be inde-pendently re-configured by IoT system administrators;(iii) independently assign topics and publish data on thebasis of the defined rules; (iv) enforce the applicationof the policies defined for the IoT system. We cansafely conclude therefore that considering a single NOS-scenario for validation purposes does not represent alimiting factor.

VII. CONCLUSIONS

Security and data quality issues represent potentialshow-stoppers for the market take-up of IoT-based prod-ucts and services in various operational scenarios andvertical application domains. To tackle these issues, inthis article we have introduced and discussed a flexiblesecurity and data quality enforcement framework, co-herently integrated within a distributed IoT middlewareplatform.

The presented framework supports security and dataquality enforcement policies, re-usable across differentdomains and able to detect violation attempts. Thefeasibility and performance of the proposed approachhave been validated by means of a prototypical imple-mentation and the development of a simple, yet real-world, use case.

In the next future we will focus on the deploymentof the middleware and the framework in a large-scalepilot focussed on building automation, in order to test itsrobustness and scalability in operational environment.

REFERENCES

[1] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac,“Survey internet of things: Vision, applications and researchchallenges,” Ad Hoc Networks, vol. 10, no. 7, pp. 1497–1516,2012.

[2] S. Sicari, A. Rizzardi, L. A. Grieco, and A. Coen-Porisini,“Security, privacy and trust in internet of things: The roadahead,” Computer Networks, vol. 76, pp. 146–164, 2015.

[3] R. H. Weber, “Internet of things - new security and privacychallenges,” Computer Law & Security Review, vol. 26, no. 1,pp. 23–30, January 2010.

16

(a) No\ Filters (b) Security\ Filters

(c) Quality\ Filters (d) All\ Filters

Fig. 7: Results

Fig. 8: Violation attempt of user service request

[4] H. Feng and W. Fu, “Study of recent development about privacyand security of the internet of things,” in 2010 InternationalConference on Web Information Systems and Mining (WISM),Sanya, October 2010, pp. 91–95.

[5] R. Roman, J. Zhou, and J. Lopez, “On the features andchallenges of security and privacy in distributed internet ofthings,” Computer Networks, vol. 57, no. 10, pp. 2266–2279,July 2013.

[6] J. Anderson and L. Rainie, “The internet of thingswill thrive by 2025, PewResearch Internet Project,”http://www.pewinternet.org/2014/05/14/internet-of-things/,May 2014, May 2014.

[7] S. Bandyopadhyay, M. Sengupta, S. Maiti, and S. Dutta, “Asurvey of middleware for internet of things,” in Third Inter-national Conferences, WiMo 2011 and CoNeCo 2011, Ankara,

Turkey, June 2011, pp. 288–296.

[8] M. A. Chaqfeh and N. Mohamed, “Challenges in middlewaresolutions for the internet of things,” in 2012 InternationalConference on Collaboration Technologies and Systems (CTS),Denver, CO, May 2012, pp. 21–26.

[9] S. Babar, A. Stango, N. Prasad, J. Sen, and R. Prasad, “Pro-posed embedded security framework for internet of things(iot),” in 2011 2nd International Conference on Wireless Com-munication, Vehicular Technology, Information Theory andAerospace and Electronic Systems Technology, Wireless VITAE2011, Chennai, India, March 2011, pp. 1 – 5.

[10] S. Sicari, A. Rizzardi, C. Cappiello, and A. Coen-Porisini, “ANFP model for internet of things applications,” in Proc. of IEEEWiMob, Larnaca, Cyprus, Oct 2014, pp. 164–171.

[11] A. Rizzardi, D. Miorandi, S. Sicari, C. Cappiello, and A. Coen-Porisini, “Networked smart objects: Moving data processingcloser to the source,” in 2nd EAI International Conference onIoT as a Service, Oct 2015.

[12] S. Sicari, C. Cappiello, F. D. Pellegrini, D. Miorandi, andA. Coen-Porisini, “A security-and quality-aware system archi-tecture for internet of things,” Information Systems Frontiers,pp. 1–13, 2014.

[13] S. Sicari, S. Hailes, D. Turgut, S. Sharaffedine, and D. U.,Security, Privacy and Trust Management in the Internet ofThings era- SePriT, 11th ed. Special Issue of Ad Hocnetworks, Elsevier, 2013.

[14] M. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann,

17

“Service-oriented computing: State of the art and researchchallenges,” Computer, vol. 40, no. 11, pp. 38–45, Nov 2007.

[15] Q. Yu, X. Liu, A. Bouguettaya, and B. Medjahed, “Deployingand managing web services: Issues, solutions, and directions,”The VLDB Journal, vol. 17, no. 3, pp. 537–572, May 2008.

[16] “Peertrack,” http://cs.adelaide.edu.au/peertrack/.

[17] “Perci (pervasiveservice interaction),”http://www.hcilab.org/projects/perci/index.htm.

[18] M. Palattella, N. Accettura, X. Vilajosana, T. Watteyne,L. Grieco, G. Boggia, and M. Dohler, “Standardized protocolstack for the internet of (important) things,” CommunicationsSurveys Tutorials, IEEE, vol. 15, no. 3, pp. 1389–1406, Third2013.

[19] I. Bagci, S. Raza, T. Chung, U. Roedig, and T. Voigt, “Com-bined secure storage and communication for the internet ofthings,” in 2013 IEEE International Conference on Sensing,Communications and Networking, SECON 2013, New Orleans,LA, United States, June 2013, pp. 523–631.

[20] D. Boswarthick, O. Elloumi, and O. Hersent, M2M Communi-cations: A Systems Approach, 1st ed. Wiley Publishing, 2012.

[21] D. Conzon, T. Bolognesi, P. Brizzi, A. Lotito, R. Tomasi,and M. Spirito, “The virtus middleware: An xmpp basedarchitecture for secure IoT communications,” in 2012 21stInternational Conference on Computer Communications andNetworks, ICCCN 2012, Munich, Germany, July 2012, pp. 1–6.

[22] A. Gomez-Goiri, P. Orduna, J. Diego, and D. L. de Ipina,“Otsopack: Lightweight semantic framework for interoperableambient intelligence applications,” Computers in Human Be-havior, vol. 30, pp. 460–467, January 2014.

[23] C. H. Liu, B. Yang, and T. Liu, “Efficient naming, addressingand profile services in internet-of-things sensory environments,”Ad Hoc Networks, vol. 18, no. 0, pp. 85–101, 2013.

[24] “European FP7 IoT@Work project,” http://iot-at-work.eu.

[25] “iCORE project,” http://www.iot-icore.eu.

[26] “IOT-EST project,” http://ict-iotest.eu/iotest/.

[27] “EBBITS project,” http://www.ebbits-project.eu/.

[28] “Usable trust in the internet of things,” http://www.utrustit.eu/.

[29] “BUTLER project,” http://www.iot-butler.eu.

[30] B. Guo, D. Zhang, Z. Wang, Z. Yu, and X. Zhou, “Opportunisticiot: Exploring the harmonious interaction between human andthe internet of things,” J. Netw. Comput. Appl., vol. 36, no. 6,pp. 1531–1539, Nov. 2013.

[31] A. Metzger, C.-H. Chi, Y. Engel, and A. Marconi, “Researchchallenges on online service quality prediction for proactiveadaptation,” in Software Services and Systems Research -Results and Challenges (S-Cube), 2012 Workshop on European,June 2012, pp. 51–57.

[32] F. Li, S. Nastic, and S. Dustdar, “Data quality observationin pervasive environments,” in Proceedings of the 2012 IEEE15th International Conference on Computational Science andEngineering. IEEE Computer Society, 2012, pp. 602–609.

[33] Z. Wu and L. Wang, “An innovative simulation environmentfor cross-domain policy enforcement,” Simulation ModellingPractice and Theory, vol. 19, no. 7, pp. 1558–1583, August2011.

[34] Y. Elrakaiby, F. Cuppens, and N.Cuppens-Boulahia, “Formalenforcement and management of obligation policies,” Data &Knowledge Engineering, vol. 71, no. 1, pp. 127–147, January2012.

[35] D. Ferraiolo and V. A. ans S. Gavrila, “The policy machine:A novel architecture and framework for access control policyspecification and enforcement,” Journal of Systems Architec-ture, vol. 57, no. 4, pp. 412–424, April 2011.

[36] R. Sandhu, E. Coyne, H. Feinstein, and C. Youman, “Role-based access control models,” IEEE Computer, vol. 29, no. 2,pp. 38–47, February 1996.

[37] D. Brewer and M. Nash, “The chinese wall security policy,” inProceedings., 1989 IEEE Symposium on Security and Privacy,Oakland, CA, May 1989, pp. 206–214.

[38] M. Bishop, Computer Security: Art and Science. AddisonWesley, 2003.

[39] J. Rao, A. Sardinha, and N. Sadeh, “A meta-control architec-ture for orchestrating policy enforcement across heterogeneousinformation sources,” Web Semantics: Science, Services andAgents on the World Wide Web, vol. 7, no. 1, pp. 40 – 56,2009.

[40] ——, “A meta-control architecture for orchestrating policyenforcement across heterogeneous information sources,” WebSemantics: Science, Services and Agents on the World WideWeb, vol. 7, no. 1, pp. 40–56, January 2009.

[41] M. Langar, M. Mejri, and K. Adi, “Formal enforcement ofsecurity policies on concurrent systems,” Journal of SymbolicComputation, vol. 46, no. 9, pp. 997–1016, Semptember 2011.

[42] J. Baeten, “A brief history of process algebra,” Theoret. Com-put. Sci., vol. 335, no. 2-3, pp. 131–146, December 2005.

[43] R. Macfarlane, W. Buchanan, E. Ekonomou, O. Uthmani,L. Fan, and O. Lo, “Formal security policy implementationsin network firewalls,” Computers & Security, vol. 31, no. 2,pp. 253–270, March 2012.

[44] J. A. Pavlich-Mariscal, S. A. Demurjian, and L. D. Michel, “Aframework for security assurance of access control enforcementcode,” Computers & Security, vol. 29, no. 7, pp. 770 – 784,2010.

[45] M. Dell’Amico, M. S. I. G. Serme, A. S. de Oliveira, andY. Roudier, “Hipolds: A hierarchical security policy languagefor distributed systems,” Information Security Technical Report,vol. 17, no. 3, pp. 81–92, February 2013.

[46] J. Singh, J. Bacon, and D. Eyers, “Policy enforcement withinemerging distributed, event-based systems,” in DEBS 2014- Proceedings of the 8th ACM International Conference onDistributed Event-Based Systems, 2014, pp. 246–255.

[47] “Ibm and eurotech, ”mqtt v3.1 protocol specification”,”http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html.

[48] “Mosquitto, ”an open source mqtt v3.1/v3.1.1 broker”,”http://mosquitto.org.

[49] “Node.JS,” http://nodejs.org/.[50] “MongoDB,” http://www.mongodb.org/.[51] N. Ulltveit-Moe and V. Oleshchuk, “Decision-cache based

XACML authorisation and anonymisation for XML docu-ments,” Computer Standards & Interfaces, vol. 34, no. 6, pp.527 – 534, 2012.

[52] V. Goyal, O. Pandey, A. Sahai, and B. Waters, “Attribute-basedencryption for fine-grained access control of encrypted data,”in Proceedings of the 13th ACM Conference on Computer andCommunications Security, 2006, pp. 89–98.

[53] R. S. Sandhu, “Role-based access control,” vol. 46, pp. 237–286, 1998.

18

Sabrina Sicari Sabrina Sicari is Assis-tant Professor at Universita’ degli Studidell’Insubria (Italy). She received her masterdegree in Electronical Engineering in 2002and her Ph.D. in Computer and Telecom-munications Engineering in 2006 from Uni-versita’ degli Studi di Catania (Italy). FromSeptember 2004 to March 2006 she has beena research scholar at Politecnico di Milano.Since May 2006 she works at Universita’degli Studi dell’Insubria in the software en-

gineering group. Her research interests are on wireless sensor net-works (WSN), risk assessment methodology and privacy models. Sheis a member of the Editorial Board of Computer Network (Elsevier).She is the general co-chair of S-Cube’09, a steering committeemember of S-Cube’10, S-Cube’11, S-Cube’13 and S-Cube’14, guesteditor for the ACM Monet Special Issue, named “Sensor, System andSoftware” and Ad Hoc Special Issue on Security, Privacy and TrustManagement in Internet of Things era (SePriT), TPC member andreviewer for many journals and conferences.

Alessandra Rizzardi Alessandra Rizzardireceived BS and MS degree in ComputerSciences with 110/110 cum laude at Uni-versity of Insubria (Italy) in 2011 and 2013respectively. Since 2011 for her MS thesis,she began working in the research group ofProf. Alberto Coen-Porisini and Dr. SabrinaSicari. From November 2013 she is a Ph.D.student at the University of Insubria underthe guidance of Dr. Sabrina Sicari. Her re-search activity is focused on issues related

to wireless sensor networks and internet of things, in particular onsecurity and privacy issues in IoT.

Daniele Miorandi Daniele Miorandi is Ex-ecutive VP R&D at U-Hopper. He receiveda PhD in Communications Engineering fromUniv. of Padova, Italy, in 2005. His cur-rent research interests include modellingand performance analysis of large-scale net-worked systems, ICT platforms for socio-technical systems and distributed optimisa-tion for smart grids. Dr. Miorandi has co-authored more than 120 papers in interna-tionally refereed journals and conferences.

He serves on the Steering Committee of various international events,for some of which he was a co-founder (Autonomics and ValueTools).He also serves on the TPC of leading conferences in the networkingand computing fields. He is a member of ACM, ISOC and ICST.

Cinzia Cappiello Cinzia Cappiello is As-sistant Professor in computer engineering atthe Politecnico di Milano (Italy) from whichshe holds a Ph.D. in Information Technology(2005). Her research interests regard dataand information quality aspects in service-based and Web applications, Web services,sensor data management, and Green IT. Onsuch topics, she published papers in inter-national journals and conferences. Cinzia isAssociate Editor of the ACM Journal of

Data and Information Quality. She has been co-chair of the workshops“Quality in Databases” in conjuction with VLDB 2010, “Data andInformation Quality” in conjuction with CAiSE 2005, “Quality inWeb Engineering” in conjuction with ICWE 2010-2013, and of thetracks “Information Quality Management in Innovative IS” of MCIS2012 and “Data and Information quality” of ECIS 2008.

Alberto Coen-Porisini Alberto CoenPorisini received his Dr. Eng. degreeand Ph.D in Computer Engineering fromPolitecnico di Milano (Italy) in 1987and 1992, respectively. He is Professorof Software Engineering at Universita’degli Studi dell’Insubria (Italy) since2001, Dean of the the School of Sciencefrom 2006 and Dean of the Universita’degli Studi dell’Insubria since 2012. Priorto that he was Associated Professor at

Universita’ degli Studi di Lecce (1998-2001), Assistant Professorat Politecnico di Milano (1993-2001) and Visiting Researcher withthe Computer Security Group at University of California, SantaBarbara (1992-1993). His main research interests are in the field ofspecification and design of real-time systems, privacy models andwireless sensor networks.