Security patterns are well-known solutions to security-specific problems. They are often claimed to benefit designers without much security expertise. We have performed an empirical study to investigate whether the usage of security patterns by such an audience leads to a more secure design, or to an increased productivity of the designers. Our study involved 32 teams of master students enrolled in a course on software architecture, working on the design of a realisticallysized banking system. Irrespective of whether the teams were using security patterns, we have not been able to detect a difference between the two treatment groups. However, the teams prefer to work with the support of security patterns.

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.

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.

Security patterns can be a valuable vehicle to design secure software. Several proposals have been advanced to improve the usability of security patterns. They often describe extra annotations to be included in the pattern documentation. This paper presents an empirical study that validates whether those proposals provide any real benefit for software architects. A controlled experiment has been executed with 90 master students, who have performed several design tasks involving the hardening of a software architecture via security patterns. The results show that annotations produce benefits in terms of a reduced number of alternatives that need to be considered during the selection of a suitable pattern. However, they do not reduce the time spent in the selection process.

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;

In the past 10 years, the research community has produced a significant number of design notations to represent security properties and concepts in a design artifact. These notations are aimed at documenting and analyzing security in a software design model. The fragmentation of the research space, however, has resulted in a complex tangle of different techniques. Hence, practitioners are confronted with the challenging task of scouting the right approach from a multitude of proposals. Similarly, it is hard for researchers to keep track of the synergies among the existing notations, in order to identify the existing opportunities for original contributions. This paper presents a systematic literature review that inventorizes the existing notations and provides an indepth, comparative analysis for each.