4.
2 Seguridad en el ciclo de desarrollo de software En muchas organizaciones es comn la puesta en produccin de sistemas sin tomar en cuenta el sector de la seguridad de la informacin. Y en la mayora de los casos, cuando se quiere implementar las medidas de seguridad para el software (o sistemas), se hace en un momento en que ya no es posible abarcar un margen de accin para en anlisis de seguridad de la aplicacin desarrollada. Por lo general, y en el mejor de los casos, cuando el software que se dise es terminado, se realiza un solo testeo de seguridad. Se encuentran errores que suponen el rediseo parcial o total de la aplicacin. Proceso que implica un costo extra de recursos de varios tipos. Pero resulta obvio que mientras ms temprano nos enfoquemos y mantengamos en la seguridad del software a lo largo de todas las etapas de desarrollo, mayor ser la calidad y confiabilidad del producto final. Las etapas pueden ser relativas al tipo de software o aplicacin, pero generalmente son las siguientes: -Anlisis de requerimientos -Diseo funcional y detallado -Codificacin -Testing -Implementacin
4.2.1 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).
4.2.2 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: Definir 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, certificados, 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 encripcin, hashes o truncamiento de la informacin)
4.2.3 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.
4.2.4 Testing
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. Es en este ltimo grupo, en donde habitualmente estn las vulnerabilidades, y el testing funcional clsico no es capaz de encontrarlas. Por este motivo se necesitan nuevas tcnicas para explorar lo desconocido. El testing de seguridad se basa principalmente en probar la
aplicacin con escenarios no planificados, incluyendo valores mutados, fuera de rango, de tipo incorrecto o malformados, acciones fuera de orden, etc. 4.2.5 Implementacin 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.