The concept of privacy-by-design has gained considerable attention in the wake of legal requirements that software systems should fulfill. The interconnected knowledge on privacy concepts, legal requirements, and software development artifacts required to implement this concept can be a major burden for organizations. To address this challenge, we propose a knowledge graph-based Exploratory Search system to help organizations complete privacy engineering tasks. We identify major requirements of such systems and develop an Exploratory Search prototype built on privacy engineering knowledge that integrates diferent information sources. While still preliminary, this work serves as a foundation for future research on integrating privacy knowledge into software development and demonstrates the potential of Exploratory Search Systems to support the cognitive process in privacy tasks such as privacy threat identification.
The concept of "privacy by design" has come to the spotlight following the implementation of the
General Data Protection Regulation (GDPR1). This concept mandates that software developers
embed privacy protection directly into their applications from the start, rather than as an
afterthought [
Given the complexity of these various areas of knowledge, Privacy Engineering stakeholders,
such as privacy engineers and software developers are often intimidated by the amount of
knowledge required to follow privacy engineering principles [
The heterogeneous sources range from privacy frameworks, software artifacts, threat
intelligence, privacy design patterns to region-specific regulations such as the GDPR and CCPA [
While ontology-based Exploratory Search strategies have been successfully implemented
in domains such as software engineering [
In this paper, we propose the adaptation of an existing Exploratory Search system method [
We selected LINDDUN as our model for privacy requirements engineering due to its extensive application and widespread acceptance [11]. Threat modeling involves the collaboration of numerous stakeholders. We outline three primary participants in the privacy engineering procedure: (i) Software Architects (SA), who focuses on designing the general architecture of the software, e.g., DFD definition (cf. Step 1 in Figure 1), (ii) Privacy Engineer (PE), who is responsible for identify privacy requirements and propose mitigation strategies (i.e., Step 2-6 in Figure 1, and (iii) Software Developer (SD), who is responsible to implement technical measures according to the chosen mitigation strategies. In this paper, we focus on the role of PE and SD, whose scenarios and requirements will be described next.
Privacy Engineer (PE). A typical privacy engineering process often begins with a PE’s review of DFD, which is created by the SA. For a more comprehensive understanding of the DFD, the PE may revisit the initial system requirements. After that, the PE can start the threat analysis, beginning with a particular element within the DFD. This analysis will involve various queries, such as "Could this data flow pose a potential threat to the system? What type of threats could emerge? If such threats exist, how can they be mitigated?".
To answer these questions, the PE explores the threat tree, which helps in identifying potential threats. Within the LINDDUN framework, seven unique threat types exist, each having its own hierarchical structure of threat trees [10]. Following the identification of potential threats, mitigation strategies can be suggested. These could involve using Privacy Enhancing Technologies (PETs) as per the existing mapping or creating a new, innovative solution beyond the current mapping.
Software Developer (SD). SDs are primarily responsible for implementing the technical measures outlined by privacy engineers. Nevertheless, SD technical expertise can contribute to a threat modeling process that includes identifying threats and selecting technical measures.
Based on our analysis on the typical scenarios of Privacy Engineering described the previous section, we identified a set of requirements to support PEs and SDs in their role in Privacy Engineering as the following:
Multiperspective Exploration. Multiple stakeholders involved in the privacy engineering process [10]. SAs provides DFDs as part of the system architecture. PEs ensure that privacy risks are identified and develop requirements for mitigating the risk. They can also recommend mitigation. The SDs will ensure that all suggested requirements and mitigations are incorporated into the system. Allowing all knowledge to be explored in one location by multiple stakeholders ensures consistency and traceability.
Data Flow Visualization. An important aspect of privacy threat modeling is understanding the data flow within a system, as this helps PEs identify potential threats. The DFD itself can be represented as a triple consisting of two elements (either external entity, process, or data store) associated with the data flow [ 12]. These elements also form the basis for threat identification [10]. Incorporating this data flow knowledge into the knowledge graph and visualizing it as a DFD within the exploratory search would be beneficial to the threat modeling process and provide traceability to the identified threat.
Threat Tree Visualization. Threat trees, also known as attack trees, are graphical representations of threats or attacks against a system that are organized hierarchically. They show diferent ways a system can be exploited by breaking down higher-level threats into smaller, more specific threats. Therefore, a hierarchical browsing capability for threat trees is important. In addition, a text-based search would be beneficial to enable PEs to search for specific threats within the threat trees.
Based on the identified requirements from Section 2.1, we developed an initial Exploratory
Search System for Privacy Engineering following the STAR approach [
Ontology for Privacy Engineering. The ontology builds on concepts derived from privacy
engineering methods [10, 15, 16]. The ontology aims to connect software development artifacts
[13] with privacy knowledge [
Ontology Population Privacy engineering tools such as ProPAN [15] or PrivacyStory [14] are examples of privacy engineering tools that would support the privacy engineering processes shown in Figure 1. These tools stored their results in various data models and formats and therefore will need to be transformed into an integrated format. In our prototype development, we use the knowledge generated by PrivacyStory3 and transform them into the the previously described ontology. In the future, we plan to integrate more resources, e.g., the threat knowledge base and mitigation tools can be fed from the known threat knowledge base, and their mitigation can be mapped based on the known ontology [9]. Legal concepts such as GDPR can also be added to the knowledge base.
The details on the development and evaluation of the ontology and the population process from privacy engineering knowledge bases are beyond the scope of this paper.
The implementation of the Exploratory Search System (ESS) is constructed upon the foundation
laid by Haller et al. [
Multiperspective Exploration. Allowing all knowledge to be explored in one location
by multiple stakeholders ensures consistency and traceability. The ESS system can efectively
use the multiperspective exploration feature for this purpose [
Figure 3 shows the perspective of PEs and SDs. The privacy engineering process begins with the selection of user stories. They can select based on specific actors or stakeholders. After choosing a particular story, the privacy engineer can view other user stories that involve the same actor. These stories come with a DFD produced by privacy engineering tools [12], providing a visual representation of how data moves through diferent processing. This point marks the start of exploration for threat modeling purposes.
SDs are able to see what technical measures were chosen by the PEs, while also being able to trace back why those measures were chosen and for what user stories.
Data Flow Visualization. We included DFD visualizations for every user story to enhance comprehension from the user’s viewpoint [12]. In addition, we’ve converted the details within the DFD and its triple connections into a format that is traceable and searchable in text, making it easier to locate using text-based searches. PrivacyStory also allows us to present a single DFD that encompasses multiple user stories [14]. In the future, we are planning to represent DFD in a machine-readable manner for a better user experience.
Threat Tree Visualization. LINDDUN provides a catalog of privacy threat trees grouped into seven categories of threats [10]. We’ve converted this catalog into a knowledge graph, which is displayed hierarchically in the ESS. The tree-like hierarchical representation can be accessed through the hierarchy menu, which is separate from the main text search.
The ESS also allows users to start with the text-based search to eficiently identify related topics. The underlying text search uses indexing based on the triple store. In our system, we use Lucene scoring, which uses a combination of the vector space model (VSM) of information retrieval and the Boolean model to determine how relevant a particular document is to a user’s query. Moreover, the ESS is capable of showing threats related to the currently displayed ones, thereby aiding users in navigating the threat knowledge base. Owing to its exploratory design, users have the flexibility to traverse back and forth within the interconnected knowledge base, thus expanding their understanding of related details and context. In future works, we aim to enhance this threat knowledge base by incorporating other privacy threat modeling approaches or knowledge [17].
Knowledge about privacy-by-design principles is currently scattered across diferent domains and locations, making it dificult for organizations to access and understand it due to the significant cognitive efort required. In this paper, we present an ontology-based search system to facilitate organizations’ access to privacy-related knowledge in relation to their own setting. The search system requires the organization to adapt its knowledge to the ontology and include it in the ontology that meets the standards. This system enables various stakeholders, including privacy engineers and developers, to visualize and understand data flow diagrams and threat trees through its networked knowledge base. While still in its early stages, this research lays the groundwork for future studies aimed at more efectively incorporating privacy knowledge in software development processes. It also highlights the potential of the Exploratory Search systems in reducing the cognitive demands associated with acquiring privacy knowledge.
In the future, we plan to evaluate how efectively privacy engineers or developers can use our exploratory search system to retrieve specific privacy knowledge and how they evaluate their user experience. We also plan to conduct comparative studies comparing the performance of our search system in facilitating the privacy engineering process with performance without the tools. Feedback from these evaluations will help us improve the ontology structure, user interface design, and overall user interaction flow.
Acknowledgments: This work is supported by the European Union’s Horizon 2020 research project OntoTrans under Grant Agreement No 862136. [9] A. Al-Momani, K. Wuyts, L. Sion, F. Kargl, W. Joosen, B. Erb, C. Bösch, Land of the lost: privacy patterns’ forgotten properties: enhancing selection-support for privacy patterns, in: Proceedings of the 36th Annual ACM Symposium on Applied Computing, 2021, pp. 1217–1225. [10] M. Deng, K. Wuyts, R. Scandariato, B. Preneel, W. Joosen, A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements, Requirements Engineering 16 (2011) 3–32. [11] K. Wuyts, L. Sion, W. Joosen, Linddun go: A lightweight approach to privacy threat modeling, in: 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), IEEE, 2020, pp. 302–309. [12] G. B. Herwanto, G. Quirchmayr, A. M. Tjoa, From user stories to data flow diagrams for privacy awareness: A research preview, in: International Working Conference on Requirements Engineering: Foundation for Software Quality, Springer, 2022, pp. 148–155. [13] G. B. Herwanto, G. Quirchmayr, A. M. Tjoa, A named entity recognition based approach for privacy requirements engineering, in: 2021 IEEE 29th International Requirements Engineering Conference Workshops (REW), IEEE, 2021, pp. 406–411. [14] G. B. Herwanto, G. Quirchmayr, A. M. Tjoa, Privacystory: Tool support for extracting privacy requirements from user stories, in: 2022 IEEE 30th International Requirements Engineering Conference (RE), IEEE, 2022, pp. 264–265. [15] R. Meis, Problem-Based Privacy Analysis (ProPAn): A Computer-aided Privacy Requirements Engineering Method, Universitaet Duisburg-Essen (Germany), 2018. [16] M. Gharib, P. Giorgini, J. Mylopoulos, Copri v. 2—a core ontology for privacy requirements,
Data & Knowledge Engineering 133 (2021) 101888. [17] C. Bloom, Privacy threat modeling, USENIX Association, Santa Clara, CA (2022).