Si trabajas en ciberseguridad, tu día a día probablemente se resume en una palabra: ruido. Ese ruido ensordecedor que genera tu escáner de vulnerabilidades (vulnerability scanner) cuando termina de analizar tu red y te lanza un PDF de 400 páginas con miles de «Critical» y «High».
El problema es que, durante años, hemos tratado el CVSS (Common Vulnerability Scoring System) como si fuera la palabra de Dios. Si tiene un 9.8, paramos las rotativas; si tiene un 4.0, lo ignoramos como si fuera un correo de «trabaja desde casa y gana millones».
Priorizar solo por el numerito del CVSS es como decidir si una enfermedad es peligrosa solo por la fiebre que da. Sí, tener 40 grados es grave, pero no es lo mismo si los tienes porque estás en el desierto o porque tienes una infección bacteriana que te está devorando por dentro. En este artículo vamos a aprender a separar el grano de la paja y a gestionar los riesgos (risk management) con cabeza, no solo con hojas de cálculo.
Índice de contenidos
El mito del 10.0: El CVSS no basta para priorización de vulnerabilidades
El CVSS es un sistema de puntuación de vulnerabilidades común (Common Vulnerability Scoring System) que nos dice qué tan mala es una vulnerabilidad en teoría. Es un estándar fantástico, pero tiene un pecado original: es estático y puramente técnico.
El termómetro que no distingue entre fiebre y quemaduras
Imagina que descubres una vulnerabilidad con un score de 9.8 en una librería de procesamiento de imágenes. Técnicamente, es el apocalipsis: ejecución remota de código (Remote Code Execution – RCE), sin autenticación, complejidad baja. ¡Pánico! Pero resulta que esa librería solo se usa en un servidor interno que no tiene acceso a internet y que solo usa un becario una vez al mes para hacer memes.
Por otro lado, tienes una vulnerabilidad de 6.5 (Media) en tu servidor perimetral que permite saltarse la autenticación (Authentication Bypass) en ciertas condiciones. El CVSS te diría que parches primero la de 9.8. La realidad es que un atacante ya está golpeando tu puerta en la de 6.5 mientras la de 9.8 está cogiendo polvo en el sótano.
La trampa de la severidad teórica vs. el riesgo real
El CVSS mide la severidad (severity), no el riesgo (risk).
- Severidad: ¿Cuánto daño puede hacer si se explota?
- Riesgo: ¿Qué probabilidad hay de que se explote y qué impacto tendrá en mi negocio?
EPSS: Prediciendo el futuro (sin bolas de cristal)
Para solucionar el «ruido» del CVSS, nació el Sistema de Puntuación de Predicción de Explotación (Exploit Prediction Scoring System – EPSS). Si el CVSS es el termómetro, el EPSS es el hombre del tiempo.
Probabilidad frente a severidad
El EPSS no te dice qué tan malo es el agujero, sino qué probabilidad hay de que alguien lo use para entrar en los próximos 30 días. Utiliza modelos de aprendizaje automático (Machine Learning) que analizan datos de ataques reales, menciones en redes sociales, exploits disponibles en GitHub y foros de la Dark Web.
| Métrica | ¿Qué mide? | Ejemplo cotidiano |
| CVSS | Impacto potencial | Un tanque pesado (hace mucho daño). |
| EPSS | Probabilidad de uso | Una navaja suiza (todo el mundo tiene una y sabe usarla). |
Un CVSS de 9.8 con un EPSS del 0.01% es una «bomba teórica». Un CVSS de 7.5 con un EPSS del 90% es un incendio activo. Priorizar por EPSS te permite reducir drásticamente el volumen de parches sin aumentar tu exposición real.
El catálogo KEV de CISA: Si está ahí, corre
Si el EPSS es una predicción, el Catálogo de Vulnerabilidades Explotadas Conocidas (Known Exploited Vulnerabilities – KEV) de la CISA es la lista de los más buscados del FBI. No es una suposición; es una lista de vulnerabilidades que se están explotando activamente en el mundo real.
Vulnerabilidades explotadas activamente
Cuando una vulnerabilidad entra en el KEV, el debate se termina. No importa si el CVSS es un 5.0 o un 10.0. Si los malos ya la están usando para cifrar servidores o robar datos, tu prioridad debería ser máxima.
Ignorar una vulnerabilidad del KEV es como ver a un ladrón entrando por la ventana de tu casa y pensar que quiere darte un abrazo (no se en vuestro barrio pero en el mío estas cosas pueden pasar, por eso vivo en un séptimo).
Puedes consultar el catálogo oficial aquí: CISA KEV Catalog. (Este es el recurso profesional que todo analista debería tener en marcadores).
Contexto del activo: No es lo mismo un servidor web que la cafetera
Aquí es donde entra tu conocimiento de la casa. El contexto del activo (Asset Context) es el ingrediente secreto que ningún escáner externo puede darte con total precisión. Es fundamental integrar esto en tu estrategia de gestión de vulnerabilidades.
Exposición real vs. teórica
Para priorizar, debes hacerte tres preguntas:
- Exposición (Exposure): ¿El activo es accesible desde internet? Si la respuesta es no, el riesgo cae en picado (a menos que el atacante ya esté dentro, pero esa es otra historia).
- Valor del activo (Asset Value): ¿Contiene datos de clientes, secretos industriales o procesa pagos? Una vulnerabilidad en el servidor de producción es una crisis; en el servidor de pruebas de la red de invitados… no.
- Controles de compensación (Compensating Controls): ¿Tengo un cortafuegos (firewall) o un WAF que bloquea específicamente ese tipo de ataque? Si es así, tengo tiempo para respirar.
Un analista inteligente sabe que un análisis de vulnerabilidades es solo el principio; la diferencia con un pentesting profesional es que el segundo te dirá si realmente se puede profundizar y hacer daño.
Ejemplo práctico: El duelo de las vulnerabilidades
Supongamos que tienes recursos para parchear solo una vulnerabilidad hoy. Tienes estas dos sobre la mesa:
- CVE-A: CVSS 9.8. Vulnerabilidad en un software de backup interno. No hay exploit público. EPSS: 0.05%.
- CVE-B: CVSS 7.2. Vulnerabilidad en tu VPN corporativa. Hay código de explotación (exploit code) circulando en Twitter y está en el KEV de CISA. EPSS: 85%.
¿Cuál eliges?
Si eliges la A, has caído en la esclavitud de las métricas irrelevantes. Si eliges la B, has entendido de qué va este juego. Se nos puede pasar (me ha pasado, más de una vez), pero intentemos que no.
Fragmento de código: Priorizando con Python y la API de EPSS
Si quieres automatizar esto (y deberías, a menos que te guste el masoquismo del Excel), puedes usar un pequeño script para obtener el EPSS de tus CVEs:
import requests
def get_epss_score(cve_id):
url = f"https://api.first.org/data/v1/epss?cve={cve_id}"
try:
response = requests.get(url, timeout=10)
response.raise_for_status()
data = response.json()
results = data.get("data", [])
if results:
return float(results[0]["epss"])
return 0.0
except requests.RequestException as e:
print(f"Error consultando EPSS: {e}")
return None
except (KeyError, ValueError, IndexError) as e:
print(f"Respuesta inesperada de la API: {e}")
return None
# Ejemplo de uso
cve = "CVE-2023-23397"
score = get_epss_score(cve)
if score is not None:
print(f"Probabilidad EPSS para {cve}: {score*100:.2f}%")
else:
print(f"No se pudo obtener el EPSS para {cve}")Nota: Este código es MUY mejorable. Es un ejemplo, no me pongáis la cruz (al menos por esto).
Checklist: Cómo priorizar como un profesional
Para que no te pierdas en el mar de alertas, sigue este orden de prioridades (de mayor a menor urgencia):
- Paso 1: ¿Está en el catálogo KEV de CISA? -> Parchea YA.
- Paso 2: ¿Tiene un EPSS > 10% (o tu umbral definido) y es accesible desde internet? -> Parchea esta semana.
- Paso 3: ¿Tiene un CVSS Crítico pero es un activo interno sin datos sensibles y su indisponibilidad no es un problema? -> Ponlo en la cola normal.
- Paso 4: ¿Existen controles de seguridad CIS que mitiguen el riesgo sin necesidad de parchear inmediatamente? -> Documenta y planifica.
- Paso 5: ¿Es una vulnerabilidad en un software que ni siquiera usamos pero que sigue instalado? -> Desinstala y elimina el riesgo de raíz. Reduce superficie, te sentirás bien.
Conclusión: De apagar fuegos y cumplir KPIs a gestionar riesgos
Gestionar vulnerabilidades basándose solo en el CVSS no es una buena práctica. El objetivo no es tener «cero vulnerabilidades» para cumplir con esos KPIs tan bonitos, sino asegurarte de que los agujeros que dejas abiertos sean los que menos probabilidad tienen de ser usados.
Al combinar el CVSS (severidad técnica), el EPSS (probabilidad), el KEV (realidad del ataque) y el contexto de tu empresa, dejas de ser un «parcheador compulsivo» para convertirte en un gestor de riesgos estratégico. Recuerda: en ciberseguridad, no sobrevive el que más parches pone, sino el que pone los parches donde realmente importa.
