Modulo 01. Tanium Comply y la gestion del riesgo tecnico

Objetivo del modulo

Entender como Tanium Comply ayuda a convertir hallazgos tecnicos en una vision accionable del risk posture del endpoint y a priorizar remediacion con contexto de negocio.

Resultados esperados

• Explicar el papel de Comply dentro del riesgo tecnico.
• Diferenciar volumen de hallazgos y prioridad real.
• Relacionar desviaciones con remediacion viable.
• Integrar contexto de activo en la priorizacion de hallazgos.

Desarrollo teorico

Comply tiene sentido cuando la organizacion deja de contar vulnerabilidades y empieza a decidir que corregir primero, en que activos y con que justificacion. Un listado de CVEs o de controles fallidos puede ser enorme, pero si no distingues criticidad del activo, exposicion real, exploitabilidad, compensating controls y viabilidad de remediacion, el backlog se vuelve inmanejable. Tanium Comply resulta util porque combina visibilidad del endpoint con logica de evaluacion continua, eliminando la brecha temporal entre escaneo y remediacion que existe en modelos tradicionales basados en escaneres periodicos.

Comply y la evaluacion de vulnerabilidades. Tanium Comply evalua endpoints contra catalogos de vulnerabilidades (CVEs) y contra benchmarks de configuracion (CIS, DISA STIG). A diferencia de un escaner de red externo que prueba desde fuera, Comply opera desde el propio endpoint, lo que le da acceso a informacion de paquetes instalados, versiones exactas, configuraciones de registro, servicios activos y estado del sistema que un escaneo remoto no siempre puede obtener. Esto mejora la precision de la evaluacion pero no la hace perfecta: la calidad del contenido de evaluacion (definiciones OVAL, checks de benchmark) determina la fiabilidad del resultado.

El flujo operativo de Comply para vulnerabilidades sigue un patron: primero se actualizan las definiciones de vulnerabilidad (feeds OVAL, NVD, feeds propios). Luego se ejecuta la evaluacion sobre los endpoints, que compara paquetes instalados y versiones contra las definiciones. El resultado es una lista de CVEs aplicables por endpoint, con severidad CVSS asociada. Hasta aqui, Comply funciona como cualquier herramienta de vulnerability assessment. La diferencia aparece en la velocidad (evaluacion continua, no periodica) y en la capacidad de actuar inmediatamente porque el mismo agente que evalua puede remediar.

Comply y benchmarks de configuracion. Los benchmarks (CIS, DISA STIG, USGCB) definen configuraciones deseables para sistemas operativos y aplicaciones. Un check de benchmark puede verificar si la politica de contrasenas cumple requisitos minimos, si SMBv1 esta deshabilitado, si el firewall local esta activo o si los logs se envian a un sistema centralizado. Comply evalua cada control y reporta pass, fail o not applicable. La lectura correcta de estos resultados requiere entender que no todo fail es igual de critico y que no todo pass garantiza seguridad real.

Priorizacion contextual. Gestionar riesgo tecnico implica traducir hallazgos a contexto empresarial. Una desviacion grave en un endpoint aislado de laboratorio no tiene el mismo peso que una desviacion moderada en un servidor expuesto que soporta autenticacion corporativa. Del mismo modo, una CVE critica sin exploit disponible y con segmentacion fuerte puede no merecer la misma urgencia que una vulnerabilidad media muy expuesta y facilmente explotable. El programa de cumplimiento tecnico maduro incorpora esa lectura contextual.

La priorizacion efectiva combina al menos cuatro factores:

1. Severidad del hallazgo: CVSS score, criticidad del control fallido.
2. Criticidad del activo: servidor de produccion vs. equipo de test.
3. Exposicion: activo expuesto a internet vs. activo segmentado.
4. Exploitabilidad: existe exploit publico, se observa explotacion activa.
5. Controles compensatorios: segmentacion, WAF, EDR activo que mitiga el riesgo.

Una organizacion que prioriza solo por CVSS termina parcheando endpoints de laboratorio con CVE 9.8 mientras deja un servidor web publico con CVE 7.5 y exploit activo sin remediar.

Gestion de excepciones. No todo hallazgo puede remediarse inmediatamente. Un sistema legacy sin parche disponible, un servidor que no puede reiniciarse en la ventana actual, una aplicacion que es incompatible con la configuracion recomendada. Las excepciones son parte del programa de cumplimiento, pero deben documentarse: que hallazgo se excepciona, en que activos, hasta cuando, que control compensatorio existe y quien asume el riesgo residual.

Comply como programa continuo. El valor real de Comply aparece cuando se opera como programa, no como escaneo puntual. Eso significa: feeds actualizados regularmente, evaluaciones continuas (no mensuales), dashboards que muestren tendencia, integracion con el proceso de parcheo (Patch) y de despliegue (Deploy) para cerrar el ciclo de remediacion, y reportes ejecutivos que traduzcan hallazgos en riesgo comprensible por la direccion.

Contenido ampliado

Puntos clave

