Вы находитесь на странице: 1из 10

Ingeniera de Requerimientos para Productos Seguros.

Resultados de un Anlisis
Bibliogrfico
Vianca Vega Zepeda

Departamento de Ingeniera de Sistemas y Computacin


Universidad Catlica del Norte, Avenida Angamos 0610, Antofagasta, Chile
vvega@ucn.cl

Abstract. Se presentan los resultados de un anlisis bibliogrfico para la Ingeniera de Requerimientos para
el desarrollo de productos de software seguro, realizado como parte de la determinacin de lneas de
investigacin a desarrollar como tesis doctoral. Un producto de software seguro es aqul que es proactivo
ante las amenazas y ataques del entorno. El desarrollo de esta investigacin se justifica por la importancia que
en los ltimos aos ha adquirido la seguridad del software, debido a los mltiples ataques que afectan a los
sistemas de software y adems por el reconocimiento que la seguridad es una propiedad emergente de los
productos de software, y como tal, no puede incorporarse cuando el producto ya ha sido desarrollado. Se
presentan un conjunto de propuestas de modelos de proceso que buscan la obtencin de un producto seguro,
con nfasis en propuestas para la Ingeniera de Requerimientos, para conseguir el objetivo de incorporar la
seguridad desde las etapas iniciales del desarrollo de software. Como resultado de la investigacin, se pudo
concluir que las lneas de investigacin posibles de desarrollar abarcan: Creacin de un inventario de
artefactos relacionados con los requerimientos de seguridad; construccin de una gua metodolgica que
integre los requerimientos funcionales con los requerimientos de seguridad; desarrollo de tcnicas de
trazabilidad de requerimientos de seguridad; y la creacin de alguna herramienta de software que permita la
administracin de requerimientos incorporando explcitamente los aspectos de seguridad.
Keywords: Ingeniera de Software, Ingeniera de Requerimientos, Software Seguro

1 Introduccin
De manera tradicional, al desarrollar productos de software el objetivo principal es el cumplimiento de ciertos
requerimientos funcionales del mismo, es decir, que este producto permita a sus usuarios desarrollar sus tareas
de manera correcta.
Sin embargo, debido a la creciente incorporacin de sistemas distribuidos, multiusuarios, que acceden
mediante Internet a los procesos de negocios de las organizaciones, se ha hecho evidente que no basta con que
las funciones del usuario sean correctas, sino adems, se requiere que estos productos de software que
sustentan sistemas de negocios incorporen ciertas caractersticas de calidad que permitan, por ejemplo, que slo
tengan acceso al sistema quienes correspondan; que cada quien pueda realizar las funcionalidades que le estn
permitidas segn su perfil de usuario; y que un usuario no pueda negar su participacin en ciertas transacciones.
Estas ltimas caractersticas se refieren a la Seguridad del Software. Los ingenieros de software se han dado
cuenta que la estrategia tradicional de desarrollar los productos sin incorporar los requerimientos de seguridad en
el proceso y posteriormente delegar el cuidado de la seguridad a elementos externos, no es suficiente.
Es as como en los ltimos aos, surge una nueva lnea de investigacin entre los Ingenieros de Software el
Desarrollo de Software Seguro, es decir, la implementacin de productos que por s mismos sean proactivos ante
las amenazas y riesgos a los que se ve expuesto en sus ambientes de operacin [1].
En este contexto surgen nuevas estrategias, tales como propuestas de procesos de desarrollo que incluyen
prcticas cuya meta es la incorporacin de la seguridad en estos nuevos productos, entendiendo que la seguridad
no slo se refiere a aspectos funcionales como el control de acceso o la criptografa, sino es una propiedad
emergente de los sistemas. Es as como ahora los desarrolladores de software deben incorporar nuevos trminos
a su vocabulario tales como ataques, riesgos, vulnerabilidades y amenazas.
Es esta creciente preocupacin la que justifica plenamente la investigacin desarrollada, permitiendo analizar
las propuestas existentes en relacin a cmo incorporar los requisitos de seguridad desde las primeras etapas del
ciclo de vida de desarrollo de software. El trabajo realizado tuvo como objetivo determinar lneas de
investigacin posibles de desarrollar como tesis doctoral.
El presente artculo se organiza de la siguiente manera: En la seccin uno se presenta la justificacin del
anlisis bibliogrfico desarrollado. Posteriormente, en la seccin dos se entregan los conceptos y bases
requeridos para entender qu es el Desarrollo de Software Seguro. La tercera seccin presenta las propuestas

para la Ingeniera de Requerimientos. El documento finaliza con la presentacin de las conclusiones y trabajos
futuros.

2 Desarrollo de Software Seguro


