Un director de seguridad de la información (CISO) de una empresa multimillonaria con el que hablamos recientemente hizo un comentario que se me quedó grabado. La capacidad de seguridad que más valoraban no era otra herramienta de detección ni otro marco de trabajo. Era la rapidez.
Para ellos, la rapidez a la hora de detectar problemas, validar soluciones y responder a los cambios era una prioridad. Con tantos incendios que apagar, esto también sugiere que el tiempo se está convirtiendo en una limitación operativa.
El experto en ciberseguridad Phil Venables ha señalado recientemente que el éxito o el fracaso de los programas de seguridad dependerá cada vez más de la rapidez.
«La velocidad lo es todo. En concreto, se trata de que los defensores puedan completar su ciclo OODA (observar, orientarse, decidir, actuar) más rápido de lo que tardan los atacantes en adaptarse».
Sin embargo, este no es otro artículo del tipo «la IA es la culpable de este desastre»: afrontemos la realidad en su conjunto. Según nuestro estudio, en el que participaron 200 responsables de seguridad de la información (CISO) y 200 responsables de ingeniería (incluidos los directores técnicos), el 76 % de las organizaciones implementa actualizaciones importantes cada semana o con mayor frecuencia, y el 39 % lo hace a diario. Los equipos de ingeniería modernos implementan cambios de forma continua.
Pero la validación de la seguridad no sigue ese ritmo; solo el 21 % comprueba la seguridad en cada lanzamiento. Esto es más que una falta de coordinación, es un fallo estructural.
Capas de ritmo
Venables recurre al marco conceptual delas «capas de ritmo»de Stewart Brand para explicar cómo evolucionan los sistemas complejos.
«Las capas rápidas aportan novedad y experimentación, mientras que las capas lentas proporcionan estabilidad y memoria».
La entrega de software constituye la capa rápida, mientras que la gobernanza y la validación forman la capa lenta. Los entornos de software modernos están provocando que estas capas se distancien aún más. Los equipos de ingeniería están aumentando el ritmo al que operan, mientras que la validación de la seguridad sigue funcionando en ciclos trimestrales o anuales.
Los resultados de seguridad llegan cuando el sistema ya ha cambiado, así que, ¿para qué sirven?
Las consecuencias de este desajuste son inevitables: el 85 % afirma que, al menos en algunas ocasiones, los hallazgos de seguridad ya están desactualizados cuando llegan los informes, y casi la mitad (48 %) de ellos señala que esto ocurre muy a menudo o siempre.
En otras palabras, para cuando se revisan los resultados de las pruebas, el sistema que describen ya ha cambiado. En la práctica, los equipos están tomando decisiones de seguridad basadas en un estado anterior del sistema. Incluso los cambios más pequeños pueden alterar la postura de seguridad de un sistema. Un nuevo punto final, un pequeño ajuste en la lógica de autorización o una dependencia actualizada pueden abrir vías de ataque completamente nuevas. A menudo, las pruebas de penetración validan una versión del sistema que ya no existe.
En consecuencia, es posible que las soluciones propuestas y las nuevas pruebas logren detectar problemas de seguridad antiguos, pero, dado que el software ha evolucionado, los equipos empiezan a perder confianza en la información que les ha proporcionado la prueba, ya que esa información llega con retraso.
El resultado se parece un poco a la mecánica temporal por capas de «Origen»: ahora, las distintas partes del sistema funcionan a velocidades muy diferentes, y las acciones que se llevan a cabo demasiado tarde en una capa pueden tener poco efecto sobre lo que ya se está desarrollando en otra.
La rapidez no debería ir en detrimento de la profundidad
Para las organizaciones que buscan mejorar su nivel de seguridad, la validación requiere razonamiento, investigación, confirmación de vulnerabilidades y análisis de los flujos de trabajo. Debe ser exhaustiva (pero eso ya lo sabías).
«El análisis estático tiene sus límites. Si no se puede validar el problema con la aplicación en ejecución, no pasa de ser una hipótesis», afirma Philippe Dourrasov, responsable de pruebas de penetración con IA en Aikido Security.
Por eso, las pruebas de seguridad rigurosas siempre han llevado tiempo.
Por lo tanto, el reto no consiste en aumentar el número de pruebas, sino en mantener la profundidad de las pruebas ofensivas reales al tiempo que se trabaja a un ritmo mucho más acelerado.
Sin embargo, las limitaciones de las pruebas periódicas en cuanto a profundidad son evidentes. Según nuestro estudio, el 51 % de los encuestados considera que las vulnerabilidades más complejas, como los fallos lógicos, los controles de acceso defectuosos o las vías de ataque de varios pasos, pasan desapercibidas siempre o con frecuencia.
Esto no se debe a que los equipos de seguridad carezcan de experiencia. Más bien se debe a que los pentesters y los equipos rojos se enfrentan a una serie de limitaciones: pruebas con plazos fijos, sistemas en expansión, una complejidad cada vez mayor y la interconexión de los sistemas. Pero, en el fondo, el dilema entre amplitud y profundidad es, en realidad, un problema de tiempo.
La validación debe ir precedida de un cambio significativo
Las organizaciones no ignoran el creciente desajuste entre la velocidad de entrega y la validación de la seguridad. Muchas han intentado reducir esta brecha realizando más pruebas de penetración a lo largo del año, llevando a cabo análisis continuos o reduciendo los proyectos manuales para adaptarlos a ciclos de lanzamiento más ajustados. En teoría, estos enfoques aumentan la velocidad. En la práctica, a menudo solo trasladan el riesgo a otro lugar.
El cambio más acertado consiste en adaptar la validación a la forma en que el software evoluciona realmente. Esto no significa, en realidad, pasar a probarlo todo de forma constante o continua, sino permitir que la validación reaccione cuando se produce un cambio significativo. En otras palabras, validar los cambios que realmente introducen riesgos. El reto es que la mayoría de los enfoques de pruebas existentes no pueden operar con este nivel de capacidad de respuesta. Las pruebas de penetración tradicionales tardan días o semanas en programarse, ejecutarse y generar informes. Ni siquiera los proyectos más rápidos pueden, de forma realista, seguir el ritmo de los cambios que se producen a diario o varias veces al día. Los cambios no son meramente cosméticos, sino cosas como nuevos puntos finales de API, cambios en la lógica de autorización, flujos de trabajo de agentes o nuevas integraciones de terceros.
En la práctica, esto significa para los equipos de seguridad que la validación debe integrarse en el proceso de entrega, y no ser un paso añadido a posteriori. A su vez, esto supone pasar de realizar pruebas periódicas de sistemas completos a validar los 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 funciones, más aplicaciones. Los equipos que lanzan sus productos más rápido obtienen una ventaja competitiva. Venables sostiene que este mismo principio se aplica cada vez más al ámbito de la seguridad.
Para aprovechar realmente la rapidez del desarrollo de software moderno, la seguridad debe avanzar al mismo ritmo. Las organizaciones que sean capaces de detectar problemas, validar soluciones y responder a los cambios con mayor rapidez obtendrán una ventaja, no solo frente a los atacantes, sino también frente a los competidores que operan en el mismo sector. Las que no puedan hacerlo se verán cada vez más obligadas a actuar basándose en supuestos obsoletos sobre sus propios sistemas.
Cuando las distintas capas de un sistema se mueven a velocidades diferentes, un sistema de seguridad que reacciona demasiado tarde puede estar actuando ya en el momento equivocado, al igual que en «Origen», donde las medidas tomadas demasiado tarde en una capa tienen poco efecto sobre lo que ya está sucediendo en otra.
