No vamos a ganar la carrera del parcheo, y por qué eso cambia la estrategia

El 14 de julio, Microsoft cerró su Patch Tuesday más grande hasta la fecha: 622 vulnerabilidades corregidas de una sola vez. Para dimensionarlo, todo el año 2025 sumó 1,273 según el reporte anual de vulnerabilidades de BeyondTrust. Un solo martes nos trajo casi la mitad de lo que normalmente vemos en doce meses.

No fue un accidente ni un mes raro. Cinco días antes, Microsoft ya lo había avisado: la IA le está permitiendo encontrar vulnerabilidades más rápido y en más código, y los ciclos de aquí en adelante van a ser más grandes. Lo dijo con todas las letras.

La reacción instintiva de cualquiera en mi lugar es pensar en cómo parchear más rápido. Yo llegué a la conclusión contraria, y de eso quiero escribir.

Parchear más rápido no es la salida

Un parche no se aplica con un clic. Se valida. Se prueba contra lo que ya está en producción, se agenda en una ventana de cambio, se coordina con las áreas que dependen de esos servicios y se prepara la marcha atrás por si algo se rompe. Ese proceso no es burocracia inútil: es lo que evita que la cura sea peor que la enfermedad.

El problema es que del otro lado la velocidad se disparó. En junio, el equipo de investigación de Anthropic hizo un ejercicio que me dejó pensando: tomaron 18 parches recientes de Firefox y midieron cuánto tardaba su modelo en convertir cada uno en un ataque funcional. El primero estuvo listo en menos de una hora. La versión corregida de Firefox que los usuarios íbamos a recibir todavía estaba a 18 días de publicarse.

Vale la pena detenerse en eso. El atacante puede tener el exploit funcionando mientras nosotros seguimos en la ventana de prueba. Y eligieron Firefox justamente porque es de lo que más rápido se parchea; lo que corre dentro de la mayoría de las empresas está mucho peor parado.

Ahí está la trampa. La industria nos empuja a competir en velocidad de parcheo, una carrera que ya perdimos. Tumbar producción para ganarle al exploit no es seguridad: es un incidente de disponibilidad que nos provocamos nosotros mismos.

Con un matiz que no quiero saltarme, porque cambia la conversación: no todo se parchea igual. Lo que da a internet —el firewall, la VPN, el portal, el servidor de correo— sí exige cadencia de emergencia, porque el atacante llega desde su casa sin necesitar nada más. Para eso vale correr. El parque interno es donde la validación controlada sigue teniendo sentido. Meter todo en la misma bolsa es el error que más veo.

Asumir que nos van a comprometer

Si aceptamos que no vamos a cerrar la ventana a tiempo, la pregunta deja de ser «¿estamos parchados?» y pasa a ser otra: ¿cuánto tiempo puede alguien moverse dentro de mi red sin que yo lo note?

Esa es, para mí, la postura correcta en 2026, y no es resignación. Es donde el dinero rinde. El estudio anual de IBM y el Ponemon Institute lo mide: las organizaciones que usan IA y automatización de forma extensiva detectan y contienen una brecha en promedio 80 días antes que las que no. Ochenta días es la diferencia entre un susto contenido y una crisis de portada.

Y no soy solo yo. En el mismo informe donde reporta el aluvión de vulnerabilidades, Microsoft dice algo parecido: la defensa que funciona no es únicamente parchear rápido, sino asumir que habrá brechas y construir capas que detecten lo anómalo. Es la misma tesis, firmada por el fabricante cuyos parches acabamos de comentar.

El regreso del SIEM, esta vez con sentido

Para mí, asumir el compromiso significa el resurgimiento del SIEM. Pero quiero ser preciso, porque la palabra arrastra malos recuerdos y presupuestos que no rindieron.

Lo que vuelve no es el SIEM de hace diez años, con su motor de reglas escritas a mano que nadie actualiza. Lo que vuelve es la idea de fondo: juntar toda la telemetría en un lugar y poder investigarla. Lo nuevo es que ahora hay IA capaz de analizar ese volumen a una velocidad que ningún analista humano alcanza, y sin que alguien haya tenido que anticipar la pregunta exacta años atrás.

¿Hacia dónde apunto esa capacidad? A la identidad, por dos razones que suelo ver mezcladas y prefiero separar.

La primera es de tiempo. La detección en el endpoint se activa cuando el ataque ya está ejecutándose, y cuando el exploit corre en minutos esa señal llega tarde. Un inicio de sesión imposible, un permiso de OAuth extraño o una cuenta dormida que de pronto revive son señales que aparecen antes.

La segunda es más incómoda: hay que dar por hecho que el EDR puede ser evadido. Existen técnicas conocidas y bien documentadas para cegar al agente en un equipo comprometido. Pero acá está el punto que lo cambia todo: la telemetría de identidad no vive en ese equipo, vive en la nube y en el proveedor de identidad. El atacante que apagó mi agente en un host sigue dejando rastro cuando usa la credencial robada, pide un token o intenta saltar a otro sistema. No puede apagar lo que no toca.

El propio ciclo de julio me dio el ejemplo perfecto. De los 622, los dos que ya estaban siendo explotados en la calle no eran ejecuciones remotas espectaculares. Eran fallas de privilegios en SharePoint y en AD FS, el servidor que emite los tokens de autenticación de todo lo demás. El ataque entró por la identidad.

Nada de esto significa botar el EDR. Significa que deje de ser lo único, y que la identidad pase al centro.

Para las empresas de la región que ya trabajan sobre Microsoft 365, la buena noticia es que casi toda esta arquitectura ya está pagada o facílmente disponible: Defender for Identity, la protección de identidad de Entra, el acceso condicional, Sentinel como repositorio y capa de análisis. En la mayoría de los diagnósticos que hacemos, el problema no es comprar; es que lo que ya se compró está apagado o a medio configurar.

Detectar no alcanza si no se contiene

Cierro con lo que suele quedar afuera. Detectar rápido y después esperar a que un comité apruebe la respuesta es entregar malas noticias más rápido, nada más. Si el atacante se mueve en horas, la contención tiene que estar decidida de antemano: qué acciones pueden ejecutarse solas, con qué límites y con qué botón de reversa, firmado antes por la dirección y por el área legal. Bloquear una IP, aislar un equipo, revocar un token: cosas acotadas y reversibles.

La velocidad del atacante no va a bajar para acomodarse a nuestros procesos. La jugada no es correr más; es cambiar dónde jugamos: menos apuesta al parche heroico, más a la detección temprana y a la respuesta ya decidida.

En GFS InfoSec ayudamos a organizaciones en Panamá y la región a poner a trabajar las capacidades de seguridad que ya tienen licenciadas en Microsoft 365. Si quiere saber en qué estado real está su detección en la capa de identidad, escríbanos y lo revisamos juntos.