De VMDR a remediación: cómo priorizar vulnerabilidades por riesgo y no por cantidad

Una lista de miles de vulnerabilidades no es un plan. Así se convierte en uno.

Cuando una organización despliega por primera vez un escáner o un agente de vulnerabilidades, el primer reporte suele generar más ansiedad que claridad. Aparecen miles de hallazgos, muchos de ellos marcados como críticos, y el equipo de infraestructura no sabe por dónde empezar.

Si la respuesta es “atacar primero todo lo que tenga CVSS 9 o más”, el equipo se agota en pocas semanas y el riesgo real casi no se mueve.

Este artículo explica cómo pasar de esa lista a un plan de remediación ordenado por riesgo real: qué factores importan, cómo los combina Qualys VMDR con TruRisk, cómo agrupar el trabajo y qué reportar a la gerencia.

Por qué el CVSS por sí solo no basta

El CVSS (Common Vulnerability Scoring System, sistema común de puntuación de vulnerabilidades) mide la severidad técnica de una falla: qué tan fácil sería explotarla y qué impacto tendría sobre la confidencialidad, la integridad y la disponibilidad.

Es un estándar útil y necesario, pero responde a una sola pregunta: “¿qué tan grave podría ser?”. No responde a otras igual de importantes:

• ¿Alguien la está explotando hoy?
• ¿El activo afectado es accesible desde internet o está aislado en una red interna?
• ¿Ese servidor sostiene la facturación de la empresa o es un equipo de pruebas?
• ¿Existe un control compensatorio que ya reduce el riesgo?

El resultado práctico es conocido: muchas vulnerabilidades reciben puntajes altos, de modo que ordenar solo por CVSS deja demasiados hallazgos “urgentes” en el mismo nivel. Priorizar todo equivale a no priorizar nada.

Los cuatro factores del riesgo real

Un enfoque basado en riesgo combina la severidad técnica con el contexto de la amenaza y del negocio. Estos son los factores que conviene considerar.

1. Explotabilidad

¿Existe código de explotación público? ¿Es una prueba de concepto o una herramienta madura, integrada en kits de ataque?

Una vulnerabilidad de severidad media con un exploit funcional disponible puede ser más peligrosa que una crítica que solo existe en papel.

2. Explotación activa

Aquí hay dos referencias públicas que cualquier equipo puede consultar:

• El catálogo KEV (Known Exploited Vulnerabilities, vulnerabilidades explotadas conocidas) de CISA, la agencia de ciberseguridad e infraestructura de Estados Unidos. Lista las vulnerabilidades con evidencia de explotación en el mundo real, y la propia CISA recomienda usarlo como insumo para priorizar. Se publica en CSV y JSON, lo que facilita cruzarlo con sus hallazgos.
• El EPSS (Exploit Prediction Scoring System, sistema de predicción de explotación), mantenido por FIRST, el foro internacional de equipos de respuesta a incidentes. Estima la probabilidad de que un CVE sea explotado en los próximos 30 días. El puntaje va de 0 a 1, viene acompañado de un percentil y se actualiza a diario.

Ambos se complementan: KEV dice “esto ya se está explotando”; EPSS dice “esto tiene alta probabilidad de explotarse pronto”.

3. Exposición

Un servidor web publicado en internet no tiene el mismo riesgo que una base de datos en una VLAN aislada, aunque ambos tengan la misma vulnerabilidad.

La exposición considera si el activo es alcanzable desde redes externas, si el servicio vulnerable está habilitado y si hay controles que limitan el acceso.

4. Criticidad del activo

Es el factor que solo su organización puede definir. Un controlador de dominio, el ERP o el servidor que procesa pagos merecen más atención que un equipo de laboratorio.

Sin una clasificación de activos, cualquier modelo de priorización queda incompleto.

Factor	Pregunta que responde	Fuente típica
Severidad técnica	¿Qué tan grave podría ser?	CVSS del CVE
Explotabilidad	¿Hay exploit disponible y qué tan maduro es?	Inteligencia de amenazas
Explotación activa	¿Se explota hoy o es probable que se explote pronto?	Catálogo KEV de CISA, EPSS de FIRST
Exposición	¿Un atacante puede alcanzar el activo?	Inventario y topología de red
Criticidad del activo	¿Cuánto le importa ese activo al negocio?	Clasificación interna de activos

Cómo combinan estos factores Qualys VMDR y TruRisk

Trabajamos con Qualys, y su plataforma VMDR (Vulnerability Management, Detection and Response) aplica precisamente esta lógica. Según la documentación pública de Qualys, el modelo TruRisk se apoya en tres piezas.

QDS (Qualys Detection Score). Es un puntaje de 1 a 100 para cada detección. Parte de la severidad técnica y la ajusta con inteligencia de amenazas: madurez del exploit, asociación con malware, actividad de actores de amenaza y si la amenaza está en tendencia.

El QDS también puede bajar si el activo tiene controles compensatorios; por ejemplo, si el servicio vulnerable está deshabilitado. La documentación agrupa el QDS en bandas (crítico, alto, medio y bajo) y sugiere atender primero las detecciones de 70 o más.

ACS (Asset Criticality Score). Es la criticidad del activo, que se asigna mediante etiquetas (tags). Los ejemplos de la documentación usan una escala de 1 a 5; si un activo tiene varias etiquetas, prevalece el valor más alto.

TruRisk Score. Es el puntaje de riesgo del activo. Combina la criticidad con las detecciones del equipo, ponderadas por severidad, y tiene un tope de 1 000. La documentación indica que la exposición externa del activo también influye en el resultado.

