Prácticas recomendadas para la gestión de parches: cómo reducir el riesgo más rápidamente

La mayoría de las listas de buenas prácticas para la gestión de parches son muy similares entre sí. Haz un inventario de tus activos. Realiza pruebas antes de implementar. Documenta una política. Automatiza siempre que puedas. Todas son ciertas, pero resultan superficiales. No dan ninguna indicación sobre cuáles mejorarán realmente tu nivel de seguridad y cuáles son aspectos «deseables» que puedes posponer si tu equipo ya está desbordado.

Esta guía los clasifica. No por orden alfabético, ni según la taxonomía del NIST, sino en función de lo que marca la diferencia en las métricas que realmente importan: el tiempo de aplicación de parches para vulnerabilidades críticas, el porcentaje de entorno cubierto, la solidez ante auditorías y la probabilidad de sufrir una brecha de seguridad. Algunas de las prácticas que se indican a continuación reducirán a la mitad su ventana de exposición. Otras ahorrarán a su equipo unas cuantas horas al mes. Las soluciones RMM de Kaseya gestionan la aplicación de parches en millones de terminales para proveedores de servicios gestionados (MSP) y equipos de TI internos, lo que ofrece una visión bastante clara de qué prácticas comparten los programas bien gestionados y cuáles nunca se llevan a cabo en aquellos que tienen dificultades.

Si lo que buscas es información básica, empieza por nuestra guía completa sobre la gestión de parches. Si no es así, pasemos a ver las prácticas.

Prácticas recomendadas para la gestión de parches: de mayor a menor impacto

Las prácticas que se indican a continuación se han agrupado por impacto, no por orden de aplicación. Dentro de cada grupo, se han ordenado, a grandes rasgos, según el esfuerzo que requieren en relación con la mejora de la seguridad.

Las prácticas de alto impacto modifican tu perfil de riesgo de forma cuantificable. Si solo tienes tiempo para tres cosas este trimestre, elige entre este grupo. Las prácticas de impacto moderado son los hábitos operativos básicos que se acumulan con el tiempo: no marcan la diferencia esta semana, pero un programa que carezca de ellas no se mantendrá en buen estado durante mucho tiempo. Y las prácticas de bajo impacto son los elementos que aparecen en todas las listas de comprobación de auditoría. Merece la pena llevarlas a cabo, pero no las confundas con el trabajo que realmente te mantiene al día.

Prácticas de gran impacto

Estas son las cuatro prácticas que mejoran tus cifras de forma cuantificable. Si las pasas por alto, el resto de la lista no te servirá de nada. Si las llevas a cabo correctamente, podrás ser un poco descuidado con la mayor parte de lo que viene a continuación y, aun así, gestionar un programa sólido. Son más difíciles que los aspectos de impacto moderado, pero la mejora en seguridad por hora invertida es varias veces mayor.

Prioriza en función de la explotabilidad, no solo de la gravedad

Las puntuaciones CVSS son un punto de partida útil, pero un punto final pésimo. Una puntuación CVSS de 9,8 en un software que no está expuesto es menos urgente que una de 7,5 que ya figura en el catálogo KEV de la CISA y que los grupos de ransomware están utilizando esta misma semana.

En 2025, la CISA añadió 245 vulnerabilidades a su catálogo de «Vulnerabilidades explotadas conocidas» (KEV), lo que elevó la lista a 1.484. Esto supone un aumento del 20 % en un solo año. Veinticuatro de las incorporaciones de 2025 ya se estaban utilizando en campañas de ransomware en el momento de su inclusión en la lista, y el 20,5 % de todas las entradas del KEV han sido utilizadas históricamente por operadores de ransomware. Ahí es donde se concentra el volumen real de ataques, y supone solo una fracción del universo total de CVE.

Un modelo de priorización basado en el riesgo utiliza tres criterios: la gravedad del proveedor (CVSS), el estado de explotación (listado KEV, fuentes de inteligencia sobre amenazas, disponibilidad pública de exploits) y el impacto en el negocio (por ejemplo, si un sistema está conectado a Internet, maneja datos sensibles o actúa como punto de enlace con sistemas críticos). Los parches que obtienen una puntuación alta en los tres criterios pasan al principio de la cola. Los parches que obtienen una puntuación alta en uno de ellos y baja en los demás se mantienen en el ritmo habitual. No se trata de un cambio complicado de implementar. Se trata, sobre todo, de un cambio de disciplina en la forma de clasificar el informe semanal de vulnerabilidades.

