El proceso de gestión de parches: una guía paso a paso
La mayoría de los programas de aplicación de parches no fracasan porque el equipo no conozca los pasos a seguir. Fracasan en los huecos que hay entre ellos: el activo que nunca llegó a incluirse en el inventario, el parche que permaneció en estado «aprobado» durante tres semanas a la espera de una ventana de mantenimiento o el informe de implementación que nadie revisó porque el panel de control ya mostraba un cumplimiento del 96 %.
Un proceso sólido de gestión de parches es lo que convierte esos traspasos tan frágiles en algo repetible. Te proporciona una secuencia que seguir, una forma de confirmar cuándo se ha completado realmente un paso y una respuesta clara cuando un auditor te pregunte cómo decidiste qué parches se instalaron el martes pasado.
Esta guía recorre paso a paso todo el ciclo de vida. Verás qué ocurre en cada fase, quién suele ser el responsable, dónde suele fallar el proceso con mayor frecuencia y cuánto tiempo debería durar aproximadamente cada paso en un entorno que funcione correctamente. El software RMM de Kaseya gestiona la aplicación de parches en millones de terminales para proveedores de servicios de gestión (MSP) y equipos internos de TI, lo que ofrece una visión bastante clara de dónde se producen los fallos y cómo debería ser un proceso «correcto» en cada fase.
¿En qué consiste el proceso de gestión de parches?
Si eres nuevo en este tema, empieza por nuestra guía completa«¿Qué es la gestión de parches?» y, a continuación, vuelve aquí. Para el resto, el proceso es la columna vertebral operativa que sustenta la definición. Se trata del ciclo repetible que toma una vulnerabilidad o una versión de un proveedor y la convierte en un terminal parcheado, verificado y documentado.
Verás que se le conoce con varios nombres diferentes en la práctica: ciclo de vida de la gestión de parches, flujo de trabajo de la gestión de parches, procedimiento de gestión de parches o, simplemente, proceso de aplicación de parches. Todos ellos describen lo mismo. El número de pasos varía entre cuatro y diez, dependiendo de quién escriba sobre el tema, pero la lógica subyacente no cambia mucho.
Aquí utilizamos siete pasos porque ese es el nivel de detalle en el que cada fase tiene un responsable claro y un resultado concreto. Si son menos, los pasos empiezan a confundirse entre sí. Si son más, se están inventando distinciones que no existen en la práctica.
Hay algo que conviene destacar antes de entrar en materia: el proceso para la aplicación rutinaria y programada de parches no es el mismo que el proceso para la aplicación de parches de emergencia o de «día cero». Los pasos pueden parecer similares sobre el papel, pero los plazos, los controles de aprobación y la tolerancia al riesgo se reducen drásticamente. Abordaremos ambos, utilizando el flujo rutinario como eje central y señalando las variaciones de emergencia allí donde más importan.
Flujo del proceso de gestión de parches: 7 pasos clave
Un proceso sólido de gestión de parches establece un método sistemático para identificar, priorizar, implementar y verificar las actualizaciones sin tener que recurrir a conjeturas. A continuación se describe el flujo habitual del proceso, desde la detección de activos hasta la elaboración de informes.
Paso 1: Inventario y detección de activos
Responsable: Normalmente, el administrador de terminales o de sistemas, con el apoyo del departamento de seguridad.
No se puede aplicar un parche a algo que no se conoce. El primer paso consiste en elaborar y mantener un inventario completo, preciso y actualizado de todos los dispositivos, sistemas operativos, aplicaciones y versiones de firmware de tu entorno. Esto incluye servidores, estaciones de trabajo, ordenadores portátiles, dispositivos móviles, máquinas virtuales, equipos de red, dispositivos IoT y cualquier carga de trabajo en la nube que esté bajo tu gestión.
Lo ideal no es una hoja de cálculo que alguien actualiza cada trimestre. Se trata de un inventario que se actualiza continuamente a partir de la detección automática, en el que cada activo se complementa con la lista de componentes de software, la versión del sistema operativo, la última hora de registro y la titularidad. Cada laguna en este inventario se convierte en una laguna en tu cobertura de parches, y cada laguna en la cobertura acaba manifestándose más adelante como ese servidor del que nadie se había dado cuenta de que ejecutaba una versión de OpenSSL fuera de soporte.
Modos de fallo habituales: dispositivos BYOD en los que no se ejecuta el agente, ordenadores portátiles de subcontratistas que se conectan a la VPN una vez al trimestre, el servidor del laboratorio que alguien puso en marcha y se olvidó de registrar, y cualquier elemento que se encuentre en una suscripción a la nube propiedad de un único equipo.
Tiempo estimado: El proceso de descubrimiento se ejecuta de forma continua. Alcanzar por primera vez una línea de base completa y fiable suele llevar entre una y cuatro semanas, dependiendo del tamaño del entorno y del grado de «TI en la sombra» que exista.
Paso 2: Supervisión e identificación de parches
Responsable: Normalmente es una responsabilidad compartida entre el departamento de TI y el de seguridad.
Una vez que sepas qué tienes, debes saber qué recursos hay disponibles para solucionarlo. Este paso implica realizar un seguimiento periódico de las versiones de parches de todos los proveedores cuyo software se ejecute en tu entorno, así como de los avisos de seguridad de la CISA, los equipos PSIRT de los proveedores y las fuentes de inteligencia sobre amenazas, en busca de vulnerabilidades que puedan requerir una respuesta fuera de banda.
Para Microsoft, Adobe y Oracle, este proceso está relativamente estructurado. El «Patch Tuesday» tiene lugar el segundo martes de cada mes, los boletines son predecibles y la mayoría de las herramientas de gestión de parches los incorporan automáticamente. Los problemas surgen en todos los demás ámbitos. Los navegadores, las herramientas de videoconferencia, las bibliotecas de tiempo de ejecución, las aplicaciones especializadas para empresas, el firmware de red y los controladores de impresora se lanzan según sus propios ritmos y, a menudo, sin mucho bombo. Este es uno de los argumentos más sólidos a favor de una herramienta de gestión de parches que gestione la detección de terceros de forma nativa, en lugar de obligar a tu equipo a supervisar manualmente un centenar de fuentes RSS.
Modos de fallo habituales: pasar por alto por completo las versiones de terceros, no tener en cuenta los avisos fuera de ciclo que se publican entre los «martes de parches» y considerar las fuentes de CVE como la fuente de referencia en lugar de los avisos de los proveedores.
Plazo previsto: En curso. Desde el lanzamiento hasta la detección en tu entorno, deberías medir este plazo en horas para los proveedores de primer nivel y en uno o dos días para el resto.
Paso 3: Evaluación de riesgos y establecimiento de prioridades
Responsable: Seguridad, con el asesoramiento del departamento de TI sobre el impacto operativo.
La mayoría de los equipos disponen de más parches de los que pueden probar e implementar. Establecer prioridades es la forma de garantizar que los parches más importantes se apliquen en primer lugar.
El enfoque tradicional consistía en clasificar las vulnerabilidades según la puntuación CVSS y aplicar parches a todas las críticas. Este método sigue teniendo su lugar, pero por sí solo resulta poco preciso. Una vulnerabilidad con una puntuación CVSS de 9,8 en un software que no está expuesto a Internet, no tiene ningún exploit conocido y se ejecuta en tres hosts internos es un problema distinto al de una vulnerabilidad con una puntuación CVSS de 7,5 con un exploit funcional que se está utilizando activamente en el mundo real contra tu sector. Un enfoque basado en el riesgo tiene en cuenta la gravedad, pero también la importancia del activo, la exposición, la disponibilidad de exploits y el impacto en el negocio.
Aquí es donde el catálogo de vulnerabilidades explotadas conocidas de la CISA y las fuentes de información sobre amenazas demuestran su utilidad. Te indican qué vulnerabilidades están utilizando los atacantes, lo que constituye un indicador mucho más fiable de qué parches hay que aplicar primero que el CVSS por sí solo.
El resultado de este paso es una lista priorizada con plazos aproximados. Un marco habitual consiste en que los parches críticos se implementen en un plazo de entre 48 y 72 horas, los de alto riesgo en un plazo de 14 días, los de riesgo medio en un plazo de 30 días y los de bajo riesgo en un plazo de 90 días. La normativa «Cyber Essentials» del Reino Unido exige que los parches para vulnerabilidades con una puntuación de 7,0 o superior se implementen en un plazo de 14 días, lo que se ha convertido en una referencia útil para las organizaciones que aspiran a alcanzar ese nivel de madurez en materia de cumplimiento. Sean cuales sean los plazos que establezcas, documéntalos en tu política de gestión de parches para que el resto del proceso los tenga en cuenta.
Modos de fallo habituales: basarse exclusivamente en el CVSS, ignorar los datos sobre la explotabilidad, considerar que todos los parches «críticos» tienen la misma gravedad, el problema inverso de tratar los plazos como fechas límite en lugar de como objetivos, y esperar hasta el día 13 para realizar la implementación.
Tiempo estimado: horas por ciclo de parches si tus herramientas se encargan del trabajo más pesado. Un día completo o más si tu equipo revisa manualmente cada aviso.
Paso 4: Prueba de parche
Responsable: Operaciones de TI, con la colaboración de los responsables de las aplicaciones en el caso de los parches de alto riesgo.
Las pruebas son la fase que se omite en primer lugar cuando un equipo está bajo presión, y es la que más se lamenta cuando se omite. El objetivo es detectar el parche que provoca un fallo antes de que llegue a producción.
Los equipos con experiencia utilizan «anillos de implementación» o implementaciones por fases. Un parche se aplica primero a una muestra representativa de equipos de prueba, que idealmente incluya una combinación de modelos de hardware, versiones de sistema operativo y aplicaciones clave. Tras un periodo de funcionamiento sin incidencias de entre 24 y 72 horas, pasa a un grupo piloto más amplio. Solo entonces se aplica a todo el entorno de producción. El número exacto de anillos es menos importante que el principio: en ningún momento una única implementación debe afectar a todos los terminales a la vez.
En el caso de los parches rutinarios, la fase de pruebas suele durar entre 24 y 72 horas. En el caso de los parches de emergencia o de «día cero», se puede reducir este tiempo a unas pocas horas de pruebas de verificación básica en un grupo reducido antes de su implementación generalizada, aceptando un mayor riesgo a cambio de cerrar más rápidamente la ventana de vulnerabilidad. Esa compensación debe ser una decisión deliberada, no la opción por defecto.
Modos de fallo habituales: omitir por completo las pruebas en entornos pequeños, realizar pruebas únicamente en equipos que no son representativos del entorno de producción, declarar que un parche ha sido «probado» tras 30 minutos de funcionamiento en un único servidor y no contar con un plan de reversión en caso de que algo falle.
Plazo estimado: de 24 a 72 horas para los parches estándar, y de dos a doce horas para las emergencias, en función de la tolerancia al riesgo.
Paso 5: Implementación
Responsable: Operaciones de TI
La implementación es donde se pone a prueba el sistema. Los parches pasan del entorno de prueba al de producción según un calendario definido y dentro de las ventanas de mantenimiento acordadas con la empresa.
Este paso presenta más puntos de fallo que cualquier otro del proceso, sobre todo porque es aquí donde interviene el caótico mundo real. Portátiles que no están conectados a la red cuando se ejecuta la implementación. Usuarios finales que no dejan de posponer los reinicios. Servidores que requieren una secuencia cuidadosa debido a las dependencias. Parches que exigen que se detenga primero un servicio específico. Dispositivos fuera de la red que llevan semanas sin conectarse.
Un RMM bien configurado realiza la mayor parte del trabajo de forma invisible. Aplica los parches según la política establecida, vuelve a intentarlo cuando los equipos vuelven a estar conectados, gestiona los reinicios dentro de los intervalos acordados y señala las excepciones para que un usuario las revise. Lo que se espera de las herramientas en esta fase es una alta tasa de éxito en la implementación sin necesidad de intervenciones manuales, además de visibilidad sobre el grupo residual de dispositivos que no recibieron el parche en el primer intento.
Las ventanas de mantenimiento son más importantes de lo que la gente cree. Un parche que requiera reiniciar una estación de trabajo clínica en pleno turno hospitalario acabará posponiéndose, lo que significa que, en realidad, el parche no se aplicará aunque el panel de control indique lo contrario. Adaptar las ventanas de mantenimiento al funcionamiento real de la empresa es lo que distingue a los programas de aplicación de parches que ofrecen buenos informes de aquellos que realmente reducen el riesgo.
Modos de fallo habituales: dar por sentado que «implementado» significa que el parche está instalado cuando en realidad solo significa que se ha enviado el paquete; ignorar la gran cantidad de dispositivos fuera de la red o que no cumplen los requisitos; realizar la implementación sin ventanas de mantenimiento coordinadas; y carecer de un plan de reversión cuando una implementación provoca fallos en el entorno de producción.
Tiempo estimado: entre unos minutos y unas horas por equipo para la propia implementación técnica, pero el tiempo total necesario para cubrir todo el parque informático durante un ciclo de parches rutinario suele ser de una a dos semanas, una vez que se tienen en cuenta los dispositivos fuera de la red, los reinicios aplazados y la gestión de excepciones.
Paso 6: Verificación
Responsable: Operaciones de TI, con auditoría a cargo del departamento de seguridad.
La verificación es el paso en el que la mayoría de los equipos saben que deberían mejorar. El objetivo es confirmar, una vez que todo se haya calmado, que cada parche se ha instalado en cada dispositivo de destino y que la vulnerabilidad subyacente se ha solucionado.
Aquí hay dos aspectos que hay que tener en cuenta. En primer lugar, ¿se ha instalado correctamente el parche? La mayoría de las herramientas de gestión de parches te lo indicarán, aunque la respuesta suele ocultar una larga lista de estados «pendientes de reinicio» o «aplazados» que parecen correctos, pero no lo son. En segundo lugar, ¿se ha solucionado realmente la vulnerabilidad? Un análisis de vulnerabilidades independiente tras la aplicación del parche detecta los casos en los que el parche se ha instalado pero no ha solucionado completamente el problema, o en los que persiste una vulnerabilidad relacionada porque se necesitaba otro parche.
La diferencia entre la «tasa de éxito en la implementación» que indica tu herramienta de aplicación de parches y la «tasa de corrección de vulnerabilidades» que indica tu escáner suele ser precisamente donde se encuentran los hallazgos de las auditorías. Un equipo que registra un 98 % de cumplimiento en la aplicación de parches, pero solo un 85 % de corrección de vulnerabilidades, tiene una deficiencia en el proceso, no un problema con la herramienta.
Modos de fallo habituales: confiar en las métricas de éxito de la implementación como prueba de que se ha solucionado el problema, no realizar un análisis tras la implementación y no investigar nunca los casos aislados de implementaciones fallidas.
Tiempo estimado: entre 24 y 48 horas tras la implementación para que se ejecute el análisis posterior a la aplicación del parche y se obtengan datos válidos.
Paso 7: Informes y documentación
Responsable: Operaciones de TI, a menudo compartidas con los departamentos de seguridad y cumplimiento normativo.
El ciclo no termina cuando se verifican los parches. Termina cuando la actividad se documenta de tal forma que demuestre a los auditores que se ha actuado con la debida diligencia, ponga de manifiesto las tendencias a la dirección y sirva de base para mejorar el siguiente ciclo.
Cómo debe ser una buena documentación: un registro por ciclo de parches que muestre qué se ha publicado, qué se ha priorizado, qué se ha implementado, qué ha fallado y por qué, qué excepciones se han concedido y a qué activos. Métricas de tiempo de aplicación de parches por nivel de gravedad. Porcentajes de cumplimiento de parches por cliente, por departamento o por clase de activo. Un registro de auditoría claro que un revisor externo pueda seguir para verificar el historial de parches de cualquier terminal concreto.
Ahí es también donde se encuentran las oportunidades de mejora. Si el 30 % de los parches críticos se quedan fuera del plazo de 14 días, la pregunta que hay que plantearse no es «¿cómo podemos implementar más rápido?», sino «¿en qué punto de los seis pasos anteriores se pierde el tiempo?». La respuesta suele estar casi siempre en el paso tres (la priorización es demasiado lenta) o en el paso cinco (la implementación tiene demasiadas excepciones). La documentación es lo que hace posible ese diagnóstico.
Modos de fallo habituales: la documentación se deja para el final; los paneles de control que informan sobre la implementación sin contexto; la ausencia de un ciclo de revisión; y la falta de relación entre las métricas y las mejoras de los procesos.
Tiempo estimado: Reunión mensual de revisión, además del registro continuo de métricas. La elaboración de los informes en sí debería estar automatizada; lo que lleva tiempo es la revisión manual y los cambios en los procesos que de ello se derivan.
Cómo los parches de emergencia modifican el proceso
Todo lo anterior describe el flujo de trabajo habitual para la aplicación de parches. Cuando surge una vulnerabilidad de «día cero» o una vulnerabilidad que se está explotando activamente, ese flujo se acorta. Se siguen aplicando los mismos siete pasos, pero el plazo disponible se reduce de semanas a horas.
En un ciclo de parches de emergencia, la identificación se lleva a cabo a las pocas horas de publicarse el aviso; la priorización viene prácticamente dada (si es crítica, si está siendo objeto de explotación, se lanza); las pruebas se reducen a una rápida comprobación preliminar en un pequeño grupo, y la implementación se lleva a cabo de forma generalizada, partiendo de la idea de que es preferible que se produzcan algunos fallos a seguir expuesto al riesgo. La verificación y la documentación se refuerzan, ya que habrá que rendir cuentas ante la auditoría.
El riesgo en la respuesta ante emergencias no suele residir en actuar con demasiada rapidez, sino en carecer de un plan, lo que hace que el equipo improvise bajo presión y se salte los pasos importantes. Un proceso de aplicación de parches de emergencia bien documentado —que incluya a una persona designada para la toma de decisiones, una excepción preaprobada al control habitual de cambios y una ruta de reversión probada— es lo que garantiza que la aplicación rápida de parches sea segura.
En qué aspectos varía el proceso de aplicación de parches según el entorno
Los servidores, los terminales, las aplicaciones de terceros y las cargas de trabajo en la nube utilizan todos la misma estructura básica de siete pasos, aunque con detalles significativamente diferentes.
En el caso de los servidores, el gráfico de dependencias cobra mayor importancia. Aplicar un parche a un servidor de base de datos en una secuencia incorrecta con respecto a los servidores de aplicaciones que dependen de él puede provocar una interrupción del servicio que se prolongue durante horas. Las ventanas de mantenimiento son más ajustadas, el control de cambios es más riguroso y la planificación de la reversión es ineludible. El plazo para aplicar parches a las vulnerabilidades no críticas de los servidores suele ser más largo que en el caso de los terminales, y eso es lo adecuado.
En el caso de los terminales, el problema radica en la «cola larga»: los portátiles que se desplazan, los dispositivos que posponen los reinicios y los usuarios que apagan el equipo en lugar de reiniciarlo. La aplicación de parches en los terminales requiere una gestión fiable de los dispositivos fuera de la red y una forma de hacer frente al inevitable 5-10 % de máquinas que se quedan fuera de cualquier ciclo de parches concreto.
En el caso de las aplicaciones de terceros, el problema radica en su volumen. Un entorno típico cuenta con docenas de aplicaciones de terceros, cada una con su propio calendario de lanzamientos, y una parte considerable de las brechas de seguridad se originan en una aplicación de terceros sin parches, más que en un sistema operativo sin parches. Este aspecto es lo suficientemente importante como para que lo hayamos tratado por separado. Consulta nuestra guía específica sobre la gestión de parches de aplicaciones de terceros para conocer los detalles operativos.
En el caso de las cargas de trabajo en la nube, la inmutabilidad supone un cambio radical. En un entorno de nube bien diseñado, no se aplican parches a una instancia en ejecución, sino que se sustituye por una nueva instancia creada a partir de una imagen actualizada. El proceso de siete pasos sigue siendo válido, pero el quinto paso se asemeja más a la creación de una imagen y la sustitución de una instancia que a la instalación de software. Los entornos híbridos acaban ejecutando ambos patrones en paralelo, y ahí es donde reside la mayor parte de la complejidad operativa.
Puntos en los que el flujo del proceso suele fallar con mayor frecuencia
Hay algunos patrones que se repiten una y otra vez en entornos en los que el programa de aplicación de parches no funciona como debería.
El primero es un inventario incompleto. Si el primer paso es deficiente, todos los pasos posteriores se ven afectados por esa carencia. Los servidores que no se conocen no reciben parches, y suelen ser los primeros que encuentran los atacantes, ya que están mal mantenidos precisamente por la misma razón por la que no figuran en el inventario.
El segundo es el desfase entre las pruebas y la implementación. Los parches se prueban, se aprueban y luego quedan a la espera de una ventana de mantenimiento que la empresa no deja de posponer. Dos semanas después, el parche sigue sin estar en producción y la urgencia inicial se ha desvanecido. La solución suele consistir en una mayor sincronización entre la aprobación y la implementación, además de unas ventanas de mantenimiento menos frecuentes y más fiables.
El tercer aspecto es la «cola larga» de dispositivos que no cumplen con los requisitos. El panel de control indica un 95 %. El 5 % restante es siempre el mismo en cada ciclo y, casi siempre, es el 5 % más importante: los portátiles de los directivos, los servidores que nadie quiere tocar, el entorno del laboratorio con sus propias normas. Un programa maduro hace visible esa «cola larga», identifica a los responsables de cada excepción y se ocupa de resolverla en lugar de ignorarla.
La cuarta es la verificación basada únicamente en el estado de implementación. La herramienta indica que la operación se ha realizado con éxito, el equipo pasa a la siguiente tarea y, tres semanas más tarde, el análisis de vulnerabilidades revela que el 8 % del entorno que se suponía que ya estaba parcheado sigue siendo vulnerable. Para subsanar esta deficiencia, es necesario considerar los resultados del análisis de vulnerabilidades como la fuente de referencia para la corrección, y no el informe de implementación de la herramienta de parches.
La combinación de estos modos de fallo es la razón por la que las organizaciones tardaron una media de 209 días en aplicar parches a las 17 vulnerabilidades de dispositivos periféricos que Verizon identificó en su DBIR de 2025, frente a los cinco días que tardó el atacante en aprovecharlas. Se trata de problemas de proceso, no de falta de concienciación.
Cómo las modernas herramientas de Kaseya transforman el proceso
La aplicación manual de parches a cualquier escala razonable no funciona. El volumen de versiones, la diversidad de plataformas y la rapidez con la que se aprovechan las vulnerabilidades han superado con creces lo que un equipo puede gestionar utilizando hojas de cálculo e implementaciones individuales.
Lo que hace una buena herramienta es sintetizar los siete pasos en un flujo de trabajo automatizado y coherente, en el que las personas intervienen en los puntos de decisión. La detección de activos se lleva a cabo de forma continua. La identificación de parches se produce a las pocas horas de su lanzamiento por parte del proveedor. La priorización puede basarse en políticas, de modo que los parches críticos se aprueban automáticamente para los anillos de emergencia. Las pruebas se ejecutan en anillos de implementación definidos sin intervención manual. La implementación localiza los dispositivos fuera de la red y gestiona los reinicios dentro de las ventanas de tiempo acordadas. La verificación se integra en los análisis de vulnerabilidades. Los informes se generan automáticamente.
Este es el modelo operativo en el que se basa la gestión automatizada de parches, que actualmente es la opción predeterminada para cualquier entorno que se tome en serio la aplicación de parches a gran escala. El proceso de siete pasos descrito anteriormente es el que subyace a la automatización; la automatización es lo que lo hace sostenible.
El software de gestión de parches de Kaseya se encarga de este flujo de trabajo para los equipos de TI y los proveedores de servicios gestionados (MSP) en todos los sistemas operativos y en más de mil aplicaciones de terceros, con implementación basada en políticas, anillos de implementación, gestión de dispositivos fuera de la red e informes de cumplimiento de parches, todo ello en una única solución. Datto RMM, que forma parte de la familia Kaseya RMM, es la opción nativa de la nube para los equipos que desean disponer de la misma capacidad de aplicación de parches sin tener que gestionar la infraestructura subyacente.
El proceso es más importante que la herramienta. Pero, una vez que el proceso es sólido, la herramienta adecuada es lo que marca la diferencia entre un programa que funciona sobre el papel y uno que realmente mantiene el parque informático actualizado al ritmo que necesita la empresa. A partir de ahí, el siguiente paso es pasar del proceso al programa: consulta nuestra guía complementaria sobre las mejores prácticas en la gestión de parches para conocer los principios que distinguen a un programa de parches que funciona de uno excelente.
