CVE y CVSS: cómo priorizar las vulnerabilidades

Cada semana aparecen cientos de vulnerabilidades nuevas. Ningún equipo, ni siquiera uno grande, puede parchearlas todas a la vez. La pregunta útil no es "¿cuántas tenemos?", sino "¿cuáles nos pueden hacer daño de verdad y cuáles hay que arreglar primero?". Para contestarla hay que entender cuatro siglas.

CVE: el nombre de la vulnerabilidad

Un CVE (Common Vulnerabilities and Exposures) es un identificador único con el formato CVE-AAAA-NNNN. Solo sirve para nombrar el fallo y que todo el mundo hable de lo mismo. No dice lo grave que es. La base de datos pública de referencia es la NVD, del instituto estadounidense NIST, y en España el INCIBE-CERT publica avisos de seguridad en castellano.

CVSS: la gravedad técnica

CVSS (Common Vulnerability Scoring System) es una puntuación de 0 a 10 que mide la gravedad técnica de un fallo en abstracto. Los rangos habituales son:

• 0,1 – 3,9: baja
• 4,0 – 6,9: media
• 7,0 – 8,9: alta
• 9,0 – 10,0: crítica

Es una buena primera pista, pero tiene un límite importante: mide el fallo "en el vacío", no en tu empresa.

EPSS y KEV: la probabilidad real

• EPSS (Exploit Prediction Scoring System) estima la probabilidad de que una vulnerabilidad vaya a ser explotada en los próximos días. Una puntuación CVSS alta con EPSS bajo es menos urgente que una media con EPSS alto.
• KEV es el catálogo de la agencia estadounidense CISA con las vulnerabilidades que ya se están explotando activamente. Si una vulnerabilidad de tu inventario aparece ahí, deja de ser teoría.

El error más común: parchear solo por CVSS

Ordenar el trabajo únicamente por la puntuación CVSS lleva a perder tiempo en fallos críticos de sistemas aislados mientras se deja sin tocar uno "medio" en un servidor expuesto a Internet que ya se está explotando. Para priorizar bien hay que añadir contexto:

1. ¿Se está explotando ya? (KEV, avisos de fabricantes y CERT)
2. ¿Está expuesto? ¿Es accesible desde Internet o solo desde la red interna?
3. ¿Qué importancia tiene el activo? No es lo mismo un servidor de pruebas que el que guarda datos de clientes.
4. ¿Hay controles que lo mitigan? Segmentación de red, un cortafuegos de aplicaciones, autenticación fuerte.

Un orden de trabajo razonable

1. Explotadas activamente y expuestas a Internet: lo primero, en cuestión de días.
2. Críticas o altas en sistemas expuestos.
3. Críticas o altas en sistemas internos importantes.
4. El resto, dentro del ciclo normal de mantenimiento.

Los plazos concretos dependen de tu organización y de tus obligaciones; lo importante es que existan, que estén escritos y que se cumplan.

Cuando no hay parche

A veces el fabricante aún no ha publicado la corrección, o no puedes aplicarla sin parar un servicio crítico. En ese caso se mitiga: desactivar la función afectada, restringir el acceso, aislar el sistema o añadir una regla de filtrado. Y se documenta como excepción, con fecha de revisión.

El proceso completo

1. Inventario de lo que tienes (no se puede parchear lo que no se conoce, ver superficie de ataque y shadow IT).
2. Escaneo periódico de vulnerabilidades.
3. Priorización con contexto.
4. Corrección o mitigación.
5. Verificación de que el fallo ya no está.
6. Registro de excepciones y revisión.

Un pentest es un buen complemento: comprueba cuáles de esas vulnerabilidades se pueden encadenar y cuánto daño harían realmente.

Dónde encaja ZyroShield

La plataforma ofensiva de ZyroShield, SPYDER, incluye un escáner de vulnerabilidades que relaciona lo que encuentra con los CVE y se alimenta de inteligencia de amenazas. Lo explicamos en nuestra página de ciberseguridad. Si quieres revisar la situación de tu empresa, escríbenos.