Antes de entrar en detalles, es necesario precisar qu se entiende por software seguro. Esta definicin no es fcil
de entregar dado que seguridad significa diferentes cosas para diferentes personas, o puede interpretarse de
forma diversa dependiendo del contexto en el que se est analizando.
McGraw [2] plantea que la seguridad de software es una idea de la Ingeniera de Software que busca que un
producto desarrollado contine funcionando correctamente ante ataques maliciosos, es la construccin de
software que puede resistir proactivamente los ataques. Indica adems que un aspecto crtico de los problemas de
seguridad son los problemas de software.
Viega y Mc Graw [3] plantean que la seguridad puede ser vista como una medida de qu tan robusto es un
sistema de software respecto a una poltica de seguridad. A su vez, definen una poltica de seguridad como una
regla de acceso a los recursos del sistema. Agregan adems la visin que la seguridad no es un aspecto que pueda
ser incorporado a un sistema en cualquier instante, esto implica que al disear un producto de software este
diseo debe realizarse pensando en la seguridad, dado que una vez desarrollado el producto no ser posible
incorporarla exitosamente.
Los desarrolladores de software tambin se han dado cuenta que en relacin a la seguridad no es suficiente la
tendencia actual, segn la cual recin una vez que se ha finalizado el desarrollo del software se busca proteger
este producto a travs de infraestructura montada sobre la plataforma en que ste funcionar. Esta estrategia que
es ms bien reactiva, no ha sido suficiente y esto se ve demostrado por la innumerable cantidad de ataques
exitosos a los sistemas informticos.
McGraw [2] indica que la base de los problemas de seguridad son la conectividad, la complejidad y la
extensibilidad de los sistemas actuales.
2.1 Modelos de Ciclo de Vida para aplicaciones seguras
El objetivo de la presente seccin es exponer algunas propuestas de ciclo de vida de desarrollo de software que
han sido pensadas para la obtencin de productos seguros, o para conseguir productos de alta calidad y que por
lo tanto son tiles para el desarrollo de productos seguros.
Apvrille y Pourzandi [4] presentan una metodologa que es una adaptacin del proceso de desarrollo iterativo,
modificado para obtener productos confiables. La figura 1 muestra las etapas del proceso.
Anlisis y
requerimientos de
seguridad

Operacin y
mantencin

Prueba de
seguridad

Ciclo de vida
de desarrollo de
software seguro

Diseo de
seguridad

Implementacin de
la seguridad
Fig. 1. Proceso de desarrollo propuesto por Apvrille y Pourzandi.

Un segundo mtodo para el desarrollo de software seguro es Cleanroom [5], el cual a pesar de no haber sido
creado especficamente para la obtencin de productos seguros es recomendado para este fin por el Department
of Homeland Security de Estados Unidos [6].
El objetivo de esta estrategia es conseguir productos de software que exhiban cero defectos. La aplicacin de
Cleanroom produce mejoras de calidad de entre 10 a 20 veces que con los modelos tradicionales adems de
incrementar tambin la productividad individual [7]. En [5] se definen catorce procesos que forman el modelo.
Otra propuesta es el mtodo Correctness by Construction desarrollado por Praxis Critical Systems, el cual
busca construir software con alta integridad de seguridad. Se basa en los principios de no introducir errores o en

caso de existir errores, removerlos tan pronto como sea posible de donde fueron introducidos [8]. Estos objetivos
se desarrollan mediante el uso de notaciones formales para los productos de trabajo generados y la incorporacin
de mtodos de validacin soportados por herramientas. Cada producto generado es validado en cada etapa del
proceso.
El proceso consiste en un conjunto de etapas que generan distintos productos de trabajo soportados por
algunas actividades genricas que son transversales a todo el proceso. El proceso es flexible, de manera tal que
las tcnicas usadas en cada etapa pueden variar segn el proyecto de desarrollo especfico [8].
Otra propuesta es RUPSec que es una extensin al Proceso de Desarrollo Unificado (RUP), cuyo propsito es
definir un modelo de proceso de desarrollo de software en la cual los requerimientos de seguridad sean
considerados en todas las fases del ciclo de vida [9]. RUPSec incorpora la seguridad mediante la definicin de
nuevos roles, actividades y artefactos que complementan los ya definidos en RUP. Estas modificaciones se
aplican en las disciplinas de Modelamiento de Negocios y Requerimientos. En el modelamiento de negocios se
incorpora como objetivo la identificacin de problemas de seguridad, la captura de potenciales amenazas y la
captura de polticas de seguridad. En los requerimientos se incorpora la captura y modelamiento de las amenazas
de seguridad contra el sistema para proponer soluciones y elicitar los requerimientos de seguridad.
Por otro lado, el mtodo CLASP1 [10] desarrollado por la organizacin Secure Software2, ms que un modelo
de ciclo de vida es una estrategia para incorporar aspectos de seguridad desde etapas tempranas de cualquier
modelo de proceso de desarrollo de software. CLASP es un conjunto de piezas del proceso con una estrategia
descriptiva que indica y documenta las actividades que se deberan desarrollar para conseguir productos seguros.
En [11] se presenta otra propuesta, un framework que apoya un proceso de desarrollo iterativo e incremental
basado en la nocin de patrones de seguridad. La idea subyacente de esta propuesta es que los desarrolladores de
software tomen ventaja del trabajo de los expertos en seguridad e integren a sus modelos soluciones ya probadas.
En esta propuesta los patrones de seguridad representan servicios de seguridad con perfiles especficos y
soluciones para diferentes ambientes. Los patrones se categorizan en distintos niveles de abstraccin que
corresponden a diferentes fases del proceso de ingeniera de seguridad, para diferentes tipos de medidas de
seguridad y para diferentes niveles de formalismos. Se da especial relevancia a la integracin de la
especificacin de requerimientos de seguridad y los patrones de seguridad durante el desarrollo del proceso en
busca de alcanzar un proceso automtico de especificacin.
McGraw [2] plantea un conjunto de prcticas que incorporan la seguridad como parte del software durante
todo el ciclo de vida. Son prcticas agnsticas, es decir, pueden aplicarse en cualquier modelo de proceso. El
objetivo de estas prcticas es que los desarrolladores piensen en la seguridad y su incorporacin al producto
desde las primeras etapas del desarrollo de software.
La figura 2 tomada de [2] muestra una visin panormica de las prcticas y en qu etapa del ciclo de vida se
aplican.
Evaluacin Externa

