-Preventing privacy-related risks in the creation of Trustworthy Smart IoT Systems (TSIS) will be essential, not only because of the growing amount of regulations that impose strict mechanisms to control risks and quality, but also to effectively mitigate the effect of potential threats exploiting vulnerabilities that may jeopardize privacy. While privacy-related risks usually consider assets represented by elements of the functional description of a TSIS, most monitoring efforts are focused on monitoring security aspects related to the system architecture components and it is not straightforward to link the evidences collected through this monitoring systems to functional description elements, making it difficult to use this information for privacy-related risk management. In this paper, we propose a methodology for continuous risk management and a model for risks to increase trustworthiness in IoT systems by enabling continuous monitoring of privacy-related risks. Our approach is based in connecting our risk model with a modelling language to describe IoT architectures, such as that proposed in GeneSIS, and Data Flow Diagrams (DFD). With the combination of architecture (technical description) and data flow models (functional description), we enable continuous risk management using monitoring to improve risk assessment related to data protection issues, as required by GDPR. Index Terms-Risk management, Trust, IoT, Continuous, Privacy, Security
Until now, IoT system innovations have been mainly
focused on sensors, device management and connectivity,
usually aimed at gathering data for processing and analysis in the
cloud1. The next generation IoT systems need to perform
distributed processing and coordinated behaviour across IoT, edge
and cloud infrastructures, manage the closed loop from sensing
to actuation, and cope with vast heterogeneity, scalability and
dynamicity of IoT systems and their environments [
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
This work is supported by the European Commission through the ENACT project under Project ID: 780351 and the PDP4E project under Project ID: 787034.
1IEC white paper entitled IoT 2020: Smart and secure IoT platform. http://www.iec.ch/whitepaper/pdf/iecWP-loT2020-LR.pdf quality and user experience. Besides, by 2021, the number of connected things will grow to 25 billion, according to Gartner2. Thus, processes that were formerly run by humans will be automated, making it much more difficult to control data ownership, privacy and regulatory compliance.
Yan et al. [
In parallel, GDPR discusses data protection by design and
by default, remarking that it is essential to consider privacy
from the beginning to address related issues successfully. This
is specially true in the IoT arena, where technologies are not
consolidated yet and mixing legal requirements with a deep
technical understanding is challenging. In particular, including
privacy aspects in a continuous risk management process
is difficult. Continuous evidence collection to support risk
management is usually key, but most monitoring approaches
focus on collecting evidences from the TSIS infrastructure or
technical architectural components. However, privacy-related
risks are usually detected by analyzing functional descriptions
of the system [
In this paper, we improve continuous risk management in
TSIS development by embedding privacy-related risks
explic2https://www.networkworld.com/article/3322517/internet-of-things/acritical-look-at-gartners-top-10-iot-trends.html
itly through the combined used of models for both the
architecture and the data flow implemented on the components of the
architecture. We present a new approach that, through linking
GeneSIS [
This paper is organized as follows. Section II provides an analysis of the state of the art. In Section III, we describe a usual use case for our proposal. Section IV presents a brief analysis of existing approaches and risk guidelines in standards. Section V presents our methodology and a class diagram model to describe the concepts we use in our risk management methodology, and describe the mapping between the architecture model and DFDs as well as our risk model. Finally, in Section VI, we draw some conclusions.
There exist quantitative risk methodologies and tools, like
RiskWatch3 or ISRAM [
Managing continuous changes in software development has
been studied from different perspectives. The most common
practice in industry is continuous software integration [
There has been work on risk management in complex and
evolving environments. For instance, different papers [
None of these contribution tackles how to monitor privacyrelated risks for continuous risk management.
In general, even for security, risks are not analysed and
monitored continuously and historical data is not taken into
account [
In parallel, Article 25 in GDPR4 discusses data protection
by design and by default, underlining that considering privacy
from the beginning is essential to address privacy successfully.
GDPR establishes binding data protection principles,
individuals rights, and legal obligations to ensure the protection of
personal data of EU citizens. However, legal measures need
to come along with technical measures to protect privacy and
personal data in practice. PDP4E H2020 project [
The MUSA Risk Assessment tool5 is a reference
implementation of the continuous risk management framework proposed
by [
In order to assess the risks in the different components of an application, the tool asks users to provide an informal description of the system and its components. Then, users are free to choose among pre-defined threats that may potentially affect each individual component. Once threats are selected, they are automatically classified in the STRIDE securityoriented framework (Spoofing identity, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege). Then the user can continue with the assessment, evaluation and posterior mitigation of the risk. We take this tool as the baseline for the proposal presented in this paper.
Recent work in the ENACT H2020 project [
5https://musa-project.eu/node/326 as the orchestration and deployment. In this paper, we will base our Risk Management methodology in the GeneSIS domainspecific modelling. Figure 1 shows a high level description of the generic elements modelled through GeneSIS.
GeneSIS modelling language is an extension of
ThingML [
LINDDUN [
Non-compliance). LINDDUN is sometimes considered the
privacy-oriented alternative to the STRIDE framework. In
fact, LINDDUN threats are described in the so-called
LINDDUN trees which are explicitly connected to STRIDE threats
trees [
Unlike the approach proposed by MUSA Risk Assessment
tool, which grounds its threat modelling on descriptions of
individual components, the LINDDUN methodology requires
to formalize the functionality of the system and their
dependencies with respect to personal data. In such sense,
LINDDUN proposed the usage of the Data Flow Diagrams [
We devote this subsection to explain the usual scenario we may find in a software company that offers Trustworthy IoT solutions. The aim of this section is to provide some context for the paper rather than characterizing the generic organization of TSIS companies, as this would require conducting an exhaustive and more accurate study.
The scenario discussed is particularly relevant in highly regulated markets where a company needs to prove they follow a risk-based approach as required by GDPR or comply with existing standards such as ISO 27001 for security for instance. This company needs to gain trust because it is dealing with data that may be crucial about users (e.g. health data about remotely monitored patients at home). Content of this section is based on our experience with our customers.
Companies in highly regulated markets usually have risk management owners in the organization. The exact role they play may depend on the type of company and the type of requirements this company may have. For instance, the company may have a Chief Security Officer (CSO), a Data Protection Officer (DPO) as requested in some situations by GDPR, etc. In large organizations, it is common to have risk analysts to support the risk management process, while in SMEs this is typically a role played by individuals whose background and knowledge is not on risk management. Companies that are truly following DevOps principles, tend to make decisions around risk in a collegial manner, involving product owners, risk analysts, developers, operations, etc.
In this context, companies need to face many challenges, including coping with rapid software evolution, the need to obtain and keep relevant certificates to gain the trust of their customers, the need to prepare for any unwanted incident that may negatively impact their businesses, etc. For this, they need to prepare internal policies to describe their procedures to handle risk management. Among these procedures, frequent meetings are usual where they need to rapidly understand the status of risks in their projects, as well as, to reshape or re-prioritize risk plans to better accommodate the current situation and market. When these needs are crossed with IoT, proper risk management procedures become even more significant. Requirements change frequently, technology evolves rapidly and, consequently, companies adopt agile software development processes. Therefore, continuous risk management is probably the only effective strategy to ensure that risks are properly mitigated in long-term development processes.
Figure 2 shows the high-level description of a typical risk management processes implemented in software companies. A company may be developing software in the form of a product or SaaS (e.g. connected to a trustworthy IoT system). Each product will have a person playing the role of the product owner, who will supervise the whole development of that product. Apart from this role, the company will typically have a risk owner, who owns the risk management process and strategy. This role may also take the form of a committee, composed of different people playing different roles, and bringing different perspectives, including Chief Product Officers, Chief Technology Officers or Chief Operation Officers. Risk owner will typically start and contribute and monitor the risk management process. Engineers may also be involved in this process including developers and operators, to empower a DevOps approach. Architects and Product Owners will also be involved in the risk management process. An efficient risk management process will help the organization to understand risk level associated to detected risks and prioritize the implementation of mitigation actions (or treatments or controls) in the form of new product features. Finally, risk management owner(s) needs to report the status of risk management.
In this context, companies lack mechanisms to continuously monitoring processes. In particular, there is a lack of mechanisms to monitor privacy-related issues. They require mechanisms to monitor the implementation of related mitigation actions and the effectiveness of the treatments.
IV. ALIGNMENT WITH STANDARDS AND BEST PRACTICES
While most risk management methodologies presented in the literature and accepted by the international community through standards, scientific work or other best practices are similar, they also differ in some aspects. Following, we analyze some well-known risk management methodologies or risk management guidelines proposed in standards, focusing in particular in those related to privacy issues. In particular, we explore the following best practices in industry and some previous related FP7 and H2020 projects:
Risk management methodologies used in MODAClouds6 and MUSA7 (and CORAS methodology implicitly): MODAClouds risk management methodology has a strong influence from CORAS, simplified to favour usability. It was later on inherited and refined in MUSA. We use it as the baseline of our methodology.
ISO/IEC 29134:2017 : it gives guidelines for: (i) a process on privacy impact assessments, and (ii) a structure and content of a Privacy Impact Assessment (PIA) report. PIAs include a methodology for risk management. ISO/IEC 27001:2013 : it specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system within the context of the organization. It also includes requirements for managing information security risks. ISO/IEC 27550 (to be published in 2019) : this standard complements ISO/IEC 27001:2013 by providing an engineering, privacy-oriented perspective. LINDDUN is mentioned as a methodology in this risk-oriented standard. ISO 31000:2018 : it provides guidelines on managing risk. It can be used throughout the life of the any organization and can be applied to any activity, including decision-making at all levels. Since it is the most generic standard to describe risk management activities and it is agnostic to a particular context, we take it as a general reference for our methodology.
Figure 3 shows a visual summary of the main steps followed by the risk management methodology in MUSA and the steps suggested in ISO/IEC 29134:2017. While the vocabulary is not identical, the processes are similar, and it is possible to establish reasonable mappings among them. For instance, in MUSA 6MODAClouds FP7 (Project id: 318484) www.multiclouddevops.com 7MUSA H2020 (Project id: 644429) www.musa-project.eu assets and vulnerabilities are defined and threats are identified with respect to those. In ISO/IEC 29134:2017, the definition of assets and vulnerabilities is quite ambiguous, but they put the emphasis in the description of risk sources. Both define threats (i.e. unwanted incidents in CORAS) and then risks. In general, a risk is an unwanted incident which likelihood and impact have been analyzed. Some methodologies talk about treatments, while others talk about controls. In general, these are all different terms to refer to mitigation actions.
In this section, we will present our risk management methodology, focusing in particular on capturing those aspects that make the risk management process suitable to enable continuous risk management on privacy-related issues.
Figure 4 presents a class diagram to model risk
management concepts to allow to control privacy risks using DFDs.
In particular, we consider each element of a DFD (Entity,
DataFlow, DataStore and Process) a specific asset, following
LINDDUN methodology. This diagram is inspired by the
UML diagram presented by Gupta et al. [
In Figure 5, we propose a methodology for risk management for the creation of TSIS and we indicate the actors involved in each of those steps. Our methodology, inspired by the previous analysis, can be summarized in 6 main steps:
S1: TSIS Assets Definition: first, we edit or load DFDs representing the functional description of the system. This DFDs are useful to manage risks related to privacy as described by LINDDUN, although they were initially used for security risk control (e.g. in STRIDE). Although
Fig. 5. Proposed Model-based Risk Management methodology. Roles: (O) Risk Management Owner; (P) Product Owner; (A) Architect; (V) Developer and (R) Risk Analist
DFDs represent our primary assets in the risk management process, our proposal entails the use of a second layer of supporting assets in the form of TSIS archictecture description. Therefore, in S1, GeneSIS Models (or equivalent architectural models) are also traversed and components are pre-loaded. This step also includes the definition of the vulnerabilities related to a component of an architecture or a subset of components.
S2: Threats Identification: in this step, users identify threats that may affect the components in the described system. These threats are captured as instances of the Unwanted Incident class in the UML diagram in Figure 4. S3: Risk Assessment: risk assessment is composed of two different steps: risk analysis, where risks are evaluated in terms of likelihood and consequence, and risk evaluation, where risks are accepted, or they are classified as risks that need to be mitigated.
S4: Definition of Treatments: mitigation actions are defined in the form of treatments.
S5: Residual Risk Assessment: once the mitigation controls are defined, the residual risks need to be reassessed. This involves again two steps: risk analysis, where likelihood and consequence are updated after the application of the control(s), and risk re-evaluation, where risks are analysed again, and they are classified as accepted or further mitigation actions required.
S6: Treatment Implementation Control: finally, we add a last step in the methodology that goes beyond other previous methodologies. In particular, it involves the monitoring of the effectiveness of the mitigation actions proposed in the previous step. This step requires the connection to data collectors or agents that collect evidences from a monitoring system in order to match them to treatments and risks. Mapping of DFDs and architectural models will be the key for this to be possible. Note that this methodology is continuous in the sense that new evidence is continuously collected to challenge previous knowledge upon which risk-related decisions were made in the past. While immediate triggering of mitigation actions is not our main focus, conditional options based on the status of the system could be included in S4 to strengthen the continuous approach. Also, the methodology is particularly customized for TSIS, specifically in S1, where GeneSIS models are used as the baseline, and S6, where evidences are collected to consider privacy-related issues, as we show later on in this section. However, the methodology can be easily adapted to other types of systems and used generically. This will mainly depend on the models and the risks and mitigation actions defined.
GDPR establishes a set of duties imposed on the data processors, controllers and third parties which are aimed at honoring the corresponding data subjects rights. In GDPR, risk is explicitly scoped (Rec. 76) with regards to the rights and freedoms of the data subject. In order to understand whether these data subject rights and principles (described in GDPR) are being effectively protected by mitigating existing risks, current approaches tend to analyze the data flow in the system (e.g. LINDDUN and DFDs). However, elements in a DFD tend to be defined at a functional level (e.g. process to collect profile data from a user or process to merge data from two existing data sources). In this situation, collecting system data to monitor a threat related to the identifiability of an entity as defined by LINDDUN, just to take an example, is not obvious, if we do not understand the relationship of a data flow in the application with the architecture of the infrastructure that we monitor. Without a proper connection of these elements to architectural levels that can be monitored, continuous risk management for privacy becomes much more difficult. Most monitoring tools monitor the infrastructure level. These tools may monitor system aspects in a data center or a particular server, tools for network monitoring, etc, and collect metrics.
The main contribution of the approach proposed in this section is the mapping of TSIS architecture models, such as the one proposed by GeneSIS, with data flows in the application under analysis (e.g. DFDs). In S6, we may assume that the elements from both models have been mapped establishing a link between the two types of models. Details on this mapping are provided below. For instance, a NoSQL data store in our system architecture may be mapped to a data store component in a DFD. As another example, a particular process element in a DFD may be mapped to the server the process is running on. As an alternative, it is possible that the mapping is not preestablished before starting the risk analysis process. In this situation, we consider that phase S1 can be extended to allow the user to establish this mapping manually.
1) Model mappings: in order to drive the mapping between
the architecture model and DFDs, we take as the baseline
the connection between privacy-related threats studied in
LINDDUN and the vulnerabilities that are related to security
aspects of the architecture, as captured by STRIDE. Please
note that LINDDUN defines a connection between threats in
LINDDUN categories and STRIDE threats through their threat
trees catalogs [
In Table II, we show a sample of vulnerabilities extracted
from [
Note that these vulnerabilities are specially relevant in an IoT context. For instance, let us take the example in Table II related to Information Disclosure of Data Flow. There may be different vulnerabilities associated in particular to TSIS. For instance, if we have a device IoT hub, eavesdropping or interfering the communication between the device and the gateway would be a potential threat. You may also find similar threats in the communication between devices, where data may be read in transit, tampering with the data or overloading the device with new connections. Or even with the cloud gateways, where eavesdropping or communication interference between devices and gateways may occur.
In general, mappings between architectural models and DFD will link:
entities in DFDs with the associated network channels in STRIDE
Threat which entity information is transmitted or data stores in which the information is stored; data flows in DFDs with the corresponding network channels; data stores in DFDs with the corresponding databases or data stores used in the system architecture; and processes in DFDs with the corresponding software components executing tasks related to those processes, specially when these tasks entail some level of secrecy.
More formally, we define a set of DFDs, which represent a functional description of the system, D = fD1; D2; : : : ; Dng, as a set of graphs Di = (DVi; DEi), where DVi = fe1; : : : ; emg are the elements in the DFD representing elements of the system architecture at the functional level. Each element ei can be an external entity, data store or a process. DEi =
ff1; : : : ; fkg represents the data flows connecting elements in DVi. We define a graph A = fVA; EAg where VA = fc1; : : : ; cmg represent the architectural components at the technical level represented in a model such as those created by GeneSIS and EA = fl1; : : : ; lkg represents the connections between any two components (ci; cj ) in the system architecture. Note that components can be both software or hardware components. We define a mapping between the two models Di and A as a function M : DVi [ DEi ! VA [ EA.
2) Exploiting model mappings: once the mapping is established, then a final step is necessary to link metrics, such as those presented as examples in Table II, to the related risks or mitigation actions defined in S3 and S4. Following the risk methodology presented above, we will obtain instances for the rest of classes in the diagram in Figure 4, including risks and mitigation actions. Once the risk model is developed for each DFD, we propose two ways to exploit the established mappings to enable continuous risk management: Automatic likelihood recalculation: during risk assessment in S3, an initial likelihood and consequence values are determined for each risk. However, a basic principle for continuous risk management is that conditions in our system may change as time goes by. Let e be an element in a DFD Di, e 2 DVi [ DEi, considered an asset in the risk management process. In S3, we define risks r1; : : : ; rj associated to e. Given a system architecture defined through a model A = fVA; EAg, we define a set of metrics mc1; : : : ; mch for each component c 2 VA [ EA. Automatic likelihood recalculation involves defining a function f for each risk r related to each asset e such that c = M(e) and f (mc1; : : : ; mch) provides a new value for the likelihood or risk r. With this, we connect the metrics defined for the architectural components and use them to calculate the likelihood of risks connected to elements of the functional description of a system, in the corresponding DFD.
Treatment effectiveness control: a parallel approach to enable continuous risk management, involves the definition of a function g for each r related to an asset e 2 DVi [ DEi such that c = M(e) and g(mc1; : : : ; mch) represents a KPI that needs to be satisfied for a risk to be considered effectively mitigated. If g exceeds a particular threshold, then a warning needs to be issued for the risk plan including mitigation actions to be reviewed.
Handling privacy-related risks is not well understood in the IoT context. There is a lack of mechanism to collect meaningful evidences and continuously monitor these risks. We need to find the intersection between data protection challenges and the enabling of TSIS. We have presented a first step towards the enactment of continuous privacy-related risk control for TSIS, leveraging the link offered by LINDDUN between privacy and security threat categories and combining functional and architectural models. As future work, we need to establish a stronger connection between privacy threat models like LINDDUN and the actual requirements imposed by GDPR, as current threat models were devised before GDPR and they may not fully cover all derived requirements. In particular, the relationship between data subject rights and GDPR principles and LINDDUN categories is unclear. Besides, we need to understand how other privacy-related evidences can be collected beyond those collected for security purposes. In particular in TSIS, where complex and distributed systems increase system weaknesses and the attack surface.
The authors would like to thank anonymous referees for their valuable comments and suggestions. We would also like to thank SINTEF and the GeneSIS team for allowing us to use some figures generated by them.