NUST Journal of Engineering Sciences, Vol 9, No. 2, 2017, pp.

1-10

Towards a Generic Model for Risk Analysis of the Internet of Things (IoT)
Mujahid Mohsin1, Zahid Anwar1,2 and Farhat Zaman1
1
National University of Sciences and Technology (NUST), Islamabad, Pakistan
2
Fontbonne University, St. Louis, Missouri, USA
e-mail: {13phdccsmmohsin, zahid.anwar, 13msccsfzaman}@seecs.edu.pk, zanwar@fontbonne.edu

Received: 15 September 2016 Accepted: 20 October 2016

Abstract

The Internet of Things (IoT) has spurred the interaction of a multitude of smart physical
objects with the existing cyber world. These connected “things” leverage
heterogeneous protocols, diverse capabilities and complex environmental
interdependencies, which have reshaped their risk profiles through introduction of
novel threat vectors. In this paper, we present a formal framework to model and analyze
the security risks linked with generic IoT systems. The approach uses existing and
widely-accepted Web Ontology Language (OWL) based ontologies, by extending them
with IoT-specific concepts and populating them with IoT instances. Risk assessment,
quantification and selection of viable mitigation techniques is carried out automatically
with the help of rule-based constraints and queries applied over OWL knowledgebase.
The practicality and effectiveness of the approach is verified through implementation
and evaluation over realistic IoT systems.
Keywords: Internet of Things, Automated risk analysis, IoT security modeling, IoT
ontology, OWL, SWRL.
1. Introduction Security is considered only as strong as the weakest
link in the system. Therefore, protection of the IoT
The Internet of Things (IoT) has given us a notion of infrastructures requires a thorough risk analysis of
a smartly connected world being driven by interlinked IoT devices for ensuring that they are
autonomous network of “things”; observing, properly-configured, standard-compliant and offer
interacting and implementing features with minimal adequate resiliency against traditional as well as IoT-
human intervention. The concept has received a specific threats. Manual approaches for risk
wide-acceptance, giving birth to promising assessment and management for large scale IoT
applications in all technological domains, ranging systems are not only taxing, they are also prone to ill-
from common home and personal appliances to judgements and human-errors. The situation calls for
sophisticated systems such as linked with e-Health, smart risk analysis and security planning solutions,
industrial automation and other safety-critical which can be driven by automation and machine
infrastructures. The number of connected devices has intelligence through understanding of risk semantics.
already surpassed human population and is predicted
to reach 50-100 billion by the year 2020 [1]. The goal Realizing the emerging security challenges and the
of the IoT is to “enable things to be connected proposed solution as discussed above, in this paper,
anytime, anyplace, with anything and anyone ideally we present a formal ontology-based approach for
using any path/network and any service” [2]. Such a automated risk analysis of complex IoT systems. Our
flexible communication model, coupled with the research methodology can be broadly decomposed
ever-expanding size, diversity and sophistication of into two main steps. Initially, the security capabilities
IoT devices, introduces several new threat vectors, and operational dependencies of individual IoT
thus significantly changing the security risk profiles. devices are semantically registered in a
knowledgebase, defined as a conjunction of two 2. Literature Review
ontologies i.e. IoT ontology and security ontology.
We have used Web Ontology Language (OWL) [3] Our work benefits from related research in
to encode the semantics of the domain knowledge. ontologies for the IoT and security capabilities as
After the semantic registration, security soundness well as the use of risk management approaches for
and risk exposure of registered facts is derived with IoT security. This section summarizes the state-of-
the help of rule-based constraints and queries, the-art in relevant areas.
developed using the built-in features of Semantic 2.1. Use of Ontologies for the IoT
Web Rule Language (SWRL) [4] and Semantic
Query-enhanced Web Rule Language (SQWRL) [5], Application of ontologies in the domain of IoT is an
respectively. The inferred knowledge is also used to emerging research area. The existing literature
isolate high-risk devices and short-list viable security mainly targets the efficiency, scalability and
solutions, which can be used to mitigate the interoperability aspects of IoT, with limited focus on
identified risks. The developed framework can its security issues.
therefore, be employed both at IoT design and Sensor networks claim a major share of typical IoT
integration stages and can assist to gauge as well as systems. A few noteworthy ontologies have been
restraint the system-level security risks. proposed to model various aspects of connected
The proposed approach renders the following key sensors. Compton et al. [6] presented an OWL
benefits: (a) Ontology based knowledge is ontology for reasoning and querying about sensors
hierarchical and hence reusable. We have developed and observations. Calder et al. [7] used ontologies
our work by extending existing ontologies and our about sensor-packages and constraints defined as
work can also be extended and reused in other rules to reason on real-time sensor data and detect
associated domains of IoT. (b) OWL being highly data anomalies and unexpected conditions. SSN
expressive, allows defining system knowledge with ontology [8], developed by W3C Semantic Sensor
high complexities and constraints as compared to Network Incubator Group (W3C-XG), is one of the
other approaches such as object oriented methods, recent and more formal efforts to comprehensively
database management systems and constraint model sensors and their observations. Being generic
satisfaction approaches (c) Knowledge semantics and domain-independent, the SSN ontology
defined in OWL can be automatically reasoned to integrates most of the concepts of earlier ontologies
remove inconsistencies and infer new knowledge, and models sensors' capabilities, deployment,
consistent with the global model (d) OWL and operating restrictions and the measurement process.
SWRL based system models are independent of However, none of the contributions mentioned above
actual implementation. Therefore, our approach is addressed the security related aspects of sensor
flexible in choosing implementation platforms (such networks.
as Jena, Jess, Prolog, etc), without the need to change Modeling IoT Entities: Typical IoT systems
the core model. constitute a diverse set of entities such as sensors,
The rest of the paper is organized as follows. In actuators, appliances, fixed and mobile controllers
Section 2, we present a review of related work. The and tag devices. Only a few efforts can be found in
contributions in the domain of ontology extension literature, which capture the knowledge of IoT
and alignment are presented in Section 3. Section 4 entities and their interactions. IoT-Lite [9], a
discusses different security constraints in the form of lightweight ontology, represented IoT objects,
selected rules and queries. Lastly, Section 5 presents resources and services. This ontology is primarily
the implementation and evaluation, while Section 6 focused on sensing, though it introduces some higher
concludes the paper, with pointers to the on-going level concepts of actuation as well. De et al. [10]
future work directions. proposed a suite of three ontologies modeling
entities, resources and services in the IoT domain.
IoT-O ontology [11] presented an integration of
multiple ontology modules covering the sensing,
actuation, life-cycle, energy and service aspects of experts. Our ontology-based approach can leverage
IoT. While their sensing module leveraged the SSN and extend such manual methods to automatically
ontology, the actuation module was developed reason about risk applicability and countermeasures,
separately to cover the behavioral patterns of IoT not only on individual IoT entities but can also deal
actuators. However, none of the ontologies discussed with complex and large-scale IoT systems.
above modeled the security vulnerabilities and risk
profiles of IoT systems as a whole. Moreover, they 3. Modeling IoT and Security Concepts
are also limited in capturing the holistic behavior of
IoT device-device and device-environment In this section, we discuss the contributions made
couplings. during the ontology engineering phase by presenting
the salient features of developed ontologies. The
Ontology-Driven IoT Security: Gyrard et al. [12] section begins with introduction to our ontology
designed a new ontology-based security knowledge engineering approach, followed by a discussion on
termed as Security Toolbox:Attack and important ontology concepts.
Countermeasures (STAC) for satisfying the security
requirements of ETSI Machine to Machine (M2M) 3.1. Ontology Engineering Approach
architecture. STAC categorizes security mechanisms
and attacks based on IoT communication mediums. Our research approach is focused on reuse of existing
The main goal of STAC is to target individual IoT ontologies, wherever possible by extending them
devices (rather than integrated systems), for with IoT-specific features such as abilities to sense,
motivating the designers to embed security during control, identify and impact applicable features,
the design process. Moreover, the published pertaining to both cyber and physical worlds. After a
ontology version of STAC does not cover the IoT- careful review of available options for IoT
specific instances of security mechanisms and ontologies, we shortlisted the SSN ontology [8] as
protocols, thus limiting its reusability profile. the most suitable candidate to serve as our foundation
stone. The SSN ontology models operational aspects
2.2. IoT-Specific Risk Analysis of connected sensors and adopts a modular approach
With the rise in IoT-specific security breach to offer reuse of ontology from different
incidents, the field of risk assessment and perspectives, including our desired views of data and
management for IoT related threats has also emerged observation, property and features of interest as well
as a dedicated research area. Liu et al. [13] proposed as broader system's perspectives. Additionally, SSN
a dynamic risk assessment methodology for the IoT, is already aligned with the relevant concepts of Dolce
inspired by the artificial immune system. Their Ultra-Light (DUL) ontology [17], a light weight
approach computed the changing risk value of an IoT ontology to describe generic concepts across
system based on attack intensity, as measured by multiple domains. This further enhances coherence,
different attack detection agents. In another work consistency and reusability of SSN structure.
[14], researchers discussed the security risks being However, SSN does not cover semantic definitions
contributed by the ever-increasing influx of IoT of other IoT devices such as actuators, controllers
devices. The authors critically analyzed such and identity devices. Moreover, it does not aim to
emerging risks, their root causes and viable model any security properties of sensors. Therefore,
mitigation techniques. Questionnaire-driven to support our work, we extended the SSN ontology
empirical study is another way of quantifying the in two major directions: (a) Transforming SSN into
security risks. Chang et al. [15] utilized this approach an IoT ontology with an aim to formally capture the
to investigate enterprise risk factors for governing interactions and dependencies among different IoT
the risk of IoT environments. Jacobsson et al. [16] and environmental entities. (b) Alignment of SSN
conducted an empirical and scenario-based risk with a suitable security ontology to reason about the
analysis for smart home automation systems. Such security capabilities and requirements for analyzing
empirical analyses are mostly manual and their IoT-specific risks.
findings are based on experiences and views of the
 Fig. 1: Sub-Class View of the Aligned IoT and Security Ontologies

