2227-1899 2227-1899 S2227-18992018000500015 Cuba 00 00 2018 00 00 2018 12 205 221

ARTÍCULO ORIGINAL

 

Requisitos de Seguridad para aplicaciones web.

 

Security Requirements for web applications.

 

 

Yisel Niño Benitez 1*, Nemury Silega Martínez1

1Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños, Km. 2 ½. Torrens, La Lisa, La Habana, Cuba. {ynino, nsilega}@uci.cu

]]>  

*Autor para la correspondencia: ynino@uci.cu

 

RESUMEN

El ritmo vertiginoso de los procesos de desarrollo de software actuales incrementa el riesgo de presentar vulnerabilidades en un sistema de software. El aseguramiento de la información y de los sistemas que la procesan es, por tanto, un objetivo crucial para las organizaciones. La gestión de la Seguridad Informática desde el inicio del desarrollo de software evita que los mecanismos de seguridad deban ser ajustados dentro de un diseño ya existente, lo que provocaría cambios que generalmente generan vulnerabilidades en el software, y un incremento de costo y el tiempo para solucionarlos. Sin embargo, un dilema común que encuentran los ingenieros de software durante el desarrollo de un Sistema es la falta de requerimientos de seguridad que permitan darle seguimiento desde etapas tempranas. En el trabajo se exponen varios elementos sobre el marco teórico referente a la Seguridad Informática y la Ingeniería de Requisitos. Además, se describe una propuesta preliminar de Requisitos No Funcionales de Seguridad para el desarrollo de aplicaciones web en la Universidad de las Ciencias Informáticas con el objetivo de reducir las vulnerabilidades.

Palabras clave: ingeniería de requisitos, propuesta, requisito no funcional seguridad, seguridad informática.

ABSTRACT

The vertiginous pace of current software development processes increases the risk of presenting vulnerabilities in a software system. The assurance of information and the systems that process it is, therefore, a first level objective for organizations. The management of Computer Security since the beginning of software development prevents security mechanisms from being adjusted within an existing design, which would cause changes that usually translate into software vulnerabilities, and an increase in budget costs and time to solve them once they have been identified. A common dilemma faced by software engineers in building a system is the lack of security requirements to manage them since early states. In the work several elements are exposed on the theoretical framework of Computer Security and Requirements Engineering, as well as a first proposal of Non-Functional Security Requirements for the development of web applications at the University of Informatics Sciences in order to achieve the decrease in their vulnerabilities.

Key words: informatic security, non-functional safety requirement, proposal, requirements engineering.

 

]]>  

INTRODUCCIÓN

“En pocos años la Web ha evolucionado enormemente: se ha pasado de páginas sencillas, con pocas imágenes y contenidos estáticos a páginas complejas con contenidos dinámicos que provienen de bases de datos, lo que posibilita la creación de aplicaciones web” (Mora, 2002). La Seguridad Informática (SI en lo adelante) es el área que se enfoca en “la protección de la infraestructura computacional y todo lo relacionado con esta, especialmente, la información contenida o circulante” (CDI, 2017). La SI llega a ser un área de vital importancia dentro de la Ingeniería de Software (IS), ya que como sucede con la seguridad aplicada a otros entornos, trata de minimizar los riesgos asociados al acceso y utilización de determinado sistema de forma no autorizada y en general malintencionada.

“La IS, por su parte, abarca un proceso, una colección de métodos (prácticas) y un conjunto de herramientas que permiten a los profesionales construir software de alta calidad” (Roger S. Pressman, 2015). Peter Neur y Brian Randell, por su parte planteaban que “un objetivo importante de la ingeniería de software es permitir a los desarrolladores construir sistemas que operen de manera confiable proporcionando teorías, métodos y herramientas para el desarrollo de software de calidad” (Naur & Randell, 1968). Dentro de la IS, el conjunto de procesos, tareas y técnicas que permiten la definición y gestión de los requisitos de un producto, de un modo sistemático, es conocido como Ingeniería de Requisitos (IR). La IR incluye las actividades relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para hacer un software nuevo o modificado, siendo una colección estructurada de actividades, mediante las cuales se obtienen, validan y mantienen documentados los requisitos del usuario y del sistema (Huebe, 2005).

