El apocalipsis de las brechas ya está aquí

Siete incidentes en siete días

La semana pasada envié una lista a nuestro equipo directivo. En siete días, el equipo interno de SecOps de Sophos respondió a siete incidentes: el uso indebido de uno de nuestros productos a través de una cuenta de prueba, el ataque a ConnectWise Cloud Backup, PHP2Shell, las SubCA débiles de eMudhra, el segundo ataque a la cadena de suministro de LiteLLM este año, vulnerabilidades críticas de Node.js y un RCE en GitLab. Hace un año, eso habría sido lo normal en todo un trimestre.

Hemos evitado un impacto grave, pero solo gracias a un esfuerzo conjunto y a muchas horas de trabajo. Es cierto que se trata de un solo caso, pero desde mi posición como responsable de proteger a un proveedor líder en ciberseguridad, la tendencia parece bastante clara.

«Entonces, ¿dónde está el impacto?»

El contraargumento es que el daño no se está haciendo evidente. PHP2Shell, hasta ahora, no se ha convertido en el evento de explotación masiva para el que muchos nos preparábamos. No ha habido ningún «desastre del Challenger», la expresión de Simon Willison para referirse al suceso mediático que pone fin a nuestra normalización de la desviación. Tal Be’ery descubrió que las notificaciones de incidentes importantes a la SEC solo aumentaron ligeramente en el segundo y tercer trimestre de 2026, mientras que las CVE de gravedad alta y crítica se multiplicaron varias veces.

Me lo tomo muy en serio. Pero siempre se nos ha dado mal medir una marea creciente hasta mucho después de que haya subido. En 2012, el difunto Ross Anderson y sus colegas contabilizaron más de 100 fuentes de datos sobre ciberdelincuencia, todas ellas «insuficientes y fragmentadas». Investigadores de Microsoft demostraron que un solo encuestado que declarara pérdidas de 50 000 dólares podía generar una estimación nacional de 10 000 millones de dólares. Solo fue hasta 2019 cuando el equipo de Anderson pudo confirmar lo que ya habían intuido en 2012: la ciberdelincuencia representaba aproximadamente la mitad de toda la delincuencia. Dan Geer señaló que entre el 70 % y el 80 % de las filtraciones las detectan terceros, por lo que es posible que muchas víctimas nunca se enteren.

La salud pública ofrece un paralelismo muy similar. Entre 1999 y 2017, la tasa de mortalidad por sobredosis de drogas en EE. UU. se triplicó con creces, alcanzando 70 237 muertes al año. Esa cifra se acumuló a partir de miles de muertes individuales, cada una de ellas registrada por un forense local, sin que se produjera ningún desastre concreto que la marcara. Estados Unidos no declaró una emergencia de salud pública hasta octubre de 2017, y aun así las cifras no eran exactas: las muertes por opioides se subestimaron entre un 20 % y un 35 % porque los certificados de defunción a menudo omitían la droga. Un accidente aéreo se contabiliza al caer la noche. Una oleada creciente de pequeños incidentes se contabiliza años después, y de forma deficiente. El daño cibernético reciente se ha producido de la misma manera: un flujo creciente de incidentes menores, sin ningún megaincidente que contabilizar.

También hay que tener en cuenta algunas medidas de mitigación que se han conseguido con mucho esfuerzo. Los proveedores, los responsables de mantenimiento y los equipos de seguridad han aplicado parches a un ritmo que nunca había visto; solo Mozilla corregió 271 errores de Firefox gracias a una iniciativa asistida por IA, y el propio equipo de ingeniería de Sophos ha estado trabajando a toda máquina en los errores que han surgido a raíz de nuestra participación en Glasswing y Daybreak. Pero eso no se aplica por debajo del umbral de pobreza en materia de seguridad: las organizaciones que carecen del dinero, la experiencia y la capacidad para protegerse. Estas entidades no presentan informes 8-K ni contratan servicios de respuesta a incidentes (IR). El grupo más expuesto es también el que peor valoramos.

Las señales de las que disponemos

Las señales operativas llegan mucho antes que las mediciones formales. El 19 de octubre, el exdirector de ciberseguridad de la NSA, Rob Joyce, escribió que «las empresas de respuesta a incidentes están saturadas y rechazan trabajo». Eso coincide con lo que vemos: nuestra propia función de respuesta a incidentes (IR) nunca ha estado tan ocupada y prevé una crisis de capacidad en todo el sector.

Del mismo modo, Google Threat Intelligence informó de 141 vulnerabilidades explotadas entre enero y agosto de 2026, frente a las 127 de todo el año 2025, y la investigación de Anthropic muestra que el patrón de ataque autónomo que documentó en 2025 «se ha extendido ahora a todas las clases de actores que investigamos».

También hay una asimetría en la notificación. Descubrir vulnerabilidades llama mucho la atención: los investigadores y los laboratorios de IA publican cifras, como los más de 10 000 hallazgos de gravedad alta o crítica en un mes del Proyecto Glasswing. Los incidentes pasan desapercibidos. En la encuesta de Bitdefender de 2026, al 55 % de los profesionales que habían sufrido una filtración se les pidió que mantuvieran la confidencialidad cuando creían que deberían haberla notificado. La gente presume de encontrar fallos. Nadie presume de haber sufrido una filtración.

La frontera también es irregular para los atacantes

La capacidad de la IA es una frontera irregular: potente en algunas tareas, sorprendentemente débil en otras similares. Ni los defensores ni los adversarios han ampliado al máximo su uso. Will Lyne y Jamie MacColl, del RUSI, sostienen que la IA «no está (todavía) reinventando fundamentalmente la ciberdelincuencia», porque los delincuentes solo cambian de modelo de negocio cuando los beneficios les obligan a ello. Be’ery plantea un argumento similar: la monetización y el blanqueo, no las vulnerabilidades, son el cuello de botella.

