Un CISO de una empresa multimillonaria con la que hablamos recientemente hizo una observación que se me quedó grabada. La capacidad de seguridad que más valoraban no era otra herramienta de detección o framework. Era la velocidad.
Para ellos, la velocidad para identificar problemas, validar correcciones y responder a los cambios era una prioridad. Con tantos frentes abiertos, también sugiere que el tiempo se está convirtiendo en una restricción operativa.
El experto en ciberseguridad Phil Venables sugirió recientemente que los programas de seguridad tendrán cada vez más éxito o fracasarán en función de la velocidad.
“La velocidad lo es todo. Particularmente, cómo los defensores pueden ejecutar su ciclo OODA (observar, orientar, decidir, actuar) más rápido de lo que los atacantes pueden adaptarse”.
Sin embargo, este no es otro artículo sobre “la IA está causando este desorden”; afrontemos la realidad más amplia. En nuestra investigación con 200 CISOs y 200 líderes de ingeniería (incluidos CTOs), el 76% de las organizaciones implementan actualizaciones significativas semanalmente o más rápido, y el 39% lo hace diariamente. Los equipos de ingeniería modernos implementan cambios de forma continua.
Pero la validación de seguridad no opera con esa cadencia; solo el 21% valida la seguridad en cada lanzamiento. Esto es más que una desalineación, es un fallo estructural.
Capas de Ritmo
Venables se refiere al framework de “Capas de Ritmo” de Stewart Brand para explicar cómo evolucionan los sistemas complejos.
“Las capas rápidas aportan novedad y experimentación, y las capas lentas proporcionan estabilidad y memoria.”
La entrega de software es la capa rápida, mientras que la gobernanza y la validación son la capa lenta. Los entornos de software modernos están haciendo que estas capas se separen aún más. Los equipos de ingeniería están aumentando la velocidad a la que operan, mientras que la validación de seguridad sigue funcionando en ciclos trimestrales o anuales.
Los resultados de seguridad llegan después de que el sistema ha cambiado, ¿entonces cuál es el sentido?
Lo que sucede como resultado de este desajuste es inevitable; el 85% afirma que los hallazgos de seguridad están desactualizados cuando llegan los informes al menos a veces, y casi la mitad (48%) de ellos dice que esto ocurre muy a menudo o siempre.
En otras palabras, cuando se revisan los hallazgos de las pruebas, el sistema que describen ya ha cambiado. En efecto, los equipos están tomando decisiones de seguridad basándose en un estado pasado del sistema. Incluso pequeños cambios pueden alterar la postura de seguridad de un sistema. Un nuevo endpoint, un ajuste en la lógica de autorización o una dependencia actualizada pueden abrir nuevas rutas de ataque. El pentesting a menudo valida una versión del sistema que ya no existe.
Como resultado, las correcciones sugeridas y las nuevas pruebas pueden resolver problemas de seguridad antiguos, pero a medida que el software ha evolucionado, los equipos comienzan a perder la confianza en la señal que la prueba les ha proporcionado porque esa señal llega tarde.
El resultado es un poco como la mecánica de tiempo por capas en Origen: diferentes partes del sistema ahora operan a velocidades muy diferentes, y las acciones tomadas demasiado tarde en una capa pueden tener poco efecto en lo que ya se está desarrollando en otra.
La velocidad no debe ir en detrimento de la profundidad.
Para las organizaciones que buscan una postura de seguridad mejorada, la validación requiere razonamiento, exploración, confirmación de exploits y análisis de flujo de trabajo. Debe ser exhaustiva (pero eso ya lo sabías).
“El análisis estático solo puede llegar hasta cierto punto. Si no puedes validar el problema contra la aplicación en ejecución, es solo una hipótesis”, dice Philippe Dourrasov, líder de pentest de IA en Aikido Security.
Por eso, las pruebas de seguridad significativas han requerido históricamente tiempo.
Así, el desafío no es aumentar el número de pruebas, sino preservar la profundidad de las pruebas ofensivas reales mientras se opera a un ritmo mucho más elevado.
Sin embargo, las limitaciones de las pruebas periódicas en cuanto a profundidad son claras. En nuestra investigación, el 51% de los encuestados cree que las vulnerabilidades más profundas, como fallos lógicos, control de acceso roto o rutas de ataque de múltiples pasos, se pasan por alto siempre o con frecuencia.
Esto no se debe a la falta de experiencia de los equipos de seguridad. En cambio, se debe a que los pentesters y los equipos rojos se enfrentan a una serie de limitaciones: pruebas con plazos definidos, sistemas en expansión, complejidad creciente y la interconexión de los sistemas. Pero en su esencia, el dilema entre amplitud y profundidad es realmente un problema de tiempo.
La validación debe seguir a los cambios significativos
Las organizaciones no son ajenas a la creciente disparidad entre la velocidad de entrega y la validación de seguridad. Muchas han intentado cerrar la brecha mediante la realización de más pentests a lo largo del año, el escaneo continuo o la compresión de las interacciones manuales para ajustarse a ciclos de lanzamiento más ajustados. En teoría, estos enfoques aumentan la velocidad. En la práctica, a menudo solo trasladan el compromiso a otro lugar.
El cambio más acertado es alinear la validación con la forma en que el software realmente cambia. Esto no significa pasar a probar todo de forma constante o continua, sino permitir que la validación responda cuando se produce un cambio significativo. En otras palabras, validar los cambios que realmente introducen riesgo. El desafío es que la mayoría de los enfoques de prueba existentes no pueden operar con este nivel de capacidad de respuesta. Los pentests tradicionales tardan días o semanas en programarse, ejecutarse y reportarse. Incluso las interacciones más rápidas no pueden seguir el ritmo de los cambios que ocurren a diario o varias veces al día. Los cambios no son meramente cosméticos, sino cosas como nuevos endpoints de API, cambios en la lógica de autorización, flujos de trabajo de agentes o nuevas integraciones de terceros.
Lo que esto significa operativamente para los equipos de seguridad es que la validación debe formar parte del pipeline de entrega, no un evento acoplado. A su vez, esto cambia el enfoque de probar sistemas completos periódicamente a validar sistemas de forma incremental.
{{cta}}
La necesidad de velocidad
Durante décadas, las organizaciones se han centrado en aumentar la producción: más código, más funcionalidades, más aplicaciones. Aquellos equipos que entregan más rápido obtienen una ventaja competitiva. Venables argumenta que el mismo principio se aplica cada vez más a la seguridad.
Para beneficiarse realmente de la velocidad del desarrollo de software moderno, la seguridad debe avanzar al mismo ritmo. Las organizaciones que pueden detectar problemas, validar correcciones y responder a los cambios más rápido obtienen la ventaja, no solo sobre los atacantes, sino también sobre los competidores que operan en el mismo ámbito. Aquellas que no puedan, se encontrarán cada vez más operando con suposiciones obsoletas sobre sus propios sistemas.
Cuando diferentes capas de un sistema se mueven a velocidades distintas, la seguridad que reacciona demasiado tarde puede estar operando ya en el marco temporal equivocado, muy parecido a lo que ocurre en Origen, donde las acciones tomadas demasiado tarde en una capa tienen poco efecto sobre lo que ya se está desarrollando en otra.