El detalle del cálculo cambia entre versiones del producto, así que conviene revisarlo en la documentación de la versión que usted utiliza. Lo importante es el principio: la misma vulnerabilidad pesa distinto según la amenaza real y según el activo donde aparece.

Para que el modelo funcione, hay un trabajo previo que le corresponde a su organización: etiquetar los activos por entorno, función y criticidad. Si todos los equipos tienen la misma criticidad por defecto, TruRisk ordenará bien las amenazas, pero no sabrá qué es importante para su negocio.

De la lista al plan de remediación

Un ranking todavía no es un plan. Para convertirlo en trabajo ejecutable conviene seguir estos pasos.

Agrupe por parche y por causa raíz

Muchas detecciones distintas se cierran con una sola acción. Una actualización acumulativa de Windows puede resolver decenas de hallazgos; actualizar una versión de Java o de un navegador elimina varios CVE a la vez.

Agrupe los hallazgos por solución, no por vulnerabilidad, y el volumen de trabajo se reduce de forma notable.

Busque también la causa raíz. Si el mismo software desactualizado aparece en todos los equipos, el problema no es cada equipo, sino la imagen base o el proceso de actualización.

Defina plazos y ventanas por nivel de riesgo

Acuerde con las áreas de negocio plazos objetivo por banda de riesgo y ventanas de mantenimiento realistas.

Lo más urgente (por ejemplo, una vulnerabilidad del catálogo KEV en un activo expuesto a internet) puede justificar un cambio de emergencia. Lo de riesgo bajo puede esperar al ciclo regular. Los plazos son decisión de su organización y deben quedar documentados en su política de gestión de vulnerabilidades.

Ejecute con Patch Management

Con Qualys Patch Management se pueden crear trabajos de parcheo dirigidos a grupos de activos por etiqueta, con ventanas y políticas de reinicio definidas.

La ventaja de tener detección y parcheo en la misma plataforma es que la priorización de VMDR alimenta directamente la ejecución, sin pasar por hojas de cálculo.

Para lo que no se resuelve con un parche (configuraciones inseguras, software sin soporte, servicios innecesarios), registre una tarea de remediación con responsable y fecha.

Gestione excepciones con fecha de vencimiento

Habrá vulnerabilidades que no se pueden corregir de inmediato: una aplicación heredada que no soporta la nueva versión, o un equipo médico o industrial que el fabricante no permite actualizar. Para esos casos:

• documente la justificación y el control compensatorio;
• obtenga la aprobación de quien asume el riesgo;
• fije una fecha de vencimiento para la excepción y revísela al llegar.

Una excepción sin fecha se convierte en un riesgo aceptado de forma permanente sin que nadie lo haya decidido.

Verifique con un nuevo escaneo

Aplicar un parche no es lo mismo que cerrar una vulnerabilidad. El parche puede fallar, quedar pendiente de reinicio o aplicarse solo a una parte de los equipos.

La única evidencia válida es una nueva detección: un escaneo o una recolección del agente posterior a la ventana de cambios que confirme que el hallazgo ya no aparece.

Esta verificación también protege al equipo. Permite demostrar con datos que el trabajo se hizo y detectar a tiempo los equipos que quedaron fuera.

Qué reportar a la gerencia

A la gerencia no le sirve un PDF de cientos de páginas con cada CVE. Le sirve saber si el riesgo está bajando y si el equipo cumple los plazos acordados.

Estas métricas se calculan con sus propios datos:

• Tendencia del riesgo: evolución del TruRisk Score de los activos críticos, mes a mes.
• Tiempo de remediación: cuánto tarda en promedio el cierre de los hallazgos por banda de riesgo, y cuántos se cierran dentro del plazo.
• Exposición a amenazas activas: cuántos activos tienen vulnerabilidades presentes en el catálogo KEV, y si ese número baja.
• Hallazgos envejecidos: cuántas vulnerabilidades de riesgo alto superan el plazo de su política.
• Excepciones vigentes: cuántas hay, quién las aprobó y cuándo vencen.
• Cobertura: qué parte del inventario se evalúa efectivamente. Un activo sin agente ni escaneo es un punto ciego.

Presente tendencias, no fotografías aisladas. Una cifra suelta dice poco; la misma cifra a lo largo de varios meses muestra si el proceso funciona.

Cómo empezar

Checklist de priorización y remediación

• Inventario completo: todos los activos tienen agente o entran en un escaneo periódico.
• Activos etiquetados por entorno, función y criticidad (ACS asignado).
• Hallazgos cruzados con el catálogo KEV de CISA y, si le resulta útil, con EPSS.
• Activos expuestos a internet identificados y etiquetados.
• Política con plazos de remediación por banda de riesgo, aprobada por la gerencia.
• Hallazgos agrupados por parche o solución, no por CVE.
• Ventanas de mantenimiento acordadas con las áreas de negocio.
• Trabajos de parcheo programados para los grupos de mayor riesgo.
• Excepciones documentadas, aprobadas y con fecha de vencimiento.
• Nuevo escaneo después de cada ventana para confirmar el cierre.
• Reporte mensual de tendencias y tiempos de remediación para la gerencia.

En resumen

Priorizar por riesgo no significa ignorar las vulnerabilidades de menor puntaje. Significa atender primero las que un atacante puede aprovechar hoy, en los activos que más le importan a su negocio. El CVSS sigue siendo un insumo, pero no la decisión final.

Si desea ver cómo se aplica este enfoque con la plataforma, puede revisar nuestra página de gestión de vulnerabilidades con Qualys.