Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Existen cinco tipos distintos de aplicación de parches —tradicional, virtual, de firmware, en tiempo real y en la nube/contenedor—; cada uno de ellos presenta su propio perfil de tiempo de inactividad, riesgo y cumplimiento normativo.
- La mayoría de los equipos siguen recurriendo por defecto a la estrategia de «aplicar parches y reiniciar», lo que deja los sistemas expuestos durante días o semanas mientras se acumulan las ventanas de cambio.
- La aplicación de parches en tiempo real permite aplicar correcciones al núcleo y a las bibliotecas en sistemas en funcionamiento sin necesidad de reiniciar, lo que reduce el tiempo de reparación de semanas a horas.
- La estrategia de aplicación de parches adecuada depende de tus requisitos de tiempo de actividad, de los acuerdos de nivel de servicio (SLA) reglamentarios y de qué capas de tu infraestructura son realmente de tu propiedad.
Son las 23:00 de un domingo. Alguien de tu equipo está supervisando una ventana de mantenimiento porque tres servidores de producción necesitan un parche CVE para el kernel, y la única forma segura de aplicarlo —según el manual de 2014— es reiniciar. El parche en sí ocupa dos megabytes. El tiempo de inactividad es de 40 minutos por host. Multiplica eso por una flota de unos cientos de servidores y toda esa «corrección de seguridad rápida» se convierte en un cuarto de hora que no recuperas.
Por eso es tan importante el tipo de aplicación de parches que elijas. El enfoque adecuado puede reducir el tiempo de mantenimiento de horas a segundos, o incluso eliminarlo por completo. El enfoque incorrecto te mantiene expuesto a una vulnerabilidad CVE conocida durante semanas, ya que no consigues la autorización para reiniciar el sistema.
Algunos de los métodos denominados «parches» ni siquiera son eso. Esta es tu guía completa para entender las diferentes opciones de parches que hay en el mercado.
¿Qué es la aplicación de parches de software?
La aplicación de parches de software es tanto un proceso informático como una práctica de seguridad fundamental. Por lo general, se describe como el proceso de corregir problemas o añadir funciones a un sistema determinado mediante la incorporación o sustitución de componentes existentes por otros actualizados. Esto puede llevarse a cabo a muchos niveles diferentes, como la actualización del código a nivel de subsistema, de dependencias o de funcionalidades básicas. Del mismo modo, se pueden aplicar parches a aplicaciones específicas, sistemas operativos, controladores o cualquier otro componente.
Aunque el objetivo siempre es disponer de una versión más actualizada de lo que se está parcheando, la forma de lograrlo es lo que distingue a los distintos enfoques de aplicación de parches; y el hecho de tratarlos como si fueran todos iguales es lo que lleva a los equipos a acabar con vulnerabilidades sin parchear que permanecen en el entorno de producción durante meses.
Al igual que otros términos del ámbito de la informática, como «depuración», el término «patching» tiene su origen en un proceso físico. Se refería a la acción real de tapar los agujeros de las tarjetas perforadas; es decir, se «parcheaba» una sección del código. Parece que este término ha caído en desuso, por lo que nos centraremos en los enfoques más modernos.
La diferencia entre un parche, una actualización y una versión completa
Antes de entrar en los distintos tipos de parches, conviene aclarar una cuestión terminológica que, en la práctica, genera una gran confusión. Los términos «parche», «actualización» y «versión completa» se utilizan indistintamente —a veces incluso por la misma persona en una misma conversación—, pero describen conceptos significativamente diferentes, sobre todo a la hora de definir el alcance de un trabajo o de hablar con un auditor de cumplimiento.
|
Parche |
Actualización |
Comunicado completo |
|
|
Definición |
Solución específica para un error concreto, un CVE o una regresión |
Paquete de parches y pequeñas mejoras |
Nueva versión principal con cambios en la arquitectura o en las funciones |
|
Alcance |
Pequeño: a menudo se trata de un único archivo binario o módulo del núcleo |
Moderado – múltiples componentes |
Amplio: todo el producto; en ocasiones, nuevas dependencias |
|
Repercusiones del tiempo de inactividad |
Mínimo o nulo (con patching en directo, cero) |
Normalmente es necesario reiniciar el sistema o el servicio |
Importante: puede requerir un plan de migración |
|
Desencadenante típico |
Divulgación de CVE, corrección de emergencia, informe de regresión |
Con periodicidad mensual o trimestral |
Hito de la hoja de ruta, fin de la vida útil de la versión anterior |
Una regla general bastante acertada: si puedes describir el cambio en una sola frase, se trata de un parche. Si viene acompañado de notas de la versión que superan un párrafo, es una actualización. Si incluye una guía de migración, se trata de una versión completa.
Hay algo que la tabla no refleja: a veces los proveedores etiquetan erróneamente las actualizaciones para que parezcan menos disruptivas. Una «actualización menor» que cambia discretamente el controlador de la base de datos subyacente se acerca más, en la práctica, a una versión completa. Lee el registro de cambios antes de fiarte de la etiqueta.
Principales tipos de parches: un análisis detallado
Los tipos que se enumeran a continuación abarcan la gran mayoría de los casos con los que se encontrarán la mayoría de los equipos de seguridad y DevOps. Algunos se solapan —un parche de firmware es también un parche de seguridad, y la aplicación de parches en tiempo real se aplica tanto a los servidores Linux tradicionales como a las cargas de trabajo en contenedores—. Las categorías no son mutuamente excluyentes, pero cada una de ellas describe un mecanismo de implementación distinto con su propio perfil operativo.
Remiendo tradicional
Esto es lo que la mayoría de la gente reconocerá como parchear. Consiste en descargar versiones actualizadas de un determinado software y, a continuación, sustituir los archivos correspondientes en el disco por las nuevas versiones.
Es relativamente sencillo de implementar y fácil de entender: tienes una versión antigua de un software determinado que se sustituye por una nueva, ya sea total o parcialmente. Es necesario reiniciar la aplicación o el sistema para que se aplique la nueva versión, pero no hay ningún otro paso adicional. Por supuesto, ahí radica también el mayor inconveniente: reiniciar aplicaciones o reiniciar sistemas completos es una operación lenta que provoca una interrupción significativa en cualquier carga de trabajo que se esté ejecutando. Debido a esto, no es algo que se pueda hacer de manera ad hoc, por lo que suele llevarse a cabo en lo que se denomina una «ventana de mantenimiento»: un periodo de tiempo previamente aprobado en el que se espera que los sistemas tengan problemas de disponibilidad o rendimiento.
La implementación de este proceso es lenta y, en caso de que surjan problemas, tiende a sobrepasar los plazos previstos. Según un informe del Ponemon Institute patrocinado por TuxCare, el 56 % de las organizaciones tarda entre cinco semanas y un año en solucionar vulnerabilidades críticas o de alta prioridad, y más del 55 % informó haber sufrido un incidente de ciberseguridad causado por un parche que ya estaba disponible pero que no se había aplicado. Ese retraso se debe, en su gran mayoría, a la programación de las ventanas de cambio, no a la instalación en sí.
Úsalo cuando dispongas de un margen de mantenimiento aceptable, un entorno de pruebas estable y no haya restricciones de cumplimiento que exijan una corrección más rápida. No lo utilices como única estrategia si ejecutas cualquier cosa que no admita un reinicio periódico.
Parcheado virtual
Se trata de una solución que incluye la palabra «parche» en su nombre y que, a primera vista, parece ofrecer resultados de parcheo, pero que, en realidad, funciona a un nivel completamente diferente. El parcheo virtual no implica ninguna sustitución ni corrección real del código. Consiste en implementar la detección de amenazas a nivel del cortafuegos, bloqueando los patrones de ataque conocidos. Desde el punto de vista del atacante, el ataque fracasa, por lo que este podría suponer que el sistema está parcheado cuando, en realidad, no lo está.
Este método de «parcheo» presenta varias desventajas: en realidad, el código corregido no llega a incorporarse a los sistemas en ningún momento; la protección solo cubre los patrones de ataque conocidos —lo que deja de lado inmediatamente los problemas de ámbito local—; y puede eludirse mediante modificaciones en el tráfico de red correspondientes a una amenaza concreta.
Si las desventajas no descartan de inmediato este enfoque, entre las ventajas se incluyen la ausencia de interrupciones (ya que, en realidad, no se realiza ninguna acción dentro del sistema), la posibilidad de que una única implementación cubra varios sistemas y la protección inmediata frente a nuevas amenazas exclusivamente remotas a medida que van surgiendo.
Considera los parches virtuales como una medida de emergencia, no como una solución definitiva. Cuando se da a conocer una vulnerabilidad grave y tu equipo necesita días, en lugar de semanas, para implementar la solución definitiva, un parche virtual te da un respiro muy valioso. Sin embargo, si sigue activo seis meses después de la revelación, habrás dejado de aplicar parches y habrás empezado a jugártela.
Úsalo cuando necesites mitigar una vulnerabilidad CVE más rápido de lo que tardarías en aplicar la solución definitiva, o si estás utilizando software al final de su ciclo de vida que ya no recibe parches del proveedor.
Parcheado de firmware
La actualización del firmware es un caso específico de la aplicación tradicional de parches, con la particularidad añadida de que se actualiza el código contenido en soportes de almacenamiento que suelen ser difíciles de actualizar, directamente en chips EPROM (memoria de solo lectura programable y borrable). Esto solía ser lo habitual en los primeros dispositivos inteligentes y en los dispositivos IoT de primera generación. El software se cargaba en fábrica y rara vez —si es que alguna vez— recibía actualizaciones. Esto se debía, en parte, a que la actualización y la seguridad no eran preocupaciones prioritarias como lo son hoy en día, pero también a que la forma en que se almacenaba el software dificultaba su actualización. Los dispositivos más recientes tendrán el código, total o parcialmente, escrito en soportes más estándar, como SSD, tarjetas SD o similares, que son mucho más fáciles de modificar.
Cuando el código se ejecutaba en chips que debían conectarse a equipos de escritura especializados, con requisitos de software y cables propietarios, se añadía un nivel de complejidad que hacía que todo el proceso resultara muy poco atractivo para la mayoría de los equipos de TI. Como consecuencia, esos dispositivos nunca llegaban a recibir ninguna actualización a lo largo de toda su vida útil. Por desgracia, muchos de ellos siguen en uso: los servidores de impresión, las cámaras IP y los sensores de los centros de datos son buenos ejemplos de dispositivos que funcionan de esta manera.
La aplicación de parches de firmware es también el tipo de actualización que entraña mayores riesgos operativos. Una actualización fallida de la BIOS deja el equipo inservible, y la respuesta habitual cuando se trata de revertir el cambio suele ser «no se puede». Los fabricantes no son uniformes en cuanto a la frecuencia con la que lanzan actualizaciones de firmware ni a la fiabilidad con la que las prueban: los fabricantes de servidores suelen ser fiables, pero en el caso del hardware para el Internet de las cosas (IoT) y de consumo, la cosa cambia.
En el caso de los dispositivos IoT y embebidos que funcionan con Linux, existe una solución intermedia que conviene conocer. KernelCare IoT de TuxCare ofrece la aplicación de parches al núcleo sin necesidad de reiniciar para dispositivos ARM64 —compatible con Raspberry Pi, Ubuntu y distribuciones basadas en Yocto en distintos chipsets, como Arm Neoverse, NXP y AWS Graviton, con integración en Microsoft Azure IoT Hub para la gestión de flotas—, lo que evita por completo el problema tradicional de las actualizaciones de firmware en la capa del núcleo.
Úsalo con una periodicidad definida —trimestralmente es razonable para la mayoría de las flotas—, siempre tras realizar pruebas en equipos representativos, y nunca omitas el paso de verificación posterior a la actualización.
Parches en vivo
La corrección en tiempo real es el proceso de modificar el código en ejecución y sustituir secciones o funciones que contienen errores conocidos por versiones corregidas de esas mismas secciones. Esto se lleva a cabo íntegramente en memoria y no requiere reiniciar la aplicación para que se apliquen los nuevos cambios. En un momento dado, el software contiene un error en una función; al instante siguiente, se utiliza en su lugar una versión corregida de esa función.
No hay reinicios, ni reinicios del sistema, ni interrupciones. Por ello, los parches se pueden implementar de inmediato: la operación no requiere una ventana de mantenimiento, lo que permite responder más rápidamente a las amenazas emergentes. En lugar de esperar semanas o meses a que se implemente un parche, como ocurre con los métodos tradicionales, ahora se puede hacer en cuestión de horas o incluso minutos desde que el parche está disponible.
La mayor complejidad del «live patching» surge en el momento de crear el parche. El parche debe crearse de tal manera que pueda cargarse en el espacio de memoria adecuado utilizando los mismos tamaños de variable y alineaciones que el código original. Esta complejidad queda oculta para los usuarios de una solución de «live patching»: solo es visible para el proveedor del parche en tiempo real.
Hace ya más de 10 años que existe un subsistema de aplicación de parches en tiempo real capaz de implementar parches en el núcleo de Linux, y se han creado múltiples soluciones diferentes. KernelCare de TuxCare es una de esas soluciones, que gestiona la aplicación de parches en tiempo real del núcleo de Linux en todas las principales distribuciones. LibCare amplía esto a las bibliotecas críticas del espacio de usuario —incluidas OpenSSL y glibc, que sustentan el cifrado y las llamadas al sistema básicas en prácticamente todas las cargas de trabajo de Linux— sin necesidad de reiniciar el servicio. Juntas, cubren la superficie de ataque de mayor riesgo en un servidor Linux sin afectar a la ventana de mantenimiento.
También existen muchas variantes del parcheo en tiempo real, entre las que se incluyen enfoques temporales y permanentes, dependiendo de si el proceso de parcheo en tiempo real se aplica como una solución provisional o como una alternativa más duradera al parcheo tradicional.
Úsalo cuando utilices Linux a una escala significativa, ejecutes cargas de trabajo reguladas con SLA de resolución estrictos o tengas partes interesadas que consideren cualquier reinicio no planificado como un incidente crítico.
Actualización de parches en la nube y en contenedores
Las cargas de trabajo en la nube y en contenedores modifican el modelo de formas que conviene comprender bien, ya que los supuestos que se aplican a los servidores tradicionales no se pueden trasladar sin más.
Normalmente, los contenedores se corrigen recompilando la imagen e implementando una nueva versión: el contenedor antiguo se sustituye por uno nuevo que incorpora la corrección. En la mayoría de los flujos de trabajo se evita deliberadamente modificar sobre la marcha un contenedor en ejecución; la inmutabilidad es el principio de diseño, y es un principio sólido. Sin embargo, esto implica que una imagen base vulnerable puede seguir presente de forma silenciosa en muchos contenedores en ejecución si el proceso de recompilación no está bien controlado.
En los entornos en la nube, la responsabilidad se distribuye según el modelo de responsabilidad compartida. Con IaaS, el proveedor se encarga de las actualizaciones del hipervisor y los hosts físicos; usted es responsable del sistema operativo invitado, el tiempo de ejecución y la capa de aplicaciones. Con PaaS, el proveedor se ocupa de una mayor parte de la pila. Con SaaS, usted se ocupa principalmente de los agentes y las integraciones. Saber exactamente de qué capa es responsable es la mitad del camino: muchos equipos han salido muy mal parados al dar por sentado que «la nube se encarga de ello» en casos en los que el proveedor no lo cubre explícitamente.
Lo que el modelo de contenedores no cambia: el núcleo de Linux que subyace al entorno de ejecución del contenedor sigue necesitando parches. Se trata de sistemas reales que ejecutan núcleos reales con vulnerabilidades CVE reales, y la aplicación de parches en tiempo real se aplica a ellos igual que a cualquier otro host Linux.
Úsalo cuando ejecute Kubernetes, ECS o cualquier plataforma de orquestación de contenedores. Combine la reconstrucción de imágenes con la aplicación de parches en tiempo real o la aplicación de parches tradicional para el sistema operativo del host subyacente: la abstracción del contenedor no hace que el núcleo que hay debajo sea mágicamente seguro.
Cómo elegir la estrategia de aplicación de parches adecuada
Hay muchas formas de abordar la aplicación de parches, y ningún método por sí solo sirve para todas las situaciones. La elección adecuada depende de una combinación de factores —algunos técnicos, otros organizativos— que, en conjunto, te inclinan hacia un enfoque u otro.
Algunas de las variables más importantes:
Requisitos de tiempo de actividad: Si un reinicio de 5 minutos no supone ningún problema, la aplicación de parches tradicional cubre la mayoría de los casos. Si el tiempo de inactividad no planificado es un incidente crítico, la aplicación de parches en tiempo real cambia significativamente la ecuación.
Acuerdos de nivel de servicio (SLA) para la corrección de incidencias: Normativas como PCI DSS e HIPAA especifican la rapidez con la que deben aplicarse los parches críticos. Si su SLA es de 30 días y sus ventanas de cambio son mensuales, no tiene margen para que algo salga mal.
Composición de la pila: Las flotas con gran presencia de Linux son las que más se benefician de los parches en tiempo real. Las flotas de Windows se basan en los parches tradicionales, utilizando los parches virtuales como solución provisional. Los dispositivos integrados y de IoT necesitan parches de firmware, en los que la mayoría de los equipos invierten de forma crónicamente insuficiente.
Madurez operativa: Los entornos de pruebas automatizados y los procedimientos sólidos de reversión determinan qué estrategias son viables. Sin ellos, cada tipo de parche conlleva más riesgo del que debería.
Un marco práctico para situaciones habituales:
- Tiempo de actividad innegociable, parque de servidores Linux → aplicación de parches en tiempo real para el núcleo y las bibliotecas compartidas críticas, aplicación de parches tradicional para todo lo demás con una periodicidad flexible
- Ventanas de mantenimiento aceptables, entorno homogéneo → la aplicación tradicional de parches con un alto grado de automatización cubre la mayoría de las necesidades
- Atrapado con un software al final de su ciclo de vida que aún no puedes sustituir → la aplicación de parches virtuales, junto con una supervisión exhaustiva, es la única solución provisional sensata
- El parque incluye servidores físicos, equipos de red o dispositivos IoT → presupuestar la aplicación de parches de firmware como un programa independiente, separado de la aplicación de parches del sistema operativo
Para cualquier organización que se preocupe, aunque sea mínimamente, por la seguridad de sus sistemas, datos y usuarios, la aplicación de parches es una de las cuestiones fundamentales que debe abordarse tanto a nivel estratégico como operativo. Cada entorno tiene sus propias particularidades; asegúrate de elegir el proceso adecuado para tu situación específica.
¿Sigues reiniciando el equipo para instalar parches? Hay una forma mejor.
Si tu flujo de trabajo actual consiste en «programar un reinicio, esperar que nada falle y repetir al mes siguiente», estás asumiendo más gastos generales de los necesarios y aceptando un periodo de vulnerabilidad más largo de lo que deberías. Los parches en tiempo real existen porque el modelo del «reinicio como necesidad» no es una ley física, sino un hábito heredado de una época en la que no había alternativa.
KernelCare y LibCare de TuxCare ofrecen la aplicación de parches en tiempo real para los núcleos de Linux y las bibliotecas compartidas críticas —incluidas OpenSSL y glibc— en todas las principales distribuciones. Los mismos servidores, sin reinicios y sin necesidad de ventanas de mantenimiento para los parches de seguridad. Y si tu parque de dispositivos incluye dispositivos IoT o integrados, KernelCare IoT amplía esta misma aplicación de parches sin reinicio a los dispositivos ARM64 que ejecutan distribuciones basadas en Raspberry Pi, Ubuntu y Yocto.
Preguntas frecuentes
Sí. Los parches son código, y el código tiene errores. La regresión —es decir, cuando una corrección estropea algo que antes funcionaba o introduce un nuevo fallo— es un riesgo conocido y documentado. Por eso un entorno de pruebas que refleje el de producción no es opcional, y por eso los lanzamientos por fases son preferibles a una implementación simultánea en toda la flota.
Por lo general, se trata de una responsabilidad compartida entre los equipos de operaciones de TI, seguridad y los equipos de aplicaciones responsables de cargas de trabajo específicas. El equipo de seguridad define el SLA y establece las prioridades en función de la gravedad de los CVE. El equipo de operaciones se encarga de la implementación. Los responsables de las aplicaciones comprueban que todo funcione correctamente. En las organizaciones más pequeñas, una sola persona desempeña las tres funciones.
Parches de seguridad críticos: tan pronto como lo permita el SLA, idealmente entre 7 y 14 días tras su publicación por parte del proveedor. Actualizaciones rutinarias: lo habitual es realizarlas mensualmente. Firmware: trimestralmente en la mayoría de las flotas. Cuanto antes se puedan aplicar los parches sin provocar fallos, menor será el periodo de exposición; y la aplicación de parches en tiempo real es la principal forma de acortar ese plazo sin sacrificar el rigor de las pruebas.
La aplicación de parches soluciona vulnerabilidades específicas conocidas mediante la implementación de los cambios de código publicados por los proveedores. El refuerzo del sistema reduce la superficie de ataque global mediante la configuración: desactivando los servicios que no se utilizan, aplicando el principio del mínimo privilegio y endureciendo las reglas del cortafuegos. Los parches subsanan las vulnerabilidades conocidas; el refuerzo del sistema dificulta el aprovechamiento de las desconocidas. Se necesitan ambos.
Sí. Los contenedores heredan las vulnerabilidades de sus imágenes base, y el sistema operativo anfitrión que subyace al entorno de ejecución del contenedor sigue siendo un sistema Linux que necesita parches para el núcleo. El modelo cambia —se trata de reconstruir la imagen en lugar de modificar el contenedor en ejecución—, pero la obligación no desaparece. El modelo de responsabilidad compartida divide la responsabilidad de aplicar los parches; no la elimina.
