Modulo 01. Fundamentos de parcheo y despliegue en Tanium

Objetivo del modulo

Comprender como Tanium Patch y Deploy conectan visibilidad, targeting, distribucion y validacion para gestionar cambios en endpoints de forma controlada y a gran escala.

Resultados esperados

• Diferenciar parcheo y despliegue de software en Tanium.
• Explicar el ciclo evaluar-remediar-validar.
• Identificar dependencias de red, contenido y gobierno.
• Disenar una estrategia basica de remediacion usando Patch y Deploy conjuntamente.

Desarrollo teorico

Parchar y desplegar software a gran escala en Tanium no consiste en lanzar una Action global y esperar lo mejor. Requiere responder preguntas previas: que falta realmente, que equipos estan afectados, que nivel de criticidad tienen, hay conflictos con aplicaciones, reinicios o ventanas de negocio, que se considera exito y que pasa con los equipos offline o con errores. Tanium Patch y Tanium Deploy son dos modulos complementarios que combinan la capacidad de inventario vivo del endpoint con accion inmediata, eliminando la brecha temporal que existe en plataformas batch entre el momento de detectar la carencia y el momento de remediarla. Esta capacidad de evaluar y actuar en la misma plataforma, en tiempo real, es lo que diferencia a Tanium de los modelos tradicionales basados en WSUS, SCCM o herramientas de distribucion que operan con ciclos de horas o dias entre deteccion y remediacion.

Tanium Patch se centra en la evaluacion e instalacion de actualizaciones del sistema operativo y de productos soportados. Trabaja con catalogos de parches que se sincronizan periodicamente desde fuentes oficiales y que contienen metadatos de cada actualizacion: identificador KB, severidad CVSS, producto afectado, prerequisitos necesarios, relaciones de supersedencia y arquitectura aplicable. El flujo basico de Patch sigue tres fases bien definidas. La primera es la evaluacion (scan): Tanium Patch ejecuta un scan en cada endpoint que compara las actualizaciones instaladas contra el catalogo vigente para determinar que actualizaciones faltan. Este scan se realiza mediante sensors especificos del modulo Patch que inspeccionan el estado del Windows Update Agent, el registro de actualizaciones instaladas y las condiciones de aplicabilidad de cada parche. El resultado del scan alimenta los dashboards de cumplimiento de la consola, mostrando por cada endpoint, Computer Group o sede que parches estan pendientes, cual es su severidad y cual es la ventana de exposicion.

La segunda fase es la remediacion (deploy): una vez evaluado el parque, el operador crea una Patch List que contiene los parches aprobados para instalacion. La Patch List puede incluir parches especificos seleccionados manualmente o puede configurarse como una lista dinamica que incluye automaticamente todos los parches de cierta severidad o producto. Sobre esa lista se define el targeting, que determina que Computer Groups recibiran la accion, y la ventana de despliegue, que especifica cuando puede ejecutarse la instalacion. Tanium Patch descarga los binarios de actualizacion desde los repositorios de Microsoft o desde un repositorio local configurado por el administrador, los distribuye a los endpoints a traves de la red de Relays y ejecuta la instalacion siguiendo la logica del Windows Update Agent o del mecanismo nativo del sistema operativo.

La tercera fase es la validacion: tras la instalacion, Patch ejecuta un nuevo scan para verificar que el parche se aplico correctamente y que el endpoint ya no lo reporta como pendiente. Si el parche requeria reinicio, Tanium verifica si el reinicio se completo o si queda pendiente. Los endpoints que no pudieron parchearse por cualquier razon (offline durante la ventana, error de instalacion, prerequisito faltante, espacio en disco insuficiente) quedan identificados como excepciones que requieren tratamiento individual.

