Si las herramientas de AppSec son la solución mágica, ¿por qué tantas empresas no las utilizan?

Una versión de este artículo apareció en Revista SC. Se ha actualizado y distribuido aquí.

‍

Uno de los muchos acertijos a los que se enfrentan los especialistas en seguridad de hoy en día es determinar el equilibrio de las soluciones que utilizarán para gestionar los riesgos cibernéticos a los que se enfrentan. ¿Cómo se debe dividir el presupuesto entre las herramientas y las personas? ¿Qué conjunto de herramientas funcionará mejor para el conjunto tecnológico existente? Con tantas opciones disponibles, no hay respuestas fáciles, y elegir las opciones incorrectas costará tiempo y dinero más adelante.

Un informe reciente reveló que el mercado de herramientas de seguridad de aplicaciones está rastreando crecimiento «explosivo» de aquí a 2025, un claro indicio de su papel indiscutible en las prácticas exitosas de DevSecOps y de su creciente relevancia en la industria ante los crecientes volúmenes de código con posibles vulnerabilidades de seguridad.

Sin embargo, hay un problema un tanto curioso. Casi la mitad de las organizaciones envían código vulnerable a sabiendas, A pesar de utilizando una serie de herramientas de AppSec diseñadas para detener precisamente eso. En el caso de productos con una demanda de mercado innegable que están ganando terreno rápidamente, no tiene mucho sentido. ¿Por qué tantas personas comprarían herramientas de seguridad sofisticadas, solo para ignorar sus hallazgos o no utilizarlas en absoluto? Es un poco como comprar una casa frente a la playa, solo para dormir en una tienda de campaña en el bosque.

Hay algunas razones por las que las herramientas de AppSec no se utilizan como cabría esperar, y se trata menos de las herramientas y su funcionalidad, y más de cómo se integran con un programa de seguridad en su conjunto.

Más herramientas no equivalen a menos problemas.

A medida que las empresas evolucionan sus procesos de desarrollo de software, pasando de Agile a DevOps y al sagrado nirvana que es DevSecOps (por ahora, es lo mejor que tenemos), es inevitable que, por el camino, adquieran varios escáneres, monitores, firewalls y todo tipo de herramientas de AppSec. Aunque parezca que se trata de «cuanto más, mejor», muy a menudo esto lleva a una pila tecnológica que se parece al Monstruo de Frankenstein, con toda la imprevisibilidad que esto implica.

Con los presupuestos y los recursos de expertos cada vez más limitados para el alcance del trabajo requerido, tratar de deshacer el lío y encontrar las mejores herramientas para avanzar es una tarea abrumadora, y el código que necesita ser escaneado y corregido no deja de llegar. No es de extrañar que muchas organizaciones hayan tenido que conservar el código de envío, aunque es bastante alarmante y sigue representando un enorme riesgo para nuestros datos y nuestra privacidad.

Las herramientas de escaneo son lentas y esto afecta a la agilidad de las versiones.

Lograr la seguridad a gran velocidad es una especie de ballena blanca en el desarrollo de software, y la verdad es que seguimos intentando hacerlo bien a pesar de que estamos llevando a las organizaciones a adoptar un enfoque orientado a DevSecops. La revisión manual y meticulosa del código podría haber funcionado como sistema de seguridad a prueba de fallos en los años 90, pero en una época en la que producimos cientos de miles de millones de líneas de código, es un plan casi tan eficaz como preparar un campo de fútbol con unas tijeras para uñas.

Las herramientas de escaneo automatizan el proceso de búsqueda de posibles problemas y se encargan de revisar meticulosamente el código por nosotros. El problema es que siguen siendo lentas en el contexto de un proceso de CI/CD que funciona a toda máquina, y ninguna herramienta encuentra todas las vulnerabilidades por sí solas. También hay un par de problemas evidentes con los resultados que el equipo de seguridad recibe tras un escaneo:

1. Hay un mucho de falsos positivos (y negativos)
2. Algún pobre experto en seguridad todavía tiene que sentarse y hacer una revisión manual para separar los errores reales de los fantasmas.
3. Muy a menudo, se revelan demasiadas vulnerabilidades comunes que deberían haberse detectado antes de implementar el código. ¿De verdad quiere que sus costosos expertos en seguridad se distraigan de los grandes y complicados problemas de seguridad que plantean las cosas pequeñas?
4. Los escáneres encuentran, no arreglan.