Pruebas de
Penetracin

Requerimientos de
Seguridad

Casos de
Abuso

Requerimientos y
Casos de Uso

Pruebas de
seguridad
basadas en
riesgos

Anlisis de
Riesgos

Diseo
s

Plan de
Prueba

Anlisis Esttico
Anlisis
de Riesgos

Cdigo

Resultado pruebas

Fin de la
Seguridad

Realimentacin

Fig. 2. Prcticas para el desarrollo de software seguro.

3 Ingeniera de Requerimientos
En la presente seccin se presentan los conceptos correspondientes a la Ingeniera de Requerimientos para el
desarrollo de productos de software seguros.
1
2

Comprehensive Lightweight Application Security Process


www.securesoftware.com

Un requerimiento puede definirse como la especificacin de lo que debera ser implementado. Es una
descripcin de cmo debera comportarse el sistema o descripciones de propiedades o atributos del mismo [12].
En trminos ms concretos, como define Kotonya [13] un requerimiento es una sentencia de un servicio o
restriccin de un sistema. La seguridad es un atributo de calidad de los sistemas que corresponde a la
clasificacin de los requisitos no funcionales. Se puede definir entonces Ingeniera de Requerimientos como el
rea de la Ingeniera de Software que cubre con tcnicas sistemticas y repetibles las actividades de descubrir,
documentar y mantener un conjunto de requerimientos para un sistema basado en computadoras [12].
En los ltimos aos la Ingeniera de Requerimientos ha alcanzado relevancia en el proceso de desarrollo de
software, luego que los desarrolladores han tomado conciencia de lo importante que es definir de manera
correcta y formalmente los requerimientos. Los errores cometidos durante el desarrollo de software resultan ms
costosos mientras ms tarde sean detectados, de all la importancia de la aplicacin de tcnicas sistemticas y
repetibles desde las etapas tempranas de los procesos de desarrollo.
La seguridad por ser una propiedad emergente de los sistemas, es decir, una propiedad que requiere que varios
componentes funcionen para que sea satisfecha, debe ser incorporada desde las etapas tempranas del desarrollo
de software. De aqu la importancia de la presente investigacin, cuyo objetivo es presentar modelos, mtodos y
herramientas que permitan este anlisis e incorporacin de los requerimientos de seguridad desde el inicio de los
proyectos de desarrollo y su posterior trazabilidad e implementacin en cada etapa del ciclo de vida del software.
A continuacin se presentan una serie de propuestas relacionadas con la Ingeniera de Requerimientos para
productos seguros.
3.1 Taxonoma de Requerimientos de Seguridad
Firesmith presenta una taxonoma de requerimientos de seguridad que se basa en las similitudes existentes entre
la seguridad (security) y los sistemas crticos (safety) [14].
Se plantea que ambos aspectos son subtipos de un factor de calidad de los sistemas conocido como
Capacidad de defensa (Defensibility), dado que ambos estn relacionados con la proteccin de bienes
valuables de daos, entendiendo por dao cualquier consecuencia negativa significativa sobre esos bienes. La
principal diferencia entre la seguridad y criticidad est dada porque los sistemas crticos se relacionan con el
dao accidental, mientras que la seguridad se relaciona con dao malicioso. Este dao se produce cuando ocurre
un incidente, el cual se define como eventos o una serie de eventos no planeados, no intencionales y no
autorizados que afectan los bienes.
La taxonoma planteada identifica cuatro clasificaciones para los requerimientos de seguridad:
De seguridad puros. Dado que la seguridad es un atributo de calidad, los requerimientos de seguridad deberan
consistir de un criterio de seguridad con un umbral mnimo requerido como medida apropiada. Se identifican dos
subtipos de requerimientos: el tipo Problema de defensa y el tipo Solucin de defensa.
Significativos de seguridad. Estas son funcionalidades del sistema que tienen ramificaciones de seguridad.
De seguridad del sistema. stos existen con el objetivo de asegurar que el sistema posee una adecuada
seguridad. Ejemplos de este tipo son el control de acceso y los antivirus.
Restricciones de seguridad. stas son polticas de seguridad obligatorias o medidas de contencin para asegurar
que se implementen los requerimientos de seguridad. Ejemplos de este tipo son: Identificacin y autenticacin;
integridad y no repudio.
Esta taxonoma puede ser utilizada para elicitar, organizar y administrar los requerimientos, lo cual traera los
siguientes beneficios: Entrenamiento de ingenieros novatos; mejora la comunicacin entre los ingenieros de
seguridad y los ingenieros de requerimientos; ayuda a la completitud de los requerimientos, dado que puede ser
utilizada como lista de chequeo para verificar que se hayan considerado todos los requerimientos de seguridad
necesarios; permite dar el nfasis adecuado a los requerimientos de seguridad; la taxonoma puede servir como
estructura para la especificacin de requerimientos de seguridad; y provee un medio de Trazabilidad de
requerimientos.
3.2 Casos de Abuso y Casos de Mal Uso
Los casos de abuso ayudan a los desarrolladores de software a ver su producto desde la perspectiva de los
atacantes. El objetivo de un caso de mal uso es decidir y documentar de antemano cmo podra reaccionar el
software a su uso ilegtimo [15]. McDermott y Fox [16] lo definen como: Una especificacin de un tipo de
interaccin completa entre un sistema y uno o ms actores, donde los resultados de la interaccin es daino para
el sistema, uno de los actores, o uno de los stakeholders del sistema. La idea es que cada vez que se crea o

