4.2 SEGURIDAD EN EL CICLO DE DESARROLLO DEL SOFTWARE

La mayor parte de las organizaciones desarrolla o contrata eldesarrollo 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 enlos aspectos de seguridad dela 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 numerososaspectos 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 OWASPTop 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 verlos 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 seguridadTradicionalmente, 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 produccinUna 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 diseoConsta de las siguientes etapas:1) Conformar un grupo de anlisis de riesgos2) 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 diseoAyuda a identificar amenazas en los componentes de un sistemaSu 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-de-desarrollo-de-software/