Gestión de vulnerabilidades: del escaneo al parche, un proceso que toda empresa necesita

Introducción al Problema#

Muchas organizaciones tienen un proceso de gestión de vulnerabilidades que parece funcionar: corren un escaner periódico, el escaner genera un reporte con cientos o miles de hallazgos, el equipo de IT recibe el reporte, y... nada. El reporte queda en un directorio de SharePoint hasta el próximo escaneo, que genera otro reporte igualmente ignorado.

Esto no es gestión de vulnerabilidades — es gestión de reportes. La diferencia entre ambos es un proceso que convierte los hallazgos del escaner en acciones concretas con responsables, plazos y verificación. Sin ese proceso, el escaneo es un ejercicio cosmético que da la ilusión de control sin proveer ninguna reducción real del riesgo.

El problema central es el volumen sin contexto. Un escaner de vulnerabilidades en una red empresarial típica puede generar miles de hallazgos. La gran mayoría de ellos tienen severidad media o baja. Muchos son falsos positivos. Algunos son reales pero sin vector de explotación activo. Y un puñado — a veces menos de 10 — representan el 90% del riesgo real porque están siendo activamente explotados por atacantes en el mundo real y son accesibles en tu entorno.

Sin un sistema de priorización que distinga lo urgente de lo ruidoso, el equipo de IT termina paralizándose frente a la lista interminable o, peor, parcheando vulnerabilidades de baja severidad mientras las críticas siguen abiertas porque el proceso no las distinguió.

Caso Real o Ejemplo Cotidiano#

Una empresa de logística con 200 equipos contrató un escaner de vulnerabilidades externo como parte de un requisito de compliance. El primer escaneo generó 4.847 hallazgos. El equipo de IT pasó 3 semanas "gestionando" el reporte, aplicando parches a sistemas Windows según el orden en que aparecían en el reporte, priorizando por el score CVSS de mayor a menor.

En ese proceso, parchearon 312 vulnerabilidades de severidad media y alta — en su mayoría actualizaciones de software no crítico. Nunca llegaron a los últimos 400 hallazgos del reporte, que incluían dos CVEs activamente explotadas publicadas por CISA en su KEV (Known Exploited Vulnerabilities Catalog): una vulnerabilidad de ejecución remota de código en el servidor VPN perimetral y una escalación de privilegios en el sistema de gestión de flotas accesible desde internet.

Tres semanas después, un atacante explotó la vulnerabilidad del servidor VPN — que estaba en la página 12 del reporte — e instaló un ransomware que cifró 80 servidores. El proceso de gestión de vulnerabilidades había estado activo y funcionando. Pero escanear y ordenar por CVSS sin contexto de explotación real es el equivalente a revisar el botiquín de primeros auxilios mientras hay un incendio en el edificio.

Riesgos para la Empresa#

Explicación Técnica Sencilla#

El ciclo de gestión de vulnerabilidades#

1. DESCUBRIR
   ├── Inventario de activos (¿qué tenés?)
   ├── Escaneo de vulnerabilidades (¿qué está roto?)
   └── Frecuencia: continua o al menos semanal para activos críticos

2. PRIORIZAR
   ├── CVSS score (severidad técnica)
   ├── EPSS score (probabilidad de explotación)
   ├── CISA KEV (¿está siendo explotado activamente?)
   └── Contexto de negocio (¿es crítico para operaciones?)

3. REMEDIAR
   ├── Asignar responsable + fecha límite por SLA
   ├── Parche, mitigación temporal, o aceptación de riesgo documentada
   └── Comunicación al equipo sobre cambios de producción

4. VERIFICAR
   ├── Re-escaneo del activo afectado post-remediación
   ├── Confirmar que el parche resolvió el hallazgo
   └── Cerrar el ticket con evidencia del re-escaneo

5. REPORTAR
   ├── KPIs: Mean Time to Remediate (MTTR) por severidad
   ├── Tendencia de exposición en el tiempo
   └── Reporte para management: riesgo actual vs. trimestre anterior

CVSS: la métrica base pero no suficiente#

CVSS (Common Vulnerability Scoring System) puntúa vulnerabilidades del 0 al 10 basándose en características técnicas: vector de ataque, complejidad, si requiere autenticación, impacto en confidencialidad/integridad/disponibilidad. Un score de 9.8 suena crítico — y lo puede ser. Pero el CVSS puro no dice:

• ¿Está siendo explotado activamente en este momento?
• ¿Existe exploit público disponible?
• ¿Es explotable en tu configuración específica?
• ¿Hay mitigaciones compensatorias que reducen el riesgo real?

Ejemplo de la trampa del CVSS:
  CVE-X: CVSS 9.8 (CRÍTICO)
  - Afecta a una librería de procesamiento de imágenes
  - Requiere que el atacante pueda subir archivos maliciosos
  - Tu aplicación no acepta uploads de usuarios
  → Riesgo real en TU entorno: muy bajo

  CVE-Y: CVSS 7.2 (ALTO)
  - Afecta a tu servidor VPN perimetral
  - No requiere autenticación
  - Está en el CISA KEV (explotación activa confirmada)
  → Riesgo real en TU entorno: CRÍTICO