Ambas opiniones son plausibles. Una visión menos cómoda es que la limitación principal es el número de delincuentes con capacidad, y la IA es precisamente una forma de ampliar ese número de personas.

La investigación de Sophos X-Ops muestra que estamos en la fase de adopción temprana. Al monitorizar foros clandestinos, encontramos una clara brecha de conocimientos: delincuentes que compran claves API a intermediarios y se piden ayuda entre ellos para la configuración básica. Tras un año de análisis de casos de MDR, descubrimos que, cuando los atacantes usaban IA, lo hacían «como asistente, con un humano al mando». La adopción observada va por detrás de la capacidad disponible. Esa brecha marca el inicio de una curva, y la capacidad ya estará lista cuando alguien encuentre el modelo de negocio.

¿Qué hacer al respecto?

Empieza por la junta directiva. Lo más útil que un responsable de seguridad puede conseguir ahora es que se acepte asumir cierto riesgo en otros ámbitos: legal, normativo, contractual o financiero. Eso significa tolerar algunas interrupciones, como la desconexión de un servicio o la aplicación de un parche antes de haberlo probado a fondo, para evitar un incidente mucho mayor. La cobertura mediática generalizada de las amenazas de la IA suele ser alarmista y, a veces, inexacta, pero ha hecho que las juntas directivas y los directores generales estén más receptivos de lo habitual. Aprovecha esa atención para conseguir un mandato; sin él, los pasos que vienen a continuación se estancan.

1. Reduce la superficie de ataque. Elimina los servicios expuestos a Internet que no sean imprescindibles. Coloca el resto detrás de una VPN, ZTNA o un proxy de autenticación, para que un exploit sin autenticar no pueda alcanzarlos. Considera también la identidad como superficie de ataque; la autenticación resistente al phishing es el equivalente para las cuentas (consulta nuestra guía de claves de acceso).
2. Elimina a las personas del proceso de aplicación de parches. Nuestro informe «AI Security 2026» reveló que el plazo entre la divulgación y la explotación se ha reducido a unas pocas horas: Ivanti Sentry (CVE-2026-10520) fue explotado en menos de 24 horas tras una prueba de concepto pública, y LiteLLM (CVE-2026-42208) en menos de 36. La CISA ha reducido a tres días el plazo obligatorio para aplicar parches a los fallos de mayor riesgo en las agencias federales. Incluso en los entornos más sensibles al tiempo de actividad, un parche defectuoso del proveedor suele ser el riesgo menor. Se revierte en cuestión de horas; recuperarse de un incidente lleva semanas. Activa las actualizaciones automáticas siempre que los proveedores las ofrezcan y usa agentes para probar y preparar el resto.
3. No pierdas de vista las alertas. Los ataques autónomos son, hasta ahora, ruidosos y lentos contra objetivos razonablemente protegidos. Microsoft observó que una campaña impulsada por IA alcanzó un pico de 2900 intentos fallidos de inicio de sesión por minuto. Reuters informó de que un hacker que utilizaba agentes de IA contra más de 1200 sitios web solía necesitar unas 23 horas por cada intrusión exitosa. Esto supone una oportunidad para las organizaciones que cuentan con una capacidad de respuesta real. Para las que no la tienen, el MDR es la forma más rápida de conseguirla.
4. Utiliza tú mismo la IA. Esto es lo más importante. Un equipo de seguridad sin IA de vanguardia y sin un presupuesto decente para tokens está luchando con una mano atada a la espalda.

Por dónde empezar

A veces, lo más difícil es dar el primer paso. Aquí tienes algunas ideas con las que hemos tenido éxito:

• Brechas en los endpoints. Dale a un agente tus fuentes de inventario de activos, el organigrama y la consola de gestión de endpoints. Pídele que encuentre dispositivos desprotegidos o mal configurados, incluidas las excepciones caducadas, ordenados por nivel de riesgo.
• Exposición del perímetro. Combina esos mismos datos de activos con los resultados de tus análisis de vulnerabilidades y dale su propia cuenta nueva de AWS con el encargo de encontrar servicios perimetrales de riesgo, poniendo en marcha instancias EC2 según sea necesario para sondear, validar y priorizar los hallazgos.
• Correcciones estancadas. Dirige a un agente hacia tu control de código fuente, sistema de tickets, documentación, herramientas de seguridad de productos existentes, organigrama, bandeja de entrada y chat. Pídele que saque a la luz los problemas sin resolver por equipo, con un historial de las comunicaciones anteriores.
• Desviaciones en el registro de riesgos. Haz que un agente revise tu bandeja de entrada, tus chats y las grabaciones de reuniones recientes, y que destaque cualquier riesgo discutido que no se corresponda claramente con el registro de riesgos de la junta directiva.

Al escribir sobre OpenClaw en febrero, dije: «Al igual que con cualquier adopción tecnológica, la gestión pragmática del riesgo es clave. Y, por suerte, todos llevamos mucho tiempo haciéndolo». Eso también se aplica aquí. No hay nada gratis: cada paso anterior cambia un riesgo por otro, ya sea un parche defectuoso, un cliente insatisfecho o un agente con más acceso del que parece adecuado. La gestión de riesgos es fácil cuando los datos están claros. Un buen liderazgo requiere actuar basándote en tu criterio mientras la información aún es incompleta. Para cuando el «apocalipsis de las brechas» sea fácil de medir, ya será demasiado tarde.