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;

The development of secure and privacy-preserving software systems entails the continuous consideration of the security and privacy aspects of the system under development.While contemporary software development practices do support such a continuous approach towards software development, existing threat modeling activities are commonly executed as single-shot efforts leading to a single, historic, and quickly obsolete view on the security and privacy of the system. This disconnect leads to undetected new issues and wasted efforts on already resolved problems, effectively accruing technical debt.The presented SPARTA prototype facilitates the consideration of security and privacy by providing support for: (i) capturing security and privacy design decisions in a DFD-based architectural abstraction, (ii) continuous threat elicitation on this knowledgeenriched abstraction, and (iii) risk analysis of the elicited threats for prioritizing security and privacy efforts. By capturing and continuously assessing the impact of security and privacy design decisions on the elicited threats, the progress towards securing the system can be assessed and alternatives can be compared, taking into account past and present design decisions.

No abstract

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.

Data Protection by Design (DPbD) is a truly interdisciplinary effort that involves many stakeholders such as legal experts, requirements engineers, software architects, developers, and system operators. Building software-intensive systems that respect the fundamental rights to privacy and data protection is the result of intensive dialogue and careful trade-off decisions.In practice however, there is a dichotomy between the legal reasoning which is conducted in Data Protection Impact Assessments (DPIA) and software engineering approaches, such as threat modeling, aimed at identifying privacy requirements and privacy risks. These activities are commonly performed in total isolation, which negatively impacts (i) the compliance exercise, (ii) the ability to evolve the system over time, and (iii) the architectural trade-offs made during system design.In this article, we present an architectural viewpoint for describing software architectures from a legal, data protection perspective whose core modeling abstractions are based on an in-depth legal analysis of the EU General Data Protection Regulation. This viewpoint is tied to Data Flow Diagrams -commonly used in threat modeling-through correspondence rules. The proposed viewpoint supports the automation of a number of data protection impact assessment steps through (i) meta-model constraints, (ii) model analysis, and (iii) interaction with the involved stakeholders. This enables a streamlined compliance exercise, reconciling legal privacy and data protection notions with architecture-driven software engineering practices. We validate our approach in the context of a realistic e-health application for a number of complementary development scenarios.Index Terms-privacy by design, data protection, architectural viewpoint, GDPR, data protection by design, data protection impact assessment, accountability

Implementing security by design in practice often involves the application of threat modeling to elicit security threats and to aid designers in focusing efforts on the most stringent problems first. Existing threat modeling methodologies are capable of generating lots of threats, yet they lack even basic support to triage these threats, except for relying on the expertise and manual assessment by the threat modeler. Since the essence of creating a secure design is to minimize associated risk (and countermeasure costs), risk analysis approaches offer a very compelling solution to this problem. By combining risk analysis and threat modeling, elicited threats in a design can be enriched with risk analysis information in order to provide support in triaging and prioritizing threats and focusing security efforts on the high-risk threats. It requires the following inputs: the asset values, the strengths of countermeasures, and an attacker model. In his paper, we provide an integrated threat elicitation and risk analysis approach, implemented in a threat modeling tool prototype, and evaluate it using a real-world application, namely the SecureDrop whistleblower submission system. We show that the security measures implemented in SecureDrop indeed correspond to the high-risk threats identified by our approach. Therefore, the risk-based security analysis provides useful guidance on focusing security efforts on the most important problems first. CCS CONCEPTS • Security and privacy → Software security engineering; • Software and its engineering → Risk management;

Data flow diagrams (DFDs) are popular for sketching systems for subsequent threat modelling. Their limited semantics make reasoning about them difficult, but enriching them endangers their simplicity and subsequent ease of take up. We present an approach for reasoning about tainted data flows in design-level DFDs by putting them in context with other complementary usability and requirements models. We illustrate our approach using a pilot study, where tainted data flows were identified without any augmentations to either the DFD or its complementary models.

Since the General Data Protection Regulation (GDPR) entered into force, every actor involved in the processing of personal data must comply with Data Protection by Design (DPbD). Doing so requires assessing the risks to data subjects' rights and freedoms and implementing appropriate countermeasures. While legal experts traditionally apply Data Protection Impact Assessments (DPIA), software engineers rely on threat modeling for their assessment. Despite significant differences, both approaches nonetheless revolve around (i) a description of the system and (ii) the identification, assessment and mitigation of specific risks. In practice, however, DPIAs and threat modeling are usually performed in complete isolation, following their own, unharmonized lexicon and abstractions. Such as disconnect lowers the quality of the assessment and of the conceptual and architectural trade-offsIn this paper, we present (i) an overview of the legal and architectural modeling requirements and (ii) incentives and recommendations for aligning both modeling paradigms in order to support data protection by design from both a legal and a technical perspective. CCS CONCEPTS• Social and professional topics → Governmental regulations; • Software and its engineering → Architecture description languages; System modeling languages; • Security and privacy → Security requirements; Software security engineering;