EPSS: probabilidad de explotación en los próximos 30 días#

EPSS (Exploit Prediction Scoring System) de FIRST.org es un modelo de machine learning que predice la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días, basándose en datos de explotación histórica, disponibilidad de exploits públicos, y características de la vulnerabilidad.

# Consultar EPSS via API de FIRST.org (gratuita, sin auth)
curl "https://api.first.org/data/v1/epss?cve=CVE-2024-12345"
# Respuesta: {"data":[{"cve":"CVE-2024-12345","epss":"0.94","percentile":"99.1"}]}
# EPSS 0.94 = 94% de probabilidad de explotación en 30 días → parchear hoy

La combinación CVSS + EPSS + CISA KEV da un sistema de priorización mucho más efectivo que CVSS solo.

CISA KEV: el listado más importante que debés tener abierto#

El CISA Known Exploited Vulnerabilities Catalog (cisa.gov/known-exploited-vulnerabilities-catalog) es el listado de vulnerabilidades que CISA ha confirmado que están siendo activamente explotadas por atacantes en el mundo real. A diferencia de CVSS (teórico) y EPSS (predictivo), el KEV es factual: estas vulnerabilidades ya están siendo usadas en ataques reales.

La regla es simple: si tenés una vulnerabilidad en el KEV en tu entorno, es emergencia. No importa el CVSS. No importa el EPSS. Está siendo atacada ahora.

Sistema de priorización propuesto:

P0 - EMERGENCIA (24hs): En CISA KEV + activo expuesto
P1 - CRÍTICO (72hs):    CVSS ≥9 + EPSS ≥0.5 + activo expuesto
P2 - ALTO (2 semanas):  CVSS ≥7 + EPSS ≥0.1 O en CISA KEV sin exposición directa  
P3 - MEDIO (30 días):   CVSS 4-6.9, sin exploit público conocido
P4 - BAJO (próximo ciclo): CVSS <4, activos internos sin acceso externo

Cómo Prevenirlo#

1. Inventariá todos los activos antes de escanear. Un escaner solo puede encontrar vulnerabilidades en activos que conoce. El primer paso es tener un inventario actualizado: servidores, workstations, dispositivos de red, servicios cloud, aplicaciones web. Shadow IT (sistemas instalados sin aprobación del área de IT) es frecuentemente el vector de compromiso porque nadie lo escaneó nunca.

2. Usá OpenVAS/Greenbone Community o Nessus Essentials para empezar — ambos son gratuitos. OpenVAS (ahora Greenbone Community Edition) es el escaner de vulnerabilidades open source más completo disponible. Nessus Essentials de Tenable es gratuito hasta 16 IPs. Para entornos pequeños, cualquiera de los dos da una vista completa del estado de vulnerabilidades en menos de una hora de escaneo. No es necesario comprar una solución enterprise para tener visibilidad básica.

3. Integrá CISA KEV en tu proceso de triaje — no es opcional. Suscribite al feed JSON del KEV (cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) y verificá cada nuevo hallazgo del escaneo contra él. Los scaners modernos ya muestran si un hallazgo está en el KEV — configurá una vista o filtro específico para esos casos y tratalos como emergencia independientemente del CVSS.

4. Establecé SLAs de remediación por severidad y medí el MTTR. Sin SLA, todo es urgente y nada se prioriza. Con SLA, el proceso tiene accountability: P0 en 24hs, P1 en 72hs, etc. El KPI principal es MTTR (Mean Time to Remediate) por severidad — cuánto tiempo pasa en promedio entre que se descubre una vulnerabilidad y se verifica el parche. Reducir el MTTR es el objetivo del programa de gestión de vulnerabilidades.

5. Automatizá el parcheo de workstations con WSUS/Intune (Windows) o Ansible/Puppet. El mayor volumen de vulnerabilidades en una organización típica son CVEs en el sistema operativo y software de usuario (navegadores, Office, Adobe) en workstations. Automatizar el parcheo de workstations reduce el trabajo manual del equipo de IT y garantiza que los parches se apliquen dentro del SLA sin depender de que alguien lo haga manualmente.

6. Documentá las excepciones con fecha de revisión. No todas las vulnerabilidades se pueden parchear de inmediato — algunas requieren ventanas de mantenimiento, testing previo, o tienen dependencias que bloquean el parche. Eso está bien, siempre que esté documentado: por qué no se parchea, qué mitigación compensatoria existe, y cuándo se va a revisar. Las "excepciones indefinidas" son riesgo aceptado sin documentación, que es diferente a riesgo aceptado conscientemente.

Herramientas Recomendadas#

OpenVAS / Greenbone Community Edition (greenbone.net): El escaner de vulnerabilidades open source más completo del mercado. Greenbone Community Edition incluye más de 90.000 tests de vulnerabilidades actualizados regularmente, una interfaz web completa para gestionar escaneos, políticas de escaneo configurables, y reporting. Corre en Docker o como appliance virtual. Para organizaciones sin presupuesto para herramientas comerciales, es el punto de partida natural para un programa de gestión de vulnerabilidades.