Los requisitos del sistema se clasifican en funcionales (RF) y no funcionales (RNF). Los funcionales describen lo que un sistema debe hacer, mientras que los no funcionales se refieren directamente a las propiedades emergentes del sistema como fiabilidad, rendimiento, mantenibilidad, seguridad, portabilidad, estándares a utilizar, entre otros (Sommerville, 2005). El RNF Seguridad se define como grado de protección de los datos, software y/o plataforma tecnológica de posibles pérdidas, actividades no permitidas o uso para propósitos no establecidos previamente (Huamaní, 2015). A diferencia de otros RNF como la fiabilidad y el rendimiento, la seguridad no ha sido completamente integrada dentro del ciclo de vida de desarrollo y todavía es considerada después que el sistema ha sido diseñado (Rosado, Blanco, Sánchez, & Medina, 2009).

En encuestas aplicadas a diferentes roles involucrados en el proceso de desarrollo en la Universidad de las Ciencias Informáticas (UCI), estos conocen que se definen RNF de Seguridad y el 100% de los encuestados lo considera imprescindible para el desarrollo de las aplicaciones seguras. Sin embargo, sobre la gestión de este RNF: solamente el 30% considera la trazabilidad y gestión de la seguridad en todo el ciclo de vida del proceso de desarrollo del producto, el 55% lo propone a partir de la disciplina Requisitos, a pesar de que solo un 10% de estos le da seguimiento hasta la disciplina de Análisis y Diseño, el resto no considera necesario el seguimiento en las disciplinas siguientes. El 95% del total conoce los inconvenientes de no hacer un tratamiento certero de la seguridad en el desarrollo e identifican como aspectos negativos en este sentido: penetración en los sistemas, uso indebido de los servidores y su información, uso indebido de credenciales de autenticación, inyecciones SQL, atraso en el cronograma de entrega del producto por la resolución de No Conformidades (NC) de seguridad en las pruebas de liberación y aumento del costo de desarrollo, imposibilidad de despliegue del producto en determinado entorno por no tener en cuentas las restricciones legales de seguridad del cliente y con ello la pérdida del prestigio de la entidad desarrolladora ante el cliente.

La encuesta aplicada ofrece evidencias empíricas que demuestran las insuficiencias en la gestión del RNF de seguridad. Además, se constató el impacto negativo de gestión ineficiente del RNF para el desarrollo de los sistemas en términos de calidad y tiempo. Con el objetivo de aliviar la problemática descrita anteriormente en este artículo se presenta una propuesta de RNF seguridad. Una característica clave de esta propuesta es que plantea el seguimiento del RNF de seguridad desde etapas tempranas lo que contribuirá a disminuir el número de vulnerabilidades en las aplicaciones web.
]]> Análisis conceptual de elementos de la Seguridad Informática

La SI tiene el objetivo de minimizar los riesgos asociados al acceso y utilización de determinado sistema de forma no autorizada y en general malintencionada (Garfinkel, 1999). Estrada, Alba y Martín la definen como las características y condiciones de sistemas de procesamiento de datos y su almacenamiento, para garantizar su confidencialidad, integridad y disponibilidad (Estrada, Alba, & Martín, 2012). Aguilera (Aguilera López, 2010) la define como “la disciplina que se ocupa de diseñar las normas, procedimientos, métodos y técnicas destinados a conseguir un sistema de información (o informático) seguro y confiable”. Para la autora de la investigación, la SI se enfoca en minimizar los riesgos y vulnerabilidades en los recursos de hardware y software relacionados con el acceso y la utilización malintencionada de la información de los sistemas de software, para garantizar la integridad, confidencialidad y disponibilidad de la misma.

Para afrontar el establecimiento de un sistema de seguridad es necesario conocer (Aguilera López, 2010):

La SI se podría resumir, en cinco principios fundamentales (CCM, 2016), los tres primeros también relacionados en la ISO 27002:2013 y en la NC ISO/IEC 25010:2016 (O. N. d. Normalización, 2016) y comunes en (Aguilera López, 2010), (Estrada et al., 2012), (Garfinkel, 1999):

Para normar estos principios atendiendo a los elementos que puedan componer un sistema, las regulaciones de cada entidad y los riesgos que puedan presentarse en su entorno, se han especificado estándares que tienen como objetivo minimizar estos riesgos y las vulnerabilidades que puedan aparecer en un escenario determinado en cuanto a SI.

Estándares de Seguridad Informática

