Adapting Secure Tropos for Security Risk Management in the Early Phases of Information Systems Development

Abstract

Abstract. Security is a major target for todays information systems (IS) designers. Security modelling languages exist to reasoning on security in the early phases of IS development, when the most crucial design decisions are made. Reasoning on security involves analysing risk, and effectively communicating risk-related information. However, we think that current languages can be improved in this respect. In this paper, we discuss this issue for Secure Tropos, the language supporting the eponymous agent-based IS development methodology. We analyse it and suggest improvements in the light of an existing reference model for IS security risk management. This allows checking of Secure Tropos concepts and terminology against those of current risk management standards, thereby improving the conceptual appropriateness of the language. The paper follows a running example, called eSAP, located in the healthcare domain.

A Modeling Ontology for Integrating Vulnerabilities into Security Requirements Conceptual Foundations

“…Matulevicius et al [20] treat vulnerabilities as beliefs in the knowledge base of attackers which may contribute to the success of an attack. In [22], the i* framework is extended to represent vulnerabilities and their relation with threats and other elements of the i* models.…”

“…Among them, CORAS [7] does not investigate which design choices, requirements, or processes have brought the vulnerabilities to the system, and the semantics of relationships among vulnerabilities, and between vulnerabilities and threats are not defined. Similar to CORAS, the resulting models in [20,22] do not specify how, by what actions and actors the vulnerability is brought to the system. These models do not capture the impact of countermeasures on the vulnerabilities and attacks.…”

“…The link between attacks and vulnerabilities are implicitly (and explicitly) modeled in all of the surveyed approaches. However, among the modeling notations that provide explicit constructs for modeling vulnerability, only a few frameworks [20] Risk-Based Security Framework by Mayer et al [22] Extensions to misuse case diagram [26] Security extension on i* framework by Elahi et al [8,9] Conceptual Foundation such as CORAS [7], i* security extensions [9,8], and extensions of misuse case models [26] relate the countermeasures to vulnerabilities. The semantics of the countermeasure impact in [7,26] is not well defined, and the model cannot be used to evaluate the impact of countermeasures on the overall system security.…”

A vulnerability-centric requirements engineering framework: analyzing security attacks, countermeasures, and requirements based on vulnerabilities

“…Only few security software engineering approaches consider analyzing vulnerabilities, as weaknesses in the systems, during the elicitation of security requirements. For instance, in [27], vulnerabilities are modeled as beliefs inside the boundary of attackers that may positively contribute to attacks. However, the resulting models do not specify which actions or assets introduce vulnerabilities into the system, and which actors are vulnerable.…”

“…The CORAS framework [5,12] provides a way for expressing how a vulnerability leads to another vulnerability and how a vulnerability (or combination of vulnerabilities) lead to a threat. However, similar to [27], CORAS does not investigate which design choice, requirement, or process has brought the vulnerabilities to the system. Current state of the art raises the need for a systematic way to link the empirical security knowledge such as information about vulnerabilities, attacks, and proper countermeasure to stakeholders' goals and security requirements.…”