Los servidores no se actualizan igual que los ordenadores portátiles. Una actualización fallida en el ordenador de un empleado supone un inconveniente para una persona. Una actualización fallida en un servidor de base de datos puede perturbar o interrumpir temporalmente las transacciones en toda una unidad de negocio, por lo que resulta esencial contar con un plan de reversión.
Las prácticas estándar de gestión de dispositivos diseñadas para terminales, sencillamente, no son aplicables a los entornos de servidores. Los riesgos operativos, las cadenas de dependencia y los requisitos de disponibilidad son totalmente distintos.
Esa diferencia en el radio de impacto lo cambia todo en cuanto a cómo se planifica, se organiza y se lleva a cabo la aplicación de parches. La gestión de parches en servidores implica una coordinación en torno a los requisitos de disponibilidad, las dependencias de las aplicaciones y los flujos de trabajo de gestión de cambios, algo que la aplicación de parches en dispositivos finales no suele requerir.
Esta guía aborda las limitaciones operativas que hacen que la aplicación de parches en los servidores sea un proceso específico, desde el inventario y el mapeo de dependencias hasta la priorización basada en el riesgo, la implementación por anillos, la coordinación entre equipos y la verificación posterior a la implementación.
Por qué la aplicación de parches en los servidores requiere un enfoque operativo diferente
Una sola actualización fallida en un servidor de bases de datos puede paralizar por completo una unidad de negocio. Por eso, la aplicación de parches en los servidores no es simplemente una versión a mayor escala de la gestión de parches : se trata de una disciplina operativa fundamentalmente diferente.
El proceso general de gestión de parches de consiste en buscar las actualizaciones que faltan, probar los parches en un entorno de prueba, implementarlos durante las ventanas de mantenimiento e informar sobre los resultados. Entre las mejores prácticas se incluyen la automatización de tareas repetitivas, seguir una cadencia regular de aplicación de parches —como el «Patch Tuesday» de Microsoft para entornos Windows—, cumplir con los ciclos de lanzamiento específicos de cada proveedor para Linux y otras plataformas, y crear copias de seguridad o instantáneas antes de aplicar las actualizaciones.
Pero ese es el marco habitual. La realidad para los equipos empresariales que gestionan servidores es más complicada.
Los servidores suelen ejecutar 24/7 cargas de trabajo con ventanas de mantenimiento muy limitadas que se negocian con semanas de antelación. Si se deja pasar esa oportunidad, el periodo de exposición se prolonga varias semanas, incluso cuando los parches ya están aprobados y preparados para su implementación. En la gestión de terminales estándar de , los dispositivos pueden reiniciarse durante la hora del almuerzo con una interrupción mínima. Los servidores no cuentan con esa flexibilidad.
Además, está el problema de la dependencia. Los servidores rara vez funcionan de forma aislada. Una actualización aplicada a un servidor puede provocar un fallo en una API de la que depende otro servidor, lo que, a su vez, afecta a un tercer sistema situado más adelante en la cadena. Esta red interconectada de servicios y dependencias es lo que hace que la aplicación de parches en los servidores sea, en esencia, más compleja que la aplicación de parches en los terminales, y la razón por la que los cambios deben secuenciarse cuidadosamente en lugar de implementarse de forma masiva.
Las limitaciones a la hora de aplicar parches en los servidores no hacen que el trabajo sea imposible. Lo hacen distinto desde el punto de vista operativo. En los apartados siguientes se explica cómo abordar cada restricción de manera que se reduzca el riesgo sin generar nuevos problemas operativos.
Inventario de servidores y mapa de dependencias
Antes de implementar cualquier cosa, debe saber qué es lo que está actualizando y qué elementos dependen de ello. Un inventario de servidores incompleto puede socavar los esfuerzos de aplicación de parches antes incluso de que comience la implementación.
Un inventario de servidores con fines de aplicación de parches va más allá de la simple identificación de activos. Incluye las versiones de los sistemas operativos, las aplicaciones instaladas, los niveles de parches y las funciones empresariales que admite cada servidor. Sin esta información, los equipos acaban aplicando parches a ciegas, sin saber con certeza si un servidor concreto aloja una carga de trabajo de prueba o una base de datos de producción.
La representación de dependencias añade otra capa. Los servidores suelen alojar servicios a los que recurren otros sistemas. Un parche que requiera reiniciar un servidor de middleware puede interrumpir temporalmente las conexiones con las aplicaciones posteriores. En entornos en los que predominan la nube y los contenedores , la aplicación de parches también puede implicar la reconstrucción de imágenes de referencia y la reimplementación de las cargas de trabajo (infraestructura inmutable), en lugar de actualizar in situ las instancias de larga duración.
Saber a qué servidores afecta cada uno y qué elementos afectan a cada servidor permite a los equipos secuenciar correctamente las actualizaciones y notificar a las partes interesadas afectadas.
| Elemento de inventario | Por qué es importante para la aplicación de parches |
|---|---|
| Versión del sistema operativo y nivel de parches | Determina qué parches se aplican y en qué orden |
| Aplicaciones instaladas | Identifica aplicaciones de terceros y otro software que también requieran actualizaciones |
| Función empresarial | Sirve de base para establecer prioridades y programar las ventanas de mantenimiento |
| Dependencias anteriores y posteriores | Evita que se produzcan fallos en cadena durante los reinicios |
| Nivel de criticidad del servidor | Determina a qué anillo de implementación pertenece el servidor |
Los procesos manuales de inventario tienen dificultades para seguir el ritmo de la proliferación de servidores. En los entornos en la nube, los servidores se activan y desactivan, y la infraestructura local cambia con la misma frecuencia, mediante bajas, reconfiguraciones y nuevas implementaciones que no siempre quedan registradas. Las desviaciones en la configuración se acumulan con el paso del tiempo. Las empresas que se basan en auditorías trimestrales suelen detectar las deficiencias solo después de que falle una actualización o de que una auditoría señale una cobertura insuficiente.
La visibilidad de los activos en tiempo real puede resolver este problema mediante el seguimiento continuo del estado de los servidores. Cuando un nuevo servidor se pone en funcionamiento o se modifica la configuración de un servidor ya existente, el inventario puede actualizarse automáticamente, en función de la configuración y la conectividad.
El software moderno de gestión de parches debe integrar esta capacidad de inventario en tiempo real directamente en el flujo de trabajo de aplicación de parches, lo que proporciona a los equipos una visión actualizada en lugar de una instantánea obsoleta y elimina la conciliación manual que ralentiza los enfoques tradicionales.
Una vez que se dispone de un inventario completo y de un mapa de dependencias, la siguiente pregunta es: ¿a qué servidores se les aplican los parches en primer lugar?
Cómo establecer prioridades en los parches de los servidores utilizando EPSS, CISA KEV y el nivel de criticidad de los activos
No todas las vulnerabilidades entrañan el mismo riesgo. Una puntuación de 9.8 según el Sistema Común de Puntuación de Vulnerabilidades (CVSS) en un servidor de pruebas sin exposición a la red es menos urgente que una puntuación CVSS de 7.5 en un servidor de producción que gestiona transacciones de clientes. Una priorización eficaz combina la gravedad de la vulnerabilidad con el contexto empresarial. Es la piedra angular de un programa de gestión de vulnerabilidades maduro y que va más allá de la mera detección de problemas para reducir de forma activa la exposición a posibles ataques.
Hay tres indicadores que ayudan a afinar el orden de prioridad más allá de las puntuaciones CVSS sin procesar:
- Sistema de puntuación para la predicción de exploits (EPSS): El EPSS estima la probabilidad de que una vulnerabilidad sea explotada en la red en los próximos 30 días. Una vulnerabilidad con un CVSS alto pero un EPSS bajo puede resultar menos urgente que otra con un CVSS moderado y un EPSS alto.
- Catálogo KEV de la CISA: . Si una vulnerabilidad aparece en la lista KEV de la CISA, los atacantes ya la están aprovechando. Las vulnerabilidades que figuran en esta lista pasan a ocupar los primeros puestos de la lista de prioridades, independientemente de otras puntuaciones. Esto resulta especialmente relevante en el caso de las plataformas de servidor más extendidas, como Windows Server y las distribuciones más populares de Linux, que aparecen con frecuencia en las listas de KEV debido a su uso generalizado en el ámbito empresarial y en entornos conectados a Internet.
- Importancia de los activos: La función que desempeña un servidor en las operaciones empresariales determina la urgencia con la que debe aplicársele un parche. Los servidores que alojan aplicaciones generadoras de ingresos, datos sujetos a regulación o servicios de atención al cliente suelen requerir una resolución más rápida de los problemas. Además, son los objetivos más atractivos para los operadores de ransomware, que buscan deliberadamente sistemas de gran valor para maximizar su poder de negociación.
Las vulnerabilidades incluidas en la lista KEV suelen requerir que se interrumpa el ciclo habitual de parches. Un programa de parches consolidado permite una respuesta fuera de ciclo para las vulnerabilidades incluidas en la lista KEV o de alto riesgo, incluso cuando ello altere la cadencia habitual de mantenimiento.
La combinación de señales da lugar a una matriz de priorización. Una vulnerabilidad con un EPSS elevado, incluida en la lista KEV de la CISA y presente en un servidor de producción de nivel 1, recibe atención inmediata. Una vulnerabilidad con un EPSS bajo, que no figure en la lista KEV y que se encuentre en un servidor de desarrollo puede esperar hasta la próxima ventana de mantenimiento programada. El objetivo no es solucionar todo de una vez. El objetivo es reducir de forma sistemática la superficie de ataque, abordando en primer lugar las vulnerabilidades que tienen más probabilidades de ser explotadas.
La priorización basada en el riesgo ayuda a los equipos a centrar sus esfuerzos en aquellos ámbitos en los que se reduce al máximo la exposición al riesgo. Una vez establecidas las prioridades, el siguiente reto consiste en aplicar los parches sin interrumpir las operaciones.
Cómo lograr una priorización más inteligente de las vulnerabilidades con Tanium Comply
Las listas de vulnerabilidades pendientes no se reducen trabajando más duro, sino trabajando de forma más inteligente. En este episodio de «Tanium Tech Talks» se explica cómo Tanium Comply integra información sobre vulnerabilidades de « », el nivel de criticidad de los terminales y los datos de los productos detectados, además de las puntuaciones CVSS, lo que ofrece a los equipos una forma más precisa y fundamentada de decidir qué problemas deben solucionarse en primer lugar.
Si su proceso de aplicación de parches en el servidor sigue comenzando con una hoja de cálculo y una decisión basada en la intuición, le conviene ver este vídeo.
Estructuración de la implementación de parches en servidores mediante un despliegue por anillos
La aplicación simultánea de parches en todos los servidores es una receta segura para que se produzcan interrupciones generalizadas del servicio. La implementación en anillos aplica los parches de forma progresiva a grupos cada vez más amplios, lo que permite detectar los problemas en una fase temprana, antes de que afecten a los sistemas críticos para la producción.
Una estructura de anillo típica tiene el siguiente aspecto:
Ring 0: Canario
Un pequeño grupo de servidores no críticos recibe los parches en primer lugar. Los servidores de prueba reflejan las configuraciones de producción, pero no soportan las cargas de trabajo de producción. Si una actualización provoca problemas, el daño queda limitado.
Nivel 1: Piloto
Una vez que los servidores «canary» han funcionado de forma estable durante un periodo determinado, los parches se transfieren a un grupo piloto. El grupo piloto incluye una variedad más amplia de tipos de servidores y puede incluir algunos sistemas de producción de nivel inferior. Durante esta fase se intensifica el seguimiento.
Ring 2: Implantación generalizada
Una vez completadas las fases «canary» y «pilot», las actualizaciones se implementan en la mayoría de los servidores. Esta fase suele llevarse a cabo durante los intervalos de mantenimiento programados e incluye comprobaciones automáticas del estado del sistema antes y después de la implementación. Los datos de las fases anteriores permiten a los equipos ajustar los plazos, el tamaño de los lotes y la secuencia antes de que la implantación alcance su máximo alcance.
Anillo 3: Crítico para la producción
Los servidores más sensibles suelen recibir los parches tras una validación satisfactoria en los anillos anteriores, a menos que la gravedad y la exposición de la vulnerabilidad exijan una corrección urgente. A estas alturas, el parche ha demostrado ser estable en cientos o miles de servidores más.
Las compuertas de retroalimentación automatizadas controlan el avance entre los anillos. Si las tasas de error se disparan o las comprobaciones de estado fallan en un anillo, la implementación se detiene antes de continuar. De este modo se evita que un parche problemático se propague en cadena por toda la flota.
La implementación basada en anillos funciona mejor cuando se integra con los procesos de gestión del cambio. Esa coordinación es la siguiente pieza del rompecabezas.
Coordinación de la aplicación de parches en los servidores entre los departamentos de operaciones de TI, seguridad y gestión de cambios
La aplicación de parches en los servidores rara vez es competencia exclusiva de un solo equipo. En un entorno informático complejo, el departamento de seguridad identifica las vulnerabilidades y establece los plazos para su corrección, mientras que el departamento de operaciones informáticas se encarga de los servidores y lleva a cabo las implementaciones; por su parte, la gestión de cambios regula cuándo y cómo se producen dichos cambios. Sin una coordinación clara entre estas funciones, los parches se quedan atascados en las colas de aprobación o se implementan sin la supervisión adecuada.
La claridad en las funciones resulta de gran ayuda. Un modelo habitual asigna las responsabilidades de la siguiente manera:
- Seguridad: Identifica vulnerabilidades, establece criterios de priorización y define los acuerdos de nivel de servicio (SLA) para la corrección de las mismas
- Operaciones de TI: Se encarga de mantener el inventario de servidores, aplicar parches y supervisar el estado de los servidores tras la aplicación de los parches
- Gestión del cambio: Aprueba los cambios, programa las ventanas de mantenimiento y documenta las excepciones
La aprobación del comité asesor de cambios (CAB) suele ser un requisito previo para la aplicación de parches en los servidores, especialmente en los sistemas de producción. La integración de los flujos de trabajo de aplicación de parches con plataformas de gestión de servicios de TI (ITSM), como ServiceNow, agiliza este proceso. Las solicitudes de parches se tramitan a través de tickets de cambio estándar, las aprobaciones se canalizan automáticamente en función del nivel del servidor y el estado de la implementación actualiza el ticket en tiempo real.
En el caso de las organizaciones en las que la aplicación de parches se presta como un servicio de TI, ya sea de forma interna o a través de un proveedor de servicios gestionados, este tipo de integración de flujos de trabajo es lo que permite una ejecución coherente y auditable a gran escala. Los proveedores de servicios gestionados (MSP), en particular, se benefician de esta integración, ya que les permite aplicar normas de aplicación de parches coherentes en múltiples entornos de clientes sin necesidad de crear flujos de trabajo personalizados para cada uno de ellos.
Muchos proveedores de servicios gestionados (MSP) ofrecen la aplicación de parches a través de plataformas de supervisión y gestión remotas (RMM), que proporcionan visibilidad y control centralizados en todos los entornos de los clientes, aunque estas plataformas difieren en su capacidad para gestionar las complejas dependencias de los servidores y la lógica de implementación por anillos.
La gestión de excepciones también requiere coordinación. Algunos servidores no pueden recibir las actualizaciones según lo previsto debido a restricciones empresariales, dependencias de los proveedores o limitaciones técnicas. La documentación de las excepciones, junto con los controles compensatorios, permite mantener las trazas de auditoría en buen estado y garantiza que los equipos de seguridad comprendan el riesgo residual.
En el caso de los servidores sin parches de que presentan un riesgo elevado, la integración de alertas en una plataforma de gestión de información y eventos de seguridad (SIEM) puede proporcionar la supervisión continua necesaria para detectar intentos de explotación hasta que sea posible aplicar las medidas correctivas.
Una vez implementados los parches y actualizados los registros de cambios, el último paso consiste en confirmar que todo ha funcionado correctamente.
Comprobación de que la aplicación de parches se ha realizado correctamente en todo su parque de servidores
La aplicación de un parche no equivale a su instalación correcta. Las actualizaciones pueden fallar por diversas razones: limitaciones de espacio en disco, conflictos entre programas, interrupciones en la red o requisitos de reinicio que no se han completado.
Sin una verificación, los equipos se basan en suposiciones en lugar de en hechos. Esa diferencia es la que distingue a un proceso de aplicación de parches maduro de uno que genera una falsa sensación de seguridad.
La posibilidad de realizar consultas en tiempo real en toda la flota es lo que hace que la verificación en bucle cerrado resulte viable a gran escala. En lugar de realizar comprobaciones aleatorias en una muestra y dar por sentado el resto, los equipos pueden confirmar el estado de los parches en todos los servidores gestionados a los pocos minutos de su implementación, y las instalaciones fallidas se detectan automáticamente para su corrección.
La verificación posterior a la implementación responde a tres preguntas:
- ¿Se ha instalado el parche? Compruebe que el sistema operativo o el gestor de paquetes haya registrado la actualización y que esta refleje el estado esperado del paquete, el número de conocimiento (KB), la compilación o la versión.
- ¿Ha surtido efecto el parche? Confirme que se han completado los reinicios necesarios del sistema o de los servicios y que la versión del núcleo o del servicio en ejecución refleja el estado corregido.
- ¿Le ha causado algún problema la actualización? Compruebe que las comprobaciones de estado y los indicadores de nivel de servicio (registros, índices de error, latencia) sean correctos y confirme las rutas de reversión o conmutación por error en caso de que surjan problemas.
La verificación automatizada permite aplicar este proceso a flotas de gran tamaño. En lugar de realizar comprobaciones aleatorias en una muestra de servidores, los equipos pueden consultar cada servidor en tiempo real para confirmar el estado de los parches. Los servidores en los que ha fallado la instalación se marcan para su corrección. Los servidores cuya instalación se haya completado con éxito actualizan sus registros en la base de datos de gestión de la configuración (CMDB).
La verificación cierra el ciclo. Convierte la aplicación de parches de una actividad de implementación en una actividad de reducción de riesgos con resultados cuantificables.
Mantener la preparación para las auditorías en materia de cumplimiento de los parches de los servidores
Los marcos normativos, entre los que se incluyen PCI DSS, HIPAA y DORA (Ley de Resiliencia Operativa Digital de la UE), exigen a las organizaciones que documenten y demuestren sus prácticas de gestión de parches y vulnerabilidades.
Los auditores no solo quieren saber si se han instalado los parches. Quieren pruebas: registros de implementación, informes de cobertura, documentación sobre excepciones y plazos de corrección. Una política de gestión de parches documentada —que defina funciones, plazos, procedimientos de excepción y vías de escalación— suele ser el primer documento que solicitan los auditores, y su ausencia es una deficiencia habitual en las revisiones de cumplimiento.
La preparación para una auditoría comienza con un mantenimiento sistemático de los registros. Cada implementación de un parche genera registros que responden a las siguientes preguntas:
- ¿Qué servidores fueron objeto del ataque?
- ¿Qué parches se han implementado?
- ¿Cuándo tuvo lugar el despliegue?
- ¿Cuál fue la tasa de éxito?
- ¿Qué servidores fallaron y qué medidas correctoras se adoptaron?
- ¿Qué servidores quedaron excluidos y qué controles compensatorios existen?
La integración de las herramientas de aplicación de parches con las plataformas CMDB e ITSM permite centralizar esta información. Cuando un auditor solicita información sobre la cobertura de parches en los servidores sujetos a la normativa PCI, la respuesta se obtiene mediante una consulta, en lugar de una conciliación manual en una hoja de cálculo.
| Marco de cumplimiento normativo | Requisitos de aplicación de parches | Advertencia importante |
|---|---|---|
| PCI DSS | Aplicación oportuna de parches de seguridad en función del riesgo | Las organizaciones suelen fijar un plazo de 30 días para las vulnerabilidades críticas y plazos más largos para los problemas de menor riesgo, aunque los plazos concretos deben confirmarse con su evaluador de seguridad cualificado (QSA). |
| HIPAA | Corrección oportuna de las vulnerabilidades que afectan a los sistemas de ePHI | La normativa no establece plazos concretos, por lo que estos deben determinarse mediante un análisis de riesgos de la organización y confirmarse con el departamento jurídico o de cumplimiento normativo. |
| DORA | Requisitos de gestión de riesgos en materia de TIC que abarcan los procesos relacionados con las vulnerabilidades y las actualizaciones de seguridad | Se aplica a las entidades financieras que operan en la UE y a sus proveedores externos de TIC críticos designados; los requisitos se basan en principios y los plazos específicos para la aplicación de parches se definen dentro del marco de gestión de riesgos de TIC de cada organización. |
| NIST SP 800-40 , Rev. 3 | Ciclo de vida formal de la gestión de parches con controles de pruebas e implementación | Proporciona un marco de referencia; los plazos y controles específicos se definen en función de la implementación y no son exigidos por el NIST. |
La documentación sobre excepciones merece una atención especial. Los auditores son conscientes de que no todos los servidores pueden recibir las actualizaciones de seguridad de forma inmediata. Lo que buscan son pruebas de que las excepciones se registran, se someten a una evaluación de riesgos y se complementan con controles compensatorios.
Un servidor al que no se le puedan aplicar parches debido a restricciones del proveedor podría contar con la segmentación de la red o una supervisión mejorada como controles compensatorios.
Cómo Tanium facilita la gestión de parches en los servidores
La plataforma de TI autónoma de Tanium, « », aborda la gestión de parches de servidores como un proceso continuo basado en datos. Consulta directamente los puntos finales en lugar de basarse en instantáneas de la base de datos o en ciclos de análisis programados, por lo que las decisiones se basan en la situación actual, y no en la que existía en el momento del último análisis.
Los equipos de operaciones y seguridad de TI obtienen una visión actualizada de qué servidores carecen de parches, cuáles están listos para recibirlos y cuáles requieren un aplazamiento, tanto en Windows, Linux como en macOS , todo ello desde una única consola.
- Visibilidad de los terminales en tiempo real: Estado actual de los parches a petición en Windows, Linux y macOS, no resultados de análisis periódicos
- Priorización basada en el riesgo: . Datos sobre vulnerabilidades combinados con EPSS, KEV de la CISA, la importancia crítica de los activos y las puntuaciones de confianza, con el fin de centrar los esfuerzos allí donde se reduzca más el riesgo.
- Puntuaciones de confianza (Windows): Información predictiva sobre el impacto de la implementación de parches de Windows , basada en las tasas de éxito de la instalación, la frecuencia de fallos y las métricas de rendimiento, antes de su implantación generalizada, con puntuaciones derivadas de datos de telemetría de implementación anonimizados de los clientes participantes, de modo que la información refleja el comportamiento real de los parches, y no meras suposiciones.
- Implementación progresiva basada en anillos: Implementaciones por fases que validan los resultados en función de umbrales de confianza antes de ampliar la escala, en las que los servidores críticos se actualizan en último lugar, de modo que los sistemas de producción y los sistemas críticos para el negocio se benefician de la validación en los anillos anteriores antes de que se les apliquen los cambios.
- Guías de automatización reguladas: Flujos de trabajo de varios pasos basados en condiciones, con controles de autorización del operador y registros de auditoría completos
- Aplicación de parches a software de terceros: Plantillas integradas para la aplicación de parches a aplicaciones y actualizaciones de terceros, sin necesidad de obtener manualmente los paquetes de los sitios web de los proveedores
- Inteligencia sobre amenazas de Tanium Guardian: Alertas oportunas y orientación específica para la corrección de numerosas vulnerabilidades críticas y de día cero, con el respaldo de Tanium VERT, que detecta las amenazas emergentes y envía medidas de corrección específicas directamente a la consola sin necesidad de cambiar de herramienta.
- Validación en bucle cerrado: . Confirmación tras la implementación del estado de los parches en todos los terminales gestionados, con detección rápida de las instalaciones fallidas.
- Evaluación de cumplimiento: Evaluaciones basadas en SCAP y OVAL, alineadas con los controles técnicos pertinentes a PCI, HIPAA, SOX y otros marcos normativos, con actualizaciones diarias de los contenidos
- Informes para la preparación de auditorías: Informes a nivel organizativo y de dispositivos con seguimiento de excepciones y paneles de control de cumplimiento
- Integración con ITSM: Flujos de trabajo de parches conectados a ServiceNow y otras herramientas de ITSM, con actualizaciones automáticas del estado de los tickets
- Operaciones asistidas por IA: Consultas en lenguaje natural para la gestión de datos de puntos finales, la investigación y la gestión de software, con un proceso de autorización en el que interviene el ser humano, lo que garantiza que las acciones automatizadas estén controladas y sean auditables
Las capacidades y los resultados descritos se basan en la documentación del producto Tanium, en casos prácticos de clientes validados y en el uso real. Los resultados reales pueden variar en función del entorno de implementación, la configuración y el grado de madurez de la organización.
Resultados en la práctica: una única fuente de información fiable para el cumplimiento de los parches de los servidores
Antes de Tanium, Honeywell carecía de un método fiable para medir el cumplimiento de forma coherente en todos los equipos: los equipos de seguridad y de operaciones de TI realizaban un seguimiento de métricas diferentes, y las discrepancias sobre las cifras eran habituales.
Tanium proporcionó a ambos equipos visibilidad sobre los mismos datos, por lo que las cifras de cumplimiento eran coherentes, independientemente de si procedían del departamento de seguridad o del de operaciones de TI. Esa coherencia proporcionó al equipo de TI de Honeywell la confianza necesaria para presentar cifras precisas tanto a los altos directivos como a los responsables de los servicios.
«. Antes de utilizar Tanium, nuestro nivel de cumplimiento en materia de parches era bajo». Ahora, gracias a Tanium, hemos superado el umbral del 90 % de cumplimiento en la aplicación de parches durante tres meses consecutivos. Eso es significativo.»Manish Chopra, director de TI de Honeywell
Preguntas frecuentes sobre la gestión de parches para servidores
La aplicación de parches en los servidores plantea retos de coordinación que las guías genéricas sobre gestión de parches suelen pasar por alto. A continuación se recogen las preguntas más habituales que se plantean los equipos de las empresas a la hora de crear o mejorar los programas de aplicación de parches en los servidores.
¿En qué se diferencia la aplicación de parches en los servidores de la aplicación de parches en los terminales?
Por lo general, los servidores ejecutan 24/7 cargas de trabajo con ventanas de mantenimiento muy limitadas, mientras que los terminales pueden reiniciarse durante el tiempo de inactividad de los usuarios. Los servidores también presentan dependencias más complejas, lo que significa que una actualización en un servidor puede afectar a las aplicaciones que se ejecutan en otros.
El alcance de las consecuencias de un parche fallido en un servidor suele ser mayor que el de un parche fallido en un terminal, lo que modifica la forma en que los equipos abordan las pruebas, la implementación en entornos de prueba y la planificación de la reversión.
¿Durante cuánto tiempo pueden los servidores funcionar de forma segura sin aplicar parches?
No existe una respuesta universal. Las vulnerabilidades críticas incluidas en la lista KEV de la CISA requieren una atención inmediata, ya que los atacantes las están aprovechando activamente. En el caso de otras vulnerabilidades, el plazo depende de factores como la exposición del servidor, los controles compensatorios y las limitaciones empresariales.
Los requisitos de cumplimiento varían en función del marco y del contexto de riesgo. En el marco de la norma PCI DSS, las organizaciones suelen aplicar los acuerdos de nivel de servicio (SLA) relativos a los parches en función del riesgo (fijando a menudo un plazo aproximado de 30 días para las vulnerabilidades de alto riesgo y plazos más largos para los problemas de menor riesgo), junto con excepciones documentadas y controles compensatorios.
Los equipos que superan los plazos establecidos acumulan tanto riesgos de seguridad como incidencias de auditoría.
¿Qué ocurre cuando no es posible aplicar los parches a un servidor en la fecha prevista?
Documente la excepción, evalúe el riesgo residual e implemente controles compensatorios. Entre las medidas compensatorias podrían figurar la segmentación de la red para limitar la exposición, una supervisión reforzada para detectar intentos de explotación o controles a nivel de aplicación que mitiguen el impacto de la vulnerabilidad. Los auditores esperan poder examinar dicha documentación, junto con un plan para la corrección de las deficiencias.
¿Cómo gestionan los equipos las actualizaciones que requieren reiniciar los servidores que están siempre en funcionamiento?
Entre las opciones se incluyen tecnologías de aplicación de parches en tiempo real (disponibles para algunas actualizaciones del núcleo de Linux de en determinadas distribuciones y en virtud de acuerdos de soporte), la conmutación por error a servidores redundantes durante la ventana de reinicio, o la programación de reinicios durante períodos de bajo tráfico con notificación a las partes interesadas.
El enfoque adecuado depende de la función del servidor, de la tolerancia de la organización ante los tiempos de inactividad y de si existe redundancia. Algunas actualizaciones de seguridad solo requieren un reinicio del sistema o de los servicios para activarse, y tener en cuenta esta circunstancia forma parte de la disciplina de aplicación de parches en los servidores.
Un parche que esté instalado pero no aplicado sigue dejando la vulnerabilidad sin solucionar. En la práctica, la coordinación de los reinicios suele ser el verdadero cuello de botella, y no la propia implementación de parches, especialmente en el caso de los sistemas en clúster y los servicios críticos para el negocio.
En el caso de los servicios de producción, los planes de aplicación de parches también deben incluir criterios de reversión y una ruta de recuperación, como instantáneas cuando sea pertinente, o la conmutación por error en entornos en clúster y de alta disponibilidad (HA).
Noticias de actualidad sobre la aplicación de parches en los servidores
Las últimas novedades que debe conocer
¿Ha afectado a su organización la vulnerabilidad «zero-day» de PeopleSoft de Oracle?
Oracle ha subsanado una vulnerabilidad de día cero en PeopleSoft que había sido aprovechada por actores maliciosos para sustraer datos de decenas de organizaciones; ya están disponibles parches y medidas de mitigación para las instancias expuestas a Internet.
¿Se han aplicado los parches correspondientes a las vulnerabilidades CVSS 10.0 en sus servidores de Ivanti, Fortinet y SAP?
Fortinet, Ivanti y SAP han corregido vulnerabilidades críticas con una puntuación CVSS de hasta 10.0 en sus productos de servidores empresariales; Ivanti Sentry CVE-2026-10520 figura en el catálogo KEV de la CISA tras haberse confirmado su explotación.
¿Qué correcciones para servidores incluyó la actualización del «Patch Tuesday» de Microsoft, que batió todos los récords?
June 2026 El «Patch Tuesday» ha corregido 206 vulnerabilidades, entre las que se incluyen una vulnerabilidad de suplantación de identidad en Exchange Server y una vulnerabilidad de ejecución remota de código (RCE) en el núcleo con puntuación CVSS de 9.8 que permite la propagación mediante gusanos; se trata de la mayor actualización individual lanzada por Microsoft hasta la fecha.
Vulnerabilidad crítica de ejecución remota de código (RCE) en Netlogon (CVE-2026-41089): lo que deben saber los equipos de servidores
La vulnerabilidad CVE-2026-41089, un desbordamiento de pila en Netlogon, permite la ejecución remota de código sin autenticación en los controladores de dominio; Tanium detalla el alcance de la vulnerabilidad y los pasos para aplicar los parches con rapidez.
La aplicación de parches en servidores a escala empresarial requiere algo más que una lista de comprobación. Esto requiere visibilidad en tiempo real, priorización basada en el riesgo, implementación por fases y la verificación de que los parches hayan reducido efectivamente la exposición.
Tanium reúne todas estas capacidades en una única plataforma, lo que ayuda a los equipos de TI y de seguridad a aplicar parches a los servidores con confianza, en lugar de basarse en conjeturas. Concierte una demostración gratuita en para ver hoy mismo cómo funciona Tanium.