Ante la amenaza de ataques informáticos, las organizaciones deben demostrar que realizan una gestión competente y efectiva de la seguridad de los recursos y datos que gestionan. Este aspecto hace necesario el uso de estándares o normas que le orienten de forma estructurada, sistemática y coherente cómo proceder ante una situación de este tipo y fundamentalmente en su prevención, teniendo en cuenta que “las personas solo pueden hacer lo correcto si saben lo que es correcto” (OWASP, Meucci, & Muller, 2014)

En el estudio realizado por Katy Anton, Jim Bird, Jim Manico (OWASP, 2016) se describen una lista de conceptos de seguridad que deben incluirse en cada proyecto de desarrollo de software. Los controles especificados en este documento se ordenan de acuerdo a su importancia, siendo el número 1 el más importante (OWASP, 2016) y (Brito, 2017). La verificación de la seguridad temprano y frecuentemente (Control 1 del Top 10 de Controles Proactivos) propone que desde el proceso de concepción del software se tengan en cuenta los requisitos de seguridad mientras se describen los requisitos del sistema, siempre teniendo en cuenta el resto de los controles propuestos. De igual manera propone verificar la seguridad con anticipación y a menudo en el proceso de desarrollo, ya sea a través de pruebas manuales o de pruebas y análisis automatizados. La gestión temprana de los requisitos de seguridad ayuda a evitar la ocurrencia de riesgos y vulnerabilidades en el proceso de desarrollo del software.

Estándares de Seguridad Informática en Cuba

Teniendo en cuenta el creciente avance de la informática en todas las esferas del desarrollo científico - técnico, económico, político y social, así como el surgimiento de nuevos riesgos asociados principalmente con el uso de las redes de datos de alcance global, en Cuba se han adoptado medidas de tipo legal que permiten regular la SI.

]]> La Oficina de Seguridad para las Redes Informáticas (OSRI), tendrá como objeto social “llevar a cabo la prevención, evaluación, aviso, investigación y respuesta a las acciones, tanto internas como externas, que afecten el normal funcionamiento de las tecnologías de la información del país” ((OSRI), 2018). También se cuenta en Cuba con el centro de Ciberseguridad del Espacio, que es una “estructura especializada que contribuye al fortalecimiento de la seguridad en el ciberespacio cubano, fomentando la cooperación entre todos los factores que inciden en la ciberseguridad a nivel nacional y potenciando la colaboración internacional en esta esfera. Tiene como misión contribuir al fortalecimiento de la seguridad en el ciberespacio cubano y coordinar de manera efectiva la gestión de los eventos cibernéticos que impactan en la ciberseguridad de la nación” (CSC, 2018).

A partir de las vulnerabilidades y debilidades propias de los sistemas informáticos, de las dificultades y limitaciones que se presentan para detectar y neutralizar oportunamente las posibles acciones enemigas en esta esfera, se implementó un basamento legal que establece los requisitos de seguridad en el empleo de las tecnologías de la información a partir de criterios de racionalidad y utilidad, que resulten susceptibles de verificación y tienden a la disminución de los riesgos en la SI (MINCOM, 2007). Para ello el MINCOM estableció la Resolución 127/2007 que tiene por objetivo “establecer los requisitos que rigen la seguridad de las tecnologías de la información y garantizar un respaldo legal que responda a las condiciones y necesidades del proceso de informatización del país” (MINCOM, 2007). Además, se cuenta con la traducción normalizada por la Oficina Nacional de Normalización de la NC-ISO/IEC 27001: 2007, elaborada por el Comité Técnico de Normalización NC/CTN 18 de Tecnología de la Información.

Sin embargo, al considerar la SI solo en ciertas etapas del proceso de desarrollo, podrían provocarse conflictos entre las necesidades de seguridad y los RF del sistema. Tener en cuenta la seguridad junto con los RF del sistema a través de las etapas de desarrollo, ayudaría a limitar los casos de conflicto, identificándolos pronto en el desarrollo del sistema, y encontrando formas de superarlos (Rosado et al., 2009).

Ingeniería de requisitos

