Validación empírica del uso de plantillas para la identificación de requerimientos de seguridad de aplicaciones de software
Loading...
Date
Authors
Martínez Mesén, Andrés
Journal Title
Journal ISSN
Volume Title
Publisher
Abstract
La identificación de los requerimientos de seguridad es una tarea esencial que debe de ser abordada en las fases tempranas del ciclo de vida del desarrollo de software (SDLC). Usualmente es encomendada a ingenieros de software y a personal de TI en general, en caso de que no haya un ingeniero de requerimientos en la organización. No obstante, estos profesionales no son expertos en seguridad y podrían fallar al definir cuáles objetivos de seguridad deben estar presentes en un sistema, por lo que podrían generar pocos o inadecuados requerimientos de seguridad. En algunos casos, este proceso de extracción de requerimientos de seguridad no se realiza o se realiza hasta que el sistema está por ser liberado. En este contexto, la seguridad podría ser vista como opcional.
Varios enfoques de ingeniería de requerimientos de seguridad han sido planteados para resolver parte de este problema. Sin embargo, estos enfoques todavía demandan que el profesional sea un experto en seguridad. Algunos investigadores han argumentado que el uso de plantillas de requerimientos podría ayudar a los profesionales a identificar los requerimientos de seguridad implícitos en los requerimientos funcionales. Riaz et al. (2014a) propuso un conjunto de 19 plantillas de requerimientos de seguridad vinculadas a seis objetivos de seguridad: confidencialidad, integridad, disponibilidad, identificación y autenticación, responsabilidad y privacidad. Este método fue diseñado para ayudar en la identificación de objetivos de seguridad implícitos en los requerimientos funcionales.
En esta investigación, se realizaron dos replicaciones diferenciadas y se analizó la efectividad de las plantillas de requerimientos de seguridad para apoyar la identificación de los requerimientos de seguridad implícitos en los requerimientos funcionales. Para esto evaluamos el uso de las plantillas y comparamos los hallazgos obtenidos en estudios previos, en un contexto diferente. En el 2015, la primera replicación del experimento original fue realizada en la Universidad de Costa Rica (UCR). En 2018, realizamos las dos nuevas replicaciones en la UCR. Las respuestas de 17 participantes fueron analizadas en términos de calidad, cobertura, relevancia y eficiencia, y discutimos el impacto de los factores de contexto de las nuevas replicaciones. Los participantes fueron divididos en dos grupos: tratamiento y control. Al primero se le proporcionaron plantillas de requerimientos de seguridad, mientras que el segundo no recibió dicha ayuda. Las respuestas fueron comparadas con las obtenidas en la replicación del 2015 y en total se analizaron las respuestas de 33 participantes.
La prueba de Mann-Whitney fue aplicada y los hallazgos obtenidos confirman algunos de los resultados previos: los grupos de tratamiento tuvieron un mejor desempeño que los grupos de control, en términos de la cobertura de los requerimientos de seguridad identificados. Además, el proceso de extracción de requerimientos tuvo un desempeño significativamente superior en cuanto a la relevancia de una de las dos replicaciones. Las plantillas de requerimientos de seguridad apoyaron a los participantes en la identificación de un conjunto básico de requerimientos de seguridad y los participantes se mostraron anuentes al uso de estas plantillas para la extracción de dichos requerimientos.
The identification of software security requirements is an essential and difficult task. This must be addressed in the early stages of the software development life cycle (SDLC). It is often entrusted to software engineers in charge of developing the software system and IT personnel in general, in case there are no requirements engineers in the organization. Nevertheless, these professionals are not security experts and could fail to define which security objectives are or must be present in a system. Therefore, they could elicit few or inadequate security requirements. In fact, this security requirements elicitation process is usually overlooked and not much attention is given to it until the software system is about to be released. In this context, security could be seen as an add-on. Several security requirement engineering approaches have been proposed to solve this recurrent problem. Nevertheless, these approaches still demand the practitioner to be knowledgeable in security concepts. Various researchers have argued that using security requirements templates could help practitioners to identify implied software security requirements from functional requirements, in the context of a software system. Riaz et al. (2014a) proposed a set of 19 security requirement templates linked to six security objectives: confidentiality, integrity, availability, identification & authentication, accountability and privacy. The method is intended to help in the identification of security objectives in functional requirements. Once these security objectives are identified, applicable templates that support the security goals related to each of the functional requirements can be instantiated. In this investigation, we conducted two differentiated replications and analyzed the effectiveness of security requirements templates to support the identification of security requirements. Our objective was to evaluate this approach and compare the applicability of the previous findings in a different context. A previous replication of the controlled experiment was conducted at University of Costa Rica (UCR) in 2015. In 2018, we conducted the two additional replications at UCR as well. We evaluated the responses of the 17 participants in terms of quality, coverage, relevance and efficiency and discussed the impact of context factors. Participants were divided into two groups: treatment and control. The first one was provided with suggested security requirement templates, while the latter did not receive such help. The responses were compared to the ones obtained in UCR’s 2015 replication. In total, the answers of 33 participants were analyzed. A Mann-Whitney U test was applied and the derived findings support some previous results: treatment groups performed significantly better than the control groups, in terms of the coverage of the identified security requirements. Besides, the requirements elicitation process performed significantly better in relevance in one of the two latter replications. Security requirements templates supported participants in the identification of a core set of the security requirements and the participants were favorable towards the use of these templates for eliciting security requirements.
The identification of software security requirements is an essential and difficult task. This must be addressed in the early stages of the software development life cycle (SDLC). It is often entrusted to software engineers in charge of developing the software system and IT personnel in general, in case there are no requirements engineers in the organization. Nevertheless, these professionals are not security experts and could fail to define which security objectives are or must be present in a system. Therefore, they could elicit few or inadequate security requirements. In fact, this security requirements elicitation process is usually overlooked and not much attention is given to it until the software system is about to be released. In this context, security could be seen as an add-on. Several security requirement engineering approaches have been proposed to solve this recurrent problem. Nevertheless, these approaches still demand the practitioner to be knowledgeable in security concepts. Various researchers have argued that using security requirements templates could help practitioners to identify implied software security requirements from functional requirements, in the context of a software system. Riaz et al. (2014a) proposed a set of 19 security requirement templates linked to six security objectives: confidentiality, integrity, availability, identification & authentication, accountability and privacy. The method is intended to help in the identification of security objectives in functional requirements. Once these security objectives are identified, applicable templates that support the security goals related to each of the functional requirements can be instantiated. In this investigation, we conducted two differentiated replications and analyzed the effectiveness of security requirements templates to support the identification of security requirements. Our objective was to evaluate this approach and compare the applicability of the previous findings in a different context. A previous replication of the controlled experiment was conducted at University of Costa Rica (UCR) in 2015. In 2018, we conducted the two additional replications at UCR as well. We evaluated the responses of the 17 participants in terms of quality, coverage, relevance and efficiency and discussed the impact of context factors. Participants were divided into two groups: treatment and control. The first one was provided with suggested security requirement templates, while the latter did not receive such help. The responses were compared to the ones obtained in UCR’s 2015 replication. In total, the answers of 33 participants were analyzed. A Mann-Whitney U test was applied and the derived findings support some previous results: treatment groups performed significantly better than the control groups, in terms of the coverage of the identified security requirements. Besides, the requirements elicitation process performed significantly better in relevance in one of the two latter replications. Security requirements templates supported participants in the identification of a core set of the security requirements and the participants were favorable towards the use of these templates for eliciting security requirements.
Description
Keywords
security requirements, requirements engineering, software engineering, replication, empirical study