SPARTA: Security & Privacy Architecture Through Risk-Driven Threat Assessment

Abstract

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.

Flaws in Flows: Unveiling Design Flaws via Information Flow Analysis

“…A second analysis of the WebRTC was performed using a different tool as a sanity-check of our results. We compared our results to the results obtained by an Eclipse plugin introduced by Sion et al [16]. The authors identify several threats as less critical.…”

“…Sion et al [16] present an approach for a risk-centric threat analysis of DFDs, which enables threat elicitation and risk analysis. The ability to model security solutions in the form of architectural patterns is useful for a more comprehensive analysis.…”

Security Debt: Characteristics, Product Life-Cycle Integration and Items

“…Some authors refer security debt as technical debt containing a security risk [7] or potential security implications [8]. Security engineering techniques (e.g., risk analysis) are used to identify the security debt [6], [8] and security risk in software can be described [7], [11] Technical debt can be a source of security debt [1], [3], [8] Tradeoffs of security and other quality attributes (e.g., performance) might force to assume security debt [5], [14] Organizational Organization policies should prioritize security debt [12], [19] Security awareness and skills are needed to avoid security debt [8], [13] Security debt involves different stakeholders requiring discussions and decision making among them [5], [14] Consequences Business damage: High interest of the debt [8], [9], [12], [14], [16], [21] Interest will be paid mainly when someone exploit the vulnerability [8], [9], [16], [21] Paying the principal of the security debt might require to change processes [16], [19] in terms of technical debt [8], e.g., including the probability attribute to the security debt item to measure the chances that the security-related defect can be actually exploited [5].…”

Threat and Risk Management Framework for eHealth IoT Applications

“…Both methodologies act upon Data Flow Diagrams (DFDs) as system representation, which makes them complementary. The efficiency of their synergy in terms of security and privacy threat modelling is proven by the SPARTA tool introduced in [28]. Since STRIDE and LINDDUN miss on risk assessment [7], SPARTA tries to enrich them with FAIR [13] risk analysis, but it does not provide means for managing variability and providing scoring for system configurations.…”