With regards to annotation and reasoning over ontologies are very extensive and have been
security properties, we have extended the NRL comprehensively discussed in the referred literature;
security ontology [18]. The reason to select NRL is therefore, re-introducing their structure is beyond the
its flexibility and interface simplicity. NRL is a scope of this paper. Hence, the figure draws only the
collection of seven security ontologies each covering relevant concepts of DUL, SSN and NRL ontologies
a unique security domain such as security alongside the newly added concepts and
credentials, security algorithms, security assurance differentiates them with appropriate legends. The
and security concepts (includes security protocols, new concepts are prefixed as “iot:” to distinguish
mechanisms and policies) as well as dedicated them from existing concepts. The ontological
ontologies for querying and linking with OWL-S structure and design considerations of some of the
service ontology [19]. The ontologies are well- important concepts and properties are discussed in
integrated through use of inter-ontology properties the subsequent sub-sections. Few additional
and also mention a list of security objectives which concepts and properties not discussed in this section
are met by the linked security concepts. However, are introduced in Section 4, while explaining the
NRL being generic in nature does not define IoT- security constraints.
specific security requirements and capabilities. 3.2. IoT Ontology
Moreover, it does not model security risks, entity-
specific vulnerabilities and threats. Therefore, we Fig. 2 represents the relational view of new IoT and
extended the NRL ontology by adding these missing security concepts with existing concepts. It links
features. these concepts with the help of appropriate OWL
properties. Both Figures 1 and 2 are to be consulted
The resulting IoT (extended SSN) and Security
in coherence to grasp the overall structure of the new
(extended NRL) ontologies were mutually aligned
ontologies. Some important extensions made in the
using the inter-ontology relationships. Additionally,
SSN ontology are introduced below:
similar to SSN, we have used Dolce Ultra-Light
(DUL) [18] as a parent ontology to explicitly define 3.2.1. IoT Devices
and align the novel concepts using a common Different categories of IoT devices are added as sub
foundation. The overall subclass view, depicting classes of ssn:Device alongside ssn:'Sensing Device'
important concepts of the integrated ontologies, is as shown in Fig. 2. Hence, these devices inherit the
given in Fig. 1. Since DUL, SSN and NRL
 Fig. 2: Relational View of the Resulting Ontology (Arrows not labelled represent sub-class relationships)

