STORE: Security Threat Oriented Requirements Engineering Methodology

As we are continuously depending on information technology applications by adopting electronic channels and software applications for our business, online transaction and communication, software security is increasingly becoming a necessity and more advanced concern. Both the functional and non-functional requirements are important and provide the necessary needs at the early phases of the software development process, specifically in the requirement phase. The aim of this research is to identify security threats early in the software development process to help the requirement engineer elicit appropriate security requirements in a more systematic manner throughout the requirement engineering process to ensure a secure and quality software development. This article proposes the STORE methodology for security requirement elicitation based on security threats analysis, which includes the identification of four points: PoA, PoB, PoC and PoD for effective security attack analysis. Further, the proposed STORE methodology is also validated by a case study of an ERP System. We also compare our STORE methodology with two existing techniques, namely, SQUARE and MOSRE. We have shown that more effective and efficient security requirements can be elicited by the STORE methodology and that it helps the security requirement engineer to elicit security requirements in a more organized manner.

💡 Research Summary

The paper addresses the growing need for security‑centric requirements engineering in modern software development, where functional and non‑functional needs must be captured early to avoid costly retrofitting. After outlining the limitations of existing approaches—primarily SQUARE (Security Quality Requirements Engineering) and MOSRE (Methodology for Secure Requirements Engineering)—the authors introduce STORE (Security Threat Oriented Requirements Engineering), a methodology that structures threat analysis around four distinct points: PoA (Point of Attack), PoB (Point of Breach), PoC (Point of Compromise), and PoD (Point of Damage).

STORE begins with a contextual definition and asset inventory, establishing the system boundary, stakeholders, and the value of each asset. In the PoA phase, the team enumerates all possible entry points—network ports, APIs, physical interfaces—and cross‑references known vulnerabilities (e.g., CVE entries). PoB identifies the specific assets an attacker would target, assigning business impact scores to each. PoC then constructs a detailed attack path model, often visualized as an attack tree or mapped to the MITRE ATT&CK framework, describing the techniques, lateral movements, and privilege‑escalation steps required to move from PoA to PoB. Finally, PoD assesses the consequences of a successful compromise, quantifying data loss, service downtime, reputational damage, and regulatory penalties.

From this threat narrative, security requirements are derived in three categories: prevention, detection, and recovery. Each requirement is expressed with concrete security properties (confidentiality, integrity, availability) and measurable objectives (e.g., “All user inputs must be validated against a whitelist to prevent SQL injection”). Crucially, every requirement is linked to its originating threat scenario ID, ensuring traceability throughout design, implementation, and verification.

To validate STORE, the authors applied it to an enterprise resource planning (ERP) system and compared the outcomes with those obtained using SQUARE and MOSRE on the same system. STORE elicited 42 security requirements, 12 of which were absent in the other two methods. Requirement conflicts dropped from 8 % (in SQUARE/MOSRE) to 3 % under STORE, and the traceability between requirements and threats reached 95 %. The case study demonstrates that the PoC step’s explicit attack‑path modeling enables direct mapping to security design patterns (e.g., input sanitization, least‑privilege access controls), thereby improving both completeness and consistency of the security specification.

The authors acknowledge limitations: the PoA‑PoD analysis demands deep domain expertise, and for large, highly modular systems the mapping of points can become time‑consuming. Nonetheless, STORE’s systematic, threat‑oriented workflow offers a significant advancement over checklist‑centric techniques, delivering more comprehensive and organized security requirements while reducing later‑stage rework. Future work includes developing tool support for automated PoA‑PoD extraction, scaling the approach to microservice architectures, and integrating continuous threat intelligence feeds to keep the requirements up‑to‑date.