El problema del ruido en ciberseguridad: cuando todo es crítico, nada lo es
16.000 vulnerabilidades, 90% con CVSS alto, menos del 5% realmente explotadas. CVSS mide severidad técnica, no riesgo real. Es hora de priorizar con KEV, EPSS y contexto de negocio.
Miles de alertas críticas, equipos saturados
Durante años hemos priorizado vulnerabilidades usando solo CVSS.
¿El resultado?
- Miles de alertas “críticas”
- Equipos saturados
- Esfuerzo mal dirigido
- Amenazas reales pasando desapercibidas
Un entorno promedio puede tener más de 16.000 vulnerabilidades, y cerca del 90% con CVSS mayor o igual a 7.0.
Pero la realidad es incómoda: menos del 5% de esas vulnerabilidades se explotan realmente.
CVSS mide severidad técnica, no riesgo real
CVSS no considera:
| Factor ausente | Por qué importa |
|---|---|
| Explotación activa | ¿Alguien está usando este exploit ahora? |
| Disponibilidad de exploits | ¿Existe código de explotación público? |
| Exposición del activo | ¿Está expuesto a internet o aislado en red interna? |
| Impacto operacional | ¿Qué pasa si este activo cae? |
| Criticidad de negocio | ¿Es un servidor de desarrollo o el ERP de producción? |
El resultado es ruido. Y el ruido es enemigo de la resiliencia.
Cambiar la pregunta
La madurez comienza cuando cambiamos la pregunta:
No es “¿qué es crítico en teoría?”
Es “¿qué me pueden explotar ahora y qué impacto tiene en mi negocio?”
Priorización basada en riesgo real
Los equipos más avanzados ya están priorizando con:
KEV — Known Exploited Vulnerabilities (CISA)
El catálogo de CISA lista las vulnerabilidades que se están explotando activamente en el mundo real. Si una CVE está en el KEV, tiene prioridad absoluta.
EPSS — Exploit Prediction Scoring System
Predice la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días. Complementa al CVSS con un dato que realmente importa: ¿qué tan probable es que alguien use esto?
Contexto del activo
- Criticidad: ¿qué tan importante es este sistema para el negocio?
- Exposición: ¿está expuesto a internet, accesible desde la VPN, o aislado?
- Rol: ¿es un controlador SCADA o un equipo de testing?
Threat-Informed Defense (MITRE ATT&CK)
Mapear vulnerabilidades contra las técnicas que los adversarios realmente usan contra tu sector. No todas las CVEs son relevantes para tu threat model.
El resultado de priorizar bien
- Menos parches innecesarios: foco en lo que importa
- Mejor uso del tiempo: equipos trabajando en riesgos reales
- Reducción real del riesgo: no del número de CVEs parcheadas
- Decisiones defensivas alineadas al negocio: lenguaje que el directorio entiende
Ejemplo práctico
| CVE | CVSS | EPSS | KEV | Activo | Decisión |
|---|---|---|---|---|---|
| CVE-2024-XXXX | 9.8 | 0.02% | No | Servidor dev interno | Parchear en ciclo normal |
| CVE-2024-YYYY | 7.5 | 89% | Sí | ERP producción expuesto | Parche inmediato |
| CVE-2024-ZZZZ | 8.1 | 0.5% | No | PLC aislado en red OT | Control compensatorio |
Con CVSS solo, los tres serían “críticos”. Con contexto, la prioridad es obvia.
Conclusión
Mitigar vulnerabilidades no es lo mismo que reducir riesgo.
Reducir riesgo exige contexto, inteligencia y priorización basada en amenazas reales.
El equipo que parchea 5.000 CVEs al año puede tener peor postura de seguridad que el que parchea 200 — si esas 200 son las correctas.