• Comply debe traducirse a riesgo y accion, no a volumen puro de hallazgos.
• Hallazgo tecnico y prioridad operativa no son lo mismo.
• El contexto del activo (criticidad, exposicion, rol) cambia la urgencia real.
• La remediacion debe ser tecnica y operativamente viable.
• Las excepciones son legitimas pero requieren documentacion y fecha de caducidad.
• Comply como programa continuo supera al escaneo periodico puntual.

Checklist operativa

• Revisa criticidad de activos afectados antes de priorizar hallazgos.
• Cruza severidad con exposicion, exploitabilidad y controles compensatorios.
• Define propietarios de remediacion para cada grupo de hallazgos.
• Separa backlog urgente de backlog planificado con criterios explicitos.
• Documenta excepciones con fecha de revision y control compensatorio.
• Reporta tendencia periodicamente a la direccion con metricas comprensibles.

Errores frecuentes

• Priorizar solo por CVSS o severidad teorica sin mirar contexto del activo.
• Ignorar contexto de red, exposicion o servicio al evaluar hallazgos.
• No documentar decisiones de excepcion y riesgo residual aceptado.
• Tratar todos los hallazgos como iguales independientemente del activo.
• Usar Comply como escaneo mensual puntual en vez de programa continuo.
• Reportar volumen de hallazgos a direccion sin traducir a riesgo de negocio.

Practica sugerida

Prioriza una lista de diez hallazgos ficticios mezclando criticidad de activo, exposicion real, severidad CVSS y presencia de exploit. Para cada hallazgo, indica: prioridad (critica/alta/media/baja), justificacion de la prioridad, accion recomendada y plazo. Para dos de ellos, redacta una excepcion documentada con control compensatorio.

Preguntas de autoevaluacion

• Por que dos CVEs con la misma severidad CVSS pueden tener prioridad operativa distinta.
• Que papel juegan los controles compensatorios en la priorizacion.
• Que hace que un backlog de hallazgos sea poco util para la toma de decisiones.
• Que diferencia hay entre evaluacion de vulnerabilidades y evaluacion de benchmarks.
• Por que un programa de cumplimiento continuo supera al escaneo periodico.

Cierre

Comply aporta valor real cuando el hallazgo tecnico se transforma en decision de riesgo informada y en remediacion priorizada por contexto de negocio, no cuando solo produce listas largas de vulnerabilidades sin accion.

Modulo 02. Benchmarking, baselines y desviaciones

Objetivo del modulo

Aplicar baselines de hardening con criterio y entender cómo interpretar desviaciones frente a un benchmark técnico.

Resultados esperados

• Diferenciar benchmark genérico y baseline adoptada.
• Identificar controles no aplicables o sujetos a excepción.
• Medir desviaciones con sentido operativo.

Desarrollo teorico

Un benchmark es un conjunto de controles o recomendaciones publicado por una entidad reconocida (CIS, DISA STIG, USGCB, fabricantes) que define configuraciones de seguridad deseables para un tipo de sistema. Una baseline es la traducción concreta de ese benchmark al entorno real de la organización. Esa diferencia es esencial y frecuentemente malinterpretada: muy pocas organizaciones pueden aplicar al 100% un benchmark genérico sin adaptación. Algunas configuraciones dependen del tipo de activo, del rol del sistema dentro de la infraestructura, de la versión del sistema operativo, de aplicaciones legacy que necesitan una excepción temporal o permanente, o de requisitos de rendimiento que colisionan con controles restrictivos.

Del benchmark a la baseline. El proceso de crear una baseline a partir de un benchmark implica varias decisiones técnicas y de gobierno. Primero se selecciona el benchmark aplicable al tipo de sistema (por ejemplo, CIS Benchmark para Windows Server 2022 Level 1). Luego se revisa cada control del benchmark y se clasifica en una de cuatro categorías: aplicable tal cual (el control se adopta sin modificación), aplicable con adaptación (el control se adopta pero con un valor o configuración diferente al recomendado, documentando la justificación), no aplicable (el control no tiene sentido para el rol del sistema o el entorno, por ejemplo un control de WiFi en un servidor de datacenter) y exceptuado (el control debería aplicarse pero no puede aplicarse por una limitación técnica o de negocio, y se documenta la excepción con control compensatorio y fecha de revisión).

Este trabajo de clasificación no es trivial y no debería hacerlo un solo equipo de forma aislada. Requiere la participación de seguridad (que entiende el riesgo de cada control), operaciones (que conoce el impacto operativo de cada configuración), arquitectura (que sabe cómo encaja el sistema en la infraestructura global) y en algunos casos negocio (cuando un control afecta a la funcionalidad de una aplicación crítica).

Niveles de benchmark. La mayoría de los benchmarks CIS definen dos niveles. El Level 1 incluye controles que pueden aplicarse a la mayoría de sistemas sin impacto significativo en funcionalidad ni rendimiento. El Level 2 incluye controles más restrictivos que proporcionan mayor seguridad pero pueden limitar funcionalidad o requerir configuración adicional. La decisión de qué nivel adoptar como baseline debe ser explícita y justificada. Muchas organizaciones adoptan Level 1 como baseline general y Level 2 para sistemas de alta criticidad o exposición.

