Solution-aware data flow diagrams for security threat modeling

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;

Integrating Threat Modeling and Automated Test Case Generation into Industrialized Software Security Testing

“…This yields a list of threats that is both holistic and specific to the SUT. This can also be extended with security building blocks that refine the threat derivation [7]. The two basic components of a threat model therefore pose an ideal tool to achieve the system modeling for security TCG: the DFD represent an abstraction of the SUT, while the according threat template represent an abstraction of the threats to the system.…”

Risk-based design security analysis

“…This section provides some background information on threat modeling in general, and the previously developed extension [18] we rely on to enable the risk analysis techniques discussed further on. Note that other security or privacy extensions [2,4,21] could be used as well.…”

“…Since security solutions are more complex and often span multiple elements, a more extensive representation is used in our approach. We rely on a more expressive representation of security countermeasures as patterns [18]. These patterns specify roles for the DFD elements involved in the pattern and specify the countermeasures that apply security protections to those roles.…”

“…Additionally, in earlier work, we have also performed a qualitative evaluation of the DFD security enrichments, by comparing it with security property-based solutions such as the Microsoft Threat Modeling Tool 2016 [13], showing positive improvements in terms of semantic quality, traceability, separation of concerns, and dynamism [18].…”

“…In these existing approaches and applications, data flow diagrams remain largely security and privacy agnostic models, with only minor, and often ad-hoc, additions for security or privacy. However, recently there have been several proposals for extensions to these data flow diagrams in order to have a more systematic representation of security-and privacy-relevant information in order to elicit the most relevant security and/or privacy threats [2,4,18,21].…”