Cuánto cuesta: unas pocas horas a la semana de trabajo de un analista. Cuánto se ahorra: la mayor parte del esfuerzo que se desperdicia, además de la capacidad de justificar las decisiones de priorización ante un auditor.

Reducir el tiempo necesario para aplicar parches en los sistemas conectados a Internet

El Informe de Investigaciones sobre Fugas de Datos de Verizon de 2025 identificó 17 vulnerabilidades que afectaban a dispositivos periféricos incluidos en la lista KEV. El tiempo medio que tardaron las organizaciones en corregir por completo dichas vulnerabilidades fue de 209 días. El tiempo medio que tardaron los atacantes en comenzar a explotarlas de forma masiva tras su divulgación fue de cinco días.

Esa brecha es donde se producen las brechas de seguridad. Los sistemas perimetrales (pasarelas VPN, cortafuegos, cortafuegos de aplicaciones web, proveedores de identidad y cualquier otro elemento accesible desde Internet) deben estar sujetos a un acuerdo de nivel de servicio (SLA) de aplicación de parches independiente y mucho más rápido que el resto de tu infraestructura. Un plazo de 14 días para los parches rutinarios relacionados con Internet y uno de entre 24 y 48 horas para los que están siendo explotados activamente es un objetivo razonable. Si el plazo es más holgado que eso, es como si dejaras la puerta abierta a sabiendas.

Esta práctica tiene un gran impacto porque centra los esfuerzos en los sistemas que los atacantes atacan en primer lugar. No exige acelerar el ritmo de aplicación de todos los parches, sino solo de aquellos que son más importantes.

Automatizar las tareas rutinarias

La aplicación manual de parches a gran escala no funciona. El catálogo de KEV creció un 20 % en un solo año, mientras que la plantilla de la mayoría de los equipos de TI se mantuvo sin cambios. Las cifras no favorecen a las personas.

La distribución realista es la siguiente: automatizar todo lo que sea predecible (identificación, programación, implementación en anillos definidos, lógica de reintentos, generación de informes) y dejar en manos de las personas todo aquello que requiera criterio (gestión de excepciones, aprobaciones de ventanas de cambio para sistemas sensibles, decisiones de reversión, comunicación con las partes interesadas). Si se hace bien, esto reduce lo que antes era un trabajo a tiempo completo dedicado a la aplicación de parches a unas pocas horas de supervisión a la semana.

La objeción más habitual es el temor a que los parches defectuosos provoquen una interrupción del servicio de producción. La respuesta a eso no es hacerlo todo a mano, sino establecer las medidas de seguridad adecuadas en la automatización: anillos de implementación que detecten los problemas en un grupo piloto antes de que afecten a la producción, reversión automática ante fallos notificados por los agentes y una ruta de excepción definida para el 5 % de los sistemas que realmente necesitan intervención manual. Para obtener más información sobre el modelo operativo y qué procesos automatizar y cuáles dejar manuales, consulta la sección sobre gestión automatizada de parches.

Analiza las aplicaciones de terceros con el mismo rigor que el sistema operativo

La mayoría de los programas de aplicación de parches gestionan Windows, macOS y Linux de forma competente, pero tratan el resto como algo secundario. Ahí es donde está la brecha. Las vulnerabilidades en navegadores, lectores de PDF, herramientas de videoconferencia, entornos de ejecución y herramientas de desarrollo son objeto de numerosos ataques, y muchas de las cadenas de ataque más frecuentes las utilizan como vector inicial.

La práctica habitual consiste en integrar las aplicaciones de terceros en el mismo inventario, el mismo marco de priorización y los mismos SLA que las actualizaciones de tu sistema operativo. No se trata de un proyecto aparte, ni de una herramienta aparte, ni de una revisión trimestral aparte. Es lo mismo. Si tu plataforma de gestión de parches es compatible de forma nativa con varios cientos de aplicaciones de terceros (como ocurre con la mayoría de las modernas), se trata más bien de un cambio de configuración que de un nuevo programa. Si no es así, esa es la carencia que hay que subsanar en primer lugar. En nuestro blog sobre la gestión de parches de terceros encontrarás las aplicaciones específicas a las que conviene dar prioridad, así como un análisis más detallado del tema.

Entrenamientos de impacto moderado

Las cuatro prácticas siguientes son las que mantienen la solidez de un programa. Por separado, ninguna de ellas reducirá a la mitad tu ventana de exposición como lo hacen los aspectos de alto impacto. En conjunto, son las que marcan la diferencia entre un programa que resiste las auditorías y la rotación de personal, y uno que se deteriora silenciosamente en cuanto alguien se marcha o la empresa entra en una época de mayor actividad.

