CVSS, EPSS y KEV:
priorizar parches sin volverse loco
Gobernanza y cumplimiento | unfantasmaenelsistema.com
Un escáner de vulnerabilidades decente sobre una red mediana devuelve miles de hallazgos. Cientos marcados como «críticos». Ningún equipo de sistemas puede parchear todo eso a la vez, así que la pregunta no es «¿tengo vulnerabilidades?» —claro que sí— sino «¿cuáles arreglo esta semana y cuáles pueden esperar?». Responderla bien es la diferencia entre un programa de gestión de vulnerabilidades y una lista de deseos.
Este artículo explica las tres piezas que hoy se combinan para priorizar —CVSS, EPSS y el catálogo KEV de CISA—, qué mide cada una y por qué ninguna sirve sola, y cómo montar con ellas un ciclo con ventanas de parcheo, excepciones y métricas que aguante una auditoría.
Qué aprenderás en este artículo
Las cinco fases del ciclo de gestión de vulnerabilidades · Qué mide CVSS v4, qué significan base, threat y environmental, y por qué la nota base no basta · Qué es EPSS y cómo leer una probabilidad de explotación · Qué es el catálogo KEV de CISA y por qué manda sobre todo lo demás · Cómo definir ventanas de parcheo (SLA), gestionar excepciones y medir el programa
1. El ciclo, en cinco fases
La gestión de vulnerabilidades es un proceso continuo, no un proyecto. Sus fases:
| Fase | Qué se hace | Dónde suele fallar |
|---|---|---|
| 1. Inventario | Saber qué activos, servicios, versiones y dependencias tienes; sin inventario no hay cobertura | Activos fuera del alcance del escáner, shadow IT, cloud efímero |
| 2. Escaneo / descubrimiento | Escáner autenticado, agentes, SCA de dependencias, feeds de los fabricantes | Escaneo sin credenciales (ve la mitad), frecuencia baja |
| 3. Priorización | Combinar gravedad, explotabilidad real y exposición del activo | Ordenar solo por CVSS base y ahogarse en «críticas» |
| 4. Remediación | Parchear, mitigar, aislar o aceptar; con un responsable y una fecha | Sin dueño claro, sin ventana de mantenimiento acordada |
| 5. Verificación y métrica | Re-escanear para confirmar el cierre; seguir indicadores y tendencia | Cerrar tickets sin re-escaneo; no medir el tiempo de remediación |
2. CVSS: gravedad, no urgencia
El Common Vulnerability Scoring System es un estándar del FIRST para puntuar la gravedad técnica de una vulnerabilidad de 0 a 10. La versión actual es CVSS v4.0 (2023), aunque todavía convive con v3.1 en muchos feeds. Tiene tres grupos de métricas:
- Base: características intrínsecas y estables de la vulnerabilidad — vector de ataque (red/adyacente/local/físico), complejidad, privilegios necesarios, interacción del usuario, y el impacto en confidencialidad, integridad y disponibilidad del sistema vulnerable y de los sistemas posteriores. Es la nota que publica el NVD y la que casi todo el mundo usa… y casi nadie completa
- Threat (en v3.1 se llamaba Temporal): madurez del código de explotación (¿hay PoC?, ¿hay exploit funcional?, ¿se explota de forma masiva?). Cambia con el tiempo y baja la nota si todavía no hay exploit
- Environmental: tu contexto — cuánto vale ese activo para ti, qué controles compensatorios tienes, si el servicio está expuesto a Internet o segmentado. Ajusta la nota a tu realidad
CVSS v4 añade además métricas suplementarias (automatizable, recuperación, densidad de valor, urgencia de respuesta del proveedor, seguridad física) que no cambian la nota pero dan contexto, y separa el impacto en el sistema vulnerable del impacto en sistemas posteriores.
Por qué ordenar solo por CVSS base es un error
La nota base no sabe si el activo está expuesto a Internet o enterrado en una VLAN aislada · No sabe si existe un exploit público ni si se está usando ahora mismo · En la práctica, un porcentaje enorme de los CVE nunca se explota; CVSS base los trata a casi todos como urgentes · Resultado típico: cientos de «críticas 9.8» y ninguna forma de saber por dónde empezar
CVSS responde a «si esto se explota, ¿cómo de malo es?». No responde a «¿va a explotarse?» ni a «¿me afecta a mí?». Para eso están las otras dos piezas.
3. EPSS: probabilidad de que se explote
El Exploit Prediction Scoring System, también del FIRST, es un modelo de datos que estima la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días. Devuelve dos números por CVE:
- Score (0 a 1): la probabilidad estimada. Un EPSS de 0,90 significa «~90% de probabilidad de actividad de explotación en 30 días»; uno de 0,002, prácticamente ninguna
- Percentil (0 a 100): dónde queda ese CVE respecto a todos los demás. Percentil 97 = está entre el 3% más probable de ser explotado
El modelo se reentrena a diario con señales reales: menciones en repositorios de exploits, tráfico de escaneo observado por honeypots y sensores, publicaciones, características del propio CVE. Los datos son públicos y gratuitos vía API.
La forma habitual de usarlo es como filtro sobre las críticas por CVSS: de todas las vulnerabilidades con CVSS alto, sube al principio de la cola las que además tienen EPSS alto. Un umbral que se cita a menudo es EPSS ≥ 0,10 (o percentil ≥ 88), pero cada organización debe calibrarlo según su capacidad de parcheo.
EPSS tampoco es suficiente solo
Es una predicción probabilística: acierta en el agregado, no garantiza nada sobre un CVE concreto · Un EPSS bajo hoy puede dispararse mañana si aparece un exploit; hay que releer el valor, no fijarlo · No tiene en cuenta tu exposición ni el valor del activo: eso lo pones tú
4. KEV: lo que ya se está explotando
El Known Exploited Vulnerabilities Catalog de CISA (la agencia de ciberseguridad de EE. UU.) es una lista de vulnerabilidades con evidencia confirmada de explotación activa en el mundo real. No es una predicción como EPSS: es un hecho observado. Para entrar en KEV, un CVE debe tener identificador asignado, prueba de explotación activa y una remediación clara disponible.
Para las agencias federales de EE. UU. el KEV es de obligado cumplimiento con plazos concretos. Para el resto del mundo su valor es distinto pero igual de útil: si un CVE está en KEV, sáltate el debate de priorización y trátalo como urgente, tengas la exposición que tengas, porque hay adversarios usándolo ahora.
| Señal | Qué te dice | Fuente | Coste |
|---|---|---|---|
| CVSS base | Gravedad técnica si se explota | NVD / fabricante | Gratis |
| CVSS threat + environmental | Gravedad ajustada a exploit real y a tu entorno | La calculas tú | Trabajo |
| EPSS | Probabilidad de explotación a 30 días | FIRST (API) | Gratis |
| KEV | Explotación activa confirmada hoy | CISA (feed JSON/CSV) | Gratis |
| Exposición del activo | ¿Internet, DMZ, interno, aislado? | Tu inventario y tu red | Trabajo |
5. Una regla de priorización que funciona
Combinando las señales, un árbol de decisión sencillo y defendible:
- ¿Está en KEV? → Urgente. Ventana de emergencia, sin más análisis
- ¿CVSS alto (≥ 7) y EPSS alto (p. ej. ≥ 0,10) y activo expuesto? → Alta prioridad. Ventana corta
- ¿CVSS alto pero EPSS bajo, o activo no expuesto? → Prioridad media. Ventana normal del ciclo mensual
- ¿CVSS medio/bajo y EPSS bajo? → Prioridad baja. Parcheo por lotes en mantenimiento rutinario
- ¿No hay parche? → Mitigación compensatoria (regla de firewall, WAF, deshabilitar función, aislar) y excepción documentada con fecha de revisión
Este enfoque es el mismo que propone la guía SSVC (Stakeholder-Specific Vulnerability Categorization) de CISA y el CERT/CC: en lugar de una nota, un árbol con decisiones (explotación, exposición, impacto en la misión) que termina en una acción — actuar ya, actuar pronto, actuar en el ciclo, o seguir vigilando.
5.1 Ventanas de parcheo (SLA)
| Prioridad | Activo expuesto a Internet | Activo interno |
|---|---|---|
| Urgente (KEV / explotación activa) | 24-72 horas | 7 días |
| Alta | 7 días | 15 días |
| Media | 30 días | 30-60 días |
| Baja | 90 días o ciclo trimestral | Ciclo trimestral |
Los números concretos los fija cada organización según su sector, su tolerancia al riesgo y su capacidad real. Lo importante es que estén escritos, aprobados y se midan.
5.2 Excepciones
Cuando un parche no se puede aplicar en plazo (rompe una aplicación, no hay ventana, el fabricante no lo ha publicado), se abre una excepción formal: qué vulnerabilidad, en qué activos, por qué no se parchea, qué mitigación compensatoria se aplica mientras tanto, quién lo aprueba y cuándo se revisa. Una excepción sin fecha de caducidad es deuda de seguridad que nadie volverá a mirar.
6. Métricas del programa
- Tiempo medio de remediación (MTTR) por nivel de prioridad: la métrica reina. Tendencia mensual, no valor puntual
- Cumplimiento de SLA: porcentaje de vulnerabilidades cerradas dentro de su ventana
- Cobertura de escaneo: porcentaje del inventario escaneado de forma autenticada en el último ciclo
- Antigüedad de la deuda: cuántas vulnerabilidades abiertas superan los 30 / 90 / 180 días, y de qué prioridad
- Vulnerabilidades KEV abiertas: idealmente cero; si no, con plan y fecha
- Tasa de reapertura: hallazgos que vuelven tras darse por cerrados (indica parcheo incompleto o re-despliegue de imágenes viejas)
Errores comunes al montar el programa
Perseguir el 0 absoluto de vulnerabilidades en vez de gestionar el riesgo: es inalcanzable y quema al equipo · Escanear sin credenciales: la visibilidad cae a la mitad y las notas son poco fiables · No cerrar el bucle con un re-escaneo: el ticket dice «resuelto», la máquina dice otra cosa · Tratar las imágenes base y las dependencias como algo aparte: la cadena de suministro también entra aquí
Conclusión
CVSS te dice cómo de grave sería, EPSS cómo de probable es, y KEV si ya está pasando. Ninguna de las tres, por separado, sirve para priorizar: juntas, y cruzadas con la exposición y el valor de tus activos, convierten un listado inmanejable en una cola de trabajo con criterio.
El objetivo no es parchearlo todo, es reducir de forma medible el riesgo real: cerrar rápido lo que se explota, a tiempo lo que probablemente se explotará, y por lotes lo demás — con las excepciones escritas y con fecha. Un programa así se sostiene ante una auditoría de NIS2, del ENS o de ISO 27001 sin sudar.
Referencias
FIRST — especificación de CVSS v4.0 y calculadora oficial · FIRST — EPSS: modelo, datos y API (first.org/epss) · CISA — Known Exploited Vulnerabilities Catalog (feed JSON/CSV) · CISA / CERT-CC — SSVC: Stakeholder-Specific Vulnerability Categorization · NIST NVD — base de datos de vulnerabilidades y notas CVSS · Nuestros artículos sobre seguridad de la cadena de suministro, endurecer Linux con CIS y NIS2
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)