Incluso en una organización que está haciendo todo lo posible por aplicar las mejores prácticas de ciberseguridad y adaptarse a los tiempos para incluir la seguridad en cada etapa del proceso, el proceso anterior sigue siendo un éxito si los escáneres son la principal medida de protección, y hay demasiados errores comunes que hacen tropezar al equipo a la hora de implementar código seguro. Es lógico pensar que en este caso se pueden tomar atajos, y eso suele consistir en confiar en el mínimo de herramientas que no pueden cubrir todos los riesgos potenciales, incluso si se ha adquirido un conjunto de soluciones.

Parte de la automatización líder en tecnología puede provocar una disminución de la calidad del código

El escaneo y las pruebas soportan la carga de los procesos automatizados de las herramientas de AppSec, junto con elementos esenciales como los firewalls y la supervisión, pero otras herramientas comunes pueden erosionar inadvertidamente las bases prácticas de seguridad con el tiempo.

Por ejemplo, la tecnología RASP (autoprotección de aplicaciones en tiempo de ejecución) se aplica a menudo para reforzar la postura de seguridad sin sacrificar la velocidad de codificación. Funciona en el entorno de ejecución de una aplicación, lo que protege contra la entrada de código malintencionado y los ataques en tiempo real, y detecta cualquier comportamiento de ejecución extraño.

No cabe duda de que se trata de una capa de protección adicional, pero si se piensa que es una protección contra cualquier posible debilidad del código base, los desarrolladores pueden caer en la autocomplacencia, especialmente cuando se enfrentan a plazos de comercialización cada vez más imposibles para lanzar nuevas funciones. Es posible que no se sigan prácticas de codificación seguras, con el supuesto de que la autoprotección durante el tiempo de ejecución detectará cualquier error. Los desarrolladores no se esfuerzan por crear patrones de codificación inseguros, pero con frecuencia la seguridad pierde prioridad en favor de la entrega de funciones, especialmente si se parte de la hipótesis de que se trata de una protección automatizada.

Las herramientas pueden fallar (y en el caso del RASP, suelen ejecutarse en modo de supervisión para evitar falsos positivos, lo que a su vez solo proporciona visibilidad, no protección, contra un ataque) y, cuando eso ocurre, se trata de un código seguro y de alta calidad en el que se puede confiar en todo momento. La concienciación sobre la seguridad en todas las funciones relacionadas con el código es fundamental para DevSecOps, y los desarrolladores que no se forman en código seguro o no producen código seguro es un error. Escribir código seguro e inseguro requiere el mismo esfuerzo; lo que más se necesita es adquirir los conocimientos necesarios para programar de forma segura. El tiempo dedicado a implementar y optimizar RASP se puede utilizar mucho mejor para mejorar las habilidades de los desarrolladores para que no cometan el error desde el principio.

Equilibrar herramientas y personas: no es una fórmula mágica, pero es lo más cerca que tenemos (por ahora).

El espíritu principal de DevSecOps es hacer de la seguridad una responsabilidad compartida, y para las organizaciones que están creando el software que impulsa nuestras vidas (desde la red eléctrica hasta nuestros timbres), necesitan llevar a todos a la aventura para garantizar un mayor nivel de seguridad.

Las herramientas no lo hacen todo, y ni siquiera es la forma más barata. Con diferencia, los mejores resultados se obtienen dando prioridad a la formación en seguridad adecuada para todos los que se dedican al código, trabajando activamente para que el equipo de desarrollo tenga en cuenta la seguridad y creando una cultura de seguridad positiva dirigida por personas, con un conjunto de herramientas que desempeñe un papel de apoyo.

Incluso teniendo en cuenta las limitaciones de tiempo, los recortes y otras cosas que hacen que los expertos en seguridad pierdan el sueño por la noche, si los desarrolladores no introducen los defectos de seguridad comunes desde el principio, esas herramientas (y si se utilizan o no) representan un factor de riesgo mucho menor.

‍