Cuando un proveedor publica un parche, los atacantes pueden obtener pistas sobre la vulnerabilidad que este corrige. Es precisamente en ese intervalo entre la publicación del parche y su instalación verificada en todos sus dispositivos donde se acumula el riesgo.
En esta guía se explica cómo funcionan técnicamente los parches, los diferentes tipos de parches con los que se encontrará y por qué la verificación es tan importante como la implementación.
Qué hace realmente un parche de software
Un parche de software es un pequeño fragmento de código que modifica un programa o un sistema operativo ya existente. Los parches corrigen errores, solucionan vulnerabilidades de seguridad o mejoran el rendimiento. A diferencia de una actualización completa del software o del lanzamiento de una nueva versión, un parche se centra en resolver problemas concretos sin sustituir la aplicación en su totalidad.
Cuando un proveedor detecta un fallo, ya sea un error de programación que provoque fallos del sistema o una de las muchas vulnerabilidades conocidas que los atacantes podrían aprovechar, desarrolla un parche para corregirlo. El parche sobrescribe o modifica archivos específicos, entradas del Registro o parámetros de configuración en el sistema de destino. Piense en ello como si se tratara de sustituir un único componente defectuoso de una máquina, en lugar de cambiar todo el motor.
Los parches se distribuyen a través de los sitios web de los proveedores, de actualizaciones automáticas como Windows Update, de tiendas de aplicaciones o de herramientas de gestión de parches para empresas. Una vez instalado, el parche modifica el comportamiento del software al alterar el código subyacente que provocaba el problema.
Esto es lo que distingue a los parches de otros tipos de actualizaciones:
- Ámbito de aplicación: Los parches abordan problemas específicos y concretos, en lugar de introducir cambios generales en la funcionalidad.
- Tamaño: Suelen ser pequeños, a menudo de apenas unos pocos megabytes
- Urgencia: . Los parches de seguridad, en particular, son urgentes, ya que corrigen vulnerabilidades que los atacantes podrían conocer ya.
Una vez que un proveedor publica un parche, comienza el periodo de vulnerabilidad para las organizaciones que aún no lo hayan aplicado. Los piratas informáticos y otros atacantes, incluidos los ciberdelincuentes organizados, suelen estar al tanto de los lanzamientos de parches, ya que estos pueden revelar pistas importantes sobre dónde se encuentra una vulnerabilidad. Por eso es tan importante el tiempo que transcurre entre la disponibilidad del parche y la verificación de su instalación.
Una vez aclarados los conceptos básicos, la siguiente pregunta es: ¿qué tipos de parches existen y en qué se diferencian?
Una taxonomía precisa de los tipos de parches de software
No todos los parches de software presentan el mismo grado de urgencia ni el mismo perfil de riesgo. Conocer las diferencias le ayuda a ordenar las implementaciones en función de su impacto real, en lugar de por orden de llegada.
| Tipo de parche | Objetivo | Urgencia típica | Complejidad de la reversión |
|---|---|---|---|
| Parche de seguridad | Corrige una vulnerabilidad concreta | De alto a crítico | Por lo general, sencillo |
| Corrección de emergencia | Soluciona un error urgente fuera de los ciclos de lanzamiento habituales | Alto | Varía en función del ámbito |
| Corrección de un error | Corrige errores funcionales que afectan al rendimiento | Medio | Por lo general, sencillo |
| Actualización acumulativa | Reúne varios parches en un único paquete | Medio | Más complejo |
| Paquete de servicio | Incluye parches, correcciones de errores y mejoras en las funcionalidades | Inferior | Complejo |
| Actualización de funciones | Incorpora nuevas características y nuevas funcionalidades | Inferior | Varía |
Los parches de seguridad, a veces denominados «actualizaciones de seguridad», corrigen vulnerabilidades que podrían permitir el acceso no autorizado, el robo de datos o el compromiso de la seguridad del sistema. El Sistema Común de Puntuación de Vulnerabilidades (CVSS) clasifica la gravedad en una escala del 0 al 10. Una puntuación CVSS de 9.0 o superior suele indicar una vulnerabilidad crítica a la que se debe dar prioridad de inmediato.
Las correcciones urgentes ( ) son parches de respuesta rápida que se publican al margen del calendario habitual de actualizaciones. Los proveedores publican correcciones de emergencia cuando esperar a la próxima versión programada supondría dejar los sistemas expuestos a amenazas activas o a errores críticos.
Las actualizaciones acumulativas agrupan varios parches en un único paquete. Las actualizaciones mensuales de Microsoft, conocidas como «Patch Tuesday», suelen adoptar este formato. Aunque resultan prácticas, las actualizaciones acumulativas pueden ser más difíciles de revertir, ya que agrupan numerosos cambios en un solo paquete.
Las implicaciones prácticas: Los parches de seguridad y , así como las correcciones , exigen una respuesta lo más rápida posible, ya que cierran las ventanas de vulnerabilidad activas. Las actualizaciones acumulativas y , así como los paquetes de servicio , agrupan varias correcciones y mejoras, lo que dificulta su reversión sin problemas. Pruébelas en entornos de aplicación representativos antes de implementarlas a gran escala.
Las actualizaciones de características que introducen nuevas funcionalidades tienen el nivel de urgencia más bajo, pero presentan el ámbito de compatibilidad más impredecible.
Una vez aclarados los tipos de parches, sigamos el recorrido que sigue un parche desde su lanzamiento por parte del proveedor hasta su instalación en el terminal.
El ciclo de vida de los parches de software, desde su lanzamiento por parte del proveedor hasta su instalación en los dispositivos finales
Entre el momento en que un proveedor envía un parche de software y el momento en que se verifica en sus dispositivos finales, pueden surgir muchos problemas. Cada etapa del ciclo de vida supone un posible retraso, y cada retraso amplía el margen de tiempo de que disponen los atacantes para actuar.
1. Detección: El proveedor identifica una vulnerabilidad de seguridad a través de pruebas internas, de investigadores de seguridad o de informes de los clientes. Por motivos de seguridad, esto suele implicar la coordinación con organismos como la CISA o el NIST antes de hacer pública la información.
2. Desarrollo: Los ingenieros crean una solución, la prueban en diversas configuraciones y la preparan para su distribución. Esta fase puede durar días o semanas, dependiendo de su complejidad.
3. Comunicado: El proveedor publica el parche a través de los canales oficiales. En el caso de programas informáticos de uso generalizado, este anuncio puede alertar a los atacantes de la existencia de la vulnerabilidad.
4. Detección: Su organización tiene conocimiento de la existencia de nuevos parches, tanto para el software propio como para las aplicaciones de terceros . Esto se lleva a cabo a través de avisos de los proveedores, notificaciones automáticas de las plataformas de gestión de parches, el catálogo de vulnerabilidades explotadas conocidas (KEV) de la CISA, la Base de Datos Nacional de Vulnerabilidades (NVD) o herramientas de análisis automatizadas.
5. Establecimiento de prioridades: Debe evaluar qué puntos finales se ven afectados y con qué urgencia es necesario implementar el parche, teniendo en cuenta la gravedad de la vulnerabilidad, la importancia de los activos y el contexto empresarial.
6. Pruebas: Antes de proceder a una implementación a gran escala, se prueban los parches en una muestra representativa de terminales para detectar problemas de compatibilidad o comportamientos inesperados.
7. Implementación: El parche se distribuye a los terminales de destino a través de su infraestructura de implementación. Esto podría llevarse a cabo por fases, comenzando por los sistemas menos críticos antes de pasar a los entornos de producción.
8. Verificación: Usted confirma que el parche de software se ha instalado correctamente en los terminales de destino, comprobando que se ha sustituido el código o la biblioteca de la aplicación vulnerable, y no solo que se haya ejecutado el comando de implementación.
El intervalo entre el paso 3 (lanzamiento) y el paso 8 (verificación) es donde se acumula el riesgo. Cada día que transcurre con dispositivos finales sin parches de puede ampliar el margen de actuación de los atacantes.
Consejo: Analice su flujo de trabajo actual para la aplicación de parches en y compárelo con estas etapas. ¿Dónde suelen producirse los retrasos? Ahí es donde hay que centrar los esfuerzos de mejora.
El periodo de exposición y el riesgo que conlleva
El periodo de vulnerabilidad es el intervalo de tiempo que transcurre desde que un proveedor publica un parche hasta que usted haya comprobado que se ha instalado en todos los terminales afectados. No se trata de un concepto abstracto. Se trata de un riesgo cuantificable.
Los atacantes no esperan. Cuando se publica un parche, suele incluir detalles sobre la vulnerabilidad que corrige. Tanto los investigadores de seguridad como los autores de amenazas pueden aplicar ingeniería inversa al parche para comprender exactamente cómo aprovechar los sistemas que no han sido parcheados. En muchos casos, aprovechan rápidamente esa información para lanzar malware diseñado para atacar la vulnerabilidad recién revelada antes de que las organizaciones hayan tenido tiempo de reaccionar.
Cada día que transcurra dentro de ese periodo de vulnerabilidad es un día en el que los atacantes pueden aprovechar la información que su propio proveedor les facilitó al publicar el parche. Reflexione sobre lo que ocurre durante un periodo de exposición típico:
- Día 0: El proveedor publica un parche y un aviso
- Día 1–3: Los atacantes comienzan a desarrollar exploits basados en los detalles del parche
- Día 7: Es posible que esté circulando código de explotación de « » en foros clandestinos
- Día 14: Comienzan a aparecer herramientas de ataque automatizadas que incorporan el exploit
- Día 30+: Su organización completa por fin la implementación
Durante ese periodo, los dispositivos finales sin parches pueden seguir siendo vulnerables. Cuanto más tiempo permanezca abierta la ventana, mayor será la probabilidad de que se produzca una intrusión. Las vulnerabilidades de las aplicaciones sin parchear se están convirtiendo cada vez más en puntos de acceso activos para los atacantes, lo que aumenta el riesgo de filtraciones de datos que acarrean consecuencias normativas, económicas y para la reputación.
Sin embargo, la ventana de exposición no se reduce únicamente a la velocidad. También se trata de la exhaustividad. Si aplica parches rápidamente al 95 % de los terminales afectados, pero se le pasa por alto el 5 %, esos sistemas que se han pasado por alto seguirán expuestos de forma indefinida.
En una gran empresa, un 5 % podría suponer miles de terminales vulnerables.
Para eliminar el riesgo de exposición es necesario cumplir dos requisitos: aplicar rápidamente los parches de software y confirmar que se han instalado efectivamente en todos los dispositivos afectados. La mayoría de las organizaciones se desenvuelven bastante bien en la primera parte. El segundo es aquel en el que los programas dejan de funcionar sin que uno se dé cuenta.
Por qué la implementación de parches de software suele fallar a gran escala
La aplicación de un parche de software en miles de dispositivos finales parece una tarea mecánica. En la práctica, es ahí donde se van creando silenciosamente las lagunas de cobertura, donde surgen las brechas de seguridad y donde las vulnerabilidades de las aplicaciones sin parchear perduran durante más tiempo.
No siempre es posible acceder a los puntos finales. Los ordenadores portátiles se llevan de viaje. Los trabajadores a distancia se conectan de forma intermitente. Es posible que los servidores situados en segmentos de red aislados no reciban los comandos de implementación. Si un dispositivo no está en línea ni conectado en el momento de la distribución del parche, no se le aplicará dicho parche.
Las dependencias generan conflictos. Un parche de software para una aplicación puede provocar fallos en otra que dependa de una versión concreta o de una biblioteca compartida. Si no dispone de información sobre qué está instalado y cómo interactúan las aplicaciones, no sabrá que hay un problema hasta que algo deje de funcionar.
Los entornos heterogéneos aumentan la complejidad. Las empresas ejecutan simultáneamente múltiples versiones de aplicaciones, conjuntos de dependencias y configuraciones de sistemas operativos. Un parche de software validado para una versión de una aplicación puede comportarse de forma diferente en otra versión. Si no sabe con certeza qué es lo que está realmente instalado, está realizando la implementación a ciegas.
La información facilitada por los propios interesados no es fiable. Muchas herramientas de aplicación de parches indican que la operación se ha realizado con éxito basándose únicamente en si se ha ejecutado el comando de implementación, y no en si el parche se ha instalado correctamente. Es posible que un terminal indique que está «actualizado», aunque la vulnerabilidad subyacente siga existiendo.
Los periodos de mantenimiento son limitados. Las aplicaciones que no pueden reiniciarse durante el horario laboral debido a posibles interrupciones del servicio limitan los intervalos de tiempo disponibles para la aplicación de parches. Cuando esas ventanas se cierran antes de que finalice la implementación, los parches de software se acumulan en la cola en lugar de aplicarse. El retraso se acumula con el tiempo, lo que amplía el periodo de vulnerabilidad de cada parche que no se ha incluido y obliga a los equipos de soporte informático a dedicarse a tareas de limpieza reactivas en lugar de a una implementación proactiva.
Comprobar que un parche se haya aplicado realmente
La puesta en marcha no es la meta. La verificación consiste en...
Un parche de software que se haya implementado sin que se haya verificado su instalación constituye una cuestión pendiente, no una vulnerabilidad resuelta. La diferencia entre «lo hemos implementado» y «lo hemos comprobado» es precisamente donde las organizaciones sobreestiman sistemáticamente su cobertura real de parches.
La verificación responde a tres preguntas:
- ¿Ha llegado el parche al punto final? Los problemas de red, los dispositivos sin conexión o los errores de implementación pueden impedir la entrega.
- ¿Se han instalado correctamente los parches en el terminal? La falta de espacio en disco, los errores de permisos o los conflictos pueden provocar fallos en la instalación, incluso cuando se haya descargado el parche.
- ¿Se ha solucionado realmente la vulnerabilidad? En algunos casos, es posible que un parche se instale, pero que no resuelva por completo el problema debido a requisitos de configuración o a reinicios pendientes.
Muchas organizaciones se basan en los informes de resultados de sus herramientas de aplicación de parches. Sin embargo, esos informes suelen reflejar intentos de implementación, no resultados contrastados. La herramienta indica que ha aplicado el parche. Esto no confirma que el terminal haya recibido e instalado correctamente los parches, ni que la vulnerabilidad subyacente se haya solucionado.
Para que la verificación sea eficaz, es necesario consultar directamente a los puntos finales con el fin de confirmar su estado actual. ¿Qué versión de la aplicación tiene instalada? ¿Sigue existiendo la biblioteca o el archivo vulnerable? ¿Se ha reiniciado la aplicación para activar el código parcheado?
Es aquí donde la visibilidad en tiempo real de los terminales de cobra una importancia fundamental. Los análisis puntuales no detectan los terminales que estaban desconectados durante el análisis.
Además, no detectan los cambios que se han producido una vez finalizado el análisis. La visibilidad continua ofrece una visión actualizada y precisa del estado de los parches en todo su entorno.
Consejo: . Tras la aplicación de cualquier parche crítico, consulte directamente los terminales afectados para confirmar que el componente vulnerable ya no está presente. No se fíe únicamente de los registros de implementación.
La verificación cierra el ciclo de un parche de software concreto. Sin embargo, ningún parche se implementa de forma aislada, y el programa encargado de gestionar el proceso desde el lanzamiento del parche por parte del proveedor hasta su verificación en los terminales es el que determina si su cobertura se mantiene a gran escala.
El papel de los parches de software en la gestión de parches
Es fundamental comprender qué es un parche de software y cómo funciona. Sin embargo, en el contexto empresarial, los parches individuales no se instalan por sí solos. Siguen un proceso: detección, priorización, pruebas, implementación y verificación.
Ese programa es la gestión de parches, y su eficacia determina la rapidez con la que su organización cierra la ventana de vulnerabilidad tras el lanzamiento de un parche de software. Para obtener información más detallada sobre cómo se estructuran y evalúan los programas de gestión de parches, consulte nuestra guía de « » sobre la gestión de parches:.
Un parche de software es el artefacto. La gestión de parches es el sistema que se encarga de que ese artefacto pase de la versión del proveedor a una instalación verificada en lo que pueden ser cientos de miles de terminales.
Esta distinción es importante porque muchos fallos en la aplicación de parches no se deben al parche en sí. Se refieren al programa:
- Lagunas en la detección: No sabe si existe un parche ni qué terminales lo necesitan
- Errores en el establecimiento de prioridades: Los parches críticos quedan en cola detrás de las actualizaciones rutinarias
- Cuellos de botella en las pruebas: La implementación se retrasa mientras los equipos comprueban manualmente la compatibilidad
- Limitaciones de implementación: Los parches no llegan a todos los dispositivos afectados
- Lagunas en la verificación: No está seguro de si los parches se han instalado realmente
Cada uno de ellos constituye un reto a nivel de programa, no un problema a nivel de parche.
La elección del software adecuado para la gestión de parches suele ser el primer paso para subsanar estas deficiencias de forma sistemática, proporcionando a los equipos la visibilidad, la automatización y la generación de informes que necesitan para operar a gran escala.
En el caso de las organizaciones que gestionan grandes parques de terminales distribuidos, los retos a nivel de programa suelen superar con creces la complejidad técnica de cualquier parche concreto.
La visibilidad en tiempo real, la implementación verificada, las políticas claras de aplicación de parches y los flujos de trabajo automatizados de gestión de parches se convierten en necesidades operativas más que en elementos prescindibles, especialmente cuando la alternativa consiste en realizar un seguimiento manual del estado de los parches en miles de terminales.
Cómo Tanium facilita la gestión de parches de software para las empresas
Los retos descritos anteriormente —entre los que se incluyen la visibilidad desactualizada, los fallos en la implementación y las correcciones no verificadas— son problemas a nivel de programa que los parches individuales no pueden resolver.
La plataforma de TI autónoma de Tanium, , aborda estos problemas desde su origen: consulta directamente los terminales para conocer el estado de los parches en tiempo real, ordena las implementaciones según el riesgo real utilizando las puntuaciones de confianza de y los datos de vulnerabilidades, y confirma que la instalación se ha realizado correctamente, en lugar de basarse únicamente en los registros de implementación.
Para las organizaciones que gestionan grandes parques de terminales distribuidos, esta combinación está diseñada para ayudar a reducir la brecha entre el lanzamiento de un parche y la corrección verificada con mayor rapidez de lo que suelen permitir los enfoques basados en análisis, sin necesidad de una infraestructura secundaria.
La visibilidad en tiempo real como base
La razón más habitual por la que los programas de correcciones fracasan a gran escala no es la falta de esfuerzo. Se trata de una falta de datos precisos y actualizados. La plataforma de TI autónoma de Tanium aborda este problema de forma directa, al ofrecer visibilidad en tiempo real del estado de los parches de los programas de en los dispositivos Windows, Linux y macOS.
En lugar de basarse en datos de análisis que pueden tener varias horas o días de antigüedad, las organizaciones que utilizan Tanium pueden consultar directamente los terminales para conocer su estado actual. Cuando se publica un parche crítico, los equipos de TI pueden identificar rápidamente qué terminales pueden verse afectadas, cuáles parecen estar ya actualizadas y cuáles podrían requerir un aplazamiento, sin tener que esperar a que finalice un ciclo de análisis programado.
La plataforma de TI autónoma de Tanium está diseñada para mantener la visibilidad en entornos distribuidos, incluidos los terminales de las sucursales, las ubicaciones remotas y los emplazamientos geográficamente dispersos, todo ello desde una única instancia de Tanium, concebida para reducir la dependencia de servidores secundarios de retransmisión, bases de datos o distribución.
La arquitectura de la plataforma está diseñada para dar soporte a entornos a gran escala, incluidas las implementaciones con cientos de miles de terminales. Esta escala es importante porque las lagunas en la aplicación de parches rara vez son uniformes: los puntos finales a los que resulta más difícil acceder suelen ser los que tienen más probabilidades de quedar sin parchear.
Establecimiento de prioridades en función del riesgo antes de la puesta en marcha
No todas las actualizaciones de software requieren la misma urgencia. Implementar sin establecer prioridades implica que sus equipos tienen las mismas probabilidades de dedicarse a aplicar actualizaciones de aplicaciones de bajo riesgo que de subsanar vulnerabilidades activas.
La plataforma de TI autónoma de Tanium permite a las organizaciones combinar los datos sobre vulnerabilidades con los índices de criticidad y fiabilidad de los terminales, con el fin de priorizar la aplicación de parches y centrarse en primer lugar en las brechas de alto riesgo.
Las puntuaciones de confianza se generan mediante un análisis en tiempo real de las tendencias realizado por la inteligencia en la nube, que incluye las tasas de éxito de las instalaciones, la frecuencia de los fallos y el impacto en el rendimiento, lo que proporciona a los equipos datos útiles para tomar decisiones fundamentadas sobre la secuencia de aplicación antes de que un parche se implemente de forma generalizada.
La plataforma también permite a los equipos utilizar las señales de riesgo y el contexto empresarial para dar prioridad a los parches que reducen en primer lugar la mayor exposición. Este enfoque integra la gestión de parches directamente en el flujo de trabajo más amplio de gestión de la exposición a amenazas ( ) , en lugar de considerarla una tarea aislada de operaciones de TI.
Los equipos pueden identificar las vulnerabilidades que pueden corregirse mediante parches y los parches no programados más importantes, lo que contribuye a agilizar la comunicación entre los equipos de seguridad y de operaciones, y garantiza que los parches se prioricen y se apliquen de forma eficaz.
Implementación controlada mediante despliegues por anillos
Una de las capacidades más relevantes desde el punto de vista operativo de la Plataforma de TI Autónoma de Tanium es su compatibilidad con la implementación progresiva y « » basada en anillos. En lugar de aplicar un parche a todos los terminales simultáneamente, las organizaciones pueden comenzar con un pequeño grupo de terminales, validar los resultados y aprovechar los conocimientos de la comunidad de clientes de Tanium para ampliar el despliegue con confianza a medida que cada fase cumpla los criterios de éxito.
Este enfoque resulta especialmente relevante en el caso de las vulnerabilidades de tipo « » de día cero, en las que la rapidez es fundamental, pero el riesgo de que un parche defectuoso provoque perturbaciones generalizadas también es elevado.
La implementación de parches puede canalizarse a través de flujos de trabajo de aprobación e integrarse en ventanas de mantenimiento para minimizar el impacto en la actividad empresarial. Los equipos pueden configurar la programación de las actualizaciones y los flujos de trabajo para adaptarlos al funcionamiento habitual de su organización, determinando qué terminales reciben las actualizaciones y en qué orden, así como en qué condiciones el proceso de implementación pasa al siguiente anillo.
Las guías de automatización creadas con Tanium Automate permiten gestionar en tiempo real los flujos de trabajo de parches de software en grandes parques de terminales, gestionando los pasos de detección, secuenciación de la implementación y verificación como un único proceso repetible, en lugar de una serie de traspasos manuales entre herramientas.
Validación y remediación en bucle cerrado
La implementación no es lo mismo que la corrección. La plataforma de TI autónoma de Tanium realiza un seguimiento en tiempo real del éxito de la aplicación de parches, las excepciones y los indicadores de rendimiento, y ofrece informes detallados para respaldar futuras mejoras en los procesos relacionados con la selección de objetivos, la planificación temporal y la secuenciación.
Tras una implementación, las organizaciones pueden comprobar el estado de los parches e identificar los sistemas que no se han actualizado, distinguiendo entre los terminales en los que el parche se ha enviado pero no se ha instalado y aquellos a los que simplemente no se ha podido acceder durante el periodo de implementación.
Tanium Comply amplía esta funcionalidad al evaluar si las vulnerabilidades del software se han solucionado realmente tras la aplicación de un parche, y no solo si se ha completado su implementación. Los equipos pueden pasar directamente de identificar una vulnerabilidad de software sin parchear a poner en marcha y realizar el seguimiento de las medidas correctivas dentro de la misma plataforma, sin necesidad de cambiar de herramienta ni de conciliar datos de sistemas distintos.
Este ciclo de identificación, corrección y validación implica que la gestión de parches no finaliza con la implementación, sino que concluye cuando se confirma que la vulnerabilidad ha sido corregida.
Informes de cumplimiento y preparación para auditorías
Demostrar que se han aplicado parches de software, y que se han aplicado correctamente, reviste una importancia cada vez mayor para los programas de auditoría regulatoria de , incluidos aquellos vinculados a marcos normativos como HIPAA y PCI. Tanium está diseñado para dar respuesta a esas necesidades de documentación.
Tanium Patch resume el estado de implementación de cualquier parche de software, proporcionando información inmediata sobre los éxitos y los fallos que requieren una solución. Cuando los auditores preguntan qué parches de software se han aplicado y cuándo, Tanium proporciona a los equipos el historial de implementación, el estado de los reinicios y la confirmación de la corrección necesarios para responder a esa pregunta con datos, en lugar de estimaciones.
De las deficiencias en el cumplimiento normativo a una cobertura de parches del 90 %: Honeywell
, de Honeywell, se enfrentaba a bajos índices de cumplimiento en la aplicación de parches, lo que ponía a la organización en riesgo de sufrir ataques de ransomware y otros ciberataques. Tras implementar Tanium, Honeywell superó el 90 % de cumplimiento en la aplicación de parches durante tres meses consecutivos, un nivel de servicio que la empresa no había podido alcanzar anteriormente.
Tanium también permitió a Honeywell consolidar y, en algunos casos, eliminar otras herramientas de aplicación de parches, además de proporcionar una vista unificada para la elaboración de informes de cumplimiento normativo, tanto a nivel ejecutivo como operativo.
[Lea el caso práctico de Honeywell]
«. 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
El funcionamiento de un parche de software es sencillo. La realidad operativa que supone su implementación en miles de terminales no es así. A continuación se incluyen las respuestas a las preguntas que se plantean con mayor frecuencia.
Preguntas frecuentes sobre parches de software
¿Cuál es la diferencia entre un parche de software y una actualización?
Un parche es una solución específica para un problema concreto, normalmente un error o una vulnerabilidad de seguridad en un programa. Una actualización es un término más amplio que puede incluir parches, nuevas funciones, mejoras de rendimiento y otros cambios. Todos los parches son actualizaciones, pero no todas las actualizaciones son parches.
¿Con qué rapidez actúan los atacantes tras el lanzamiento de un parche de software?
Más rápido de lo que la mayoría de las organizaciones pueden ponerlo en marcha. Cuando un proveedor lanza un parche de software, el propio parche puede revelar detalles sobre la vulnerabilidad subyacente, lo que proporciona a los atacantes una guía para aprovechar los sistemas que no han sido parcheados. En el caso de las vulnerabilidades de software de gran repercusión, el código de explotación puede aparecer a las pocas horas de la publicación del parche.
La vulnerabilidad 2021 Log4j , un fallo en una biblioteca de registro de Java muy utilizada, registró más de 200,000 intentos de ataque en las 24 horas siguientes a su divulgación, según Check Point Research. Por eso, el lapso de tiempo que transcurre entre el lanzamiento de un parche de software y su instalación verificada constituye un riesgo cuantificable, y no solo un inconveniente operativo.
¿Es posible revertir una actualización de software si surge algún problema?
Depende de cómo se haya empaquetado el parche. La mayoría de los parches de software independientes pueden desinstalarse a través de la propia aplicación o de sus herramientas de gestión de parches, lo que permite restablecer la versión anterior. Las actualizaciones acumulativas son más difíciles de revertir de forma ordenada, ya que revertir un cambio implica revertir varios.
Antes de implementar cualquier parche de software de forma generalizada, pruébelo en una muestra representativa de terminales y asegúrese de disponer de una vía de reversión en caso de que el parche provoque problemas de compatibilidad o un comportamiento inesperado de las aplicaciones.
¿Por qué algunos parches de software requieren un reinicio?
Los parches de software que modifican archivos de aplicaciones o bibliotecas compartidas que se están utilizando en ese momento no pueden completarse mientras dichos archivos estén activos. Un reinicio del sistema, o en algunos casos un reinicio de la aplicación, libera esos bloqueos y permite que los archivos parcheados surtan efecto. La necesidad de reiniciar el sistema depende de lo que modifique el parche de software y de si la aplicación afectada puede reiniciarse de forma segura sin necesidad de reiniciar todo el sistema.
¿Qué ocurre si un dispositivo final no recibe una actualización de software?
El dispositivo sigue estando expuesto a la vulnerabilidad de software que el parche debía subsanar. El hecho de no haber llevado a cabo una implementación no es una deficiencia menor. Esto significa que el fallo de código subyacente sigue presente y puede ser objeto de explotación. Para identificar los puntos finales que se han pasado por alto, es necesario consultar directamente las versiones actuales del software y el estado de los parches en cada uno de ellos, en lugar de basarse en los registros de implementación, que solo confirman que el parche se ha enviado, pero no que se haya instalado correctamente.
Muchas soluciones modernas de gestión de parches están diseñadas para realizar un seguimiento de las implementaciones fallidas, volver a intentarlas automáticamente y detectar las deficiencias, de modo que haya menos dispositivos sin parches durante períodos prolongados.
Una gestión eficaz de los parches de software comienza por comprender qué se está implementando y por qué, hasta el punto de conocer el cambio específico que introduce un parche en el código y qué ocurre si no se instala correctamente. A partir de ahí, se trata de cerrar la ventana de exposición lo más rápido y completamente posible, y luego verificar que realmente lo haya conseguido.
Tanium ofrece visibilidad en tiempo real del estado de los parches de software en entornos de terminales distribuidos, lo que permite a los equipos identificar deficiencias, realizar implementaciones con confianza y confirmar que se han subsanado los problemas, en lugar de darlo por sentado. Solicite una demostración en para ver cómo funciona a escala empresarial.
