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
.rpmo.deby 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
| Cloud Agent | Escaneo autenticado | |
|---|---|---|
| Qué cubre | Puestos y servidores Windows, Linux y macOS con agente | Todo lo que tiene IP, incluidos equipos de red, appliances e impresoras |
| Credenciales | No necesita | Registros de autenticación (Windows, Unix, por SSH, SNMP…) |
| Portátiles fuera de la oficina | Siguen informando | No los ve |
| Visión de red | No | Puertos y servicios abiertos tal como los ve un atacante interno |
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
| Prioridad | Criterio | Plazo |
|---|---|---|
| Crítica | KEV o explotación activa en activo expuesto o crítico | 72 horas |
| Alta | QDS 70 o más, o severidad 5 | 14 días |
| Media | QDS 40–69, severidad 3–4 | 60 días |
| Baja | El resto | Siguiente ciclo de mantenimiento |
Los plazos son de ejemplo: lo importante es que estén aprobados por la dirección y que el informe mensual los mida.
- El informe por propietario (etiqueta) sale el día después del Patch Tuesday.
- Cada equipo parchea con su herramienta (Intune, MECM, el repositorio de Linux).
- El agente reescanea en su intervalo, o se fuerza (sección 6). La detección pasa a Fixed sola: nadie la cierra a mano.
- 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."
- ¿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.
- Forzar un escaneo en el propio servidor:
Get-Service QualysAgent | Select-Object Status, StartTypeStatus StartType------ ---------Running AutomaticGet-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 2 HotFixID, InstalledOnHotFixID InstalledOn-------- -----------KB5066123 21/10/2026 0:00:00KB5065410 16/09/2026 0:00:00Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"TrueSet-ItemProperty -Path "HKLM:\SOFTWARE\Qualys\QualysAgent\ScanOnDemand\Vulnerability" -Name ScanOnDemand -Value 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.
- 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.
- 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.
What you'll get
A vulnerability inventory that covers every machine, ordered by what really matters, with deadlines the infrastructure team knows and meets, and exceptions written down instead of forgotten. And the judgement to answer when someone says "I've already patched it and Qualys still says no".
Before you start
- A Qualys VMDR subscription with access to your region's platform (the platform and agent service URLs depend on it: they appear in the console itself).
- A virtual scanner appliance on the internal network for machines without an agent.
- Who patches what: the endpoint team (Intune or MECM), the server team, the network team. Without an owner, a vulnerability never gets closed.
1. Deploy Cloud Agent with Intune or MECM
In Cloud Agent › Agent Management › Activation Keys you create an activation key per type of machine (endpoints, servers) and attach tags to it: every agent activated with it receives them. Then download the Windows installer and package it:
- In MECM it is the same as an application with a registry key detection method, deployed to a collection. On Linux, an
.rpmor.debpackage and a script with the same three values. - The agent reports in Cloud Agent › Agents: status, version and Last Checked-In. An agent that hasn't connected for days is a machine you aren't seeing.
- Review the agent's configuration profile: vulnerability scan interval and CPU limit. The endpoint one can be more aggressive than the one for critical servers.
2. Tags: who is who
Tags are the basis of everything else: reports, deadlines, scans and owners.
- Dynamic by rule: operating system, network range (
10.20.0.0/16= Madrid data centre), name (srv-*), installed software. - Business: environment (Production, Pre-production), owner (Servers, Endpoints, Network) and asset criticality from 1 to 5. In VMDR, criticality feeds into the asset's TruRisk score.
- Internet-facing: a tag for what is published (reverse proxies, VPN, web). It is the first priority filter.
3. Authenticated scan versus agent
| Cloud Agent | Authenticated scan | |
|---|---|---|
| What it covers | Windows, Linux and macOS endpoints and servers with the agent | Anything with an IP, including network devices, appliances and printers |
| Credentials | Not needed | Authentication records (Windows, Unix over SSH, SNMP…) |
| Laptops away from the office | Keep reporting | Not seen |
| Network view | No | Open ports and services as an internal attacker sees them |
The usual pattern is the agent on everything that supports it and authenticated scans for the rest, plus an external perimeter scan. Authentication records are created in Scans › Authentication: for Windows, a dedicated domain account with local administrator rights on the servers (via GPO) and SMB access; for Linux, SSH with a key and limited sudo. After each scan, the authentication report shows which machines the login failed on: an unauthenticated scan finds a fraction of what is there.
4. Read a detection and prioritise
Each detection has a QID (the Qualys check), its severity from 1 to 5, the CVEs it covers, the QDS (Qualys Detection Score, 1 to 100, weighting known exploitation and active threats), the status (New, Active, Fixed, Reopened) and, most usefully, the Results field: the specific evidence it found, usually a file path and version.
The order of work comes from crossing three things: is it in the KEV catalogue or actively exploited?, is it exposed? and how critical is the asset? A severity 5 on a test laptop with no data can wait behind a QDS 90 on a published server. Severity alone doesn't order the work.
5. The patch-and-rescan loop, with deadlines
| Priority | Criterion | Deadline |
|---|---|---|
| Critical | KEV or active exploitation on an exposed or critical asset | 72 hours |
| High | QDS 70 or higher, or severity 5 | 14 days |
| Medium | QDS 40–69, severity 3–4 | 60 days |
| Low | Everything else | Next maintenance cycle |
These deadlines are examples: what matters is that management approves them and the monthly report measures them.
- The report per owner (tag) goes out the day after Patch Tuesday.
- Each team patches with its own tool (Intune, MECM, the Linux repository).
- The agent rescans on its interval, or a scan is forced (section 6). The detection moves to Fixed by itself: nobody closes it by hand.
- Whatever can't be patched in time needs a documented exception: reason, compensating control (network isolation, a firewall rule, disabling the service), owner and expiry date. In Qualys it is recorded by ignoring the detection with a comment and a date; in the risk register, with its approval.
An exception with no expiry date is a vulnerability accepted for ever. Review them all every quarter.
6. The ticket: "the vulnerability is still there after patching"
Javier Ruiz, from the server team: "I patched srv-files02 on Tuesday and Qualys still shows the October Windows detection."
- Has the agent reported since the patch? In Cloud Agent › Agents, the Last Checked-In date and the last vulnerability scan. If they are earlier than the patch, Qualys doesn't know yet.
- Force a scan on the server itself:
Get-Service QualysAgent | Select-Object Status, StartTypeStatus StartType------ ---------Running AutomaticGet-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 2 HotFixID, InstalledOnHotFixID InstalledOn-------- -----------KB5066123 21/10/2026 0:00:00KB5065410 16/09/2026 0:00:00Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"TrueSet-ItemProperty -Path "HKLM:\SOFTWARE\Qualys\QualysAgent\ScanOnDemand\Vulnerability" -Name ScanOnDemand -Value 1- Pending reboot. There it is: the update is installed but the files aren't replaced until the reboot, and Qualys looks at the file version, not the list of KBs. Reboot in the window and rescan.
- If that's not it, read the Results field. It says which file and which version it found. The usual causes:
- Superseded patch: an older update was installed and the detection wants the latest cumulative one.
- A different product: the path belongs to a second installation (an old version of Java, .NET or a runtime bundled inside an application), not the one that was updated.
- Configuration needed: some fixes also need a registry key or a configuration change; the QID description says so.
- If the evidence makes no sense (the file is at the fixed version), open a case with Qualys with the QID, the asset and the Results content: it may be a flaw in the detection logic.
7. What you review each month
- Coverage: inventory assets with no agent or no successful authenticated scan, and agents that haven't reported in 7 days.
- Deadline compliance by priority and by owner, and the TruRisk trend.
- Open KEV detections on exposed assets: it should be zero.
- Exceptions about to expire and those already expired.
Next steps
- The Intune and MECM / SCCM guides for the update rings that close most detections.
- Microsoft Sentinel to correlate critical vulnerabilities with alerts on the same assets.
- ISO 27001/NIS2/RGPD in IT to fit deadlines and exceptions into risk management.
- Ansible to apply patches and configuration changes on Linux repeatably.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →