Model-driven Evidence-based Privacy Risk Control in Trustworthy Smart IoT Systems Victor Muntés-Mulero∗ , Jacek Dominiak† , Elena González‡ David Sanchez-Charles Beawre Digital SL Trialog SA Barcelona, Spain Paris, France {∗ victor.muntes, † jacek.dominiak, ‡ elena.gonzalez}@beawre.com david.sanchez@trialog.com Abstract—Preventing privacy-related risks in the creation of quality and user experience. Besides, by 2021, the number Trustworthy Smart IoT Systems (TSIS) will be essential, not of connected things will grow to 25 billion, according to only because of the growing amount of regulations that impose Gartner2 . Thus, processes that were formerly run by humans strict mechanisms to control risks and quality, but also to effectively mitigate the effect of potential threats exploiting will be automated, making it much more difficult to control vulnerabilities that may jeopardize privacy. While privacy-related data ownership, privacy and regulatory compliance. risks usually consider assets represented by elements of the Yan et al. [27] described the different dimensions of trust functional description of a TSIS, most monitoring efforts are for IoT systems, concluding that risk management is essential focused on monitoring security aspects related to the system to guarantee trustworthiness. Markets in the need of TSIS, architecture components and it is not straightforward to link the evidences collected through this monitoring systems to functional such as eHealth, are just flourishing and businesses will be description elements, making it difficult to use this information continuously adapting to new technologies. In this context, for privacy-related risk management. In this paper, we propose poor risk management together with a reactive strategy usually a methodology for continuous risk management and a model forces companies to continuously re-factor application archi- for risks to increase trustworthiness in IoT systems by enabling tectures to improve software quality and security, incurring continuous monitoring of privacy-related risks. Our approach is based in connecting our risk model with a modelling language to high re-implementation costs [5]. In general, there is the lack describe IoT architectures, such as that proposed in GeneSIS, and of solutions to support continuous control of risks through Data Flow Diagrams (DFD). With the combination of architecture evidence collection. Companies have little control on actual (technical description) and data flow models (functional descrip- effectiveness of the mitigation actions defined during risk tion), we enable continuous risk management using monitoring management process. Besides, many companies fill this gap by to improve risk assessment related to data protection issues, as required by GDPR. using manual procedures based on storing all the information Index Terms—Risk management, Trust, IoT, Continuous, Pri- in spreadsheets, by departments and locally [1]. This approach vacy, Security rapidly turns inefficient as projects or teams grow. In parallel, GDPR discusses data protection by design and I. I NTRODUCTION by default, remarking that it is essential to consider privacy Until now, IoT system innovations have been mainly fo- from the beginning to address related issues successfully. This cused on sensors, device management and connectivity, usu- is specially true in the IoT arena, where technologies are not ally aimed at gathering data for processing and analysis in the consolidated yet and mixing legal requirements with a deep cloud1 . The next generation IoT systems need to perform dis- technical understanding is challenging. In particular, including tributed processing and coordinated behaviour across IoT, edge privacy aspects in a continuous risk management process and cloud infrastructures, manage the closed loop from sensing is difficult. Continuous evidence collection to support risk to actuation, and cope with vast heterogeneity, scalability and management is usually key, but most monitoring approaches dynamicity of IoT systems and their environments [9]. To focus on collecting evidences from the TSIS infrastructure or unleash the full potential of IoT, it is essential to facilitate technical architectural components. However, privacy-related the creation and operation of trustworthy Smart IoT Systems risks are usually detected by analyzing functional descriptions or, for short, TSIS. TSIS typically operate in changing and of the system [26] (e.g. data flows). Connecting this functional often unpredictable environments. Thus, the ability of these level with the components of the architecture that are being systems to continuously evolve and adapt to their new environ- monitored is not trivial. Recognizing the overlap between pri- ment is essential to ensure and increase their trustworthiness, vacy and security is key to determining when existing security Copyright © 2019 for this paper by its authors. Use permitted under Creative risk models may be applied to address privacy concerns [6]. Commons License Attribution 4.0 International (CC BY 4.0). In this paper, we improve continuous risk management in This work is supported by the European Commission through the ENACT TSIS development by embedding privacy-related risks explic- project under Project ID: 780351 and the PDP4E project under Project ID: 787034. 1 IEC white paper entitled IoT 2020: Smart and secure IoT platform. 2 https://www.networkworld.com/article/3322517/internet-of-things/a- http://www.iec.ch/whitepaper/pdf/iecWP-loT2020-LR.pdf critical-look-at-gartners-top-10-iot-trends.html 23 itly through the combined used of models for both the architec- None of these contribution tackles how to monitor privacy- ture and the data flow implemented on the components of the related risks for continuous risk management. architecture. We present a new approach that, through linking In general, even for security, risks are not analysed and GeneSIS [8] models and Data Flow Diagrams (DFDs) [7], monitored continuously and historical data is not taken into improves risk assessment process for privacy-related risks. We account [1], [4]. Besides, security risks are assessed based on achieve this by enabling the use of the information that is speculation rather than evidence [21], [25]. The interaction typically collected from the infrastructure to control security, between analytics capabilities and information security risk thanks to the link that LINDDUN [26] establishes between management (ISRM) capabilities can help organizations to privacy and security threads in STRIDE [22]. perform continuous risk assessments and enable evidence- This paper is organized as follows. Section II provides an based decision making [19]. analysis of the state of the art. In Section III, we describe In parallel, Article 25 in GDPR4 discusses data protection a usual use case for our proposal. Section IV presents a by design and by default, underlining that considering privacy brief analysis of existing approaches and risk guidelines in from the beginning is essential to address privacy successfully. standards. Section V presents our methodology and a class GDPR establishes binding data protection principles, individ- diagram model to describe the concepts we use in our risk uals rights, and legal obligations to ensure the protection of management methodology, and describe the mapping between personal data of EU citizens. However, legal measures need the architecture model and DFDs as well as our risk model. to come along with technical measures to protect privacy and Finally, in Section VI, we draw some conclusions. personal data in practice. PDP4E H2020 project [15] focuses on the importance to involve engineers in the loop, for Privacy- II. S TATE OF THE ART by-Design (PbD) to be viable. There exist quantitative risk methodologies and tools, like A. MUSA Risk Assessment tool RiskWatch3 or ISRAM [13] and qualitative risk methodolo- gies such as OCTAVE [2], CORAS [14] or STRIDE [22]. The MUSA Risk Assessment tool5 is a reference implemen- Traditional risk management methodologies focus on the as- tation of the continuous risk management framework proposed sessment of risks at a singular stage in time, and do not address by [18]. The tool uses a pull system in the style of Kanban, the challenge of managing continuously evolving risk profiles. where the status of each asset with respect to a risk analysis methodology is expressed through the different columns in the Managing continuous changes in software development has Kanban board. Albeit this approach makes the tool agnostic been studied from different perspectives. The most common to any specific risk analysis methodology, the tool showcases practice in industry is continuous software integration [24]. a methodology that is tailored to multi-cloud environments. Fitzgerald et al. [10], for instance, published a roadmap and In order to assess the risks in the different components agenda for continuous software engineering. Besides, there is of an application, the tool asks users to provide an informal a growing interest on security and privacy and this has moti- description of the system and its components. Then, users are vated work on continuous security and regulatory compliance. free to choose among pre-defined threats that may potentially Continuous security [16] was proposed to prioritize security affect each individual component. Once threats are selected, throughout the whole software development life cycle. they are automatically classified in the STRIDE security- There has been work on risk management in complex and oriented framework (Spoofing identity, Tampering, Repudia- evolving environments. For instance, different papers [12], tion, Information disclosure, Denial of service and Elevation [20] propose managing risk related to accountability, assur- of privilege). Then the user can continue with the assessment, ance, agility or financial aspects in multi-cloud applications. evaluation and posterior mitigation of the risk. We take this Risks analysis is then used to guide the selection of cloud tool as the baseline for the proposal presented in this paper. service providers. Shrivastava et al. [23] present a risk man- agement framework for distributed agile development, study- B. GeneSIS Modelling Language ing risks related to software development life cycle, project Recent work in the ENACT H2020 project [9] defined TSIS management, group awareness, etc. However, they focus on as the next generation IoT systems, capable of performing analysing risk factors that represent a threat to the successful distributed processing and coordinated behaviour across IoT, completion of a software development project, rather than edge and cloud infrastructures. GeneSIS [8] facilitates the risk related to non-functional requirements such as security or development and continuous deployment of TSIS, allowing privacy. In [3], the authors performed a systematic literature decentralized processing across heterogeneous IoT, edge, and review on risks and control mechanisms for distributed soft- cloud infrastructures. GeneSIS includes a domain-specific ware development. Moran [17] explicitly tackles issues related modelling language to model the architecture of TSIS as well to risk management for agile software development. Moran 4 Regulation (EU) 2016/679 of the European Parliament and of the Council proposes a risk modified kanban board and user story map. Finally, in [18], a framework to manage risks that supports of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and collaboration, agility, and continuous development is proposed. repealing Directive 95/46/EC (General Data Protection Regulation). Official Journal of the European Union, L119:188, May 2016. 3 RiskWatch: https://www.riskwatch.com . Accessed: 2019-07-18 5 https://musa-project.eu/node/326 24 as the orchestration and deployment. In this paper, we will base to formalize the functionality of the system and their de- our Risk Management methodology in the GeneSIS domain- pendencies with respect to personal data. In such sense, specific modelling. Figure 1 shows a high level description of LINDDUN proposed the usage of the Data Flow Diagrams [7]. the generic elements modelled through GeneSIS. The notation of a DFD is based upon 4 distinct element types: (i) an external entity (i.e., end-users or third party services that are external to the system), (ii) a data flow (explains data propagation and dependencies between all the functional components), (iii) a data store (i.e., a passive container of information) and (iv) a process (i.e., a computation unit). III. U SE CASE MOTIVATION 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 organiza- tion 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 Fig. 1. GeneSIS concepts [8]. existing standards such as ISO 27001 for security for instance. This company needs to gain trust because it is dealing with GeneSIS modelling language is an extension of data that may be crucial about users (e.g. health data about ThingML [11]. ThingML is a domain specific language remotely monitored patients at home). Content of this section for modelling distributed IoT systems including the behaviour is based on our experience with our customers. of the distributed components in a platform-specific or Companies in highly regulated markets usually have risk -independent way. Currently, GeneSIS engine maintains a management owners in the organization. The exact role they list of the generic component types that are available in the play may depend on the type of company and the type of re- registry, namely FIWARE Orion, Arduino, RFXCom, and quirements this company may have. For instance, the company ThingML. For instance, a component written in ThingML will may have a Chief Security Officer (CSO), a Data Protection use the ThingML type. However, GeneSIS is very flexible Officer (DPO) as requested in some situations by GDPR, etc. and allows any user to create new component types at any In large organizations, it is common to have risk analysts to level of abstraction (e.g. “SQL database” or even “Oracle support the risk management process, while in SMEs this is SQL database”). Any of these types can be modelled as typically a role played by individuals whose background and a subtype of an Internal, an External or an Infrastructure knowledge is not on risk management. Companies that are Component (see Figure 1). Communication channels can be truly following DevOps principles, tend to make decisions established between internal and external components and around risk in a collegial manner, involving product owners, also between internal components through execution ports. risk analysts, developers, operations, etc. In this context, companies need to face many challenges, C. LINDDUN including coping with rapid software evolution, the need to LINDDUN [26] is a threat modelling methodology that obtain and keep relevant certificates to gain the trust of their encourages risk analysts to address privacy risks affecting end- customers, the need to prepare for any unwanted incident that users of the application or system. This methodology provides may negatively impact their businesses, etc. For this, they need some guidance to identify and categorize threats under a set to prepare internal policies to describe their procedures to of general risks (Linkability, Identifiability, Non-repudiation, handle risk management. Among these procedures, frequent Detectability, Disclosure of information, Unawareness, and meetings are usual where they need to rapidly understand Non-compliance). LINDDUN is sometimes considered the the status of risks in their projects, as well as, to reshape privacy-oriented alternative to the STRIDE framework. In or re-prioritize risk plans to better accommodate the current fact, LINDDUN threats are described in the so-called LIND- situation and market. When these needs are crossed with IoT, DUN trees which are explicitly connected to STRIDE threats proper risk management procedures become even more sig- trees [22]. We take this link between privacy and security as nificant. Requirements change frequently, technology evolves the baseline for our proposal in this paper. rapidly and, consequently, companies adopt agile software de- Unlike the approach proposed by MUSA Risk Assessment velopment processes. Therefore, continuous risk management tool, which grounds its threat modelling on descriptions of is probably the only effective strategy to ensure that risks are individual components, the LINDDUN methodology requires properly mitigated in long-term development processes. 25 and MUSA7 (and CORAS methodology implicitly): MODAClouds risk management methodology has a strong influence from CORAS, simplified to favour us- ability. 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 Fig. 2. High-level overview of the tasks around risk management that are relevant in the creation of TSIS. 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 Figure 2 shows the high-level description of a typical risk complements ISO/IEC 27001:2013 by providing an engi- management processes implemented in software companies. A neering, privacy-oriented perspective. LINDDUN is men- company may be developing software in the form of a product tioned as a methodology in this risk-oriented standard. or SaaS (e.g. connected to a trustworthy IoT system). Each • ISO 31000:2018 : it provides guidelines on managing product will have a person playing the role of the product risk. It can be used throughout the life of the any owner, who will supervise the whole development of that organization and can be applied to any activity, including product. Apart from this role, the company will typically have decision-making at all levels. Since it is the most generic a risk owner, who owns the risk management process and standard to describe risk management activities and it is strategy. This role may also take the form of a committee, com- agnostic to a particular context, we take it as a general posed of different people playing different roles, and bringing reference for our methodology. different perspectives, including Chief Product Officers, Chief Technology Officers or Chief Operation Officers. Risk owner will typically start and contribute and monitor the risk manage- ment 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 mech- anisms to monitor privacy-related issues. They require mech- anisms to monitor the implementation of related mitigation actions and the effectiveness of the treatments. IV. A LIGNMENT 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 Fig. 3. Comparison between the methodology followed by the Risk Assess- similar, they also differ in some aspects. Following, we analyze ment tool of MUSA (inspired by CORAS) and ISO/IEC 29134:2017. some well-known risk management methodologies or risk management guidelines proposed in standards, focusing in Figure 3 shows a visual summary of the main steps followed particular in those related to privacy issues. In particular, we by the risk management methodology in MUSA and the steps explore the following best practices in industry and some suggested in ISO/IEC 29134:2017. While the vocabulary is not previous related FP7 and H2020 projects: identical, the processes are similar, and it is possible to estab- 6 lish reasonable mappings among them. For instance, in MUSA • Risk management methodologies used in MODAClouds 6 MODAClouds FP7 (Project id: 318484) www.multiclouddevops.com 7 MUSA H2020 (Project id: 644429) www.musa-project.eu 26 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. V. M ODEL - BASED C ONTINUOUS R ISK M ANAGEMENT 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 manage- ment concepts to allow to control privacy risks using DFDs. Fig. 5. Proposed Model-based Risk Management methodology. Roles: (O) In particular, we consider each element of a DFD (Entity, Risk Management Owner; (P) Product Owner; (A) Architect; (V) Developer DataFlow, DataStore and Process) a specific asset, following and (R) Risk Analist LINDDUN methodology. This diagram is inspired by the UML diagram presented by Gupta et al. [12]. We generalize that UML diagram eliminating the part of the model that was DFDs represent our primary assets in the risk manage- specific to cloud aspects. We also introduce the idea of a ment process, our proposal entails the use of a second vulnerability associated to a combination of different assets in layer of supporting assets in the form of TSIS archictec- the system. In order to consider vulnerabilities and unwanted ture description. Therefore, in S1, GeneSIS Models (or incidents on multiple assets, we propose a new AssetSet equivalent architectural models) are also traversed and class and link vulnerabilities to this class (in addition to the components are pre-loaded. This step also includes the link to Asset class). Finally, note that when simplifying the definition of the vulnerabilities related to a component of risk management process is important, the explicit description an architecture or a subset of components. of vulnerabilities may be taken into consideration implicitly. • S2: Threats Identification: in this step, users identify Therefore, an alternative UML diagram could be considered threats that may affect the components in the described that connects Asset class with Unwanted Incident class. system. These threats are captured as instances of the In Figure 5, we propose a methodology for risk management Unwanted Incident class in the UML diagram in Figure 4. for the creation of TSIS and we indicate the actors involved in • S3: Risk Assessment: risk assessment is composed of each of those steps. Our methodology, inspired by the previous two different steps: risk analysis, where risks are eval- analysis, can be summarized in 6 main steps: uated in terms of likelihood and consequence, and risk • S1: TSIS Assets Definition: first, we edit or load DFDs evaluation, where risks are accepted, or they are classified representing the functional description of the system. This as risks that need to be mitigated. DFDs are useful to manage risks related to privacy as • S4: Definition of Treatments: mitigation actions are described by LINDDUN, although they were initially defined in the form of treatments. used for security risk control (e.g. in STRIDE). Although • S5: Residual Risk Assessment: once the mitigation con- trols are defined, the residual risks need to be reassessed. This involves again two steps: risk analysis, where like- lihood 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 Fig. 4. Class diagram to model risk management concepts using DFDs to them to treatments and risks. Mapping of DFDs and describe system functionality. architectural models will be the key for this to be possible. 27 TABLE I C ONNECTION BETWEEN LINDDUN THREAT CATEGORIES ( PRIVACY ) AND STRIDE THREAT CATEGORIES ( SECURITY ). L I N D D U N Information Disclosure at data flow Entity (between user and service) Data flow Information Disclosure at data flow Information Disclosure at data store Tampering with policy Data store Spoofing External Entities Information data store Tampering against authorization process Disclosure Information Disclosure of a process Spoofing External Entities Process Tampering against authorization process Tampering threats against persistent storage/process blocks Note that this methodology is continuous in the sense that are provided below. For instance, a NoSQL data store in our new evidence is continuously collected to challenge previous system architecture may be mapped to a data store component knowledge upon which risk-related decisions were made in the in a DFD. As another example, a particular process element in past. While immediate triggering of mitigation actions is not a DFD may be mapped to the server the process is running on. our main focus, conditional options based on the status of the As an alternative, it is possible that the mapping is not pre- system could be included in S4 to strengthen the continuous established before starting the risk analysis process. In this approach. Also, the methodology is particularly customized for situation, we consider that phase S1 can be extended to allow TSIS, specifically in S1, where GeneSIS models are used as the user to establish this mapping manually. the baseline, and S6, where evidences are collected to consider 1) Model mappings: in order to drive the mapping between privacy-related issues, as we show later on in this section. the architecture model and DFDs, we take as the baseline However, the methodology can be easily adapted to other types the connection between privacy-related threats studied in of systems and used generically. This will mainly depend on LINDDUN and the vulnerabilities that are related to security the models and the risks and mitigation actions defined. aspects of the architecture, as captured by STRIDE. Please note that LINDDUN defines a connection between threats in Model-based Risk Management approach LINDDUN categories and STRIDE threats through their threat GDPR establishes a set of duties imposed on the data trees catalogs [26]. Table I is a summary of the analysis of the processors, controllers and third parties which are aimed at connection of these LINDDUN and STRIDE threat catalogs. honoring the corresponding data subjects rights. In GDPR, risk In Table II, we show a sample of vulnerabilities extracted is explicitly scoped (Rec. 76) with regards to the rights and from [22] related to the STRIDE threats analyzed in Table I. freedoms of the data subject. In order to understand whether The table shows a brief description and some usual mitigation these data subject rights and principles (described in GDPR) actions. In the last two columns, we show examples of metrics are being effectively protected by mitigating existing risks, that could be used for continuous security monitoring and current approaches tend to analyze the data flow in the system what type of architectural components are being monitored. (e.g. LINDDUN and DFDs). However, elements in a DFD We would like to remark that this table is not meant to tend to be defined at a functional level (e.g. process to collect be an exhaustive list of all the potential threats, but some profile data from a user or process to merge data from two examples for illustrative purposes that serve the purpose of existing data sources). In this situation, collecting system data analyzing which DFD components are to be mapped to which to monitor a threat related to the identifiability of an entity as architectural components. defined by LINDDUN, just to take an example, is not obvious, Note that these vulnerabilities are specially relevant in an if we do not understand the relationship of a data flow in IoT context. For instance, let us take the example in Table II the application with the architecture of the infrastructure that related to Information Disclosure of Data Flow. There may we monitor. Without a proper connection of these elements be different vulnerabilities associated in particular to TSIS. to architectural levels that can be monitored, continuous risk For instance, if we have a device IoT hub, eavesdropping management for privacy becomes much more difficult. Most or interfering the communication between the device and the monitoring tools monitor the infrastructure level. These tools gateway would be a potential threat. You may also find similar may monitor system aspects in a data center or a particular threats in the communication between devices, where data may server, tools for network monitoring, etc, and collect metrics. be read in transit, tampering with the data or overloading the The main contribution of the approach proposed in this device with new connections. Or even with the cloud gateways, section is the mapping of TSIS architecture models, such as the where eavesdropping or communication interference between one proposed by GeneSIS, with data flows in the application devices and gateways may occur. under analysis (e.g. DFDs). In S6, we may assume that the In general, mappings between architectural models and DFD elements from both models have been mapped establishing a will link: link between the two types of models. Details on this mapping • entities in DFDs with the associated network channels in 28 TABLE II S AMPLE OF THE MAPPING BETWEEN STRIDE THREATS ( RELATED TO LINDDUN THREATS IN TABLE I) AND RELATED METRICS THAT CAN BE DETECTED FROM MONITORING ARCHITECTURAL COMPONENTS . STRIDE STRIDE tree Metrics for continuous Monitored Description Key mitigation actions Threat node [22] monitoring Components An attacker copies an Use standard authentication Continuous authenticator Network / authenticator from a non- protocols, instead of your detector warnings (comparing Spoofing Transit Communication encrypted channel or tamper own. Use strong encryption data in the channel with user External Channels with the connection. and authentication. database) Entities Avoid static passwords. Obtain Monitoring of number of Reuse of passwords is Avoid using e-mail credential brute-force attempts or Network / common. 3rd parties may addresses as usernames. from storage successful logins from a new Communication leak passwords your Detect brute-foce attempts, at a 3rd location or IP. Continuous user Channels customers use. or increase in successful party behavior analysis. logins from new locations. Predictable usernames or Detect usernames sent Predictable If assigning passwords, use Database / a poor random generator matching actual user names in credentials strong randomness. Data store for passwords. your internal databases. No or Weak Cryptographic. Use Continuous monitoring message Confidentiality Content of a message not Network / available message content readability. Can Information (Observing a protected or weakly Communication protection add-ons or we detect some content structure Disclosure Message protected. Channels tunneling. or detect words with meaning? at Data Structure) Flow No or Weak No or weak protection of Continuous channel monitoring Network / Confidentiality channel contents. Data Encrypt the channel. content readability. Can we get Communication (Observing a about the messages can Tunneling. some structure of the content? Channels Channel) be revealing. Or detect words with meaning? Bypassing Random data editor reporting Tampering protection ACLs, permissions, policies, Ensure data is created with the number of successful Database / at Data rules because etc allow people to alter data appropriate permissions. attempts to change data with Data store Store of no or weak without a clear justification. Change permissions. no or low privileges. protection Software Information Code time execution can Design for cryptography Monitoring execution time and components Disclosure Timing reveal confidential to take constant time. control variability. to solve tasks of a Process information. requiring secrecy. which entity information is transmitted or data stores in those presented as examples in Table II, to the related risks which the information is stored; or mitigation actions defined in S3 and S4. Following the risk • data flows in DFDs with the corresponding network methodology presented above, we will obtain instances for channels; the rest of classes in the diagram in Figure 4, including risks • data stores in DFDs with the corresponding databases or and mitigation actions. Once the risk model is developed for data stores used in the system architecture; and each DFD, we propose two ways to exploit the established • processes in DFDs with the corresponding software mappings to enable continuous risk management: components executing tasks related to those processes, • Automatic likelihood recalculation: during risk assess- specially when these tasks entail some level of secrecy. ment in S3, an initial likelihood and consequence values More formally, we define a set of DFDs, which represent a are determined for each risk. However, a basic principle functional description of the system, D = {D1 , D2 , . . . , Dn }, for continuous risk management is that conditions in our as a set of graphs Di = (DVi , DEi ), where DVi = system may change as time goes by. Let e be an element {e1 , . . . , em } are the elements in the DFD representing el- in a DFD Di , e ∈ DVi ∪ DEi , considered an asset ements of the system architecture at the functional level. Each in the risk management process. In S3, we define risks element ei can be an external entity, data store or a process. r1 , . . . , rj associated to e. Given a system architecture DEi = {f1 , . . . , fk } represents the data flows connecting defined through a model A = {VA , EA }, we define a set elements in DVi . We define a graph A = {VA , EA } where of metrics mc1 , . . . , mch for each component c ∈ VA ∪EA . VA = {c1 , . . . , cm } represent the architectural components at Automatic likelihood recalculation involves defining a the technical level represented in a model such as those created function f for each risk r related to each asset e such by GeneSIS and EA = {l1 , . . . , lk } represents the connections that c = M(e) and f (mc1 , . . . , mch ) provides a new value between any two components (ci , cj ) in the system architec- for the likelihood or risk r. With this, we connect the ture. Note that components can be both software or hardware metrics defined for the architectural components and use components. We define a mapping between the two models them to calculate the likelihood of risks connected to Di and A as a function M : DVi ∪ DEi → VA ∪ EA . elements of the functional description of a system, in the 2) Exploiting model mappings: once the mapping is estab- corresponding DFD. lished, then a final step is necessary to link metrics, such as • Treatment effectiveness control: a parallel approach to 29 enable continuous risk management, involves the defi- [9] N. Ferry, A. Solberg, H. Song, S. Lavirotte, J.-Y. Tigli, T. Winter, nition of a function g for each r related to an asset V. Muntés-Mulero, A. Metzger, E. R. Velasco, and A. C. Aguirre, “Enact: Development, operation, and quality assurance of trustworthy e ∈ DVi ∪ DEi such that c = M(e) and g(mc1 , . . . , mch ) smart iot systems,” in International Workshop on Software Engineering represents a KPI that needs to be satisfied for a risk to be Aspects of Continuous Development and New Paradigms of Software considered effectively mitigated. If g exceeds a particular Production and Deployment. Springer, 2018, pp. 112–127. [10] B. Fitzgerald and K. Stol, “Continuous software engineering: A roadmap threshold, then a warning needs to be issued for the risk and agenda,” Journal of Systems and Software, vol. 123, pp. 176–189, plan including mitigation actions to be reviewed. 2017. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2015.06.063 [11] F. Fleurey and B. Morin, “Thingml: A generative approach to engineer VI. C ONCLUSIONS heterogeneous and distributed systems,” in 2017 IEEE International Conference on Software Architecture Workshops (ICSAW). IEEE, 2017, Handling privacy-related risks is not well understood in pp. 185–188. the IoT context. There is a lack of mechanism to collect [12] S. Gupta, V. Muntés-Mulero, P. Matthews, J. Dominiak, A. Omerovic, J. Aranda, and S. Seycek, “Risk-driven framework for decision support meaningful evidences and continuously monitor these risks. in cloud service selection,” in 2015 15th IEEE/ACM International We need to find the intersection between data protection Symposium on Cluster, Cloud and Grid Computing. IEEE, 2015, pp. challenges and the enabling of TSIS. We have presented a first 545–554. [13] B. Karabacak and I. Sogukpinar, “Isram: Information security risk step towards the enactment of continuous privacy-related risk analysis method,” Comput. Secur., vol. 24, no. 2, pp. 147–159, Mar. control for TSIS, leveraging the link offered by LINDDUN 2005. [Online]. Available: http://dx.doi.org/10.1016/j.cose.2004.07.004 between privacy and security threat categories and combining [14] M. S. Lund, B. Solhaug, and K. Stølen, Model-driven risk analysis: the CORAS approach. Springer Science & Business Media, 2010. functional and architectural models. As future work, we need [15] Y.-S. Martin and A. Kung, “Methods and tools for gdpr compliance to establish a stronger connection between privacy threat through privacy and data protection engineering,” in 2018 IEEE Eu- models like LINDDUN and the actual requirements imposed ropean Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 2018, pp. 108–111. by GDPR, as current threat models were devised before GDPR [16] M. Merkow and L. Raghavan, “An ecosystem for continuously se- and they may not fully cover all derived requirements. In par- cure application software,” RUGGED Software, CrossTalk March/April, ticular, the relationship between data subject rights and GDPR 2011. [17] A. Moran, Agile Risk Management. Springer International Publishing, principles and LINDDUN categories is unclear. Besides, we 2014. need to understand how other privacy-related evidences can [18] V. Muntés-Mulero, O. Ripolles, S. Gupta, J. Dominiak, E. Willeke, be collected beyond those collected for security purposes. In P. Matthews, and B. Somosköi, “Agile risk management for multi-cloud software development,” IET Software, vol. 13, no. 3, pp. 172–181, 2018. particular in TSIS, where complex and distributed systems [19] H. Naseer, G. Shanks, A. Ahmad, and S. Maynard, “Towards an increase system weaknesses and the attack surface. analytics-driven information security risk management: A contingent resource based perspective,” Procs of ECIS 2017, pp. 2645–2655, 2017. ACKNOWLEDGMENT [20] A. Omerovic, “Supporting cloud service selection with a risk-driven cost-benefit analysis,” in Advances in Service-Oriented and Cloud Com- The authors would like to thank anonymous referees for puting, A. Celesti and P. Leitner, Eds. Cham: Springer International their valuable comments and suggestions. We would also like Publishing, 2016, pp. 166–174. to thank SINTEF and the GeneSIS team for allowing us to [21] A. Shameli-Sendi, R. Aghababaei-Barzegar, and M. Cheriet, “Taxonomy of information security risk assessment (isra),” Computers & Security, use some figures generated by them. vol. 57, pp. 14–30, 2016. [22] A. Shostack, Threat modeling: Designing for security. John Wiley & R EFERENCES Sons, 2014. [1] A. Ahmad, J. Hadgkiss, and A. B. Ruighaver, “Incident response [23] S. V. Shrivastava and U. Rathod, “A risk management teams–challenges in supporting the organisational security function,” framework for distributed agile projects,” Information and Software Computers & Security, vol. 31, no. 5, pp. 643–652, 2012. Technology, vol. 85, pp. 1 – 15, 2017. [Online]. Available: [2] C. J. Alberts and A. Dorofee, Managing Information Security Risks: http://www.sciencedirect.com/science/article/pii/S0950584916304815 The Octave Approach. Boston, MA, USA: Addison-Wesley Longman [24] D. Ståhl and J. Bosch, “Modeling continuous integration Publishing Co., Inc., 2002. practice differences in industry software development,” J. Syst. [3] A. Aslam, N. Ahmad, T. Saba, A. S. Almazyad, A. Rehman, A. Anjum, Softw., vol. 87, pp. 48–59, Jan. 2014. [Online]. Available: and A. Khan, “Decision support system for risk assessment and man- http://dx.doi.org/10.1016/j.jss.2013.08.032 agement strategies in distributed software development,” IEEE Access, [25] J. Webb, A. Ahmad, S. B. Maynard, and G. Shanks, “A situation vol. 5, pp. 20 349–20 373, 2017. awareness model for information security risk management,” Computers [4] R. Baskerville, P. Spagnoletti, and J. Kim, “Incident-centered informa- & security, vol. 44, pp. 1–15, 2014. tion security: Managing a strategic balance between prevention and [26] K. Wuyts, “Privacy threats in software architectures,” 2015. response,” Information & management, vol. 51, no. 1, pp. 138–151, [27] Z. Yan, P. Zhang, and A. V. Vasilakos, “A survey on trust management 2014. for internet of things,” Journal of network and computer applications, [5] B. Boehm and R. Turner, Balancing agility and discipline: A guide for vol. 42, pp. 120–134, 2014. the perplexed, portable documents. Addison-Wesley Professional, 2003. [6] S. Brooks, S. Brooks, M. Garcia, N. Lefkovitz, S. Lightman, and E. Nadeau, An introduction to privacy engineering and risk management in federal systems. US Department of Commerce, National Institute of Standards and Technology, 2017. [7] T. DeMarco, “Structure analysis and system specification,” in Pioneers and Their Contributions to Software Engineering. Springer, 1979, pp. 255–288. [8] N. Ferry, P. H. Nguyen, H. Song, P.-E. Novac, S. Lavirotte, J.-Y. Tigli, and A. Solberg, “Genesis: Continuous orchestration and deployment of smart iot systems.” In the proceedings of the IEEE COMPSAC conference, Milwaukee, USA, July 15-19. Springer, 2019. 30