Blog:
Por  Jeremy Nelson / 7 Jul 2026 / Temas: Cybersecurity
Hace unas semanas, estaba en plena reunión cuando mi portátil decidió que ya había esperado bastante. Había pospuesto la misma actualización de parches una vez de más y, justo en ese momento, a mitad de una frase, se apagó. Sin «recuérdamelo más tarde». Sin opción de aplazarlo.
Y esto es lo curioso: ni siquiera pude enfadarme. Cogí el móvil, volví a conectarme a la reunión y seguí adelante. Porque esa política (la misma que acababa de interrumpir mi llamada) es la que llevo tiempo diciéndoles a los responsables de seguridad que deben adoptar: forzar la interrupción en tus propios términos, no en los de otro.
Aplicar parches «a contrarreloj» significa tratar las vulnerabilidades críticas como incidentes activos, cuyo tiempo de respuesta se mide en horas, no en los días prescritos en un calendario.
Y si voy a pedirles a nuestros clientes que replanteen su forma de aplicar parches, más me vale predicar con el ejemplo.
Así que así es como les he estado planteando esto a los responsables de seguridad.
Se me ocurrió esta imagen durante una conversación durante el almuerzo con un responsable de seguridad en Cisco Live, y no he podido quitármela de la cabeza desde entonces. Imagina un control deslizante. En un extremo está el impacto operativo: el riesgo de interrumpir tu negocio. En el otro extremo está un incidente de seguridad: el riesgo de sufrir una brecha. Todas las organizaciones se sitúan en algún punto de esa escala, se den cuenta o no, y ese punto lo dice todo sobre cómo entienden el riesgo.
Esto es lo que la mayoría de las organizaciones llevan años reflejando. Cuando aplicas un ciclo de parches de 90 días (y seré sincero, esa era nuestra cadencia en Insight no hace tanto tiempo), estás haciendo una apuesta. Estás diciendo: «Prefiero jugármela con un incidente de ciberseguridad antes que arriesgarme a paralizar la producción para aplicar un parche». Has situado tu control deslizante firmemente del lado de proteger las operaciones. Sientes que una brecha es el resultado menos probable, así que optimizas frente a la interrupción que ves venir.
Entiendo perfectamente ese instinto. Nos encantan nuestros procesos. Nos encantan nuestras ventanas de cambio, nuestras revisiones del comité de cambios (CAB) y nuestros controles; existen para mantenernos protegidos y para que las operaciones de TI sean predecibles. Pero Mythos, y otros modelos de AI de vanguardia como este, han cambiado silenciosamente las probabilidades de esa apuesta, y muchos responsables aún no han reaccionado ni han movido su control deslizante de riesgo.
Esto es lo que cambió mi forma de pensar. Cuando la ventana entre la divulgación de una vulnerabilidad y la aparición de un exploit en el mundo real se reduce de días a horas (y, en un futuro no muy lejano, a minutos), la brecha deja de ser el resultado improbable. Se convierte en el inminente.
Y aquí está la parte con la que realmente quiero que te quedes: una brecha también es una interrupción de la producción. No puedes evitar la interrupción simplemente no aplicando el parche. Solo cambias un tipo de interrupción por otro.
Cuando aplicas el parche en tus propios términos, la interrupción es planificada y controlada. La has programado. Tienes a tu equipo preparado. Tienes las herramientas de reversión listas. Si algo sale mal, lo solucionas y sigues adelante.
Cuando sufres una brecha, también tienes una interrupción, pero esta vez no está planificada. Es inesperada, ocurre a las 2 de la madrugada cuando no dispones del personal necesario, y es maliciosa. La persona que la ha provocado tiene un interés directo en mantenerte fuera de servicio, no en ayudarte a recuperarte. Ese es precisamente el cambio de perspectiva: planificada y controlada frente a inesperada y maliciosa.
Ya no eliges si vas a sufrir una interrupción. Solo eliges en los términos de quién ocurre.
Por eso he empezado a hablar de aplicar parches como un incidente en lugar de una tarea de mantenimiento. El mismo CVE, una postura completamente distinta.
En el modelo de mantenimiento, la pregunta que nos hacemos es «¿Este parche romperá la producción?». Medimos el éxito por el porcentaje de activos que hemos cubierto, y el reloj corre en semanas o meses. En el modelo de incidente, la pregunta cambia a «¿Cuál sería el radio de impacto si no aplicamos este parche?». Medimos el éxito por el tiempo medio de resolución, y el reloj corre en horas. Cuando la explotación se produce en cuestión de horas, una ventana de mantenimiento mensual ya no es un proceso, es un pasivo que aumenta tu exposición al riesgo operativo.
Ahora hablamos de desplegar parches mediante el mismo tipo de flujo de trabajo que esperarías de un incidente de ciberseguridad tradicional: detectar, clasificar, contener, remediar y validar. Captamos la divulgación mediante la gestión continua de la exposición a amenazas, localizamos dónde está presente en todo el entorno, utilizamos machine learning para valorar la probabilidad de que sea explotada realmente en tu entorno específico, y lo validamos con pruebas de penetración continuas. Si se trata de una vulnerabilidad alta o crítica, se pone en marcha un reloj de SLA y nuestros equipos de respuesta se activan de inmediato.
No se trata de parchear todo en el momento en que se divulga. Se trata de identificar el pequeño subconjunto de vulnerabilidades que suponen un riesgo real y explotable en tu entorno, y tratarlas con la urgencia propia de un incidente.
En lugar de esperar al siguiente ciclo de parches, una vulnerabilidad crítica expuesta externamente activa un flujo de trabajo inmediato: el equipo de seguridad la señala, valida la exposición e inicia la aplicación del parche en cuestión de horas, tal y como se haría con un incidente activo.
Ahora bien, si eres un responsable de operaciones, seguro que salta tu alarma: ¿parchear con más frecuencia significa más interrupciones, verdad?
En realidad, es justo lo contrario, y este es el argumento que quiero que los CISO trasladen a sus socios de operaciones y de negocio. Una de las principales razones por las que las ventanas de parcheo se descontrolan es que dejamos que los parches se acumulen y luego los desplegamos por decenas en decenas de subsistemas a la vez. Cuando pasas a responder en tiempo real, estás parcheando un único módulo afectado, de forma aislada. Las probabilidades de que surja una desagradable sorpresa en cascada se reducen drásticamente. Estás dando pasos más pequeños, más controlados y más específicos, y en el proceso reduces el riesgo operativo.
No voy a fingir que la tecnología sea la parte difícil. No lo es. Lo difícil es lo organizativo. Tienes que estar dispuesto a romper el molde de cómo has abordado siempre el parcheo, y tienes que integrar una alta disponibilidad genuina en tus sistemas, porque no puedes ejecutar grandes aplicaciones monolíticas bajo este modelo sin poner en riesgo esa aplicación crítica cada día. Es una forma diferente de entender la arquitectura, y es una conversación que debe llegar mucho más allá del equipo de seguridad.
Te dejo con la misma pregunta a la que sigo volviendo. Vas a asumir cierta interrupción; eso ya no es opcional. Lo único que puedes decidir es si será planificada y en tus términos, o imprevista y en los del atacante.
En Insight, nos hemos convertido en el cliente cero de este cambio radical en el enfoque de parcheo de los sistemas de TI. Nos enfrentamos al mismo cambio existencial al que se enfrenta todo el mundo, reconstruimos nuestro enfoque de la seguridad y las operaciones de TI en torno a él, y después lo llevamos a nuestros clientes. Porque, en realidad, no importa quién tenga acceso a Mythos. Existe. Y existe con el lanzamiento de modelos igualmente capaces en el horizonte, algunos de los cuales no están siendo desarrollados por los «buenos».
Lo que importa es si has reconocido que la forma de defender tu negocio ha cambiado de manera fundamental, y que muevas tu control deslizante antes de que alguien lo mueva por ti.