Utiliza ciclos de implementación, en lugar de hacerlo todo de una vez o uno por uno

Un «anillo de implementación» es una secuencia definida de grupos del sistema que reciben un parche por fases: primero, un pequeño grupo piloto representativo del conjunto más amplio; a continuación, un grupo de validación más amplio; y, por último, el despliegue completo en producción. Cada anillo tiene un periodo de espera antes de que comience el siguiente, durante el cual la supervisión detecta cualquier problema provocado por el parche.

Esta práctica descarta dos modos de fallo que suponen un coste real para los equipos. El primero es el enfoque de «implementar en todo el sistema el viernes por la tarde», que garantiza que cualquier parche defectuoso paralice a toda la organización de golpe. El segundo es el enfoque de «aplicar el parche a una máquina cada vez», que parece prudente, pero lleva tanto tiempo que el parche queda obsoleto antes de que se haya implementado por completo. Los «rings» te ofrecen la rapidez de la automatización con la seguridad de una implementación por etapas.

Una estructura inicial razonable consiste en tres fases: entre el 5 % y el 10 % del sistema como prueba piloto, entre el 25 % y el 35 % como validación más amplia, y el resto como implementación definitiva. Los periodos de espera de entre 24 y 48 horas entre cada fase son adecuados para las actualizaciones rutinarias, y se reducen a unas pocas horas en caso de emergencia.

Haz que la reversión sea una operación de primer orden, no un simulacro de emergencia

La reversión es una práctica con la que todo el mundo está de acuerdo, pero que la mayoría de los equipos aún no han probado. El momento adecuado para descubrir que tu procedimiento de reversión no funciona no es la mañana después de que una actualización defectuosa haya dejado fuera de servicio 4.000 terminales.

Para que la capacidad de reversión sea viable se necesitan tres cosas: un procedimiento documentado para cada sistema operativo principal y cada tipo de parche, una ruta de restauración que se sepa que funciona correctamente (imagen, instantánea o desinstalación nativa de la plataforma) y, al menos, un simulacro cada trimestre en el que el equipo lleve a cabo la reversión con un grupo de prueba. El simulacro es la parte que la mayoría de los programas se saltan. Sin él, la documentación se va deteriorando y nadie se da cuenta hasta que la necesita.

Se trata de un impacto moderado, y no de uno elevado, porque, en programas bien gestionados y con una buena implementación de los anillos, las reversiones son poco frecuentes. Pero la asimetría es importante: los incidentes poco frecuentes que tardan días en resolverse suponen un coste mayor que los frecuentes que se resuelven en cuestión de minutos.

Realizar un seguimiento e informar sobre el cumplimiento por dispositivo, no solo de forma global

Una cifra de cumplimiento del 95 % resulta tranquilizadora, pero carece en gran medida de significado. La pregunta interesante es qué 5 % incumple las normas, por qué y durante cuánto tiempo. Que sea siempre el mismo 5 % el que incumpla las normas en cada ciclo es un problema distinto al de un 5 % distribuido aleatoriamente, y la respuesta adecuada también es diferente.

La práctica habitual consiste en elaborar informes con un nivel de detalle a nivel de dispositivo, indicando los propietarios de cada dispositivo que incumple la normativa y definiendo un estado de excepción. Un dispositivo puede estar conforme, encontrarse en una excepción documentada con una fecha de revisión o incumplir la política. Tres estados, sin ambigüedades. La mayoría de los equipos descubren, al realizar este ejercicio por primera vez, que la mayor parte de su «incumplimiento continuo» proviene de un grupo reducido y estable de dispositivos: portátiles de viaje con una disciplina deficiente a la hora de reiniciarse, sistemas heredados cuyos propietarios se muestran reacios a tocarlos, y segmentos de desarrollo o de laboratorio que funcionan fuera del ámbito de aplicación de los parches de producción. La lista es finita. Reducirla de forma deliberada es un problema distinto al de mejorar el cumplimiento general, y merece una atención trimestral específica.

En el caso de los programas que prestan servicio a varias unidades de negocio o, en el caso de los MSP, a varios clientes, se aplica la misma práctica por cada inquilino. Los informes de cumplimiento por cliente son, además, el documento de auditoría que más se solicita en las revisiones del marco.

Documentar el programa en una política real y de obligado cumplimiento

Todos los marcos de auditoría y la mayoría de las solicitudes de seguro cibernético exigen ahora una política de gestión de parches. La versión deficiente es un documento de tres páginas que dice «los parches se aplicarán de forma oportuna» y que se guarda en una carpeta de SharePoint que nadie abre. La versión útil especifica los acuerdos de nivel de servicio (SLA) según la gravedad de los parches, define las funciones y los procesos de aprobación, establece las franjas horarias de mantenimiento, fija el proceso de excepciones y se revisa trimestralmente.