Tanium Deploy se orienta a la distribucion de software, scripts, configuraciones o binarios que no encajan en el modelo de parcheo clasico basado en catalogos de actualizaciones. Deploy trabaja con Packages, que son unidades de contenido autocontenidas que incluyen los ficheros necesarios (instaladores, scripts, archivos de configuracion), el comando de ejecucion, parametros de linea de comandos, condiciones de aplicabilidad y logica de verificacion de resultado. Un Package puede instalar un agente de seguridad, desplegar una configuracion de registro de Windows, ejecutar un script PowerShell de remediacion, distribuir un certificado raiz o actualizar una herramienta interna que no tiene catalogo de parches.

La Action en Tanium Deploy es la operacion que combina un Package con un targeting y una ventana temporal. Cuando se lanza una Action, el Tanium Server distribuye la instruccion a los endpoints objetivo a traves de la linear chain, cada cliente descarga el contenido del Package desde el servidor o desde el Relay mas cercano via TCP 17472, verifica la integridad del paquete mediante hash SHA-256 y ejecuta el comando definido en el Package. El resultado de la ejecucion se reporta de vuelta al servidor, donde el operador puede ver cuantos endpoints completaron exitosamente, cuantos fallaron y cual fue el codigo de error en cada caso.

Patch y Deploy trabajan juntos en muchos escenarios reales. Una vulnerabilidad critica puede exigir parcheo del producto via Patch y, simultaneamente, despliegue de una configuracion de mitigacion complementaria via Deploy. Un ciclo mensual de parcheo puede requerir prerequisitos como frameworks actualizados o agentes en version minima, que se distribuyen con Deploy antes de lanzar la campana de Patch. Otro caso comun es la remediacion de excepciones: endpoints que no pudieron parchearse automaticamente reciben un Package de Deploy con un script de remediacion personalizado que resuelve el bloqueo especifico y luego relanza el proceso de parcheo.

Las dependencias que afectan a ambos modulos son la conectividad de red y la distribucion de contenido a traves de Relays, el gobierno mediante RBAC que controla quien puede crear contenido y quien puede lanzar acciones, y la verificacion previa del estado del endpoint. Antes de parchear o desplegar, se deben usar Questions con sensors para confirmar la poblacion elegible, verificar prerequisitos como espacio en disco y estado del servicio de Windows Update, y comprobar que el endpoint no esta en medio de otra operacion. Lanzar una accion sin esta verificacion previa es como administrar medicacion sin diagnostico.

Contenido ampliado

Puntos clave

• Patch y Deploy se apoyan en la misma visibilidad del endpoint pero resuelven problemas distintos.
• El parcheo no empieza por la accion, sino por la evaluacion y la priorizacion.
• Desplegar con seguridad exige targeting, pilotos, validacion y gestion de excepciones.
• El exito depende tanto de gobierno (RBAC, aprobaciones) como de contenido tecnico.
• La distribucion de contenido a gran escala requiere planificar impacto en red y usar Relays.

Checklist operativa

• Define el objetivo del despliegue o remediacion antes de crear el Package o la lista de parches.
• Identifica poblacion elegible y exclusiones explicitas (servidores criticos, endpoints offline).
• Valida prerequisitos del endpoint: espacio, conectividad, agentes, servicios necesarios.
• Prueba el Package o la lista de parches en un grupo piloto reducido.
• Diseña la verificacion posterior: Saved Questions, dashboards o informes de cumplimiento.
• Documenta excepciones y su plan de tratamiento.

Errores frecuentes

• Lanzar acciones masivas sin segmentacion ni grupo piloto.
• No validar prerequisitos del endpoint (espacio, servicio de update activo, cliente sano).
• Confundir "accion lanzada" con "cambio exitoso" sin verificar resultado.
• No preparar gestion de excepciones para endpoints que fallan.
• Ignorar el impacto en red de distribuir Packages pesados sin Relay.
• Usar catalogos desactualizados y asumir que el estado de cumplimiento es correcto.

Practica sugerida

Describe el flujo completo de una campana de parcheo mensual desde la actualizacion del catalogo hasta el cierre de excepciones. Incluye: evaluacion inicial, creacion de lista de parches aprobados, targeting por grupos, despliegue piloto, validacion, despliegue general, gestion de excepciones y reporte final de cumplimiento.