properties of ssn:System and dul:‘Physical object’. respective security devices, depending on the
Besides inheriting the properties from their super- requirements.
classes, each device type is also defined by its unique 3.2.2. Controller
set of properties. To illustrate this further, semantic
definitions of iot:ActuatingDevice and We define controllers as those IoT devices which can
iot:SecurityDevice are given below: be used to (a) configure other devices directly or
through authorized applications or (b) force other
ActuatingDevice: Actuators are known for their devices to perform certain actions based on the
capabilities to impact the associated environmental commands generated by them. Controllers play a
properties of respective features of interest such as crucial role in any IoT network as they are primarily
the light bulb changing the luminosity (property) of used to exercise administrative privileges over
the living room (feature of interest) or the air- devices being controlled. The Controller class is
conditioner impacting on the room temperature. defined as a sub-class of dul:Role. This role can be
Thus, the iot:ActuatingDevice class is linked with assigned to any appropriate device through
ssn:Property through iot:impacts object property. As iot:hasRole property. Controllers iot:collects the
a subclass of ssn:Device and dul:‘Physical object’, observations made by linked sensors and based on
iot:ActuatingDevice inherits their properties as well. the collected information, control authorized IoT
Therefore, actuators can be characterized by their devices. Therefore, the concept is linked with
respective operating and survival ranges and they ssn:Device through iot:controls property. They
may also constitute other devices as sub-systems normally use some iot:Application for Controlling;
(through ssn:‘has subsystem’ property). therefore, Controller and Application are defined as
SecurityDevice: The SecurityDevice class is defined domain and range respectively for property
as a subclass of ssn:Device and an equivalent class to iot:controlsThrough.
∃ : ∙ : ℎ 3.2.3. Deployment Sector
(i.e. any device implementing some security
mechanism is categorized as a security device and all DeploymentSector is introduced as a sub class of
security devices implement some security ssn:‘deployment related process’ which links the
mechanism). Different security devices such as instances of systems or devices with instances of
Firewall, IDS and IPSec are added as sub-classes of sectors (e-health, home automation, industrial
SecurityDevice. Each such subclass can be further automation, smart vehicles, etc.) in which they are
extended to align corresponding ontologies of the deployed. This discrimination is important since the
same device, deployed in different sectors, presents
varying level of security risks. For example, consider exploited to manipulate or fabricate the commands
the risks attached with a temperature sensor installed directed towards it.
for home automation and the same sensor installed at 3.3.2. Security Risk
a nuclear plant. The types, impacts and motives
behind the attacks on these two devices may widely We assess security risk as a function of threats and
differ. The concept ssn:System is linked with vulnerabilities contained by all the devices
iot:DeploymentSector through property constituting an IoT system. Since the nature of risks
iot:hasDeploymentSector. keeps on evolving over time, owing to the dynamic
behavior of threats, we define Risk as a subclass of
3.3. Security Ontology dul:Situation. In addition to routine
CyberSecurityRisk, IoT infrastructure is also
The IoT ontology discussed above is required to be susceptible to PhysicalRisk. Therefore, both these
aligned with some suitable security ontology to risk categories are introduced as sub-classes of Risk
reason about the security capabilities and risk (Fig. 1). IoT related risks can be quantified and
profiles of IoT systems. As justified earlier, we have analyzed with reference to RiskLikelihood and
used NRL ontology for this purpose after enriching RiskImpact, both defined as sub-classes of
it with IoT-specific security requirements and dul:Amount. Instance population of various risk
associated concepts. Some of the worth-mentioning categories and their respective scores can leverage
enhancements made to the ontology are discussed domain specific risk studies. As a proof of concept,
here. we have adopted the risk analysis conducted by
Jacobsson et al. [16] for smart home automation
3.3.1. Vulnerability and Threat systems. The authors in this study, identified a total
The NRL ontology does not cover semantic of 32 risks and categorized them with reference to
definitions of security vulnerabilities and threats. associated threats, vulnerabilities and severity, based
However, risk analysis of IoT systems essentially on the likelihood and impact of the exploit.
require these concepts to be properly defined and 3.3.3. IoT Security Objectives
precisely aligned with the existing security concepts.
Therefore, we define vulnerability and threat as The existing list of nrl:SecurityObjectives defined in
dedicated classes inside the security main ontology the Security Main ontology is extended with
of NRL ontology suite. Fig. 2 illustrates the key following IoT-specific and self-explanatory security
ontology relationships for these concepts. objectives a) secure-firmware-upgrade b) secure-
Vulnerability class points to specific weaknesses bootstrap c) end-to-end-security d) group-key-
present in a given IoT device. Each vulnerability management e) host-mobility f) device-
pertainsTo software, firmware, hardware, authentication
communication protocol/link or information (data); 3.3.4. Adding New Instances
categories defined as subclasses of the iot:Resource
class. These vulnerabilities can be mitigated by Existing version of the NRL ontology is not
implementing corresponding security objective(s). populated with instances of IoT-specific security
For example, the vulnerability of inadequate protocols. We conducted an extensive literature
confidentiality and authentication at an IoT gateway review of such security protocols and added some of
can be countered by implementing the security the most widely-adopted and recommended
objective of end-to-end-security among the protocols as instances of the appropriate NRL
communicating nodes, using that gateway. Thus, concepts. Moreover, existing NRL instances were
vulnerabilities in a system can be mapped to the also enriched by annotating them with data linked
corresponding security capabilities, which can through newly added properties.
counter them through a common security objective.
Vulnerabilities are exploitedBy security threats such
as a lack of authentication at actuator level can be
4. Rule-Based Reasoning properties. A sample constraint is given as Rule-2.
This rule checks for authentication pairing at
This section gives an overview of the proposed
application / service level by utilizing
methodology for ontology-driven risk assessment
nrl:ServiceSecurity ontology, which is already
and management of IoT systems. The dependencies,
aligned with OWL-S ontology. As shown in Rule-2,
risks and corresponding security requirements are
authentication pairing is defined by using
derived from the existing OWL facts by using
nrl:securityRequirement and nrl:securityCapability
suitable rule and query languages (such as SWRL
properties, which are registered as sub-properties of
and SQWRL respectively). Rule-based reasoning
OWL-S:serviceParameter.
leverages existing or built-in OWL concepts and
properties to offer more powerful deductive 4.2. Risk-Driven Constraints
reasoning capabilities than OWL alone. We initially
deploy SWRL to infer device level pairings based on We utilized the power of deductive reasoning to
their dependencies and matching security protocols analyze risks for a given IoT system. This knowledge
and categorize these rules as inherent constraints. was then used in conjunction with inherent
Followed by that, we demonstrate sample rules to constraints to isolate the required security
infer risk exposure, quantify its severity and propose capabilities, which can be used to mitigate these
viable mitigation options. risks. As mentioned earlier, we considered the
domain of smart home automation system and
4.1. Inherent Constraints leveraged the empirical risk analysis study
These are the constraints, which derive dependency conducted by Jacobsson et al. [16].
and security relationships among the registered IoT
Rule-3: Mapping Vulnerabilities
entities. We established these relationships by (? 1) ∧ (? 2)
: :
modeling a variety of inherent constraints. Some ∧ :ℎ (? 2, ? 1)
examples of such constraints are given in Listing 1. ∧ : (? 2, ? 1)
With regards to operational dependencies, the related ⇒ℎ (? 1, _ )∧
devices are linked using the iot:hasDependency ℎ (? 2, _ )
object property. A sample constraint is given as Rule-4: Risk Exposure
: (? ) ∧ : ℎ (? , ) ∧
Rule-1 for controller dependency. A given IoT : (? , ? ) ∧ : ℎ (? ) ∧
device is dependent on its designated controller(s), : (? , ? ) ∧ : (? )
which regulate its operations by issuing appropriate ⇒ : (? , ? )
commands. Similar dependency relationships can Rule-5: Risk Scoring
also be established for other types of IoT entities, : (? ) ∧ : (? , ? ) ∧ : ℎ _
ℎ (? , ? ) ∧ :ℎ (? , ? )
while catering for their interaction requirements.
∧ :ℎ (? , ? ) ∧ :ℎ
(? , ? ) ∧ : (? , ? , ? ) ∧
Rule-1: Controller Dependency : ℎ (? , 10.0)
: (? 1) ∧ :ℎ (? 1, ? 1) ∧
⇒ : (? )
: (? 1) ∧ : (? 1, ? 2) ∧
Rule-6: Risk Mitigation
: (? 2) ⇒ :ℎ (? 2, ? 1)
: (? ) ∧ : ℎ
Rule-2: Authentication Pairing
(? , ? ) ∧ : (? , ? 1) ∧
: (? 1) ∧ :ℎ (? 1, ? 1)
: (? 1) ∧ : _
∧ : (? 1, ? 1)
(? ) ∧ :
∧ : ℎ ℎ (? 1)
(? , ? 2) ∧ : (? 1, ? 2)
∧ : (? 2) ∧ :ℎ (? 2, ? 2)
⇒ : (? , ? )
∧ : (? 2, ? 1)
∧ : (? 1, ? 1)
⇒ :ℎ ℎ (? 2, ? 1) Listing 2: Risk-Driven Constraints

