Priorizar por explotabilidad real: CVSS, EPSS y contexto de negocio

Cualquier organización con un escáner en marcha acumula más hallazgos de los que puede corregir. La respuesta habitual —«arreglamos primero los críticos»— parece razonable y produce dos efectos perversos: se dedica esfuerzo a vulnerabilidades que nadie va a explotar nunca, y se dejan abiertas otras de gravedad media que están siendo explotadas esta semana.

El problema no es la falta de datos. Es que se usa una sola métrica para responder a una pregunta que tiene tres dimensiones distintas.

Qué mide CVSS y qué no

CVSS describe las características intrínsecas de una vulnerabilidad: cómo de accesible es el vector, qué privilegios exige, si necesita interacción del usuario y qué impacto tiene sobre confidencialidad, integridad y disponibilidad. Es una descripción estructurada y comparable, y como tal es útil.

Lo que casi nadie usa es el resto del estándar. La puntuación base, la que viene en el CVE y la que aparece en el 95 % de los informes, está pensada para ser modulada por los grupos de métricas ambientales y de amenaza —en CVSS v4.0, publicado por FIRST en noviembre de 2023, se llaman así; en v3.1 eran temporal y environmental—. Esos grupos existen precisamente para recoger si hay código de explotación disponible y qué valor tiene el activo afectado en tu entorno.

Cuando una organización dice «priorizamos por CVSS» casi siempre quiere decir «priorizamos por la puntuación base de otro». Es decir, por una métrica deliberadamente descontextualizada.

Qué añade EPSS

EPSS, mantenido también por FIRST, responde a otra pregunta: la probabilidad de que una vulnerabilidad concreta sea explotada en la práctica durante los próximos 30 días. Es un modelo estadístico entrenado sobre señales observadas —actividad de explotación reportada, características del CVE, presencia de exploits públicos— y se recalcula a diario.

Devuelve dos números que conviene no confundir. La probabilidad es un valor entre 0 y 1: un 0,08 significa que el modelo estima un 8 % de posibilidades de explotación observada en el periodo. El percentil dice cuántas vulnerabilidades tienen una probabilidad menor que esta. Un percentil 0,95 no significa 95 % de probabilidad: significa que está entre el 5 % más probable del catálogo, lo que puede seguir siendo una probabilidad absoluta modesta.

La utilidad práctica de EPSS es que invierte el sesgo. La gran mayoría de los CVE publicados nunca llegan a explotarse de forma observable, y EPSS es bastante bueno separando ese ruido. Como criterio de descarte es más eficiente que CVSS; como criterio de urgencia, sólo funciona combinado.

Los dos juntos: cuatro cuadrantes, no una fórmula

La tentación es construir una fórmula que multiplique CVSS por EPSS y ordenar por el resultado. No lo hagas: pierdes la información de qué dimensión disparó la prioridad y ya no puedes explicar la decisión.

Es más útil pensar en cuatro cuadrantes:

Gravedad alta y probabilidad alta. Cola corta, acción inmediata. Aquí es donde debería vivir tu proceso de emergencia.
Gravedad alta y probabilidad baja. El caso que más discusión genera. Entra en el ciclo normal de parcheo, no en el de emergencia, salvo que el activo sea crítico y esté expuesto.
Gravedad baja y probabilidad alta. El cuadrante que la priorización por CVSS ignora sistemáticamente y por el que entran bastantes incidentes reales. Merece vigilancia activa aunque la puntuación base sea un 5,3.
Gravedad baja y probabilidad baja. Cola larga. Se resuelve por mantenimiento programado, no por tickets individuales.

Y hay una lista que gana a ambas métricas: el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA. Si un CVE está ahí, se ha observado explotación real. En ese caso no hace falta estimar probabilidad: ya ocurrió.

La tercera dimensión, que ninguna de las dos incluye

CVSS y EPSS describen la vulnerabilidad. Ninguno sabe nada de tu sistema. Y la pregunta que importa no es «cómo de grave es este CVE», sino «qué pasa si alguien lo explota aquí».

Cuatro factores de contexto cambian la prioridad más que cualquier ajuste de métrica:

Exposición. ¿El activo está publicado en internet o vive en un segmento interno con acceso restringido? La diferencia entre ambos casos suele valer más que dos puntos de CVSS.
Compensaciones reales. ¿Hay un WAF con regla específica desplegada, una segmentación que impide alcanzar el puerto, autenticación previa obligatoria? Una compensación verificada rebaja la urgencia; una compensación asumida no.
Valor del dato o de la función. Un desbordamiento de memoria en un equipo de laboratorio y el mismo desbordamiento en el sistema que soporta una función esencial declarada bajo DORA no son el mismo hallazgo.
Coste y riesgo de la corrección. Un parche que exige ventana de indisponibilidad en un sistema de tiempo real compite con otras prioridades. Esto no rebaja el riesgo, pero sí determina qué camino se toma.

Un esquema que funciona sin convertirse en burocracia

Un procedimiento sencillo, defendible ante un auditor y que no exige un modelo propio:

Descarta con EPSS. Todo lo que esté por debajo de un umbral de probabilidad bajo y no figure en KEV pasa al ciclo de mantenimiento.
Escala por exposición. De lo que queda, separa lo accesible desde internet de lo que no.
Ordena por impacto de negocio. Usa la criticidad ya declarada del activo —si has hecho la categorización del ENS o el inventario de funciones de DORA, ya la tienes hecha, no la inventes otra vez.
Fija plazos por cuadrante, no por hallazgo. «Crítico expuesto: 7 días. Crítico interno: 30. Resto: ciclo mensual.» Un plazo por cuadrante se puede medir; un plazo negociado hallazgo a hallazgo, no.
Registra la decisión, sobre todo cuando rebajas. La excepción es la parte auditable del proceso: qué hallazgo, qué compensación se invocó, quién la aceptó, hasta cuándo.

Lo que suele revisar un auditor

No suele discutir tu fórmula. Comprueba tres cosas: que el criterio esté escrito y sea anterior a las decisiones, que los plazos declarados se cumplan en la práctica —tomando una muestra— y que las excepciones tengan nombre, fecha y caducidad.

Un programa que corrige el 70 % de lo crítico en plazo y documenta por qué el 30 % restante sigue abierto aguanta una revisión sin problemas. Uno que declara el 100 % y no puede mostrar la traza, no.

El coste real de todo esto no está en decidir, está en mantener la decisión enlazada al hallazgo cuando el escáner vuelve a encontrarlo tres semanas después con otro identificador. Resolver esa continuidad —que la excepción, la compensación y el plazo viajen con el hallazgo entre campañas— es el trabajo que en Violet Security automatizamos, porque a mano se pierde siempre.