Two Architectural Threat Analysis Techniques Compared

Tuma, Katja; Scandariato, Riccardo

doi:10.1007/978-3-030-00761-4_23

Cited by 24 publications

(27 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This result is not surprising. Similar measurement of precision and recall have been reported in related empirical studies investigating manual knowledge-based threat analysis techniques, i.e., STRIDE [17,21]. In general, high precision and low recall may be a common trait for techniques that manually analyze software architectures.…”

Section: Resultssupporting

confidence: 67%

“…Similar measurements of precision and recall have been reported in related empirical studies investigating knowledge-based manual threat analysis techniques, i.e. STRIDE [17,21]. We have found that many participants have expressed doubts when detecting certain security design flaws.…”

Section: Introductionsupporting

confidence: 83%

“…The system documentation (about 30 pages) includes (1) the description of the problem domain with scenarios, (2) the requirements of the system including non-functional requirements and (3) a hierarchically decomposed architecture specified with UML (e.g, deployment diagram). The complete description of the system has been used in previous studies [21] and is open to the public. The participants were tasked to read the preparatory material (including the system documentation) before the experiment took place.…”

Section: Empirical Experimentsmentioning

confidence: 99%

See 2 more Smart Citations

Inspection guidelines to identify security design flaws

Tuma

Hosseini

Malamas

et al. 2019

Proceedings of the 13th European Conference on Software Architecture - Volume 2

Self Cite

View full text Add to dashboard Cite

Recent trends in the software development practices (Agile, De-vOps, CI) have shortened the development life-cycle causing the need for efficient security-by-design approaches. In this context, software architectures are analyzed for potential vulnerabilities and design flaws. Yet, design flaws are often documented with natural language and require a manual analysis, which is inefficient. Besides low-level vulnerability databases (e.g., CWE, CAPEC) there is little systematized knowledge on security design flaws. The purpose of this work is to provide a catalog of security design flaws and to empirically evaluate the inspection guidelines for detecting security design flaws. To this aim, we present a catalog of 19 security design flaws and conduct empirical studies with master and doctoral students. This paper contributes with: (i) a catalog of security design flaws, (ii) an empirical evaluation of the inspection guidelines with master students, and (iii) a replicated evaluation with doctoral students. We also account for the shortcomings of the inspection guidelines and make suggestions for their improvement with respect to the generalization of guidelines, catalog re-organization, and format of documentation. We record similar precision, recall, and productivity in both empirical studies and discuss the potential for automating the security design flaw detection.

show abstract

Section: Resultssupporting

confidence: 67%

Section: Introductionsupporting

confidence: 83%

Section: Empirical Experimentsmentioning

confidence: 99%

See 1 more Smart Citation

Inspection guidelines to identify security design flaws

Tuma

Hosseini

Malamas

et al. 2019

Proceedings of the 13th European Conference on Software Architecture - Volume 2

Self Cite

View full text Add to dashboard Cite

show abstract

“…The results of Tuma and Scandariato [29] indicate that a perelement STRIDE threat analysis is more effective than a per-interaction based one, so we focus on the elements as assets rather than the interactions. Therefore, all elements in the DFD are assets.…”

Section: Item Definition and Asset Identificationmentioning

confidence: 99%

Proposing HEAVENS 2.0 – an automotive risk assessment model

Lautenbach

Almgren

Olovsson

2021

Computer Science in Cars Symposium

View full text Add to dashboard Cite

Risk-based security models have seen a steady rise in popularity over the last decades, and several security risk assessment models have been proposed for the automotive industry. The new UN vehicle regulation 155 on cybersecurity provisions for vehicle type approval, as part of the 1958 agreement on vehicle harmonization, mandates the use of risk assessment to mitigate cybersecurity risks and is expected to be adopted into national laws in 54 countries within 1 to 3 years. This new legislation will also apply to autonomous vehicles. The automotive cybersecurity engineering standard ISO/SAE 21434 is seen as a way to fulfill the new UN legislation, so we can expect quick and wide industry adoption. One risk assessment model that has gained some popularity and is in active use in several companies is the HEAVENS model, but since ISO/SAE 21434 introduces additional requirements on the risk assessment process, the original HEAVENS model does not fulfill the standard.In this paper, we investigate the gap between the HEAVENS risk assessment model and ISO/SAE 21434, and we identify and propose 12 model updates to HEAVENS to close this gap. We also discuss identified weaknesses of the HEAVENS risk assessment model and propose 5 additional model updates to overcome them. In accordance with these 17 identified model updates, we propose HEAVENS 2.0, a new risk assessment model based on HEAVENS which is fully compliant with ISO/SAE 21434. CCS CONCEPTS• Computer systems organization → Embedded and cyberphysical systems; Dependable and fault-tolerant systems and networks; • Security and privacy → Security requirements; Systems security; Embedded systems security.

show abstract

“…For instance, STRIDE is a well-known threat analysis technique that is also used in the automotive domain. This technique has the tendency to produce a high volume of threats [15,19]. Many threats are later-on discarded due to a low risk value (a combination of impact and likelihood).…”

Section: Introductionmentioning

confidence: 99%

Finding Security Threats That Matter: An Industrial Case Study

Tuma,

Sandberg,

Thorsson

et al. 2019

Preprint

Self Cite

View full text Add to dashboard Cite

Recent trends in the software engineering (i.e., Agile, DevOps) have shortened the development life-cycle limiting resources spent on security analysis of software designs. In this context, architecture models are (often manually) analyzed for potential security threats. Risk-last threat analysis suggests identifying all security threats before prioritizing them. In contrast, risk-first threat analysis suggests identifying the risks before the threats, by-passing threat prioritization. This seems promising for organizations where developing speed is of great importance. Yet, little empirical evidence exists about the effect of sacrificing systematicity for high-priority threats on the performance and execution of threat analysis. To this aim, we conduct a case study with industrial experts from the automotive domain, where we empirically compare a risk-first technique to a risk-last technique. In this study, we consciously trade the amount of participants for a more realistic simulation of threat analysis sessions in practice. This allows us to closely observe industrial experts and gain deep insights into the industrial practice. This work contributes with: (i) a quantitative comparison of performance, (ii) a quantitative and qualitative comparison of execution, and (iii) a comparative discussion of the two techniques. We find no differences in the productivity and timeliness of discovering high-priority security threats. Yet, we find differences in analysis execution. In particular, participants using the risk-first technique found twice as many high-priority threats, developed detailed attack scenarios, and discussed threat feasibility in detail. On the other hand, participants using the risk-last technique found more medium and low-priority threats and finished early.

show abstract

Two Architectural Threat Analysis Techniques Compared

Cited by 24 publications

References 17 publications

Inspection guidelines to identify security design flaws

Inspection guidelines to identify security design flaws

Proposing HEAVENS 2.0 – an automotive risk assessment model

Finding Security Threats That Matter: An Industrial Case Study

Contact Info

Product

Resources

About