Listing 1: Inherent Constraints Listing 2 presents some of the rules supporting this
inference process. Rule-3 proposes an automated
Inherent constraints are also used for pairing the means of identifying vulnerabilities, induced due to
devices with reference to their matching security the lack of security inter-operability among
dependent devices. The rule states that if a given pair common capabilities by using the sqwrl:intersection
of dependent devices are deprived of encryption built-in set operator.
pairing then they are vulnerable to
poor_confidentiality. Since SWRL is based on open- 5. Implementation and Evaluation
world assumption, execution of Rule-3 requires the
We have used Protégé software [20] to build and
world to be closed using suitable axioms. Rule-4
extend our ontology. Protégé is a W3C standard-
consumes the vulnerability and threat information
compliant, free and open-source ontology-editor tool
associated with respective devices to infer the types
developed and maintained by Stanford University.
of risks applicable on them. Next, Rule-5 categorizes
Ontology inference and consistency checking was
the IoT assets with regards to the level of risk
performed by utilizing the Pellet-engine, which is an
exposure. It isolates the devices with risk scores
OWL2, java-based, open source reasoner and comes
greater than or equal to 10 (in accordance with the
pre-configured with Protégé. Pellet can not only be
categorization made by [16]), as members of
used to perform traditional reasoning tasks such as
iot:CriticalDevice. Finally, Rule-6 recommends the
classification, debugging and querying with
list of those security capabilities, which can be used
soundness and completeness, it additionally allows
to mitigate the vulnerabilities inducing that risk.
the use of SWRL and SQWRL built-ins in the rules,
These capabilities are linked with the device under
facilitates incremental classification and also
risk using candidateSecurityCapability property.
supports reasoning through Jena in addition to OWL
4.3. Querying the Inferred Knowledge API interface.
After reasoning over the registered IoT data using For IoT systems, we conducted an extensive survey
OWL restrictions and rule-based constraints, of the real-world IoT devices and their capabilities,
information regarding the desired set of security mainly targeting the domains of home automation
capabilities can be inferred. This information can and building management systems. Risk profiles for
further be scrutinized through customized queries. these devices were built by leveraging the risk
For instance, queries can be used to isolate those categories and corresponding likelihood values of
dependent devices, which cannot communicate using our reference study [16]. However, values for risk
an inter-operable security protocol or do not meet the impact were intuitively assigned, while catering for
desired security objectives. the device operational goals and capabilities. For
example, impact of a security breach on a smart door
: (? ) ∧ : (? ) lock or a smoke sensor will be considerably large as
∧ :ℎ (? , ? )
compared to a smart light, since the former can
∧ : (? , ? 1)
(? , ?
threaten the physical security and safety of the
∧ :ℎ 2)
∘ : (? 1, ? 1) premises respectively. Contrary to that, for a given
∧ : (? 1, ? ) risk, the referred study [16] assigned same impact
∧ : (? 2, ? 2) values to the complete group of IoT devices.
∧ : (? 2, ? ) The IoT device-specific information was extracted
∧ : (? 3, ? 1, ? 2) from openly available resources and was
⇒ : (? , ? , ? 3)
Listing 3: Report Matching Security Capabilities
subsequently structured using an H2 database engine
(a Java SQL RDBMS). Information from the
Similarly for risk mitigation, only those capabilities database was mapped and populated as ontology
can be selected, which are also supported by the instances using the ontopPro [21] data import
dependent devices, as demonstrated by the query plugin. OntopPro is a DB-ontology mapping editor
given in Listing 3. The query generates two sets, S1 plugin for Protégé, which offers a powerful and
for capabilities required by each critical device for intuitive mapping language to generate RDF triples
risk mitigation and S2 for capabilities supported by (ABox assertions) for the targeted ontology.
its respective dependent devices. It then enlists the Additionally, it also supports querying the database
 Fig. 2: (a) Impact of network size on constraint verification time (b) Impact of network size on
