Qualys: agentes, etiquetas, priorización y la vulnerabilidad que sigue ahí tras parchear

Qué vas a conseguir

Un inventario de vulnerabilidades que cubre todos los equipos, ordenado por lo que de verdad importa, con plazos que el equipo de sistemas conoce y cumple, y excepciones escritas en lugar de olvidadas. Y el criterio para responder cuando alguien dice "ya lo he parcheado y Qualys sigue diciendo que no".

Antes de empezar

• Una suscripción de Qualys VMDR con acceso a la plataforma de tu región (la URL de la plataforma y del servicio de agentes dependen de ella: aparecen en la propia consola).
• Un appliance de escaneo virtual en la red interna para los equipos sin agente.
• Quién parchea qué: el equipo de puestos (Intune o MECM), el de servidores, el de red. Sin dueño, una vulnerabilidad no se cierra nunca.

1. Desplegar Cloud Agent con Intune o MECM

En Cloud Agent › Agent Management › Activation Keys se crea una clave de activación por tipo de equipo (puestos, servidores) y se le asocian etiquetas: cada agente que se active con ella las recibe. Después se descarga el instalador de Windows y se empaqueta:

• En MECM es lo mismo como aplicación con método de detección por la clave de registro, desplegada a una colección. En Linux, paquete .rpm o .deb y un script con los mismos tres valores.
• El agente informa en Cloud Agent › Agents: estado, versión y Last Checked-In. Un agente que lleva días sin conectar es un equipo que no estás viendo.
• Revisa el perfil de configuración del agente: intervalo de escaneo de vulnerabilidades y límite de CPU. El de puestos puede ser más agresivo que el de servidores críticos.

2. Etiquetas: quién es quién

Las etiquetas son la base de todo lo demás: informes, plazos, escaneos y dueños.

• Dinámicas por regla: sistema operativo, rango de red (10.20.0.0/16 = CPD Madrid), nombre (srv-*), software instalado.
• De negocio: entorno (Producción, Preproducción), propietario (Sistemas, Puestos, Red) y criticidad del activo del 1 al 5. En VMDR la criticidad entra en el cálculo del TruRisk del activo.
• Expuesto a Internet: una etiqueta para lo que está publicado (proxies inversos, VPN, web). Es el primer filtro de prioridad.

3. Escaneo autenticado frente a agente

Lo normal es agente en todo lo que lo admite y escaneo autenticado para el resto, más un escaneo externo del perímetro. Los registros de autenticación se crean en Scans › Authentication: para Windows, una cuenta de dominio dedicada con derechos de administrador local en los servidores (por GPO) y acceso por SMB; para Linux, SSH con clave y sudo limitado. Tras cada escaneo, el informe de autenticación dice en qué equipos falló el inicio de sesión: un escaneo sin autenticar encuentra una fracción de lo que hay.

4. Leer una detección y priorizar

Cada detección tiene un QID (la comprobación de Qualys), su severidad de 1 a 5, los CVE que cubre, el QDS (Qualys Detection Score, de 1 a 100, que pondera explotación conocida y amenaza activa), el estado (New, Active, Fixed, Reopened) y, lo más útil, el campo Results: la prueba concreta que encontró, normalmente una ruta y una versión de fichero.

El orden de trabajo sale de cruzar tres cosas: ¿está en el catálogo KEV o se explota activamente?, ¿está expuesto? y ¿qué criticidad tiene el activo? Una severidad 5 en un portátil de pruebas sin datos puede esperar a un QDS 90 en un servidor publicado. La severidad sola no ordena el trabajo.

5. El ciclo de parcheo y reescaneo, con plazos

Los plazos son de ejemplo: lo importante es que estén aprobados por la dirección y que el informe mensual los mida.

1. El informe por propietario (etiqueta) sale el día después del Patch Tuesday.
2. Cada equipo parchea con su herramienta (Intune, MECM, el repositorio de Linux).
3. El agente reescanea en su intervalo, o se fuerza (sección 6). La detección pasa a Fixed sola: nadie la cierra a mano.
4. Lo que no se puede parchear en plazo pide una excepción documentada: motivo, control compensatorio (aislamiento de red, regla del cortafuegos, deshabilitar el servicio), responsable y fecha de caducidad. En Qualys se registra ignorando la detección con comentario y fecha; en el registro de riesgos, con su aprobación.

Una excepción sin fecha de caducidad es una vulnerabilidad aceptada para siempre. Revísalas todas cada trimestre.

6. El ticket: "la vulnerabilidad sigue ahí después de parchear"

Javier Ruiz, del equipo de servidores: "Parcheé srv-files02 el martes y Qualys sigue con la detección de Windows de octubre."

1. ¿Ha informado el agente desde el parche? En Cloud Agent › Agents, la fecha de Last Checked-In y la del último escaneo de vulnerabilidades. Si es anterior al parche, Qualys aún no lo sabe.
2. Forzar un escaneo en el propio servidor:

›Get-Service QualysAgent | Select-Object Status, StartTypeStatus  StartType------  ---------Running Automatic›Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 2 HotFixID, InstalledOnHotFixID  InstalledOn--------  -----------KB5066123 21/10/2026 0:00:00KB5065410 16/09/2026 0:00:00›Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"True›Set-ItemProperty -Path "HKLM:\SOFTWARE\Qualys\QualysAgent\ScanOnDemand\Vulnerability" -Name ScanOnDemand -Value 1

1. Reinicio pendiente. Aquí está: la actualización está instalada pero los ficheros no se sustituyen hasta reiniciar, y Qualys mira la versión del fichero, no la lista de KB. Reiniciar en la ventana y reescanear.
2. Si no es eso, leer el campo Results. Dice qué fichero y qué versión ha encontrado. Las causas habituales:

• Parche sustituido: se instaló una actualización anterior y la detección pide la acumulativa más reciente.
• Otro producto: la ruta es de una segunda instalación (una versión antigua de Java, .NET o un runtime que una aplicación lleva dentro), no la que se ha actualizado.
• Requiere configuración: algunas correcciones necesitan además una clave de registro o un cambio de configuración; la descripción del QID lo indica.

1. Si la prueba no tiene sentido (el fichero está en la versión corregida), abre un caso con Qualys con el QID, el activo y el contenido de Results: puede ser un error en la lógica de detección.

7. Lo que revisas cada mes

• Cobertura: activos del inventario sin agente o sin escaneo autenticado correcto, y agentes que no informan en 7 días.
• Cumplimiento de plazos por prioridad y por propietario, y la tendencia del TruRisk.
• Detecciones KEV abiertas en activos expuestos: debería ser cero.
• Excepciones a punto de caducar y las ya caducadas.

Siguientes pasos

• La guía de Intune y la de MECM / SCCM para los anillos de actualización que cierran la mayoría de detecciones.
• Microsoft Sentinel para correlacionar las vulnerabilidades críticas con alertas sobre los mismos activos.
• ISO 27001/NIS2/RGPD en IT para encajar los plazos y las excepciones en la gestión de riesgos.
• Ansible para aplicar parches y cambios de configuración en Linux de forma repetible.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.