Preguntas de autoevaluacion

• Que diferencia operativa hay entre Patch y Deploy y cuando se usan juntos.
• Que informacion necesitas obtener del endpoint antes de lanzar un despliegue.
• Por que la validacion post-despliegue es imprescindible y que pasa si se omite.
• Que riesgos genera lanzar un Package pesado a miles de endpoints sin planificar distribucion.
• Como afecta un catalogo desactualizado a los informes de cumplimiento de parcheo.

Cierre

La potencia de Patch y Deploy aparece cuando el cambio se trata como un ciclo completo --evaluar, preparar, ejecutar, validar y cerrar-- y no como un clic aislado en la consola.

Modulo 02. Patch: catalogos, evaluacion y cumplimiento

Objetivo del modulo

Usar Tanium Patch para evaluar brechas, interpretar catálogos de parches y medir cumplimiento.

Resultados esperados

• Entender cómo se organiza la evaluación de parches.
• Priorizar remediación según severidad y exposición.
• Interpretar informes de cumplimiento con criterio.

Desarrollo teorico

Tanium Patch opera sobre un modelo de evaluación continua que permite a las organizaciones conocer en tiempo real el estado de parcheo de cada endpoint y tomar decisiones de remediación informadas. El motor de evaluación se basa en catálogos de parches que contienen los metadatos de todas las actualizaciones disponibles para los sistemas operativos y productos soportados. Comprender cómo funcionan estos catálogos, cómo se ejecuta el scan de evaluación y cómo se interpreta el cumplimiento resultante es fundamental para operar Tanium Patch de forma efectiva.

Los catálogos de parches en Tanium se sincronizan desde fuentes oficiales y se almacenan en el Tanium Server. Para sistemas Windows, Tanium mantiene un catálogo propio derivado de las actualizaciones publicadas por Microsoft que incluye todos los tipos de actualización: Security Updates, Cumulative Updates, Servicing Stack Updates, Feature Updates y actualizaciones de productos como Office, .NET Framework y Edge. Para sistemas Linux, Tanium Patch soporta los repositorios nativos de las distribuciones principales como Red Hat (yum/dnf), Ubuntu (apt), SUSE (zypper) y Amazon Linux, evaluando los paquetes instalados contra las versiones disponibles en los repositorios configurados. Para macOS, Patch evalúa las actualizaciones de sistema disponibles a través del mecanismo nativo de Software Update.

Cada entrada del catálogo contiene metadatos esenciales para la evaluación y priorización. El identificador de la actualización (KB en Windows, advisory ID en Linux) permite referenciar el parche de forma unívoca. La severidad indica el nivel de criticidad según la clasificación del fabricante (Critical, Important, Moderate, Low). El CVSS score, cuando está disponible, proporciona una valoración numérica del riesgo de la vulnerabilidad que el parche corrige. Los prerequisitos definen qué condiciones debe cumplir el endpoint para que el parche sea aplicable: versión mínima del sistema operativo, actualizaciones previas instaladas o Servicing Stack Updates necesarias. Las relaciones de supersedencia indican qué parches anteriores quedan obsoletos porque el parche actual los incluye, lo cual es crítico para evitar instalar actualizaciones innecesarias y para interpretar correctamente los informes de cumplimiento.

El proceso de scan de evaluación se ejecuta mediante sensors específicos del módulo Patch. En Windows, el sensor de Patch Scan interactúa con el Windows Update Agent (WUA) del endpoint para determinar qué actualizaciones del catálogo son aplicables y cuáles de esas actualizaciones están ya instaladas. El resultado es una lista por endpoint de parches faltantes (missing patches) que alimenta los dashboards de la consola. El scan puede programarse como una Saved Question que se ejecuta periódicamente, típicamente cada 4 a 24 horas dependiendo del nivel de urgencia operativa. También puede lanzarse bajo demanda cuando se necesita una evaluación inmediata, por ejemplo tras la publicación de un parche crítico de día cero.