memory requirements (c) Impact of network size on CPU load
on the fly without the need to import it in the memory and processing power consumed in relation
ontology. with the number of registered devices. The results
reflected a near-linear rise in time and memory
We developed a number of SWRL/SQWRL
requirements while increasing the network size.
constraints such as for mapping IoT dependencies,
aligning their security properties, identifying and 6. Conclusion
quantifying associated risks and mapping applicable
security controls for critical devices. OWL In this paper, we presented an ontology-driven
restrictions and SWRL constraints were processed approach for risk analysis of IoT systems. The
by the reasoner to derive and update the inferred methodology adopts an automated way of
information. Subsequently, SQWRL based queries semantically registering the security and functional
were run to output risk reports alongside suitable properties of IoT elements, pairs these elements
recommendations. We tested our system for based on their respective parameters and
accuracy and scalability as discussed below: subsequently verify their correctness in relation to
Accuracy: The accuracy of the system was verified desirable security configurations, applied as
through different ways. First of all, the correctness of constraints over the registered information. We are
the inferred knowledgebase was stamped by the actively working towards extending this work in
reasoning engine, which ensured the soundness and several directions. The IoT and security ontologies
completeness of the results through inherent features. presented in this paper are being extended to
Soundness preserves the accuracy by ensuring that comprehensively model related IoT aspects such as
all inferences based upon facts are valid with behavior, operational specifications and network
reference to the semantics. Conversely, topologies. We also plan to port our ontology into
completeness ensures that knowledge that is actually Apache Jena [22], a free and open source Java-based
true can be correctly and completely inferred by the framework for linked data applications. Our initial
system. We also verified the accuracy with the help experiments over Jena have shown much improved
of a ground truth scenario based on a small-scale results in terms of scalability, data materialization
home-automation system. Different security time and reasoning efficiency.
constraints were tested by firing the SWRL based
rules on the registered IoT facts and then manually 7. Acknowledgements
comparing the inferred configurations with the facts, A part of this research has been supported by the
thus verifying the correctness. Higher Education Commission (HEC), Pakistan
Scalability: With regards to scalability, we fed IoT through Indigenous 5000 PhD Fellowship program
data of varying size into the ontology and analyzed (Phase-II).
the time and space performance of verifying different 8. REFERENCES
constraints. We utilized a corei5 machine with a
4GB RAM for the experiments. The results of 1. H. Sundmaeker, P. Guillemin, P. Friess, and S.
experiments are given in Fig. 3, plotting time, Woelffl´e, Eds., Vision and Challenges for
 Realising the Internet of Things. Luxembourg: the ETSI machine-to-machine architecture,” in
