Vladimir Villa, CEO de Fluid Attacks.
[12/02/2020] La seguridad debe acompañar al desarrollo, esa es en resumen la filosofía que Fluid Attacks, firma de hacking ético, ha lanzado al campo de la seguridad. Conversamos con Vladimir Villa, CEO de la compañía, para entender en mayor profundidad los caminos por los que actualmente se están desarrollando las iniciativas de seguridad.
Ya no basta con revisar la seguridad luego del desarrollo del software, es necesario acompañar ese desarrollo desde el inicio, sostiene el CEO, cuando nos explica lo que vienen haciendo las compañías de seguridad para seguirle el paso al desarrollo ágil de software. Si el desarrollo se ha acelerado también tiene que hacerlo la seguridad.
¿Cómo se podría definir el hacking ético?
Lo que busca es hacer una simulación controlada. Básicamente lo que hacen los hackers éticos es atacar un sistema, con autorización, para encontrar las vulnerabilidades o problemas de seguridad rápidamente, de manera que la institución pueda corregir esas vulnerabilidades y no se vea expuesta a que atacantes verdaderos las puedan explotar y comprometer registros o materializar fraudes.
¿Cuáles son las compañías que acuden al hacking ético?
Unas son las que acuden y otras las que deberían. Si me pregunta quién debería hacer una prueba de seguridad, la respuesta es 'cualquier compañía que esté construyendo un software para poner en una red'. Hoy, en el mundo actual, es casi cualquier compañía que tenga presencia en Internet. Cualquier compañía que esté desarrollando software debería hacer pruebas de seguridad y testear su software.
¿Quiénes acuden? Pues cada vez hay más conciencia y son cada vez más las compañías que tienen presencia en Internet y buscan hacer pruebas de seguridad. Pero la realidad es que, principalmente, los que acuden son los que tienen alguna regulación que se los exige -como el sector financiero. Otros son a quienes su mercado o sus clientes les exigen ser seguros, y otros son los que tienen conciencia, pero la conciencia se gana porque ha sufrido un incidente o porque su información es demasiado crítica y es necesario tener seguridad.
El mercado viene regulando al sector financiero nuevo, a las fintechs. Si bien las fintechs en la mayoría de los países no están reguladas, ellos transan con compañías más grandes que sí están reguladas y esas compañías les exigen pruebas de seguridad; las pruebas de seguridad para las fintechs son un habilitador de negocios. Y para el sector tradicional es una buena praxis.
Hay empresas que tienen controles de seguridad que se implementan y luego quieren probar esos controles. Sin embargo, el hacking ético no solo aplica para validar controles de seguridad, sino también para garantizar que la construcción de un software es la adecuada. De hecho, ese es el enfoque que se debe tener. Cuando se tiene una estrategia de seguridad adecuada, se deben hacer las pruebas de seguridad de manera proactiva y lo que se busca es que se garantice que la construcción del software sea segura, que las aplicaciones que se están sacando a producción sean seguras y que la seguridad sea parte del ciclo de vida de desarrollo. El hacking ético debe ser continuo mientras se va desarrollando el software, no debe ser reactivo.
¿Cuáles son las fallas de seguridad más comunes?
Típicamente la tecnología se divide en dos capas. Una es la de aplicaciones y la otra es la de infraestructura. La capa de aplicaciones la podemos entender como el software funcional, la aplicación que consumo. Y la infraestructura son los servidores o computadoras o instancias en la nube donde se despliega ese software.
La mayoría de las vulnerabilidades y las más críticas se encuentran en la capa de software, porque es la menos estandarizada. Si bien los grandes vendors de infraestructura son pocos, si tienes una adecuada instalación y configuración y unas buenas prácticas -realizar las actualizaciones cuando es necesario- se puede decir que el nivel de seguridad es muy alto y que las vulnerabilidades que se encuentran son pocas.
Pero el software es construido por diversas personas y casi a la medida, mediante un proceso muy artesanal y casi artístico, no es estandarizado; y, por eso, la mayoría de las vulnerabilidades y las vulnerabilidades más críticas se encuentran en la capa de aplicaciones.
Si me pregunta cuáles son las más comunes, diría que hay de todo; pero básicamente, la mayoría de las principales vulnerabilidades se dan por falta de validación de datos. El programador está confiado en que la información que va a recibir el software es correcta y no la valida, y eso se debe a que el programador está pensando en hacer un software que sea funcional. Pero uno como atacante -ético o no- lo que busca es hacer que el software funcione como no debe funcionar. Es muy típico tener una aplicación móvil y por detrás una API, y hoy es un error muy común hacer validaciones en las aplicaciones, pero no en la API; un atacante podría consumir la API directamente y vulnerar el sistema.
Ahora que se pide desarrolle ágil ¿también se ha acelerado la seguridad?
Ese es el reto que tenemos todos en tecnología. El reto que tenemos es que el mundo está cambiando muy rápido, y la tecnología tiene que ser un habilitador de ese cambio rápido; entonces, tenemos que sacar productos a producción de manera ágil, pero los productos tienen que ser buenos y seguros. Entonces el reto es desarrollar tecnología ágil y segura.
Básicamente, la estrategia es muy simple: hacer pruebas de seguridad durante la construcción. Eso se llama 'moverse a la izquierda' en el ciclo de desarrollo del software. Típicamente, lo que antes se hacía era que se construía todo el software y luego se hacía una prueba de seguridad; se era reactivo, ahora se tiene que ser proactivo.
Eso implica impactar esos procesos de software desde la construcción; es decir, desde que el desarrollador está escribiendo la primera línea de código uno debe tener un proceso paralelo que esté validando la seguridad de ese código. Para eso se hacen pruebas estáticas y pruebas dinámicas; además se tiene que utilizar la tecnología; es decir, automatizar parte de la búsqueda de vulnerabilidades y tener un proceso manual que sea ágil y que impacte rápidamente el proceso de construcción.
La combinación tiene que ser óptima entre el uso de la automatización y el talento humano, porque hoy la tecnología de automatización de búsqueda de vulnerabilidades no logra encontrar todas las vulnerabilidades; tiene dos grandes retos, primero que se le pasan muchas vulnerabilidades y segundo que tiene muchos falsos positivos. Si solo confío en la automatización, voy a tener grandes problemas.
Del 100% de vulnerabilidades que tiene un software hoy, la tecnología existente en el mundo solo permite encontrar el 15% de manera automática y con certeza; pero ese 15% es válido, agrega velocidad. Luego, debo hacer un proceso manual desde las fases iniciales de construcción del software para encontrar el otro 85%.
Nosotros, en nuestra compañía, acompañamos procesos de desarrollo donde hay pasos a producción diarios y son pasos que ya tienen la seguridad validada, simplemente porque tenemos esa combinación óptima entre automatizar lo que es automatizable, y el resto hacerlo manualmente, pero dentro del ciclo de vida del desarrollo del software.
Jose Antonio Trujillo, CIO Perú
Puede ver también
¿Qué es el hacking ético?:Conceptos básicos y requisitos