especifica un nuevo requerimiento, alguien se dedique a pensar cmo esta nueva funcionalidad puede ser
intencionalmente mal utilizada o abusada.
Hope, McGraw y Antn [15] plantean que los diseadores y analistas de un sistema estn en posicin
privilegiada para conocer el sistema mejor que los potenciales atacantes. Recomiendan utilizar esta ventaja para
apoyar la seguridad y confiabilidad del sistema, partiendo por responder las siguientes preguntas: Qu
suposiciones estn implcitas en el sistema?; Qu clase de cosas hacen falsas esas suposiciones?; Qu clase de
patrones de ataques podra aplicar un atacante?
Tradicionalmente los aspectos de seguridad de un sistema han sido tratados a travs de modelos matemticos,
los cuales no son fciles de entender ni interpretar por desarrolladores inexpertos en temas de seguridad y an
ms difciles para los usuarios [16]. Por este motivo se han diseado los casos de abuso que son mucho ms
fciles de entender y que al igual que los conocidos casos de uso de UML, sirven como una eficaz herramienta
de comunicacin entre desarrolladores y usuarios.
Dado que los casos de abuso se derivaron a partir de los casos de uso, los diagramas de casos de abuso
utilizan los mismos smbolos que un diagrama de casos de uso UML. Adems, a los tradicionales tipos de
relaciones <<include>> y <<extend>> existentes entre casos de uso, se incluyen relaciones de <<prevents>> y
<<detects>> que relacionan los casos de uso con los casos de abuso [17]. Los mismos autores de los casos de
mal uso recomiendan la creacin de un solo diagrama que rena los casos de uso con los de mal uso, mostrando
de esta manera la relacin existente entre requerimientos funcionales y los requerimientos de seguridad [17].
Al igual que los casos de uso, los casos de abuso pueden ser descritos en distintos niveles de abstraccin,
permitiendo de esta forma la existencia de casos de abuso esenciales y casos de abuso reales. Adems de la
creacin de los diagramas de caso de abuso se realiza una descripcin de los actores participantes, donde se debe
resaltar para cada actor sus recursos, habilidades y objetivos.
Se recomienda tambin la creacin de un rbol que describa los casos de abuso, donde la raz del rbol
representa al sistema y las hojas son los recursos o componentes del sistema que son el objetivo de los casos de
abuso. Los nodos interiores representan subsistemas, aplicaciones y clases. Cada camino entre la raz y las hojas
muestra los componentes que deberan verse afectados para lograr el abuso descrito en el nodo hoja [15].
McDermott y Fox [16] presentan una serie de pasos para la creacin de los casos de abuso y su diagrama,
partiendo siempre desde la base dada por los casos de uso definidos para el sistema. Los pasos considerados son
los siguientes:
Identificacin de actores. Para cada actor de los casos de uso, se debe determinar si puede afectar
negativamente el sistema de alguna manera, si es as, se agrega como actor al diagrama de casos de abuso.
Tambin se debe considerar como actor cualquier tipificacin de posibles atacantes. Los autores resaltan la
importancia de discutir con los clientes los actores de los casos de abuso.
Identificar los casos de abuso. Para cada actor identificado en el paso anterior, determinar sus posibles
interacciones con el sistema.
Definir los casos de abuso. Descripcin detallada de cada caso de abuso.
Revisar la granularidad. En esta etapa se busca determinar si hay muy pocos o demasiados casos de abuso.
Revisar completitud y minimalidad. Se revisa la descripcin de cada caso de abuso para asegurar que estn
completos y que incorporen todos los detalles y consideraciones necesarias. Para asegurar que no se ha dejado de
lado ningn caso de abuso, se debe consultar y discutir con los clientes y usuarios.
Los autores destacan que los casos de abuso son tiles en distintas etapas del ciclo de desarrollo. Durante la
fase de requerimientos ayudan a que los usuarios y clientes tomen conciencia de los aspectos de seguridad
deseados en el producto en desarrollo. Adems, en esta misma etapa ayudan a la elicitacin de requerimientos.
Durante el diseo del software ayudan a determinar qu funcionalidades y qu aspectos concretos de seguridad
sern incorporados al sistema. Dependiendo de qu tan peligrosa sea una amenaza en funcin de las habilidades,
recursos y objetivos de actores identificados, se decide si se invertir, y en qu medida, en incorporar la defensa
a ese posible ataque. Durante la fase de prueba del sistema los casos de abuso pueden ser utilizados para guiar las
pruebas de seguridad a realizar sobre el sistema.
Los casos de mal uso, adems de ayudar en la elicitacin de requerimientos de seguridad, entregan otras
ventajas [17]: Se enfocan en la seguridad desde etapas tempranas del ciclo de desarrollo de producto de software;
asegura a los usuarios y clientes al hacerlos analizar sus riesgos y amenazas; ayuda a la creatividad de los
analistas en la identificacin de amenazas antes que se concreten; facilitan la trazabilidad mediante el registro
explcito de las motivaciones tras la incorporacin de cada caso de mal uso; organiza los requerimientos, lo que
mejora su administracin. Tambin facilita el relacionamiento entre requerimientos funcionales y de seguridad;
ayudan en la transicin de los requerimientos al diseo orientado al objeto; y estandariza el manejo de
requerimientos funcionales y de seguridad.
Sindre y Opdahl [18] presentan una plantilla para la especificacin de casos de mal uso.