La parte «real y aplicada» es la práctica. Una política que no se ajusta a lo que el equipo hace en la práctica es peor que no tener ninguna política, ya que genera incidencias de auditoría cada vez que la realidad se desvía del documento. La disciplina consiste en cambiar la política cuando cambia la práctica o en cambiar la práctica para que se ajuste a la política. Para conocer la estructura de una política viable y las secciones que realmente importan a los auditores, consulta nuestra guía para elaborar una política de gestión de parches.

Prácticas de bajo impacto

Estas medidas aparecen en todas las listas de comprobación. Merece la pena llevarlas a cabo, pero no esperes que influyan mucho en tus cifras:

• Llevar un inventario de activos supone un trabajo considerable, pero la mayoría de los equipos ya cuentan con uno. El mayor problema en materia de inventario es la «TI en la sombra» y los terminales no gestionados, algo que el propio inventario no puede solucionar.
• Merece la pena informar a los usuarios finales de los periodos de mantenimiento para mantener una buena relación con la empresa, pero eso no modifica tu nivel de seguridad.
• La estandarización en torno a las versiones de software compatibles tiene un valor real, aunque los beneficios tardan en notarse: reducir el número de versiones distintas de sistemas operativos y aplicaciones en el entorno facilita todo lo demás, pero el proyecto para lograrlo suele llevar un año o más.
• Enseñar a los usuarios finales a no ignorar las notificaciones de actualización tiene cierta utilidad, pero la mayoría de las vulnerabilidades que se aprovechan no requieren que el usuario haga nada. El comportamiento del usuario es más importante en el caso del phishing que en el de la aplicación de parches.

La razón por la que aparecen en todas las listas es que son fáciles de anotar y difíciles de rebatir. La razón por la que ocupan los últimos puestos de esta lista es que, aunque las cumplas a la perfección, si te saltas las prácticas de las dos primeras secciones, no estarás a salvo.

Métricas de gestión de parches: cómo medir el éxito de las mejores prácticas

Una práctica que no se puede medir no es una práctica. Es una aspiración. Los indicadores que merece la pena seguir semanal o mensualmente son pocos:

1. Tiempo necesario para aplicar parches a las vulnerabilidades críticas, medido desde el lanzamiento por parte del proveedor hasta la implementación en todo el entorno.
2. Porcentaje del parque informático que cumple con el SLA de aplicación de parches, desglosado por nivel de prioridad de los parches (crítico, alto, moderado).
3. Edad media de las vulnerabilidades sin parchear que aún persisten en el entorno.
4. Número de dispositivos en estado de excepción documentado, con fecha de revisión actualizada.
5. Número de incidencias provocadas por parches por ciclo, como señal de retroalimentación sobre las pruebas y la implementación en el anillo.

Cinco cifras. Si evolucionan en la dirección correcta, el programa está funcionando. Si se mantienen estables o empeoran a pesar del esfuerzo, significa que alguna de las prácticas mencionadas anteriormente no se está llevando a cabo tal y como se describe.

En qué aspectos destaca Kaseya

Las prácticas anteriores describen en qué consiste un programa de gestión de parches eficaz. La elección de las herramientas determina si tu equipo podrá mantener esas prácticas sin llegar al agotamiento.

Las características que hay que tener en cuenta: un inventario unificado en todos los sistemas operativos y aplicaciones de terceros; una priorización basada en políticas que incorpore datos de KEV; una implementación por anillos con períodos de retención automáticos; la gestión de dispositivos fuera de la red; reintentos automáticos y escalado de excepciones; e informes de cumplimiento por dispositivo que generen pruebas listas para auditoría bajo demanda.

Las soluciones RMM de Kaseya ofrecen software de gestión de parches para proveedores de servicios de gestión (MSP) y equipos internos de TI en distintos sistemas operativos, mientras que el módulo «Advanced Software Management» de Datto RMM cubre más de 200 aplicaciones de terceros listas para usar, políticas de anillos de implementación, gestión fuera de la red e informes de cumplimiento por cliente, tal y como requieren las prácticas mencionadas anteriormente. 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 las mismas capacidades sin tener que gestionar la infraestructura subyacente.

Las prácticas que marcan la diferencia son las que figuran en la sección de «alto impacto» anterior. Elige una para este trimestre, ponla en práctica correctamente y mide el cambio.