Publications Office of the European Union, ITHINGS 2014, IEEE International
2010. Conference on Internet of Things 2014,
2. P. Guillemin, P. Friess et al., “Internet of things September 1-3, 2014, Taipei, Taiwan, Province
strategic research roadmap,” The Cluster of of China, 09 2014. [Online]. Available:
European Research Projects, Tech. Rep., http://www.eurecom.fr/publication/4322.
September, 2009. 13. C. Liu, Y. Zhang, J. Zeng, L. Peng, and R.
3. D. L. McGuinness, F. Van Harmelen et al., Chen, “Research on dynamical security risk
“OWL web ontology language overview,” assessment for the internet of things inspired by
W3C recommendation, vol. 10, no. 10, 2004. immunology,” in Eighth International
4. I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Conference on Natural Computation (ICNC).
Tabet, B. Grosof, M. Dean et al., “SWRL: A IEEE, pp. 874–878, 2012.
semantic web rule language combining OWL 14. R. Roman, P. Najera, and J. Lopez, “Securing
and RuleML,” W3C Member submission, vol. the internet of things,” Computer, vol. 44, no.
21, p. 79, 2004. 9, pp. 51–58, 2011.
5. M. J. O’Connor and A. K. Das, “SQWRL: A 15. S.-I. Chang, A. Huang, L.-M. Chang, and J.-C.
Query Language for OWL,” in OWLED, vol. Liao, “Risk factors of enterprise internal
529, 2009. control: Governance refers to internet of things
6. M. Compton, H. Neuhaus, K. Taylor, and K.- (iot) environment,” RISK, 2016.
N. Tran, “Reasoning about sensors and 16. A. Jacobsson, M. Boldt, and B. Carlsson, “A
compositions.” in SSN. Citeseer, pp. 33–48, risk analysis of a smart home automation
2009. system,” Future Generation Computer
7. M. Calder, R. A. Morris, and F. Peri, “Machine Systems, vol. 56, pp. 719–733, 2016.
reasoning about anomalous sensor data,” 17. A. Gangemi, “DOLCE Ultralight Ontology,”
Ecological Informatics, vol. 5, no. 1, pp. 9–18, http://www.loa.istc.cnr.it/ontologies/DUL.owl
2010. [Online]. Available: http://linkinghub. , 2007, accessed: 2016-11-09.
elsevier.com/retrieve/pii/1574954109000715. 18. A. Kim, J. Luo, and M. Kang, Security
8. L. Lefort, C. Henson, K. Taylor, P. Barnaghi, ontology for annotating resources. Springer,
M. Compton, O. Corcho, R. Garcia-Castro, J. 2005.
Graybeal, A. Herzog, K. Janowicz et al., 19. D. Martin, M. Burstein, J. Hobbs, O. Lassila,
“Semantic Sensor Network XG-final report,” D. McDermott, S. McIlraith, S. Narayanan, M.
W3C Incubator Group Report, vol. 28, 2011. Paolucci, B. Parsia, T. Payne et al., “OWL-S:
9. M. Bermudez-Edo, T. Elsaleh, P. Barnaghi, Semantic markup for web services,” W3C
and K. Taylor, “IoT-Lite Ontology,” member submission, vol. 22, pp. 2007–04,
https://www.w3.org/ 2004.
Submission/2015/SUBM-iot-lite-20151126/, 20. H. Knublauch, R. W. Fergerson, N. F. Noy, and
2015, accessed: 2016-08-01. M. A. Musen, “The Protégé OWL plugin: An
10. S. De, P. Barnaghi, M. Bauer, and S. Meissner, open development environment for semantic
“Service modelling for the internet of things,” web applications,” in The Semantic Web–
in Federated Conference on Computer Science ISWC, Springer, pp. 229–243, 2004.
and Information Systems (FedCSIS). IEEE, pp. 21. KRDB Research Group, “ontopPro: The
949–955, 2011. OBDA Plugin for Protégé,”
11. M. B. Alaya, S. Medjiah, T. Monteil, and K. http://ontop.inf.unibz.it/,accessed: 2016-11-09.
Drira, “Toward semantic interoperability in 22. A. Jena, “A free and open source java
oneM2M architecture,” IEEE Communications framework for building semantic web and
Magazine, vol. 53, no. 12, pp. 35–41, 2015. linked data applications,” URL:
12. A. Gyrard, C. Bonnet, and K. Boudaoud, “An http://jena.apache. org, 2011.
ontology based approach for helping to secure