Medición de desviaciones con Tanium Comply. Una vez definida la baseline, Tanium Comply evalúa los endpoints contra ella y reporta las desviaciones. Cada control evaluado produce un resultado: pass (el endpoint cumple), fail (no cumple), error (no se pudo evaluar) o not applicable. La lectura correcta de las desviaciones requiere contexto. Un fail no siempre es un hallazgo de seguridad relevante. Puede ser un control que está marcado como excepción aprobada pero aún no se ha configurado la exclusión en Comply. Puede ser un control que no aplica al rol específico del servidor pero el perfil de evaluación no lo excluye. Puede ser un control que se rompió por un cambio reciente no planificado. Cada tipo de fail requiere una respuesta diferente.

Gestión de desviaciones operativas. Las desviaciones se gestionan mediante un flujo que incluye detección (Comply reporta el fail), clasificación (se determina si es un hallazgo real, una excepción conocida o un falso positivo), asignación (se asigna un owner responsable de la remediación o de la justificación de la excepción), remediación o excepción (se corrige la configuración o se documenta formalmente la excepción) y verificación (se confirma que la corrección ha surtido efecto en la siguiente evaluación).

Las organizaciones maduras automatizan parte de este flujo. Las desviaciones que corresponden a excepciones aprobadas se filtran automáticamente de los reportes operativos. Las desviaciones nuevas generan tickets automatizados con asignación al owner correspondiente. Las correcciones se verifican en la siguiente evaluación sin intervención manual.

Evolución de la baseline. Una baseline no es estática. Debe revisarse cuando cambia el benchmark de referencia (CIS publica versiones actualizadas regularmente), cuando cambia la plataforma (nueva versión del SO, cambio de arquitectura), cuando cambian los requisitos regulatorios o de negocio, o cuando la experiencia operativa demuestra que un control genera más fricción que valor de seguridad. La revisión de la baseline debe ser un proceso gobernado con cadencia definida (al menos anual) y participación de los mismos equipos que intervinieron en su creación.

Scoring y métricas de cumplimiento. El porcentaje de cumplimiento de una baseline es una métrica de resumen útil pero que debe leerse con cuidado. Un 95% de cumplimiento puede significar que el 5% restante incluye los controles más críticos. Por eso el scoring debe complementarse con análisis del impacto de los controles no cumplidos. Las métricas útiles incluyen porcentaje de cumplimiento global, porcentaje de cumplimiento por tipo de activo, número de desviaciones críticas (controles de alto impacto no cumplidos), número de excepciones activas con y sin control compensatorio, y tendencia de cumplimiento a lo largo del tiempo.

Contenido ampliado

Puntos clave

• No todo benchmark debe aplicarse igual a todo activo; la baseline es una decisión de gobierno técnico.
• Las desviaciones solo son útiles si se leen con contexto de aplicabilidad y criticidad del control.
• Las excepciones son parte legítima del programa pero deben ser formales, documentadas y revisables.
• La baseline debe revisarse periódicamente porque el benchmark, la plataforma y los requisitos evolucionan.
• El porcentaje de cumplimiento global debe complementarse con análisis de impacto de los controles fallidos.

Checklist operativa

• Revisa aplicabilidad de cada control del benchmark por tipo de activo y rol del sistema.
• Clasifica controles como aplicables, adaptados, no aplicables o exceptuados.
• Documenta excepciones con justificación, control compensatorio y fecha de revisión.
• Define criterio de medición, frecuencia de evaluación y owners por grupo de activos.
• Establece cadencia de revisión de la baseline (al menos anual).
• Valida que la baseline sigue siendo vigente cuando cambia la plataforma o el benchmark de referencia.

Errores frecuentes

• Adoptar benchmarks sin adaptación al entorno real, generando fricción y falsos hallazgos.
• Mezclar excepciones temporales con permanentes sin fecha de revisión.
• No revisar la baseline cuando cambia la plataforma, el benchmark o los requisitos.
• Medir cumplimiento sin contexto de aplicabilidad ni criticidad de los controles.
• Tratar todo fail como hallazgo de seguridad sin clasificar excepciones conocidas.
• Usar el porcentaje de cumplimiento global como única métrica sin analizar el impacto de los fails.

Practica sugerida

Prepara una tabla de baseline para servidores Windows y puestos de usuario: selecciona 15 controles CIS, clasifícalos como aplicables, adaptados o exceptuados para cada tipo de activo, y para las excepciones documenta el control compensatorio y la fecha de revisión.

Preguntas de autoevaluacion

• Qué diferencia hay entre benchmark y baseline y por qué importa esa distinción.
• Cuándo una desviación no debería tratarse como fallo operativo.
• Por qué la excepción debe tener fecha de revisión y control compensatorio.
• Qué equipos deben participar en la creación de una baseline y por qué.
• Por qué un 95% de cumplimiento puede ser peor que un 85% en otro contexto.

Cierre

Benchmarking aporta valor real cuando se convierte en una baseline realista, gobernada y revisada periódicamente, no en un objetivo universal aplicado sin contexto ni adaptación al entorno operativo.