4.

2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

La mayor parte de las organizaciones desarrolla o contrata el desarrollo

de aplicaciones propias para su gestin de negocio. Como todo software,
estas aplicaciones pueden contener fallas de seguridad y a diferencia del
software comercial, no se dispone de actualizaciones o parches liberados
en forma peridica por el fabricante. El tratamiento de las
vulnerabilidades en aplicaciones propias corre por parte de la
organizacin que las desarrolla.
Lamentablemente es una prctica habitual en muchas organizaciones la
puesta en produccin de sistemas sin la participacin del sector de
Seguridad de la Informacin.
Muchas otras veces, el sector de Seguridad se entera demasiado tarde,
y no tiene suficiente margen de accin para el anlisis de seguridad de
la aplicacin desarrollada.
Por lo general, en el mejor de los casos, se coordina un testeo de
seguridad una vez que la aplicacin ya est desarrollada. Aqu muchas
veces se encuentran errores que requieren el rediseo de parte de la
aplicacin, lo cual implica un costo adicional en tiempo y esfuerzo.
Seguridad en el anlisis de requerimientos
En esta etapa, se deben identificar aquellos requerimientos funcionales
que tendrn impacto en los aspectos de seguridad de la aplicacin.
Algunos de ellos son: requerimientos de compliance con normativas
locales o internacionales (ej: PCI, SOX, A 4609, etc.), tipo de
informacin que se transmitir o procesar (ej: Informacin pblica o
confidencial, datos personales, datos financieros, contraseas, datos de
pago electrnico, etc.) y requerimientos de registros de auditora (ej:
Qu debe registrar la aplicacin en sus Logs).
Seguridad en el diseo
Antes de comenzar a escribir lneas de cdigo, hay numerosos aspectos
de seguridad que deben ser tenidos en cuenta durante el diseo de la
aplicacin.
Algunos de ellos son: diseo de autorizacin
(ej: Defnir los roles, permisos y privilegios de la aplicacin), diseo de
autenticacin (aqu se debe disear el modo en el que los usuarios se
van a autenticar, contemplando aspectos tales como los mecanismos o
factores de autenticacin con contraseas, tokens, certifcados, etc.

posibilidades de integrar la autenticacin con servicios externos como

LDAP, Radius o Active Directory y los mecanismos que tendr la
aplicacin para evitar ataques de diccionario o de fuerza bruta (ej:
bloqueo de cuentas, implementacin de captchas, etc.), diseo de los
mensajes de error y advertencia, para evitar que los mismos brinden
demasiada informacin y que sta sea utilizada por atacantes y diseo
de los mecanismos de proteccin de datos (aqu se debe contemplar el
modo en el que se proteger la informacin sensible en trnsito o
almacenada; segn el caso, se puede definir la implementacin de
encriptacin, hashes o truncamiento de la informacin).
Una vez que se cuenta con el diseo detallado de la aplicacin, una
prctica interesante es la de realizar sobre el mismo un anlisis de
riesgo orientado a software. Existen tcnicas documentadas al respecto,
tales como Threat Modeling. Estas tcnicas permiten definir un marco
para identificar debilidades de seguridad en el software, antes de la
etapa de codificacin. Como valor agregado, del anlisis de riesgo
orientado a software se pueden obtener casos de prueba para ser
utilizados en la etapa de Testing/QA.
Seguridad en la codificacin
Una vez concluido el diseo, le toca a los desarrolladores el turno de
codificar los distintos componentes de la aplicacin. Es en este punto en
donde suelen incorporarse, por error u omisin, distintos tipos de
vulnerabilidades. Estas vulnerabilidades podramos dividirlas en dos
grandes grupos a saber: vulnerabilidades clsicas y vulnerabilidades
funcionales. Las primeras son bien conocidas y categorizadas.
Ejemplo de estas vulnerabilidades son las presentes en el OWASP
Top 10 (Vulnerabilidades de inyeccin, Cross Site Scripting, errores en
manejo de sesiones, etc.) como as tambin otras vulnerabilidades no
ligadas directamente con las aplicaciones WEB, como desbordamiento
de buffer, denegacin de servicio, etc. Los Frameworks de desarrollo
de aplicaciones son una buena ayuda en este punto, ya que ofician de
intermediario entre el programador y el cdigo, y permiten prevenir la
mayora de las vulnerabilidades conocidas. Ejemplos de estos
frameworks son Struts, Ruby on Rails y Zope.
Vulnerabilidades funcionales son aquellas ligadas especficamente a la
funcionalidad de negocio que posee la aplicacin, por lo que no estn
previamente categorizadas.
Algunos ejemplos ilustrativos de este tipo de vulnerabilidad son los
siguientes: una aplicacin de banca electrnica que permite realizar
transferencias con valores negativos, un sistema de subastas que

permite ver los valores de otros oferentes, un sistema de venta de

entradas para espectculos que no impone lmites adecuados a la
cantidad de reservas que un usuario puede hacer.
En la etapa de codificacin, una de las reglas de oro es verificar todos
los valores de entrada y de salida. Esto es, asumir siempre que el valor
pudo haber sido manipulado o ingresado maliciosamente antes de ser
procesado.
Testing / QA de seguridad
Tradicionalmente, la labor del equipo de Testing/QA fue la de encontrar y
reportar errores funcionales de la aplicacin. Para esto, se desarrollan
casos de test basados en la funcionalidad esperada. A esto
denominamos testing funcional y bsicamente consiste en validar que
la aplicacin haga lo que se esperaba que hiciera. Sucede que
habitualmente hay un desfasaje entre el diseo original de la aplicacin
(lo que se espera que haga) y la implementacin real (lo que realmente
hace). Aqu surgen 3 reas bien definidas: lo que fue definido y la
aplicacin hace, lo que fue definido y la aplicacin no hace (errores
funcionales) y lo que no fue definido pero la aplicacin hace.
Implementacin / Puesta en produccin
Una mala configuracin al momento de implementar la aplicacin podra
echar por tierra toda la seguridad de las capas anteriores. Tanto la
aplicacin como el software de base deben configurarse de manera
segura al momento de poner el software en produccin. En este punto
se deben contemplar tareas tales como: cambio de usuarios y
contraseas iniciales o por defecto, borrado de datos de prueba y
cambio de permisos de acceso. Es tambin importante mantener una
correcta separacin de los ambientes de desarrollo, testing y produccin
y procedimientos de traspaso seguro de uno a otro de estos ambientes.
La seguridad en las aplicaciones de software debe abordarse desde el
primer da del proceso de desarrollo y a lo largo de todas las etapas del
mismo. En cada una de estas etapas, se pueden realizar diversas
actividades que en su conjunto ayudarn a aumentar la seguridad de la
aplicacin de software que se est desarrollando. Es importante que en
cada organizacin, el sector de seguridad de la informacin sea invitado
a participar a lo largo de todo el proceso de desarrollo como supervisor
de las tareas y verificaciones de seguridad.

Anlisis de riesgo Threat Modeling

Seguridad en el dise Seguridad en el diseo

Consta de las siguientes etapas:
1) Conformar un grupo de anlisis de riesgos
2) Descomponer la aplicacin e identificar componentes clave.
3) Determinar las amenazas a cada componente de la aplicacin.
4) Asignar un valor a cada amenaza.
5) Decidir cmo responder a las amenazas.
6) Identificar las tcnicas y tecnologas necesarias para mitigar los
riesgos identificados.

Mtodo STRIDE

Seguridad en el diseo
Ayuda a identificar amenazas en los componentes de un sistema
Su nombre es un acrnimo de:
Spoofing Identity: Suplantar la identidad de otro usuario o servicio.
Tampering with Data: Modificar maliciosamente datos almacenados.
Repudiation: Imposibilidad de identificar el autor de una accin.
Information Disclosure: Divulgar informacin a usuarios no autorizados.
Denial of Service: Provocar que un servicio deje de funcionar.
Elevation of privilege: Conseguir privilegios mayores a los asignados

Bibliografa:
http://prezi.com/gu9iod4v-qkz/seguridad-en-el-ciclo-de-vida-dedesarrollo-de-software/