Vladimir Villa, CEO de Fluid Attacks

  • Las organizaciones que desarrollan software para ellas y para otros deberían implementar y exigir en sus equipos unas buenas prácticas de programación que permitan garantizar productos seguros para sus clientes o usuarios.

¿Cómo es que en el desarrollo de software aún muchas empresas no relacionan directamente la calidad con la seguridad del código? ¿Cuáles son esas buenas prácticas relacionadas con seguridad que los equipos de desarrollo suelen dejar de lado para enfocarse más en la funcionalidad de sus productos? Fluid Attacks, empresa especializada en contribuir a que las compañías desarrollen y desplieguen software seguro y sin retrasos, comparte algunas recomendaciones a tener en cuenta en el desarrollo de aplicaciones seguras.

Tal como plantea Vladimir Villa, CEO de Fluid Attacks, “la calidad de las aplicaciones debemos juzgarla no solo a partir de qué tan bien cumplen sus funciones, sino además de qué tanto protegen la confidencialidad y privacidad de los usuarios. Una seguridad deficiente en una aplicación puede dar lugar a que los cibercriminales alteren o interrumpan sus operaciones e incluso tomen provecho de información sensible presente en ella, con consecuencias devastadoras. La seguridad debe entonces ser vista e implementada como requisito por defecto en el desarrollo de software”.

Muchas veces, las empresas que desarrollan software ven la seguridad como un obstáculo para una salida rápida al mercado. No es hasta que dichas compañías se transforman en víctimas que reconocen la necesidad de hacer seguros sus productos. Cada ciclo de vida de desarrollo de software debería tener la seguridad como responsabilidad desde el comienzo. Cada desarrollador debería recibir retroalimentación sobre la seguridad del código que produce desde el principio.

Así pues, desde una postura preventiva se promueve lo anterior y se incentivan unas buenas prácticas de desarrollo para la programación segura de software, algunas de las cuales comparte Fluid Attacks a continuación.

Las empresas deben garantizar que cada aplicación que desarrollan cumple con lo siguiente:

  • Es revisada desde el principio y continuamente tanto por equipos y herramientas de seguridad internos y externos para la identificación de vulnerabilidades de seguridad a remediar.

  • Está construida con componentes de software conocidos y en sus últimas versiones que muestran verdadera utilidad dentro de ella. Además, todas las dependencias entre componentes deberían estar mapeadas y constituir un conjunto cuya complejidad sea la menor posible.

  • Es desarrollada y mantenida en sistemas confiables de control de código fuente y seguimiento de cambios que se realizan en un único repositorio. Dichos cambios deberían darse preferiblemente como microcambios que generen valor diario a los usuarios. Debería haber un entorno de integración continua/despliegue continuo en el que toda modificación sea puesta a prueba en relación con el cumplimiento de requisitos de estructura, funcionalidad y seguridad determinados. En caso de no cumplir con ellos, las integraciones y despliegues deberían verse interrumpidos.

  • Valida toda la información que llega a ella. Por tanto, cuenta con una clasificación de fuentes confiables y no confiables, distingue correctamente entre comandos y datos, y acepta solo la entrada de información externa que cumple con determinadas características.

  • Verifica la identidad de cada usuario que interactúa con ella. Para los casos de operaciones críticas, como transferencias de dinero, debería solicitar autenticación multifactor.

  • Solicita a sus usuarios la generación de contraseñas largas y complejas. Adicionalmente, debería sugerir el cambio frecuente de contraseñas y bloquear temporalmente las cuentas con varios intentos fallidos de inicio de sesión.

  • Restringe el acceso a datos y funciones sensibles solo a unos pocos usuarios autorizados. Debería tener como base el principio de privilegio mínimo, denegando varios accesos por defecto y limitando el empleo de recursos para que se acceda solo a aquellos que son necesarios para cumplir con tareas específicas.

  • Cierra la sesión de un usuario al poco tiempo de que este muestre inactividad, y no permite inicios de sesión simultáneos con una misma cuenta.

  • Posee algoritmos de cifrado de información conocidos, debidamente probados y actualizados para proteger todos los datos sensibles que se almacenan o que transitan por ella. Ninguno de esos datos debería almacenarlos como texto legible o sin cifrar, y su código fuente no debería contener comentarios que revelen información confidencial.

  • Genera mensajes de error cuando se trata de llevar a cabo en ella actividades inválidas, pero en dichos mensajes no revela ninguna información que podría ser útil para los atacantes. Toda la información relacionada con actividades inválidas debería quedar registrada pero ser bloqueada y de acceso restringido solo a unos pocos usuarios.

“Cuando las pruebas de seguridad se incluyen tempranamente en los ciclos de desarrollo de software, de la mano de expertos y herramientas automatizadas, los equipos de desarrollo pueden contar con retroalimentación rápida y continua. Pueden conocer los errores en sus prácticas que dan lugar a vulnerabilidades de seguridad y remediarlas con prontitud. Esto, aparte de que reduce costos y esfuerzos, permite que el despliegue de la aplicación no se vea retrasado y que se garantice a los usuarios finales un producto seguro en el que pueden confiar”, concluye el CEO de Fluid Attacks.