Using the AMAN-DA method to generate security requirements: a case study in the maritime domain

Abstract

Abstract. [Context and motivation]Security requirements are known to be "the most difficult of requirements types", and potentially the ones causing the greatest risk if they are not correct. One approach to requirements elicitation is based on the reuse of explicit knowledge. AMAN-DA is a requirement elicitation method that reuses encapsulated knowledge in security and domain ontologies to produce security requirements specifications.[Question/Problem] The main research question addressed in this paper is to what extent is AMAN-DA able to generate domain specific security requirements? [Principal idea/results] Following a well-documented process, a case study related to the maritime domain was undertaken with the goal to demonstrate the utility and effectiveness of AMAN-DA for the elicitation and analysis of domain specific security requirements. The usefulness of the method was also evaluated with a group of twelve experts.[Contribution] The paper demonstrates the elicitation of domain specific security requirements by presenting the AMAN-DA method and its application. It describes the evaluation and reports some significant results and their implications for practice, and future research, especially for the field of knowledge reuse in requirements engineering.

Security models of the Internet of Things

“…Безпека IoT з акцентом на вплив нових технологій представлена у роботі [9]. Питання формування вимог безпеки до компонентів IoT розглядаються в [10,11]. Огляд заходів безпеки для IoT представлено в [12].…”

Towards a new template for the specification of requirements in semi-structured natural language

“…(Arora, et al 2013) and (Arora, et al 2015) provide additional insight by supporting the automatic compliance of the requirements using NL processing techniques for the verification of requirements, something that our work does not raise and that will be part of later work on the automatic verification of the requirements. In addition, (Arora, et al 2013) also presents a flexible template to specify requirements that can be adapted to different styles of writing requirements and other proposals such as (Souag, et al 2018) go even further by allowing the automatic generation of non-functional requirements (security in particular) in semi-structured NL thanks to the use of two ontologies: a security ontology (Souag, et al 2015) and a domain-specific ontology. In contrast, our proposal is agnostic to the type of non-functional requirements; however, it should be inspired in the future by the related work to facilitate the writing of requirements.…”

The Requirement Cube

“…Security goals and requirements can be distinguished and written in different patterns. A case study is conducted in the maritime industry to identify stakeholders' security goals, and participants have agreed on the model's success (Souag, Mazo, Salinesi, & Comyn-Wattiau, 2018). Toval, Nicolás, Moros, & García (2002) propose a method called SIREN (Simple Reuse of Software Requirements), which focuses on the reuse of security requirements.…”

“…In summary, requirement writing methods use either too specific and sophisticated approaches like formal notations and domain ontologies (Siau, 2016;Yue et al, 2019) or focus on a specific type of requirements, such as stakeholder and non-functional requirements (Souag et al, 2018;Toval et al, 2002;Franch et al, 2010). Sophisticated approaches are almost impossible to be implemented in industry practices (Siau, 2016).…”