La era de los parches ya va a velocidad de máquina y los ciclos trimestrales han muerto

¿Qué pasa cuando encontrar un error sale más barato que corregirlo? Acabamos de verlo en directo, y no fue bonito. Varios gobiernos desconectaron sus webs y quienes mantienen las tuberías de internet pasaron la semana en modo triaje.

En resumen: dos fallos críticos en PHP, que según apunta la AFP funciona en buena parte de los sitios web del mundo, se descubrieron con modelos de IA. Según informa L'Express, webs gubernamentales de Europa y de otros lugares quedaron fuera de línea por precaución mientras los responsables corrían a aplicar el parche. Dos empresas de seguridad, Calif y Wiz, afirmaron haber encontrado los errores de forma independiente, y Wiz dijo que usó modelos de OpenAI y Google. Los fallos llevaban años en el código.

Para nosotros, los fallos en sí importan menos que lo que revelan. El descubrimiento ya va a velocidad de máquina. La mayoría de las organizaciones sigue parcheando a velocidad humana.

Lo que asusta no es el error, sino el reloj

Michael Daniel, presidente de la Cyber Threat Alliance y antiguo coordinador de ciberseguridad de la Casa Blanca, le dio a la AFP la cifra que más se nos quedó grabada. Antes pasaban uno o dos meses hasta que aparecía una prueba de concepto, y otro mes o dos hasta que llegaba a los kits de explotación. Ahora, dice, se mide en horas o días.

Pensad en lo que eso supone para un ciclo de parches trimestral. Si el plazo entre que se hace público un fallo y que los atacantes lo usan se reduce a horas o días, un proceso basado en ventanas de mantenimiento mensuales es, a nuestro juicio, una decisión de quedarse expuesto. La investigación de Reuters resumida por Distributique señala que, según datos de VulnCheck, el número de vulnerabilidades descubiertas se duplica en un año. Duplicar el volumen de entrada mientras la ventana de respuesta se desploma es una presión que probablemente no se resuelva contratando a más gente.

Eso sí, hay que ser justos con los matices. Daniel recuerda que históricamente solo se ha explotado entre un cinco y un seis por ciento de las vulnerabilidades, y nada indica que esa proporción esté subiendo. Sobre este fallo concreto, las informaciones se contradicen. Los investigadores citados por Distributique decían que, cuando se publicó la investigación de Reuters, no se había confirmado ningún exploit funcional. L'Express, por su parte, cuenta que las tecnológicas advirtieron de que algunos hackers ya estaban explotando los fallos. Desde aquí no podemos zanjarlo. Nuestra lectura es que, ante todo, es un problema de velocidad, y que decir que internet ya arde es exagerar. Encogerse de hombros sería peor.

«Probarlo todo durante semanas» era un lujo, no una política

La idea más incómoda de la entrevista de Daniel tiene que ver con la tolerancia al riesgo. La mayoría de las empresas aplicaba lo que él llama tolerancia cero a que algo se rompiera, así que probaba los parches de forma exhaustiva. Sostiene que ya no tienen ese tiempo. Si un parche tiene un uno por ciento de probabilidades de romper algo, pero un ataque podría costar 50 millones de dólares, la balanza cambia.

Creemos que tiene razón, aunque a muchos departamentos de informática no les guste oírlo. Parchear despacio y con cuidado era racional cuando la explotación era lenta. Ahora el coste de esperar es el mayor riesgo. En la práctica, se traduce en tres tareas poco vistosas. Primero, un inventario fiable de lo que usas y de qué parte da a internet. Segundo, vías automatizadas de prueba y despliegue que permitan sacar una corrección rápido. Tercero, mitigaciones temporales para cuando un parche no pueda salir de inmediato. Es más o menos la lista que plantea el artículo de Distributique, y nada de eso requiere IA. Requiere disciplina, que es más difícil.

Las pequeñas organizaciones son las grandes perjudicadas. El consejo de Daniel para ellas es directo: reorganizarse para poder aceptar las actualizaciones del proveedor lo más rápido posible. Para quien use una plataforma gestionada, eso significa sobre todo elegir proveedores por la rapidez con que parchean.

La deuda técnica es la verdadera historia, y la IA es quien viene a cobrarla

Daniel habla de que «la deuda técnica vence». El coste implícito de mantener software antiguo no aparece en los libros hasta que ocurre un episodio como este. Rob Joyce, antiguo director de ciberseguridad de la NSA, lo ha llamado «el gran incendio forestal purificador del software antiguo». Las dos imágenes nos convencen.

Hay también una lectura esperanzadora. Daniel espera que las herramientas de IA se apliquen al software antes de desplegarlo, de modo que el código nuevo nazca con menos agujeros. Jason Clinton, directivo de seguridad de Anthropic, escribió en X que las cosas empeorarán mucho antes de mejorar y que hay que aguantar unos 18 meses, según 01net. Es un pronóstico, no un hecho, y viene de una empresa que construye estos modelos. Aun así, la lógica es plausible: con el tiempo, los defensores tendrán las mismas herramientas.

Otra cautela es el ruido. Daniel admite sin rodeos que muchos hallazgos comunicados por IA son falsas alarmas o están en software que nunca se expone a internet. El cuello de botella parece ser el triaje, no el descubrimiento.

Nuestro veredicto

Dejad de verlo como una historia de PHP. Tomadlo como una prueba de resistencia de vuestro proceso de parcheo y preguntaos con sinceridad cuánto habríais tardado esta semana en aplicar una corrección crítica. Si la respuesta es «semanas», ese es el proyecto del próximo trimestre, no del próximo ciclo de parches. Haced inventario de lo que usáis, automatizad el despliegue, aceptad un pequeño riesgo de que algo falle y retirad el software que mantenéis vivo por pura inercia. La riada que describe Daniel llegará de todos modos. Lo único que se puede decidir es si habéis construido un aliviadero.