La interpretación del cumplimiento de parcheo requiere contexto y no debe reducirse a un porcentaje global. Un dashboard que muestre un 95 por ciento de cumplimiento puede ocultar que el 5 por ciento restante corresponde precisamente a los servidores que soportan servicios críticos de negocio o a endpoints expuestos a internet. Por eso Tanium Patch permite segmentar el cumplimiento por Computer Group, lo que permite ver el estado de parcheo separado por tipo de activo (servidores, workstations, portátiles), por entorno (producción, desarrollo, DMZ), por sede geográfica o por cualquier otra agrupación definida en la plataforma.

La priorización de la remediación debe combinar la severidad del parche con la criticidad del activo y la exposición del endpoint. Un parche de severidad Critical en un servidor expuesto a internet tiene más urgencia que el mismo parche en un equipo de laboratorio aislado. Tanium permite crear Patch Lists filtradas por severidad, por producto, por fecha de publicación o por cualquier combinación de criterios, lo que facilita la creación de campañas de parcheo priorizadas. Las Patch Lists pueden ser estáticas, donde el operador selecciona manualmente los parches, o dinámicas, donde se incluyen automáticamente todos los parches que cumplen ciertos criterios como severidad Critical publicados en los últimos 30 días.

La gestión de la supersedencia es un aspecto técnico que tiene impacto directo en la calidad de los informes. Cuando Microsoft publica una Cumulative Update mensual, esta incluye todas las correcciones de las Cumulative Updates anteriores. Si el catálogo no refleja correctamente las relaciones de supersedencia, un endpoint que tiene instalada la última Cumulative Update podría aparecer como no conforme para parches individuales que ya están incluidos en ella. Tanium gestiona la supersedencia automáticamente en su catálogo, pero es responsabilidad del operador verificar que la sincronización del catálogo está al día y que no hay inconsistencias.

La frescura del catálogo es otro factor crítico. Si el catálogo no se actualiza después del Patch Tuesday mensual de Microsoft, los nuevos parches publicados no aparecerán en la evaluación y los endpoints parecerán conformes cuando en realidad tienen actualizaciones pendientes. La sincronización del catálogo debe ejecutarse al menos semanalmente, y preferiblemente dentro de las 24 a 48 horas siguientes a la publicación de nuevas actualizaciones por parte del fabricante. Tanium permite configurar la sincronización automática del catálogo en la sección de Patch Settings de la consola.

Los informes de cumplimiento deben incluir no solo el porcentaje actual sino también la tendencia temporal, que muestra si el nivel de parcheo mejora o empeora con cada ciclo. También deben identificar las excepciones: endpoints que no pueden parchearse por razones técnicas o de negocio y que requieren un plan alternativo de mitigación documentado con propietario, justificación, riesgo residual aceptado y fecha de revisión.

Contenido ampliado

Puntos clave

• La evaluación de parches es la base de la remediación.
• El cumplimiento debe leerse con criticidad y contexto.
• No todos los endpoints pendientes tienen la misma prioridad.
• Patch necesita combinarse con clasificación y gestión de excepciones.

Checklist operativa

• Revisa catálogos y parches críticos pendientes.
• Segmenta por severidad y tipo de activo.
• Identifica excepciones justificadas.
• Prepara informe de cumplimiento con contexto.

Errores frecuentes

• Guiarse solo por porcentaje global.
• No distinguir servidores críticos de puestos estándar.
• Ignorar exclusiones técnicas documentadas.
• No revisar tendencia entre ciclos.

Practica sugerida

Construye una priorización de remediación para cinco grupos de activos con distinto riesgo y criticidad.

Preguntas de autoevaluacion

• ¿Qué hace que un gap de parcheo sea prioritario?
• ¿Por qué el porcentaje global puede engañar?
• ¿Qué debe contener una excepción de parcheo bien justificada?

Cierre

Patch aporta valor cuando convierte la brecha de actualización en un backlog priorizado y medible.