3.3 Casos de Uso de Seguridad


Firesmith [19] presenta los casos de uso de seguridad, los cuales son una propuesta distinta de los casos de mal
uso descritos en la seccin previa.
La creacin y utilizacin de los casos de uso de seguridad se justifica por el hecho que los casos de uso
tradicionales, en relacin a la seguridad, slo son tiles para especificar mecanismos arquitecturales de seguridad
pero no permiten un anlisis de los bienes y servicios que deben ser protegidos, ni de las amenazas relacionadas
con dichos bienes y servicios.
La principal diferencia entre los casos de uso de seguridad y los casos de mal uso radica en que estos ltimos
especifican la interaccin de un usuario malicioso, mientras que los primeros especifican el punto de vista del
sistema en relacin a la seguridad. Firesmith plantea que los casos de mal uso analizan las amenazas de
seguridad pero que son inapropiados para la especificacin de requerimientos de seguridad propiamente, es
decir, especifica los requerimientos para proteger los bienes que estn bajo amenaza.
En [19] se presenta una plantilla para la especificacin de los requerimientos de seguridad utilizando los casos
de uso de seguridad. La tabla 1 [19] presenta una comparacin entre los casos de uso de seguridad y los casos de
mal uso.
Tabla 1. Comparacin entre casos de uso de seguridad y casos de mal uso.
Criterio de comparacin
Uso
Criterio de xito
Producido por
Usado por
Actores externos
Conducido por

Casos de mal uso


Analiza y especifica las amenazas de
seguridad
El usuario malicioso es exitoso
Equipo de seguridad
Equipo de seguridad
Usuarios maliciosos, usuarios
Anlisis de vulnerabilidades de los
bienes y anlisis de amenazas

Casos de uso de seguridad


Analiza y especifican los
requerimientos de seguridad
La aplicacin es exitosa
Equipo de seguridad
Equipo de requerimiento
Usuarios
Casos de mal uso

Como puede verse en el ltimo criterio de comparacin de la tabla, los casos de uso de seguridad no
reemplazan a los casos de mal uso, sino que los complementan.
Existen algunas recomendaciones que deben tenerse presente a la hora de crear los casos de uso de seguridad
[19]: Los casos de uso de seguridad deben ser esenciales, es decir, evitar la especificacin innecesaria de
mecanismos arquitecturales asociados a la seguridad; diferenciar cuidadosamente los requerimientos; evitar
especificar restricciones de diseo; documentar explcitamente los caminos individuales del caso de uso de
seguridad; basar los casos de uso de seguridad en los diferentes tipos de requerimientos de seguridad;
documentar las amenazas de seguridad que justifican cada camino de un caso de uso de seguridad; distinguir
claramente entre las acciones del usuario y del usuario malicioso; distinguir claramente entre las interacciones
visibles del sistema de aquellas ocultas; y documentar las pre y post condiciones.
3.4 Derivacin de Requerimientos utilizando descripciones de amenazas
Esta propuesta presentada por Haley, Laney y Nuseibeh [20] trata de solucionar el problema surgido porque la
mayora de las veces los requerimientos de seguridad son presentados en trminos de cmo implementar la
seguridad, por ejemplo, uso de criptografa, en lugar de especificar el problema de seguridad a ser resuelto. Se
definen los requerimientos de seguridad como: restricciones sobre los requerimientos funcionales que intentan
reducir el alcance de las vulnerabilidades. [20].
La estrategia propuesta utiliza conceptos transversales del desarrollo de software orientado al aspecto y
estructuras de problemas (Soluciones para varias clases de problemas). Aqu los requerimientos de seguridad se
expresan como restricciones sobre los requerimientos funcionales, logrando de esta forma que sean incorporados
de manera ms natural en el proceso de especificacin. En este contexto la tarea del Ingeniero de Requerimientos
es describir problemas a travs de la descripcin de dominios que existen en el mundo. La especificacin de
requerimientos se convierte as es una coleccin de especificaciones de dominios que juntas permiten el
cumplimiento de los requerimientos.
La estrategia propuesta se forma de un proceso iterativo de cuatro pasos:
Identificacin de los objetos en el contexto del problema que podran participar en una amenaza. Esos son los
bienes candidatos.
Identificacin de amenazas sobre los bienes identificados en el paso anterior. En este punto se crean las
descripciones de las amenazas.

Cruzar las descripciones de amenazas con los requerimientos funcionales en bsqueda de bienes en el
dominio involucrado. En este punto se determina si existen vulnerabilidades que permitan desarrollar las
amenazas asociadas con los bienes. Tambin se deben enumerar las restricciones sobre los requerimientos
funcionales para debilitar las vulnerabilidades a un nivel aceptable.
Identificacin de conflictos.
Los autores resaltan que estos pasos no son un proceso mecnico, cada etapa puede ser combinada o existir
subiteraciones en uno o un conjunto de etapas. Tambin se destaca que la habilidad y experiencia del analista
que aplica el mtodo es muy importante.
3.5 SQUARE
El modelo SQUARE3 [21] fue desarrollado por el Software Engineering Institute de la Universidad de Carnegie
Mellon. Segn la definicin de sus autores, este proceso provee un medio para elicitar, categorizar y priorizar
requerimientos de seguridad. La metodologa busca construir los conceptos de seguridad desde las etapas
tempranas del ciclo de vida de desarrollo. El proceso se forma de nueve pasos, los cuales se muestran en la tabla
2 adaptada de [21] junto a sus entradas y salidas.
Si bien es cierto este mtodo no presenta una tcnica especfica para cada paso que se debe realizar, si hace
algunas sugerencias: Para el desarrollo de artefactos, se mencionan como ejemplos, escenarios, casos de mal uso,
plantillas y formularios; para la evaluacin de riesgo, se sugiere el uso de OCTAVE [22]; para la priorizacin de
los requerimientos sugiere mtodos tales como Triage y Win-Win; para la inspeccin de los requerimientos
sugiere mtodos como Fagan y revisin de pares.
Tabla 2. Etapas del modelo SQUARE.
ETAPA
Crear
un
vocabulario
comn.
Identificar objetivos de
seguridad
Seleccionar tcnicas de
elicitacin
Desarrollar los artefactos
Elicitar requerimientos de
seguridad
Categorizar
los
requerimientos
Valorizar el riesgo
Priorizar los requerimientos
Inspeccin
requerimientos

de

ENTRADAS
Definiciones tomadas desde estndares
Definiciones, posibles objetivos, aspectos del
negocio y ejemplos
Metas,
definiciones,
posibles
tcnicas,
experticia de los stakeholders, estilo y cultura
organizacional, nivel de las necesidades de
seguridad y anlisis costo beneficio.
Tcnicas seleccionadas y potenciales artefactos.
Artefactos y Tcnicas seleccionadas.
Requerimientos iniciales y Arquitectura.
Requerimientos categorizados
operacional destino.

ambiente

Requerimientos categorizados y resultados de


la valorizacin de riesgo.
Requerimientos priorizados y Tcnicas de
inspeccin formal candidatas.

Definiciones

SALIDAS

Metas
Tcnicas de elicitacin seleccionadas.

Artefactos necesarios.
Versin inicial de los requerimientos de
seguridad.
Requerimientos categorizados.
Riesgos valorizados, ms requerimientos
de mitigacin para alcanzar un nivel de
exposicin aceptable.
Requerimientos priorizados.
Requerimientos seleccionados.
Documentacin del proceso de decisiones
y su justificacin.

3.6 SIREN4
Toval, Nicols y Moros [23] presentan un mtodo para el reuso de requisitos, justificando su desarrollo por la
afirmacin compartida por mltiples investigadores que los beneficios de la reutilizacin aumentan si sta es
aplicada en niveles de abstraccin mayores a la codificacin.
La propuesta provee un repositorio de requerimientos estructurados en dominios. Entre estos dominios se
encuentra la seguridad, motivo por el cual se incluye SIREN en el presente estudio. Sin embargo, se debe
mencionar que la reutilizacin de estos requerimientos de seguridad se ve restringida por el hecho que los

3
4

System Quality Requirements Engineering


Simple Reuse of Software Requirements

requerimientos han sido especificados en concordancia a la legislacin espaola sobre la Ley Orgnica de
Proteccin de Datos de Carcter Personal y el Reglamento de Medidas de Seguridad de dicho pas.
La base de la reutilizacin de requerimientos radica en identificar descripciones de sistemas que sean
comunes para cierto tipo de aplicaciones, en su totalidad o parcialmente.
En SIREN los requerimientos son descritos textualmente pero pueden ser enlazados a otro tipo de objetos,
como diagramas, esquemas o tablas.
El mtodo incorpora: Guas a travs de la utilizacin de una jerarqua de documentos de especificacin de
requerimientos; un repositorio de requerimientos reutilizables organizados por dominios de aplicacin; un
modelo de proceso basado en el ciclo espiral para Ingeniera de Requerimientos presentada por Kontoya [13]; y
una herramienta que da soporte al repositorio.
3.7 Reutilizacin de requerimientos de seguridad a travs del uso de plantillas
Firesmith [24] plantea que en el ms alto nivel de abstraccin, las aplicaciones tienden a tener las mismas clases
de bienes vulnerables que estn sujetos a las mismas clases bsicas de amenazas de seguridad a travs de ataques
desarrollados por la misma clase de atacantes. Plantea que una forma de reuso es encontrar los subfactores
asociados a la seguridad, y utilizar stos como base para la organizacin e identificacin de los requerimientos
de seguridad.
Se sugiere para la reutilizacin de requerimientos de seguridad el uso de plantillas que especifiquen
requerimientos para dominios de aplicacin. En [24] se muestra la plantilla sugerida por Firesmith.
Firesmith presenta adems un proceso para la reutilizacin de requerimientos basado en las plantillas
mencionadas [24]. A pesar que el proceso presentado consta de 13 pasos bien definidos, se plantea que ms
importante que desarrollar todas las etapas sugeridas, es tener conciencia que cualquier proceso utilizado debera
basarse en los bienes vulnerables que deben ser protegidos. A continuacin se presentan los pasos sugeridos:
Identificar bienes valuables. En base a: requerimientos funcionales, de datos e interfaces; entrevistas con los
stakeholders; y el listado de bienes identificados durante la planificacin de recuperacin de desastres.
Identificar amenazas. En base a: tablas reusables de amenazas comunes; y casos de mal uso esenciales.
Identificar atacantes comunes. Se recomienda el uso de perfiles de atacantes.
Estimar la vulnerabilidad de los bienes ante las amenazas identificadas.
Determinar los resultados negativos que resultaran si las amenazas contra los bienes se concretan.
Priorizar las vulnerabilidades en trminos de importancia para optimizar los recursos.
Identificar situaciones relevantes. Para cada requerimiento funcional se debe analizar si est relacionado con
algn requerimiento de seguridad.
Considerar subfactores de calidad para determinar si son pertinentes o no para el desarrollo actual.
Identificar las plantillas relevantes. Es aqu donde se eligen las plantillas que se reutilizarn.
Determinar los criterios de seguridad.
Determinar los indicadores para cada criterio.
Determinar el nivel mnimo aceptable requerido para los indicadores identificados en el paso anterior.
Especificar los requerimientos.
3.8 NFR Framework
Si bien esta propuesta presentada por Chung y Nixon [25] no es exactamente una tcnica para elicitacin y
anlisis de requerimientos, se incluye en este estudio dado que se caracteriza porque durante el desarrollo del
software permite tratar los potenciales conflictos entre requerimientos no funcionales, por lo cual, considera la
negociacin entre atributos de seguridad y otras caractersticas de calidad. En este enfoque los requerimientos no
funcionales (NFR) son parte integral del proceso de desarrollo, y se usan para conducir el proceso y actan como
criterios de seleccin.
De la manera tradicional como se manejan los requerimientos no funcionales, los desarrolladores esperan
satisfacerlos slo en ciertos lmites aceptables en lugar de satisfacerlos absolutamente como lo hace este mtodo.
La metodologa propuesta consta de dos grandes fases, las que a su vez se dividen en dos actividades
especficas:
Adquisicin de conocimiento. Incluye las tareas de Conocimiento especfico de los NFR y Conocimiento del
dominio
Aplicacin del Framework. Incluye las tareas de Identificacin de los NFR y Enlazar los NFR.

3.9 Modelo Volere


Adems de las tcnicas presentadas previamente, el modelo para la Ingeniera de Requerimientos Volere [26]
recomienda una serie de tcnicas para la elicitacin de requerimientos. De este conjunto de tcnicas
recomendadas se pueden destacar por su utilidad para los requerimientos de seguridad las siguientes:
Entrevistas. Mediante las cuales se puede conseguir que los usuarios tomen conciencia de sus propias
necesidades de seguridad en relacin al sistema en desarrollo.
Tormenta de ideas. Las cuales ayudan a complementar las visiones individuales en relacin a la seguridad.
Revisin de casos de uso. En este caso se recomienda el desarrollo y revisin de los casos de abuso y/o casos de
uso de seguridad en conjunto con los usuarios.
Modelo de eventos. Esta tcnica podra ayudar a modelar no slo los eventos normales que afectan al sistema,
sino tambin deberan ser modelados los eventos dainos que podran convertirse en ataques al mismo.

4 Conclusiones
La investigacin realizada ha abarcado mltiples aspectos que han permito entender y determinar el contexto de
la Ingeniera de Requerimientos para el desarrollo de productos de software seguro.
Sin duda, existe una tendencia que va en aumento a cambiar las estrategias actuales de seguridad, donde sta
se delega a elementos externos al software que tratan de defender al producto de las amenazas y ataques que
sufren. Esta nueva tendencia busca incorporar la seguridad desde las etapas iniciales del desarrollo de software,
motivo por el cual las metodologas para la Ingeniera de Requerimientos que trabajen incorporando los
requerimientos de seguridad, adquieren una relevancia primordial en estas nuevas estrategias.
Como resultado del estudio de modelos de procesos para la Ingeniera de Requerimientos se concluye que no
existen muchas propuestas concretas especficas para los requerimientos de seguridad.
Sin duda, la estrategia de reutilizar requerimientos de seguridad es lo ms adecuado, sobre todo teniendo en
cuenta que los conocimientos sobre la seguridad del software no es masivo para los ingenieros de software. Por
lo anterior, se debe encontrar alguna estrategia que permita hacer reuso de requerimientos de seguridad que sean
universales y adaptables a realidades particulares de dominios de aplicacin, en distintos pases con distintas
legislaciones, culturas y realidades.
Mayor desarrollo han alcanzado las tcnicas para la elicitacin de requerimientos de seguridad, la mayora de
las cuales van acompaadas de alguna plantilla que ayuda adems en la especificacin de dichos requerimientos.
Especial utilidad presentan aquellas estrategias o tcnicas basadas en el lenguaje UML, debido al amplio
conocimiento y utilizacin que tiene dicho lenguaje en la actualidad, ayudando de esta forma en la incorporacin
paulatina de estas nuevas propuestas.
Un aspecto importante se presenta en las tcnicas de trazabilidad de requerimientos. Luego del estudio se
concluye que no se han desarrollado tcnicas especficas para trazabilidad de requerimientos de seguridad. Si
bien es cierto las tcnicas tradicionales como las matrices o listas de trazabilidad podran ser adaptadas para este
fin, no se encontraron propuestas que permitan trazar los requerimientos de seguridad durante todo el proceso de
desarrollo, es decir, mtodos que permitan ver qu elementos del diseo y/o implementacin son resultado o
estn relacionados con los aspectos de seguridad.
Teniendo en cuenta todo lo anteriormente planteado, es posible identificar lneas de investigacin que no han
sido desarrolladas an:
Creacin de un inventario de artefactos relacionados con los requerimientos de seguridad que estn
estructurados de forma que puedan permitir su reuso universal mediante la adecuacin a realidades particulares.
Construccin de una gua metodolgica que acompae a una propuesta de algn modelo de proceso para la
Ingeniera de Requerimientos que permita trabajar en forma integrada los requerimientos funcionales con los
requerimientos de calidad, en especial de seguridad. Lo anterior se plantea debido a que actualmente las
propuestas de seguridad se presentan como un asunto aislado de la administracin de requerimientos funcionales,
dando muy pocas guas de cmo integrar ambos aspectos.
Desarrollo de tcnicas de trazabilidad de requerimientos de seguridad que administren las relaciones entre
stos con los requerimientos funcionales, artefactos del diseo y objetos de la implementacin, permitiendo de
esta forma poseer una visin y aseguramiento global en todo el ciclo de vida de desarrollo del cumplimiento de
los requerimientos de seguridad.
Asociado a los puntos anteriores aparece la necesidad de la creacin de alguna herramienta de software
que permita la administracin de requerimientos que incorpore explcitamente y d realce a los aspectos de
seguridad. Esta herramienta debera prestar servicios integrales para el anlisis, especificacin y modelamiento
de la seguridad, permitiendo realizar, por ejemplo, no slo la creacin de casos de mal uso o casos de uso de

