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

‍

Uno de los muchos dilemas 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 debe repartirse el presupuesto entre herramientas y personas? ¿Qué conjunto de herramientas funcionará mejor con la pila tecnológica existente? Con tantas opciones disponibles, no hay respuestas fáciles, y elegir las opciones equivocadas costará tiempo y dinero más adelante.

Un informe reciente ha revelado que el mercado de herramientas de seguridad de las aplicaciones va a experimentar un crecimiento "explosivo" de aquí a 2025, lo que es un claro indicio de su papel indiscutible en el éxito de las prácticas de DevSecOps y de la creciente importancia del sector frente a los crecientes volúmenes de código con posibles vulnerabilidades de seguridad.

Sin embargo, existe un problema un tanto curioso. Casi la mitad de las organizaciones envían a sabiendas código vulnerable, a pesar de utilizar una serie de herramientas de AppSec diseñadas para impedirlo. En el caso de productos con una innegable demanda de mercado que está ganando una rápida tracción, no tiene mucho sentido. ¿Por qué tantos compran herramientas de seguridad sofisticadas, para luego ignorar sus resultados o no utilizarlas en absoluto? Es un poco como comprar una casa en la playa, sólo 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 no se trata tanto de las herramientas y su funcionalidad, sino de cómo se integran en 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, al santo nirvana que es DevSecOps (hey, por ahora, es lo mejor que tenemos), es inevitable que se compren múltiples escáneres, monitores, cortafuegos y todo tipo de herramientas de AppSec en el camino. Aunque puede parecer que es un caso de "cuanto más, mejor", muy a menudo esto conduce a una pila de tecnología que se asemeja al Monstruo de Frankenstein, con toda la imprevisibilidad que esto implica.

Con presupuestos y recursos de expertos cada vez más limitados para el alcance del trabajo requerido, tratar de deshacer el desorden y encontrar el mejor camino de herramientas hacia adelante es una tarea desalentadora, y el código que necesita ser escaneado y remediado sigue llegando. No es de extrañar que muchas organizaciones hayan tenido que seguir enviando código, aunque es bastante alarmante, y sigue suponiendo un inmenso riesgo para nuestros datos y nuestra privacidad.

Las herramientas de escaneo son lentas, y esto afecta a la agilidad de la publicación.

Lograr la seguridad a toda velocidad es una especie de ballena blanca en el desarrollo de software, y la verdad es que todavía estamos tratando de hacerlo bien, incluso cuando llevamos a las organizaciones a adoptar un enfoque orientado a DevSecOps. La revisión manual y meticulosa del código podría haber funcionado como un mecanismo de seguridad 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 que resulta tan eficaz como preparar un campo de fútbol con unas tijeras para uñas.

Las herramientas de escaneo automatizan el proceso de encontrar problemas potenciales, haciendo esa parte de revisión meticulosa del código por nosotros. El problema es que siguen siendo lentas en el contexto de una cadena de CI/CD que funciona a toda máquina, y ninguna herramienta encuentra todas las vulnerabilidades. También hay un par de problemas evidentes con los resultados que se escupen al equipo de seguridad después de una exploración:

1. Hay muchos 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. A menudo, se revelan demasiadas vulnerabilidades comunes que deberían haberse detectado antes de desplegar el código. ¿Realmente quieres que tus carísimos expertos en seguridad se distraigan de los grandes y espeluznantes problemas de seguridad con las pequeñas cosas?
4. Los escáneres encuentran, no arreglan.

Incluso en una organización que está haciendo todo lo posible para trabajar con las mejores prácticas de ciberseguridad, y se mueve con los tiempos para incluir la seguridad en cada etapa del proceso, el proceso anterior sigue siendo un obstáculo si los escáneres son la principal medida de protección, y demasiados errores comunes hacen que el equipo se tropiece con el despliegue de código seguro. Es lógico que se tomen atajos en este sentido, y eso suele ocurrir cuando se confía en el mínimo de herramientas que no pueden cubrir todos los riesgos potenciales, aunque se haya adquirido un conjunto de soluciones.

Algunas automatizaciones dirigidas por técnicos pueden conducir a una disminución de la calidad del código

La exploración y las pruebas soportan la carga de los procesos automatizados en las herramientas de AppSec, junto con elementos esenciales como los cortafuegos y la supervisión, pero otras herramientas comunes pueden erosionar inadvertidamente los fundamentos prácticos de la seguridad con el paso del 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, protegiendo contra la entrada de código malicioso, los ataques en tiempo real y señalando cualquier comportamiento de ejecución extraño.

Es ciertamente una capa de protección adicional, pero si se piensa en ella como un seguro contra cualquier debilidad potencial en la base de código, los desarrolladores pueden volverse complacientes, especialmente cuando se enfrentan a plazos de salida al mercado cada vez más imposibles para sacar nuevas características. Es posible que no se sigan las prácticas de codificación segura, con la suposición de que la autoprotección en tiempo de ejecución detectará cualquier error. Los desarrolladores no se esfuerzan por crear patrones de codificación inseguros, pero la seguridad a menudo se desprecia en favor de la entrega de características, especialmente con la suposición de una salvaguarda automatizada.

Las herramientas pueden fallar (y en el caso de RASP, a menudo se ejecutan en modo de monitorización para evitar falsos positivos, lo que a su vez solo proporciona visibilidad -no protección- contra un ataque), y cuando eso ocurre, es un código seguro de alta calidad en el que se puede confiar siempre. La concienciación sobre la seguridad en todos los roles que tocan el código es fundamental para DevSecOps, y los desarrolladores que no se formen o produzcan código seguro es un error. El código seguro e inseguro requiere el mismo esfuerzo para escribirlo; es la adquisición de conocimientos para codificar de forma segura lo que requiere la verdadera energía. El tiempo que se dedica a implementar y optimizar el RASP puede aprovecharse mucho mejor en capacitar a los desarrolladores para que no cometan el error en primer lugar.

Equilibrar las herramientas y las personas: no es una bala de plata, pero es lo más cercano que tenemos (por ahora).

El principal espíritu de DevSecOps es hacer de la seguridad una responsabilidad compartida, y para las organizaciones que están creando el software que impulsa nuestras vidas -todo, desde la red eléctrica, hasta los timbres de nuestras puertas-, necesitan incorporar a todos en el viaje para garantizar un mayor nivel de seguridad.

Las herramientas no lo harán todo, y ni siquiera es la forma más barata. Los mejores resultados se consiguen, con mucho, dando prioridad a la formación en seguridad para todos los que tocan el código, trabajando activamente para mantener la seguridad en la mente del equipo de desarrollo y construyendo una cultura de seguridad positiva dirigida por el ser humano, con un conjunto de herramientas que desempeña un papel de apoyo.

Incluso ante 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 defectos de seguridad comunes en primer lugar, entonces esas herramientas (y si se utilizan o no) representan un factor de riesgo mucho menor.

‍