El día jueves 2 de abril entre 9 y 18 horas se realizó un evento presencial de Microsoft en el auditorio de New Horizons Chile, en el marco de la semana de la seguridad. En la jornada de la tarde (de 14 a 18 horas) estuvo dedicado al desarrollo de software. (si hacen click podrán ver las grabaciones de esos eventos, más otros que se han dado en otras fechas).
Lo que se habló y vio ese día me animó a volver un rato por los ruedos bloggeros para dar mi opinión sobre varios conceptos e ideas que se discutieron ese día.
La masificación de internet y el incremento en la complejidad e interacción entre las aplicaciones y los sistemas, a traído sobre el tapete el tema de la seguridad más seguido. Pero como en todo, el que se hable más de un tema no significa que tenga realmente mayor relevancia o que se haga más al respecto.
La masificación de internet también ha dado más facilidades a los atacantes para conectarse a nuestras aplicaciones e intentar vulnerar la seguridad de esta.
Como dije, más allá que se habla mucho de seguridad, aún los roles envueltos en la mayoría de los proyectos de desarrollo de software hacen poco por asegurar realmente sus aplicaciones escudándose en que es un proceso altamente costoso o altamente dificultoso.
Planificación
A menudo, en el proceso de planificación del proyecto no se le asigna a la seguridad la relevancia necesaria debido a que muchas veces quienes participan en esta etapa no tienen, o tienen un limitado conocimiento, acerca de las vulnerabilidades que podría poner en riesgo la seguridad de su aplicación, como por ejemplo ataques organizacionales, ataques automatizados en busca de vulnerabilidades, ataques de fuerza bruta, denegación de servicio (DoS) y vulnerabilidades varias debidas a malas o deficientes prácticas de desarrollo.
También sucede que muchas veces están conscientes de las vulnerabilidades pero creen que su aplicación no va a ser afectada por estas o que su aplicación nunca será atacada. Esto es muy habitual cuando se desarrolla software para ambientes corporativos internos o intranets, donde se piensa que al no estar expuestas al mundo (internet) la aplicación está segura, olvidándose del enemigo interno y dejando la aplicación a merced de este.
Finalmente, el último escenario es que se esté consciente de las vulnerabilidades, se sepa que nuestra aplicación va a ser afectada, pero no se tome en cuenta el tema hasta el final (si es que queda tiempo) debido a las restricciones de tiempos en los proyectos (deadlines). Es importante recalcar que al planificar nuestro proyecto debiésemos planificar con el tiempo necesario para poder realizar los pasos necesarios que aseguren un nivel de seguridad adecuado en nuestra aplicación. Pero además como todos los oradores dijeron ese día (recomiendo oir el material de las sesiones de ese día) hay muchas técnicas que podemos usar para aumentar la seguridad de nuestra aplicación y que no significan un aumento en nuestros tiempos de desarrollo.
Desarrollo
Así como en la planificación se falla muchas veces en reconocer las vulnerabilidades de seguridad, otras tantas los desarrolladores fallamos en implementar código seguro por diversas causas.
Así como los planificadores, los desarrolladores muchas veces tampoco son conscientes de las vulnerabilidades potenciales, muchas veces debido a la falta de capacitación y de información con respecto a este tema.
Otro inconveniente habitual es que a menudo los desarrolladores no son capaces de implementar código seguro debido a que la seguridad de la aplicación depende de la cooperación entre los desarrolladores y los administradores de sistemas (nuestros amigos de infraestructura), y eso habitualmente no sucede porque nuestra práctica habitual nos indica que la seguridad es una responsabilidad individual. Si estamos trabajando en una aplicación que funciona en red entonces esperamos que la seguridad sea vista por el administrador del sistema por que la red es concernencia de la gente de infraestructura, lo cual nos lleva a olvidar que una aplicación más segura es responsabilidad de todos los roles que se vean envueltos en el normal funcionamiento de esta (Administradores de sistemas, Arquitectos de solución, Arquitectos de infraestructura, analistas, desarrolladores, etc.)
También como dijimos en el punto de planificación, tal vez los desarrolladores estén conscientes de las vulnerabilidades, pero las restricciones de tiempo o de presupuesto no le permiten implementar al menos la seguridad básica. Mencioné las restricciones de presupuesto pues muchas veces se piensa en que los costos de implementar seguridad son elevados y los beneficios poco palpables o claros, aunque realmente los costos altos se producen al no implementar seguridad, pues si una aplicación no es asegurada adecuadamente y un usuario malicioso posteriormente explota y/o expone esta vulnerabilidad, los costos de desarrollar parches de seguridad para esta vulnerabilidad incluyen básicamente: los desarrolladores deben arreglar el código, los testers deben aplicar las diversas pruebas de rigor al parche de seguridad y debemos dar aviso al cliente y publicar el parche (con el costo de pérdida de credibilidad asociado).
En resumen descubriremos que los costos mencionados anteriormente serán más altos que agregar características de seguridad en etapas como la de diseño o desarrollo.
Espero ir habitualmente entregando tips, experiencias, how to, que demuestren lo dicho en este post y que nos ayuden a mejorar nuestra conciencia de seguridad en el desarrollo de software.