Poster: Systematic Elicitation of Common Security Design Flaws Stef Verreydt imec-DistriNet KU Leuven Heverlee, Belgium stef.verreydt@kuleuven.be Koen Yskout imec-DistriNet KU Leuven Heverlee, Belgium koen.yskout@kuleuven.be Laurens Sion imec-DistriNet KU Leuven Heverlee, Belgium laurens.sion@kuleuven.be Wouter Joosen imec-DistriNet KU Leuven Heverlee, Belgium wouter.joosen@kuleuven.be Abstract—Threat modeling allows potential security threats to be identified and mitigated at design time. Countermea- sures in current threat modeling approaches are mostly modeled as a boolean: either they are implemented, or they are not. This does not allow to take into account potential design flaws for the countermeasure itself. A considerable number of security issues is, however, related to the wrong or incomplete application of common security tactics. For example, the effectiveness of audit logs drops if the data written to the logs is not sanitized. In this paper, we describe our novel approach which aims to systematically and automatically identify common security design flaws. Index Terms—Threat modeling, CWE, Security-by-design 1. Introduction Security and privacy by design principles are becom- ing increasingly important to develop secure software systems. Indeed, insecure design is one of the most critical software risks according to the OWASP Top 10 2021 [1], and adhering to security and privacy by design principles is even obligated by regulations such as the General Data Protection Regulation (GDPR) [2]. Threat modeling provides a systematic approach to analyze the security and privacy of a software design, thereby allowing potential threats to be identified early on in the development lifecycle. The first step of a threat modeling exercise involves creating a model of the system being analyzed, usually as a Data Flow Diagram (DFD). The DFD notation comprises just five elements, namely processes, data stores, external entities, data flows and trust boundaries. That model can then be analyzed to identify potential security threats. Tool support for auto- matic threat elicitation based on machine-readable system models is widespread, and new techniques are being de- veloped rapidly [3]. Common threat elicitation methods used by these tools are based on STRIDE (an acronym for spoofing, tampering, information disclosure, denial of service and elevation of privilege), but more specific types of threats or attacks such as CAPEC, CWE or CVE entries are also identified by some [4]. The next step of a threat modeling exercise is to miti- gate the identified threats by introducing countermeasures. This often involves standard tactics, for example using logging to mitigate repudiation threats [5]. Applying such tactics in a design requires careful consideration of their precise requirements and assumptions. For example, data written to audit logs should be sanitized (CWE-1171), and should not contain sensitive information such as creden- tials (CWE-5322). Ideally, design flaws which violate such requirements should be flagged automatically. One of the underlying issues which prevents this type of analyses is that most threat modeling tools [6] only allow to capture the effect of a countermeasure, and not how countermeasures are included in a design or which el- ements are involved [7]. For example, a repudiation threat could be marked as mitigated in the Microsoft Threat Modeling Tool [6], but there is no support to explicitly capture the countermeasure which mitigates the threat. To allow tracing back why and how threats are mitigated, Sion et al. [7] extended the DFD notation with a first-class representation for countermeasures. For example, a log- ging countermeasure can be explicitly added to the system model, allowing tool support to automatically mark certain repudiation threats as mitigated. In our novel approach, we leverage this explicit countermeasure information to automatically identify flaws rooted in the design of the count