Dentro de su empresa hay dos relojes corriendo a la vez y solo uno está a la vista. El primero arranca cuando un fabricante publica un fallo y alguien de su equipo abre el ticket. El segundo arranca cuando otra persona, en cualquier parte del mundo, termina de escribir el código que aprovecha ese mismo fallo. Durante años los dos relojes corrían más o menos parejos. Este año dejaron de hacerlo.
El informe de brechas de Verizon correspondiente a 2026 dejó una cifra que conviene leer despacio: la explotación de vulnerabilidades es hoy la vía de entrada número uno, con el 31% de las brechas. Es la primera vez en diecinueve ediciones del informe que las credenciales robadas pierden ese primer lugar. En el mismo periodo, el tiempo mediano para aplicar un parche subió de 32 a 43 días.
¿Qué significan de verdad esos 43 días?
Mediana no es promedio. Que la mediana sea de 43 días quiere decir que la mitad de las organizaciones tarda todavía más, y que en esa mitad hay empresas con equipos, presupuesto y herramientas. No es un problema de negligencia. Es un problema de física operativa: la cantidad de fallos publicados cada mes crece, el inventario de lo que hay que parchear crece, y las ventanas de mantenimiento siguen siendo las mismas dos madrugadas al mes de siempre. Quien quiera el marco completo del proceso puede ver antes qué es la gestión de vulnerabilidades; aquí voy directo a por qué se atasca.
Hay un segundo dato del mismo informe que en mi opinión es más incómodo que el primero. De las vulnerabilidades del catálogo de fallos explotados activamente de CISA, es decir de las que se sabe con certeza que alguien está usando ahora mismo contra alguien, la proporción que las organizaciones remedian por completo cayó del 38% al 26%. Ese catálogo es la lista corta. Si la lista corta se está cumpliendo a un cuarto, el problema no es de priorización fina, es de capacidad.
La ventana de exposición no es un solo número
Cuando en un comité se habla de “días para parchear” casi siempre se está midiendo un tramo del recorrido y no el recorrido completo. En la práctica el reloj se parte en cuatro tramos, y cada uno se pierde por motivos distintos.
1. Del aviso al enterarse. El fabricante publica. Su equipo se entera por un boletín, por el proveedor o por el escáner en la siguiente corrida. Aquí se van días enteros según cada cuánto corra el escaneo y quién lea los avisos.
2. De enterarse a saber si le toca. ¿Tiene ese producto? ¿En qué versión? ¿Expuesto a internet o interno? Este tramo se alarga cuando el inventario no es confiable, que es casi siempre.
3. De saber a poder. Aparece el dueño del sistema, aparece el cambio, aparece la ventana. Si el activo es crítico y no tiene alta disponibilidad, el parche espera al fin de semana. A veces al fin de mes.
4. De aplicar a verificar. El tramo que más se olvida. Un parche aplicado y no verificado, o aplicado en 80 de 100 equipos, deja el hueco abierto igual y además tranquiliza al comité, que es peor.
¿Por qué se tarda más ahora si hay más herramientas que nunca?
Porque casi todo lo que se sumó en los últimos años ayuda en el tramo 1 y en el tramo 2, que son los baratos, y no toca los tramos 3 y 4, que son los caros. Un escáner nuevo le va a dar más hallazgos, no más ventanas de mantenimiento.
A eso se le suma dónde está pegando el atacante. Los equipos de borde, los concentradores de VPN, los firewalls perimetrales y los portales de acceso remoto son justamente los que no admiten agente, los que no se pueden reiniciar en horario laboral y los que a veces administra un tercero. Es el peor cruce posible: lo más expuesto es también lo más lento de tocar. Si su empresa vive con proveedores administrando parte de esa infraestructura, ese acuerdo debería tener un tiempo de respuesta escrito, porque hoy probablemente no lo tenga.
¿Cómo se recorta la ventana sin romper producción?
No conozco ninguna empresa que haya bajado su tiempo de parcheo comprando algo. Las que lo bajaron cambiaron reglas de operación. Estas son las que más veces he visto funcionar.
Seis decisiones que sí mueven la aguja
- Separe el catálogo de CISA del resto. Todo lo que esté en esa lista y exista en su red se trata como incidente, no como ticket de mantenimiento. Con su propio plazo y su propio escalamiento.
- Ponga plazo por exposición, no por severidad. Un fallo de severidad media en un servicio publicado a internet es más urgente que uno crítico en un sistema interno sin salida. El CVSS solo no ordena la cola.
- Deje de negociar la ventana caso por caso. Ventanas fijas, calendarizadas y aprobadas una vez al año. Cada negociación individual cuesta días.
- Nombre dueño por activo, no por equipo. Si el dueño es “infraestructura”, el parche no tiene dueño. Si es una persona con nombre, sí.
- Mida el tramo 4 y publíquelo. Porcentaje de cobertura verificada del parche, no cantidad de parches aplicados. Son dos números muy distintos y el segundo se ve mejor de lo que es.
- Revise el borde aparte. Concentradores de VPN, firewalls y portales remotos con inventario propio, responsable propio y plazo propio, más corto que el del resto.
Ninguna de las seis cuesta dinero. Todas cuestan discusiones, que en la práctica es lo que de verdad escasea.
¿Y cuando el parche simplemente no puede salir a tiempo?
Va a pasar. Hay sistemas que no se pueden tocar, fabricantes que tardan en liberar el arreglo y aplicaciones que se rompen con la actualización. Cuando eso ocurre, el trabajo cambia de naturaleza: ya no se trata de cerrar el hueco, se trata de que usarlo no salga gratis.
Ahí entran las medidas de contención que se pueden aplicar en horas: reglas de bloqueo en el perímetro, segmentación del activo, restricción de quién puede llegarle, y control reforzado en el endpoint. Una plataforma de EDR bien afinada no cierra la vulnerabilidad, pero convierte la explotación silenciosa en una explotación ruidosa. Es exactamente el mismo razonamiento que aplicamos con el ransomware: si no puede impedir la entrada, asegúrese de que la entrada haga ruido.
Y ese ruido alguien lo tiene que estar escuchando a las tres de la mañana de un sábado, que es cuando suele pasar. Un SOC operando 24/7 no reemplaza al parcheo ni pretende hacerlo. Lo que hace es comprarle a su empresa el margen que hoy le está costando 43 días conseguir por la vía formal.
Si quiere saber en qué tramo se le están yendo los días, empiece por medir los cuatro por separado durante un mes. La respuesta casi nunca está donde uno cree.
El parche espera a la ventana de mantenimiento. El exploit no espera a nada.