Pressman plantea que un proceso sólido de IR ayuda a garantizar que se ha especificado un sistema que recoge las necesidades del cliente y cumple con sus expectativas. Identifica como parte de este proceso siete tareas fundamentales: inicio (identificación de la necesidad u oportunidad de negocio), elicitación, elaboración, negociación, especificación, validación y administración de requisitos (Roger S. Pressman, 2015). Para Ian Sommerville en (Sommerville, 2005), la IR es el proceso de desarrollar una especificación del software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores. Describe la IR en 4 pasos, estos tratan de la evaluación de si el sistema es útil para el negocio (estudio de viabilidad); el descubrimiento de requisitos (obtención y análisis); la transformación de estos requisitos en formularios estándar (especificación), y la verificación de que los requisitos realmente definen el sistema que quiere el cliente (validación).

El término requisito puede conceptualizarse según lo planteado en la traducción certificada de la ISO 9000: 2000 como “la necesidad o expectativa establecida, generalmente implícita u obligatoria”. Pueden utilizarse calificativos para identificar un tipo específico de requisito, por ejemplo, requisito de un producto, requisito de la gestión de la calidad, requisito del cliente. Los requisitos pueden ser generados por las diferentes partes interesadas (ISO, 2000). La IEEE publicó que un requisito es: “una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal” (IEEE, 1990). El SEI (del inglés Software Engineering Institute) plantea como parte del glosario del modelo CMMI que un requisito es: (1) Una condición o capacidad necesitada por un usuario para solucionar un problema o lograr un objetivo. (2) Una condición o capacidad que debe cumplir o poseer un producto o componente de producto para satisfacer un contrato, un estándar, una especificación u otros documentos impuestos formalmente. (3) Una representación documentada de una condición o capacidad como en (1) o en (2) (SEI, 2010).

]]> Clasificación de requisitos

Sommerville clasifica los requisitos en dos categorías (Sommerville, 2005):

Para la Software Engineering Body of Knowledge (SWEBOK) existen dos grandes categorías en las que pueden clasificarse los requisitos (ISO/IEC, 2005a), estas son:

]]> Los requisitos de seguridad, se identifican mediante una evaluación metódica de los riesgos de seguridad (ISO/IEC, 2005b). Existen tres fuentes principales de requisitos de seguridad, una fuente se deriva de evaluar los riesgos para la organización, tomando en cuenta la estrategia general y los objetivos de esta. A través de la evaluación del riesgo, se identifican las amenazas para los activos, se evalúa la vulnerabilidad y la probabilidad de ocurrencia y se calcula el impacto potencial. Otra fuente son los requisitos legales, reguladores, estatutarios y contractuales que tienen que satisfacer una organización, sus socios comerciales, contratistas y proveedores de servicio; y su ambiente socio-cultural. Y una tercera es el conjunto particular de principios, objetivos y requisitos comerciales para el procesamiento de la información que una organización ha desarrollado para sostener sus operaciones (ISO/IEC, 2005b) y (Mentor, 2017).

Estándares y normas para la Ingeniería de Requisitos

Los estándares de calidad desarrollan normas y modelos en función de organizar y formalizar los procesos en la industria del software incluyendo los relativos a la IR.

]]> Las normas ISO e IEEE son considerados estándares con un alto grado de complejidad lo que dificulta su entendimiento debido en su mayor parte a que se encuentran desagregadas en varios documentos que tienden a confundir a los interesados en su implementación y esto implica un aumento en los esfuerzos y costos para preparar la documentación e implantación de los sistemas. Estas normas no definen elementos fundamentales como una propuesta de proceso, qué roles deben ejecutar las actividades, cuáles técnicas o herramientas pueden utilizarse para apoyar el proceso. Aunque algunas hacen referencia a las mediciones, no realizan una propuesta detallada de indicadores concretos a medir y no se hace alusión a la gestión explícita del conocimiento.

“Los modelos CMMI® (Capability Maturity Model® Integration) son colecciones de buenas prácticas que ayudan a las organizaciones a mejorar sus procesos. Estos modelos son desarrollados por equipos con miembros procedentes de la industria, del gobierno y del Software Engineering Institute (SEI) (…) Las buenas prácticas del modelo se centran en las actividades para desarrollar productos y servicios de calidad con el fin de cumplir las necesidades de clientes y usuarios finales” (SEI, 2010).

CMMI define 22 áreas de procesos, concentradas en cuatro grandes grupos: gestión de procesos, gestión de proyectos, ingeniería y soporte. Las áreas de proceso de ingeniería cubren las actividades de desarrollo y de mantenimiento que se utilizan en todas las disciplinas de ingeniería y se aplican al desarrollo de cualquier producto o servicio dentro del dominio de desarrollo: