Documentos de Académico
Documentos de Profesional
Documentos de Cultura
1, Enero-Junio 2012
RESUMEN
El desarrollo de software seguro es un asunto de alta importancia en las compaas, debido a que la mayora de ellas dependen
altamente de sus aplicaciones para su operacin normal. Es por esto que se hace necesario implementar efectivamente
metodologas de desarrollo seguro que sean aplicadas en cada fase del ciclo de vida: requisitos, diseo, desarrollo y pruebas. Es
importante tener presente la seguridad desde las etapas ms tempranas del proceso de desarrollo y no dejarla en un segundo
plano. Adems, se requiere investigar el estado del arte en desarrollo de aplicaciones seguras y as escoger metodologas de
acuerdo con las necesidades de cada aplicacin y los requisitos de los interesados en el producto final. El objetivo de este artculo
es recopilar una serie de metodologas y herramientas existentes que se puedan implementar, aadiendo seguridad en toda la
aplicacin y desarrollando no slo software de alta calidad sino tambin de alta seguridad.
Palabras clave
Ciclo de Vida de Desarrollo de Sistemas, Desarrollo Seguro, Pruebas Seguras, Arquitectura Segura.
Keywords
Systems development life cycle, secure development, secure tests, secure architecture.
Mots-cls
Cycle de vie de dveloppement de systmes, dveloppement scuris, essais scuriss, architecture scurise .
C. Marulanda L. & J. Ceballos H. Una revisin de metodologas seguras en cada fase del ciclo de vida del desarrollo de software.
Ing. USBMed, Vol. 3, No. 1, pp. 15-22. ISSN: 2027-5846. Enero-Junio, 2012. 15
Ing. USBMed, Vol. 3, No. 1, Enero-Junio 2012
16
Ing. USBMed, Vol. 3, No. 1, Enero-Junio 2012
no conocen los ataques al cdigo ni las herramientas Conformidad. Actividades planeadas, sistemticas y
que explotan esas vulnerabilidades y, simplemente, al multidisciplinarias que aseguren que los
no saber cmo se puede explotar el cdigo, no saben componentes y productos de software estn
cmo escribir de forma segura [2]. conforme a los requisitos, procedimientos y
estndares aplicables para su uso especfico.
17
Ing. USBMed, Vol. 3, No. 1, Enero-Junio 2012
debilidades de seguridad, los controles de seguridad, 2. Suposiciones incorrectas del ingeniero, incluyendo
los impactos tcnicos y el impacto al negocio cuando las relacionadas con la capacidad, las salidas, el
se materialice la amenaza [11]. comportamiento de los estados del ambiente de
ejecucin del software o con entradas esperadas de
entidades externas.
3. Implementacin defectuosa en el diseo o en los
requisitos de interfaces del software con otras
entidades externas o en ambiente de ejecucin de
los componentes del software.
4. Interaccin no planeada entre componentes de
software, incluyendo los de otros proveedores [1].
Fig. 3: Rutas atreves de las aplicaciones [11]
Teniendo esto definido, se puede proceder a
El OWASP The Open Web Application Security categorizar o priorizar los riesgos, con el objetivo de
Project [10], publica anualmente el top 10 de los definir cules son los ms pernicioso y, de esa forma,
riesgos ms serios que se presentan en las lograr una categorizacin que permita definir el orden
organizaciones, el cual se puede observar en la Tabla I en que se deben atender y para identificar dnde
para 2010. Cada organizacin realiza su anlisis de invertir mayor esfuerzo o dinero para mitigar el riesgo
riesgos mediante una evaluacin de stos para asociado.
detectar su severidad.
4. METODOLOGAS INVESTIGADAS
TABLA I
OWASP Top 10 2010 [10] 4.1 Funcionamiento con carga compartida [2]
Top Riesgo Con el objetivo de definir estndares de desarrollo de
A1 Injection cdigo seguro varias compaas de todo el mundo,
A2 Cross-Site Scripting (XSS)
como Siemens en Alemania, Tata en India, Nomura
A3 Broken Authentication and Session Management
Research en Japn, CIBC en Londres y las
A4 Insecure Direct Object References
americanas Kaiser Permanente, Boeing, Cisco,
A5 Cross-Site Request Forgery (CSRF)
A6
Symantec, Intel y American Express, se unieron a esta
Security Misconfiguration
A7 Insecure Cryptographic Storage
iniciativa. El proyecto pretende no slo mejorar los
A8
procesos en cada una de las empresas sino el
Failure to Restrict URL Access
desarrollo de software en s. Todas tienen como patrn
A9 Insufficient Transport Layer Protection
A10 Unvalidated Redirects and Forwards
comn que sus desarrollos dependen de la calidad del
software, lo que permitir adems que los clientes
Antes de comenzar a desarrollar cdigo seguro, lo reciban productos seguros, ya sean desarrollados por
primero que se debe hacer es un anlisis de riesgos. terceros o propios. A este grupo de empresas se
Primero se identifican cules son los activos crticos de unieron tambin desarrolladores de otras
la organizacin que estn involucrados en el proceso organizaciones y universidades, como Amazon,
de desarrollo o que de alguna forma van a estar Secure Compass, Universidad Carnegie Mellon y el
expuestos en la aplicacin y luego se identifican cules equipo OWASP, para dar lugar al Concilio de
son las posibles amenazas que pueden explotar las Programacin segura que, desde el 2007, se rene
vulnerabilidades de estos activos. En la seguridad de para definir estndares y documentos que indiquen las
la informacin la amenaza, la fuente del peligro, a habilidades necesarias para escribir cdigo seguro.
menudo es una persona intentando hacer dao con
uno o varios agentes maliciosos [1]. Debido a la necesidad de evaluar el cdigo y tambin
impulsados por buscar la certificacin de los
El software est sujeto a 2 categoras generales de desarrolladores, SANS lanz el Software Security
amenazas: Institute SSI, que est enfocado en proveer
informacin, entrenamiento y una librera de
Amenazas durante el desarrollo. Un ingeniero de investigaciones e iniciativas para ayudarles a
software puede sabotear el programa en cualquier desarrolladores, arquitectos y administradores a
punto de su desarrollo. proteger sus aplicaciones, incluyendo las Web.
Adicionalmente, el SSI lanz GSSP Secure Software
Amenazas durante la operacin. Un agresor intenta Programmer que certifica a los usuarios que
sabotear el sistema. cumplen con todos los requisitos y habilidades
requeridas para realizar codificacin segura y cuenta
El software en la red est comprometido por el con una evaluacin online para medir sus
aprovechamiento de sus debilidades, las cuales se capacidades.
derivan de las siguientes fuentes:
4.2 Security Requirements Engineering Process [5]
1. Complejidad o cambios incluidos en el modelo de El SREP es un mtodo basado en activos y orientado
procesamiento a riesgos, que permite el establecimiento de requisitos
de seguridad durante el desarrollo de las aplicaciones.
18
Ing. USBMed, Vol. 3, No. 1, Enero-Junio 2012
Bsicamente lo que define este mtodo es la cumplir, de acuerdo con las amenazas encontradas en
implementacin de Common Criteria durante todas las el nivel necesario para la aplicacin, tambin se
fases del desarrollo de software CC es un estndar definen las pruebas de seguridad que se aplicarn a
internacional ISO/IEC 15408 para seguridad cada requisito o conjunto de requisitos; (7) categorizar
informtica, cuyo objetivo es definir requisitos seguros y priorizar los requisitos, porque una vez identificados
que les permitan a los desarrolladores especificar se deben ordenar por importancia de acuerdo al
atributos de seguridad y evaluar que dichos productos impacto que tengan en el cumplimiento de los
si cumplan con su cometido. En este proceso objetivos; (8) inspeccin de requisitos, para garantizar
tambin se apunta a integracin con el Systems la calidad y la consistencia de los hallados deben ser
Security Engineering Capability Maturity Model validados por el equipo de trabajo, para que se
(ISO/IEC 21827), que define un conjunto de acepten y refinen de acuerdo con las observaciones
caractersticas esenciales para el xito de los procesos encontradas y (9) mejora el repositorio, aqu se deben
de ingeniera de seguridad de una organizacin. En recopilar todos los documentos, diagramas y modelos
contraste con su derivado, el CMM, SSE-CMM que se hayan encontrado durante el ciclo de desarrollo
establece una plataforma para mejorar y medir el y deben quedar consignados en el SRR.
desempeo de una aplicacin, en cuanto a principios
de ingeniera de seguridad, en vez de centrarse en las 4.3 SQUARE [4]
22 Process Areas. El modelo SQUARE Security Quality Requirements
Engineering propone varios pasos para construir
Esta metodologa trata cada fase del CVDS como a un modelos de seguridad desde las etapas tempranas del
mini proceso o iteracin, dentro de las cuales se ciclo de vida del software. En el proceso del modelo se
aplican las actividades SREP que permiten identificar y hace un anlisis enfocado a la seguridad, los patrones
mantener actualizados los requisitos de seguridad de de ataque, las amenazas y las vulnerabilidades y se
la fase, permitiendo mitigar efectivamente los riesgos desarrollan malos casos de uso/abuso. Los pasos son:
asociados a cada una. El proceso se detalla en la
Figura 4. 1. Acuerdo en las definiciones. Se debe generar un
acuerdo con el cliente en cuanto a las definiciones
de seguridad, como en el control de acceso, la lista
de control de acceso, el antivirus, entre otras.
2. Identificar metas de seguridad. Que se trazan con
base en las propiedades de seguridad definidas en
el documento.
3. Desarrollar artefactos. Diagramas de arquitectura,
casos de mal uso, casos de uso de seguridad,
identificar activos y servicios esenciales, rboles de
ataques, patrones de ataque, requisitos de
seguridad, mecanismos de seguridad.
4. Evaluacin de los riesgos. Se analizan las
Fig. 4: El proceso SREP [5]
amenazas y vulnerabilidades y se definen
estrategias de mitigacin.
Las nueve actividades definidas para cada iteracin
5. Elicitacin de los requisitos.
son las siguientes: (1) acuerdo en las definiciones,
6. Clasificar los requisitos. De acuerdo con el nivel o
donde se verifica que todos los participantes del
las metas de seguridad.
software aprueben y estn de acuerdo en la definicin
7. Priorizar los requisitos. (1) Esenciales, si el
de un conjunto de requisitos de seguridad que se
producto no puede ser aceptado si l, (2)
adapte a las polticas de la compaa; (2) identificacin
condicionales, si requerimiento incrementa la
de activos crticos o vulnerables, que consiste en
seguridad, pero el producto se acepta sin l y (3)
realizar una lista detallada de los activos de
opcionales, si es de baja prioridad frente a los
informacin ms importantes para la organizacin, con
esenciales y condicionales.
base en el Security Resources Repository, que debe
8. Revisin por pares.
ser obtenido previamente; (3) identificar los objetivos y
dependencias de seguridad, donde se debe tener en 4.4 CoSMo [6]
cuenta las polticas de seguridad y los aspectos Debido a la necesidad de integrar aspectos de
legales para definir correctamente hacia qu se apunta seguridad en el proceso de modelado de software, el
para definir el nivel necesario de seguridad requerido; modelado conceptual debe abarcar los requisitos y los
(4) identificar amenazas y desarrollar artefactos, aqu mecanismos de seguridad de alto nivel. Los autores
es necesario identificar todas las amenazas que trabajan en el desarrollo de un mtodo de
puedan afectar cada uno de los activos para modelamiento conceptual de seguridad al que
desarrollar artefactos; (5) evaluacin del riesgo, en denominan CoSMo Conceptual Security Modeling.
esta etapa se seleccionan los riesgos a tratar y cules Antes de tener la visin de que los mecanismos de
a mitigar o transferir, teniendo presente los objetivos seguridad pueden hacer cumplir los requisitos, se
definidos y los activos crticos de la aplicacin; (6) elaboran cuestiones fundamentales de polticas de
elicitar los requisitos de seguridad, donde se seguridad; las cuales consisten de un conjunto de
documentan los requisitos de seguridad que se deben
19
Ing. USBMed, Vol. 3, No. 1, Enero-Junio 2012
leyes, normas y prcticas que regulan cmo una El estereotipo Critical se usa para marcar datos que
organizacin gestiona, protege y distribuye informacin necesitan ser protegidos a toda costa; esta proteccin
sensible. Cada requisito de seguridad lo puede est apoyada por los estereotipos data security y no-
ejecutar uno o ms mecanismos de seguridad, down flow. El primero establece bsicamente que toda
resultando en una matriz de requisitos y mecanismos. la informacin establecida como secrecy debe
Ambos se definen genricamente porque se usan para permanecer igual ante cualquier amenaza.
modelar la seguridad en el nivel conceptual. En primer
lugar, los autores de CoSMo tratan de mostrar cmo La metodologa UMLSec pretende reutilizar los
integrar las consideraciones de seguridad en el marco diseos ya existentes, aplicando patrones para formar
de modelado de procesos conceptuales. Despus, nuevos a partir de una transformacin al existente, tal
enumeran de forma sistemtica los requisitos de como se observa en las Figuras 6 y 7.
seguridad frecuentes e indican claramente cules son
los mecanismos para hacerlos cumplir.
20
Ing. USBMed, Vol. 3, No. 1, Enero-Junio 2012
21
Ing. USBMed, Vol. 3, No. 1, Enero-Junio 2012
evitando de esta forma que se tenga acceso indebido Por otro lado, tambin se recomiendan los modelos
al cdigo fuente o que puedan entenderlo o incluso iterativos, debido a que permiten refinar y sostener las
hasta copiarlo. Algunas de esas herramientas son: metodologas en el tiempo, ya que no basta slo con
Proguard [13], un ofuscador de cdigo Java, Jabson implementar una buena metodologa sino tambin que
[14], ofuscador de cdigo Javascript y Skater.NET [15], debe ser mejorada y refinada continuamente; porque
ofuscador de cdigo .NET en cada iteracin se pueden encontrar nuevas
falencias o aspectos a mejorar que enriquecen el
Como se mencion antes, estas herramientas se producto final.
utilizan en la etapa de desarrollo y su gran ventaja,
adems de identificar vulnerabilidades en una etapa El uso de herramientas automticas para anlisis de
muy temprana del CVDS, es que son baratas y no vulnerabilidades en etapas de desarrollo y de pruebas
requieren que la aplicacin este desplegada o es muy recomendado, siempre y cuando se
instalada. Aunque su mayor desventaja puede ser la monitoreen y refinen continuamente los resultados por
deteccin de falsos positivos dentro del cdigo, debido uno o varios integrantes del equipo de trabajo.
a se basan en patrones de reglas pre-establecidas
para que los analizadores semnticos las puedan 7. REFERENCIAS
reconocer. Esto hace que su margen de error en
deteccin de vulnerabilidades se incremente [1] J. H. Allen et al. Software Security Engineering: A
directamente de forma proporcional al nmero de guide for Project Managers. Addison-Wesley. 2008.
lneas de cdigo de la aplicacin, por lo que es [2] M. Brown & A. Paller. Secure software development:
Why the development world awoke to the challenge.
necesario que los resultados se evalen, analicen y Information Security Technical Report, Vol. 13, No. 1,
refinen continuamente por el equipo de desarrollo, con pp. 40-43, 2008.
el objetivo de evitar inconvenientes innecesarios. [3] J. Jrjens. Foundations for Designing Secure
Architectures. Electronic Notes in Theoretical
En la etapa de pruebas existen varias herramientas Computer Science, Vol.142, pp. 31-46, 2006.
que son de gran utilidad para lograr buenos resultados [4] N. R. Mead & T. Stehney. Security Quality
en pruebas de penetracin, de carga y de monitoreo Requirements Engineering (SQUARE) Methodology.
del trfico y el flujo de informacin de la aplicacin. ACM SIGSOFT Software Engineering Notes, Vol. 30,
Entre estas se encuentran: No. 4, pp. 1-7, 2005.
[5] D. Mellado D.; E. Fernandez-Medina & M. Piattini. A
common criteria based security requirements
Webgoat. Una gua que sugiere los pasos para las engineering process for the development of secure
pruebas de vulnerabilidad. information systems. Computer Standards &
Webscarab. Con la que se prueban diferentes tipos Interfaces, Vol. 29, No. 2, pp. 244-253, 2007.
de ataque como inyeccin, hijacking, cookies [6] R. Villaroel; E. Fernandez-Medina & M. Piattini. Secure
tampering, man in the middle, fuzzing. information systems development: A survey and
Wireshark. Un sniffer que permite revisar el flujo de comparison. Computers & Security Vol. 24, No. 4, pp.
paquetes en la red con el fin de identificar 308-321, 2005.
contraseas o sentencias SQL que viajen sin cifrar. [7] CMMI Product Team. CMMI for Development.
Version 1.22. CMU/SEI-2006-TR-008. Carnegie
jMeter [9]. Permite similar concurrencia de usuarios y Mellon, 2006.
de esta forma similar ataques de DoS; soporta el uso [8] W. Brooks & M. Warren. A Methodology of Health
de cookies. Information Security Evaluation. In J. Westbrook et al
(Eds.), HIC 2006 and HINZ 2006: Proceedings.
6. CONCLUSIONES Brunswick East, Vic.: Health Informatics Society of
El diseo de aplicaciones seguras se ha convertido en Australia, pp. 464-470, 2006.
un tema de alta prioridad. Debido al auge que la [9] D. Nevedrov. Using JMeter to Performance Test Web
seguridad de la informacin ha tenido en los ltimos Services, 2006. Online [Oct. 2011].
aos y a la dependencia que las empresas tienen de [10] Fundacin OWASP. https://www.owasp.org.
[11] Fundacin OWASP. https://www.owasp.org/index.php/
sus aplicaciones, se hace necesario garantizar su Top_10_2010-Main. [Oct. 2011].
correcto funcionamiento mediante proteccin a los [12] OWASP Spain Charter Meeting III. Herramientas para
ataques internos y externos. anlisis esttico de seguridad: estado del arte. Online
[Oct. 2011].
El anlisis de riesgos se convierte en un factor comn [13] J. Sanz A. Ofuscadores de Cdigo Java. Slo
en cualquier metodologa de desarrollo seguro, porque Programadores, No. 83, pp. 6-11, 2001.
es imperativo conocer cules son los activos crticos [14] JavaScript Obfuscation Fascination. www.jason.com.
de la organizacin y cules son las amenazas [Oct. 2011].
asociadas con ellos. Es recomendable, para cualquier [15] Rustemsof. http://www.rustemsoft.com/obfuscator_net
.asp. [Oct. 2011].
aplicacin, utilizar metodologas basadas en UML
porque son aceptadas de forma general y no requieren
mayor esfuerzo en entrenamiento del equipo de
desarrollo para su implementacin.
22