No abstract

Threat modeling refers to a number of systematic approaches for eliciting security and privacy threats. Data Flow Diagrams (DFDs) are the main input for threat modeling techniques such as Microsoft STRIDE or LINDDUN. They represent system-level abstractions that lack any architectural knowledge on existing security solutions. However, this is not how software is built in practice: there are often previously-made security-and privacy-relevant decisions that originate from the technological context or domain, reuse, or external dependencies. Not taking these into account leads to the enumeration of many non-applicable threats during threat modeling. While recording the effect of these decisions on individual elements can provide some relief, the lack of a proper first-class representation causes conflicts when modifying the architecture and inhibits traceability between effect and decision. In this paper, we enrich Data Flow Diagrams with security solution elements, which are taken into account during threat elicitation. Our modeling approach is supported by a proof-of-concept implementation of a threat modeling framework and validated in the context of a STRIDE analysis of an industrial video conferencing solution that is based on WebRTC. The presented DFD enrichments are a key enabler for future efforts towards dynamic and continuous threat modeling. CCS CONCEPTS • Security and privacy → Software security engineering; • Software and its engineering → Data flow architectures; Abstraction, modeling and modularity;

Threat modeling involves the systematic identification, elicitation, and analysis of privacy-and/or security-related threats in the context of a specific system. These modeling practices are performed at a specific level of architectural abstraction -the use of Data Flow Diagram (DFD) models, for example, is common in this context.To identify and elicit threats, two fundamentally different approaches can be taken: (1) elicitation on a per-element basis involves iteratively singling out individual architectural elements and considering the applicable threats, (2) elicitation at the level of system interactions (which involve the local context of three elements: a source, a data flow, and a destination) performs elicitation at the basis of system-level communication.Although not considering the local context of the element under investigation makes the former approach easier to adopt and use for human analysts, this approach also leads to threat duplication and redundancy, relies more extensively on implicit analyst expertise, and requires more manual effort.In this paper, we provide a detailed analysis of these issues with element-based threat elicitation in the context of LINDDUN, an element-driven privacy-by-design threat modeling methodology. Subsequently, we present a LINDDUN extension that implements interaction-based privacy threat elicitation and we provide indepth argumentation on how this approach leads to better process guidance and more concrete interpretation of privacy threat types, ultimately requiring less effort and expertise.A third standalone contribution of this work is a catalog of realistic and illustrative LINDDUN privacy threats, which in turn facilitates practical threat elicitation using LINDDUN.