Una VPN con un exploit conocido y treinta servidores sin reiniciar: la corrección de vulnerabilidades frente al SLA

El problema

El escáner dice cuántas vulnerabilidades hay; no dice si estamos cumpliendo lo que prometimos, los plazos de corrección por severidad. Esos plazos se suelen seguir en una hoja de cálculo actualizada a mano, y las cifras esconden los motivos: un equipo de VPN que vuelve de un cambio por garantía con un firmware antiguo y una vulnerabilidad explotada desde hace dos años; servidores con el parche instalado hace una semana que siguen siendo vulnerables porque nadie acordó el reinicio; equipos de la sala de trading vulnerables otra vez tras reinstalarse desde una imagen maestra antigua; servidores con un sistema operativo que ya no se puede parchear, cubiertos por una excepción que caducó hace un mes; un equipo que cierra la mitad de sus correcciones a tiempo mientras el resto supera el 90 %; y una actualización del navegador, retenida por una versión fijada, que supone el 40 % de todas las vulnerabilidades críticas y altas de los portátiles.

Qué he hecho

• SLA: cada detección abierta de Qualys con su plazo (15, 30, 90 o 180 días según la severidad; 7 días si está en el catálogo KEV de CISA, tiene un EPSS alto o es crítica en un equipo expuesto a internet) y su estado: en plazo, vence en 7 días, vencida o vencida más del doble del plazo.
• KEV y exposición: vulnerabilidades explotadas conocidas abiertas después de la fecha límite de CISA, equipos expuestos a internet con vulnerabilidades críticas o altas, y detecciones vencidas con un EPSS alto.
• Por qué no se cierran: parche instalado con el reinicio pendiente, detecciones que vuelven a abrirse tras corregirse y sistemas operativos sin soporte del fabricante.
• Cobertura y excepciones: equipos que Qualys no analiza o no analiza desde hace dos semanas, equipos sin responsable, agentes de parcheo que fallan, y excepciones caducadas, sin control compensatorio o demasiado amplias.
• Arreglos y tendencia: las diez actualizaciones o paquetes que más riesgo eliminan, el porcentaje cerrado dentro del plazo en cada uno de los tres últimos meses, el tiempo medio de corrección por severidad y los equipos responsables que van con retraso.
• report.html con un estado por área y un veredicto global, sla-review.md con la lista semanal de críticas y el informe mensual, CSV de cada área y un exportador de solo lectura en PowerShell para la API de Qualys, el catálogo KEV de CISA, la API de EPSS e Intune.

Cómo está hecho

Python solo con la librería estándar. La demo es un bróker inventado con unos 400 servidores y 1.200 equipos con Windows 11 repartidos entre seis equipos responsables: casi 7.000 detecciones de Qualys (abiertas y corregidas recientemente), el inventario de activos, el estado de parcheo de Tanium e Intune, siete excepciones, puntuaciones EPSS y una pequeña muestra del catálogo KEV, con los problemas puestos a propósito. 15 tests, un runbook para las revisiones semanal y mensual y para pedir o renovar una excepción, y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.

Qué aprendí

De llevar la IT de una sede, donde uso Qualys y Tanium para la gestión de vulnerabilidades y parches, Microsoft Defender (que uso desde un puesto anterior) e Intune y MECM en cogestión, incluida la migración a Windows 11 de una oficina con sala de trading; de la gestión de riesgos de ciberseguridad, los planes de tratamiento y el seguimiento de la corrección con métricas e indicadores de seguridad; de aplicar ISO 27001, NIS2 y NIST CSF, y de las auditorías; y del CAB como responsable del proceso de cambios. Las lecciones que dan forma a la herramienta son que el reloj empieza cuando el escáner encuentra la vulnerabilidad, así que la cobertura forma parte del SLA; que un exploit conocido manda sobre la puntuación de severidad; que instalado no es corregido hasta que el equipo se reinicia; que muchos equipos que vuelven a abrirse la misma semana apuntan a una imagen, no a la mala suerte; que una excepción es una decisión con fecha de caducidad y un control, no una forma de poner el informe en verde; y que una sola actualización bien desplegada puede cerrar la mitad de la lista.

Siguientes pasos

• Leer Qualys y Tanium desde sus API de forma programada, para que la lista semanal de críticas esté lista el lunes por la mañana sin exportaciones.
• Abrir un ticket por equipo responsable con sus detecciones vencidas y los arreglos que las cierran, y cerrarlo cuando el nuevo análisis lo confirme.
• Comparar cada mes con el anterior: nuevas, cerradas y aún vencidas, y el porcentaje dentro del plazo por equipo.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.