seguridad, sino tambin permitir y facilitar el anlisis de riesgo tan recomendado en las nuevas propuestas de
seguridad.

Referencias
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.

McGraw, G., Software Security. Building Security In. Software Security Series. 2006: Addison Wesley.
McGraw, G., Software Security. IEEE Security & Privacity, 2004: p. 80-83.
Viega, J. and G. McGraw, Building Secure Software: How to avoid security problems the right way.
Computing Series. 2001: Addison Wesley
Apvrille, A. and M. Pourzandi, Secure Software Development by Example. IEEE Security & Privacity,
2005. 3(4): p. 10-17.
Linger, R. and C. Trammell, Cleanroom Software Engineering Reference Model Version 1.0. 1996,
Software Engineering Institute.
Davis, N., et al., Processes for producing secure software. Security & Privacy Magazine IEEE, 2004.
2(3): p. 18 - 25
Read, K. and P. Werbicki, Cleanroom Software Engineering, Software Engineering Institute.
Hall, A. and R. Chapman, Software Engineering Correctness by Construction. 2004, Praxis Critical
Systems.
Jaferian, P., et al. RUPSec: Extending Business Modeling and Requirements Disciplines of RUP for
Developing Secure Systems in 31st EUROMICRO Conference on Software Engineering and Advanced
Applications. 2005.
Viega, J. Security in the software development lifecycle. An introduction to CLASP, the Comprehensive
Lightweight Application Security Process. [cited 2006 May 8 2006].
Ray, D. Integration of Security Patterns in Software Models based on Semantic Descriptions. [cited
2006 Mayo 2006].
Sommerville, I. and P. Sawyer, Requirements Engineering. A good practice guide. 1997: Wiley.
Kotonya, G. and I. Sommerville, Requirements Engineering. Worldwide Series in Computer Sciencie,
ed. D. Barron and P. Wegner. 1998.
Firesmith, D. A Taxonomy of Security-Related Requirements. in Fifth International Workshop on
Requirements for High Assurance Systems (RHAS`05 - Chicago) 2005. Chicago - USA: Software
Engineering Institute
Hope, P., McGraw, G., Antn, A. , Misuse and Abuse Case: Getting Past the Positive. IEEE Security &
Privacity, 2004.
Mcdermott, J., Fox, C. , Using Abuse Case Models for Security Requirements Analysis. Department of
Computer Science, James Madison University, Harrisonburg.
Sindre, G. and A. Opdahl. Capturing Security Requirements through Misuse Cases. [cited 2006 Mayo
2006].
Sindre, G. and A. Opdahl. Templates for Misuse Case Description. in Seventh International Workshop
on Requirements Engineering: Foundation for Software Quality 2001. Interlaken, Switzerland.
Firesmith, D. (2003) Security Use Case. Journal of Object Technology Volume, 53-64
Haley, C., R. Laney, and B. Nuseibeh, Deriving Security Requirements from Crosscutting Threat
Descriptions. 2003, Department of Computing. Faculty of Mathematics and Computing, The Open
University.
Mead, N. and T. Stehney. Security quality requirements engineering (SQUARE) methodology. in
International Conference on Software Engineering. 2005: Software Engineering for Secure Systems.
Alberts, C. and A. Dorofee, Managing Information Security Risks. The OCTAVE Approach. SEI Series.
2005.
Toval, A., J. Nicols, and B. Moros, SIREN: Un proceso de Ingeniera de Requisitos basado en
reutilizacin, in Jornadas de Ingeniera de Requisitos Aplicada. 2001: Sevilla.
Firesmith, D., Analyzing and specifying reusable security requirements. SEI- Carnegie Mellon
University.
Chung, L., Nixon, B. , Dealing with non-functional requirements: three experimental studies of a
process-oriented approach. The University of Texas at Dallas - University of Toronto.
Robertson, S. and J. Robertson, Mastering the Requirements Process. 1999.