Nessus Essentials (tenable.com/products/nessus/nessus-essentials): La versión gratuita de Nessus de Tenable, limitada a 16 IPs. Para organizaciones pequeñas (hasta ~16 hosts críticos que escanear), es el escaner de vulnerabilidades comercial más fácil de usar y con la base de datos de plugins más actualizada. La interfaz es más pulida que OpenVAS, los reportes son más legibles para management, y la integración con el CISA KEV es nativa. Para entornos más grandes, Nessus Professional es la versión de pago.

CVSS Calculator (nvd.nist.gov/vuln-metrics/cvss/v3-calculator): La calculadora oficial del NIST para CVSS v3.1 y v4.0. Útil para entender el score de una CVE en el contexto de tu entorno específico: podés ajustar los vectores temporales (¿hay exploit disponible?) y de entorno (¿tenés mitigaciones compensatorias?) para obtener un score más preciso que el base score publicado. Herramienta de aprendizaje y calibración para equipos que están construyendo su proceso de priorización.

EPSS API de FIRST.org (first.org/epss): La API pública y gratuita del Exploit Prediction Scoring System. Sin autenticación, devuelve el score EPSS y el percentil para cualquier CVE. Se puede integrar fácilmente en scripts de automatización para enriquecer los reportes del escaner con datos de probabilidad de explotación. El dataset completo también está disponible para descarga, lo que permite integrarlo en pipelines de datos internos o en herramientas CSPM custom.

Checklist Final#

• Existe un inventario actualizado de todos los activos de IT de la organización (servidores, workstations, red, cloud)
• Se ejecuta un escaneo de vulnerabilidades al menos mensualmente (semanalmente para activos expuestos a internet)
• El proceso de priorización usa CVSS + EPSS + CISA KEV, no solo CVSS
• Existe un SLA de remediación documentado y conocido por el equipo (P0 24hs, P1 72hs, etc.)
• Se verifica el CISA KEV al menos semanalmente y se trata cualquier coincidencia como emergencia
• Los hallazgos tienen responsable asignado y fecha límite de remediación en el sistema de tickets
• El parcheo de workstations Windows está automatizado (WSUS, Intune, o equivalente)
• Existe un proceso de verificación post-parche con re-escaneo confirmatorio
• Las excepciones (vulnerabilidades no parcheadas con justificación) están documentadas con fecha de revisión
• Se mide y reporta el MTTR (Mean Time to Remediate) por severidad como KPI del programa
• El management recibe un reporte trimestral de postura de vulnerabilidades con tendencia en el tiempo
• Los activos cloud están incluidos en el scope del escaneo (no solo infraestructura on-premise)

CVE / Vulnerabilidades Relacionadas#

Este artículo describe el proceso de gestión de vulnerabilidades en lugar de ilustrar CVEs específicas, porque el proceso es agnóstico a la vulnerabilidad particular — aplica igual para una CVE en Windows Server que para una en Apache Tomcat o en el firmware de un switch. Sin embargo, hay tres fuentes de referencia que cualquier profesional de seguridad debe conocer y consultar regularmente:

CISA KEV (cisa.gov/known-exploited-vulnerabilities-catalog): El catálogo de vulnerabilidades con explotación confirmada activa. Actualizado múltiples veces por semana por CISA. Cualquier CVE listada aquí representa riesgo real e inmediato. El feed JSON es consumible automáticamente para integración con herramientas internas.

NVD — National Vulnerability Database (nvd.nist.gov): La base de datos oficial de CVEs del gobierno de EE.UU., mantenida por NIST. Contiene scores CVSS, descripciones técnicas, vectores de ataque, y referencias a parches. El punto de partida para investigar cualquier CVE.

EPSS (first.org/epss): El modelo de predicción de explotabilidad de FIRST. Complementa al NVD con contexto probabilístico de cuán probable es que una CVE se explote activamente — el dato que el NVD no da y que es fundamental para priorizar.

La combinación de estas tres fuentes — NVD para el qué, EPSS para el cuándo, y KEV para el ya está pasando — es el sistema de priorización más efectivo disponible gratuitamente para cualquier organización.

Conclusión y CTA#

La gestión de vulnerabilidades sin proceso es ruido. Miles de alertas generan parálisis, no seguridad. La diferencia entre un programa efectivo y uno decorativo es la priorización inteligente — no hacer más, sino hacer lo correcto en el orden correcto.

CVSS te dice qué tan grave es técnicamente. EPSS te dice qué probabilidad tiene de ser explotado. CISA KEV te dice qué ya está siendo atacado. Con esas tres fuentes y un proceso simple de asignación, seguimiento y verificación, podés reducir la superficie de ataque real de tu organización de forma sistemática y medible.

El primer paso: corré OpenVAS o Nessus Essentials contra tus activos más críticos esta semana, exportá los hallazgos, y verificá cuántos están en el CISA KEV. El número que encontrés va a definir la urgencia de formalizar el proceso.

¿Querés implementar un programa de gestión de vulnerabilidades en tu organización o revisar y mejorar el proceso existente? Hablá con nuestro equipo — o volvé al inicio del módulo avanzado: Análisis de malware para no expertos.