Del CVSS a la RBVM: cómo priorizar correctamente las vulnerabilidades

Cuando te encuentras por primera vez con el Sistema común de puntuación de vulnerabilidades (CVSS, por sus siglas en inglés), es fácil pensar que es la herramienta perfecta para clasificar y priorizar las vulnerabilidades. Una puntuación más alta debe significar una vulnerabilidad más crítica, ¿verdad? En realidad, ese enfoque no funciona del todo bien. Cada año, vemos un número creciente de vulnerabilidades con puntuaciones altas en el CVSS. Los equipos de seguridad simplemente no pueden parchearlas todas a tiempo, pero la gran mayoría de estos defectos nunca llegan a explotarse en ataques reales. Mientras tanto, los atacantes aprovechan constantemente vulnerabilidades menos llamativas con puntuaciones más bajas. También hay otras trampas ocultas, que van desde problemas puramente técnicos, como puntuaciones conflictivas en el CVSS, hasta cuestiones conceptuales, como la falta de contexto empresarial.

Estas no son necesariamente deficiencias del propio CVSS. En cambio, esto pone de manifiesto la necesidad de usar la herramienta correctamente, como parte de un proceso de gestión de vulnerabilidades más sofisticado y completo.

Discrepancias en el CVSS

¿Alguna vez has notado cómo la misma vulnerabilidad puede tener diferentes puntuaciones de severidad según la fuente disponible? ¿Una puntuación del investigador de ciberseguridad que la encontró, otra del proveedor del software vulnerable y otra más de una base de datos nacional de vulnerabilidades? No siempre se trata de un simple error. A veces, diferentes expertos pueden discrepar sobre el contexto de explotación. Es posible que tengan diferentes ideas sobre los privilegios con los que se ejecuta una aplicación vulnerable o sobre si está conectada a Internet. Por ejemplo, un proveedor podría basar su evaluación en sus mejores prácticas recomendadas, mientras que un investigador de seguridad podría considerar cómo se configuran habitualmente las aplicaciones en las organizaciones del mundo real. Un investigador podría calificar la complejidad del exploit como alta, mientras que otro la consideraría baja. Esto no es algo poco común. Un estudio de 2023 realizado por Vulncheck concluyó que el 20 % de las vulnerabilidades en la Base de datos nacional de vulnerabilidades (NVD, por sus siglas en inglés) tenían dos puntuaciones CVSS3 provenientes de diferentes fuentes, y el 56 % de esas puntuaciones emparejadas estaban en conflicto entre sí.

Errores comunes al usar el CVSS

Durante más de una década, FIRST ha defendido la aplicación metodológicamente correcta del CVSS. Sin embargo, las organizaciones que utilizan las puntuaciones del CVSS en sus procesos de gestión de vulnerabilidades continúan cometiendo errores típicos:

1. Usar la puntuación base del CVSS como indicador principal de riesgo. El CVSS mide la severidad de una vulnerabilidad, no cuándo se explotará ni el posible impacto de su explotación en la organización atacada. A veces, una vulnerabilidad crítica es inofensiva dentro del entorno específico de una empresa porque reside en sistemas insignificantes y aislados. Por el contrario, un ataque de ransomware a gran escala podría comenzar con una vulnerabilidad de fuga de información aparentemente inocua con una puntuación de 6 en el CVSS.
2. Utilizar la puntuación base del CVSS sin los ajustes de amenaza/temporal y ambiental. La disponibilidad de parches, exploits públicos y medidas compensatorias influye considerablemente en la forma y en la urgencia con que debe abordarse una vulnerabilidad.
3. Centrarse solo en las vulnerabilidades por encima de una puntuación determinada. Este enfoque a veces es exigido por el gobierno o los reguladores del sector (“remediar vulnerabilidades con una puntuación del CVSS superior a 8 en un mes”). Como resultado, los equipos de ciberseguridad se enfrentan a una carga de trabajo en continuo crecimiento que, en realidad, no hace que su infraestructura sea más segura. El número de vulnerabilidades con puntuaciones altas en el CVSS identificadas anualmente ha aumentado rápidamente durante los últimos 10 años.
4. Emplear el CVSS para evaluar la probabilidad de explotación. Estas métricas están poco correlacionadas: solo el 17 % de las vulnerabilidades críticas se aprovechan en ataques.
5. Utilizar solo la puntuación del CVSS. La cadena de vectores estandarizada se introdujo en el CVSS para que los defensores pudieran comprender los detalles de una vulnerabilidad y calcular de forma independiente su importancia dentro de su propia organización. CVSS 4.0 se revisó específicamente para facilitar la consideración del contexto empresarial mediante métricas adicionales. Cualquier esfuerzo de gestión de vulnerabilidades basado únicamente en una calificación numérica será en gran medida ineficaz.
6. Ignorar fuentes de información adicionales. Basarse en una única base de datos de vulnerabilidades y analizar solo el CVSS no es suficiente. La ausencia de datos sobre parches, pruebas de concepto funcionales y casos de explotación del mundo real dificulta la decisión de cómo abordar las vulnerabilidades.

Lo que el CVSS no te dice sobre una vulnerabilidad

El CVSS es el estándar del sector para describir la gravedad de una vulnerabilidad, las condiciones en las que se puede explotar y su posible impacto en un sistema vulnerable. Sin embargo, más allá de esta descripción (y la puntuación base del CVSS), hay muchas cosas que no abarca:

• ¿Quién encontró la vulnerabilidad? ¿Fue el proveedor, un investigador ético que informó del fallo y esperó un parche, o fue un actor malicioso?
• ¿Hay algún exploit disponible públicamente? En otras palabras, ¿existe código disponible fácilmente para aprovechar la vulnerabilidad?
• ¿Cómo de práctico es explotar la vulnerabilidad en escenarios del mundo real?
• ¿Existe un parche? ¿Cubre todas las versiones del software vulnerables y cuáles son los posibles efectos secundarios de aplicarlo?
• ¿La organización debería abordar la vulnerabilidad? ¿O afecta a un servicio en la nube (SaaS) donde el proveedor reparará automáticamente los defectos?
• ¿Hay indicios de explotación en el mundo real?
• Si no hay ninguno, ¿cuál es la probabilidad de que los atacantes aprovechen esta vulnerabilidad en el futuro?
• ¿Qué sistemas específicos dentro de su organización son vulnerables?
• ¿La explotación es prácticamente accesible para un atacante? Por ejemplo, un sistema podría ser un servidor web corporativo accesible para cualquier persona en línea, o podría ser una impresora vulnerable conectada físicamente a un único ordenador que no tenga acceso a la red. Un ejemplo más complejo podría ser una vulnerabilidad en el método de un componente de software, donde la aplicación empresarial específica que usa ese componente nunca llama al método.
• ¿Qué pasaría si los sistemas vulnerables se vieran comprometidos?
• ¿Cuál es el coste financiero de un evento así para la empresa?

Todos estos factores influyen considerablemente en la decisión de cuándo y cómo reparar una vulnerabilidad, o incluso si la reparación es necesaria.

¿Cómo modificar el CVSS? ¡La RBVM tiene la respuesta!

Muchos factores que a menudo son difíciles de tener en cuenta dentro de los límites del CVSS son fundamentales para un enfoque popular conocido como Gestión de vulnerabilidades basada en riesgos (RBVM, por sus siglas en inglés).

La RBVM es un proceso holístico y cíclico, con varias fases clave que se repiten regularmente:

• Inventariar todos los activos de TI de tu empresa. Esto incluye todo, desde ordenadores, servidores y software, hasta servicios en la nube y dispositivos de IoT.
• Priorizar los activos según su importancia, identificando tus joyas de la corona.
• Analizar los activos en busca de vulnerabilidades conocidas.
• Enriquecer de los datos de vulnerabilidad. Esto incluye refinar las puntuaciones del CVSS-B y del CVSS-BT, incorporar inteligencia sobre amenazas y evaluar la probabilidad de explotación. Dos herramientas populares para medir la explotabilidad son EPSS (otra puntuación de FIRST que proporciona un porcentaje de probabilidad de explotación en el mundo real para la mayoría de las vulnerabilidades) y consultar bases de datos como CISA KEV, que contiene información sobre las vulnerabilidades que los atacantes están explotando activamente.
• Definir el contexto empresarial: comprender el impacto potencial de un exploit en sistemas vulnerables, teniendo en cuenta sus configuraciones y cómo se utilizan dentro de tu organización.
• Determinar cómo se puede neutralizar la vulnerabilidad mediante parches o medidas compensatorias.
• La parte más emocionante: evaluar el riesgo empresarial y establecer prioridades en función de todos los datos recopilados. Se priorizan las vulnerabilidades con mayor probabilidad de explotación y un posible impacto significativo en tus activos clave de TI. Para clasificar las vulnerabilidades, puedes calcular el CVSS-BTE, incorporando todos los datos recopilados en el componente Ambiental, o utilizar metodologías de clasificación alternativas. Los aspectos regulatorios también influyen en la priorización.
• Establecer plazos para la resolución de cada vulnerabilidad según su nivel de riesgo y consideraciones operativas, como el momento más conveniente para las actualizaciones. Si no hay actualizaciones o parches disponibles, o si tu implementación introduce nuevos riesgos y complejidades, adopta medidas compensatorias en lugar de una remediación directa. A veces, el coste de reparar una vulnerabilidad supera el riesgo que representa, y se puede tomar la decisión de no repararla en absoluto. En esos casos, la empresa acepta conscientemente los riesgos de que se explote la vulnerabilidad.

Además de lo que hemos comentado, es fundamental analizar periódicamente el panorama de vulnerabilidades y la infraestructura de TI de tu empresa. Después de este análisis, tienes que introducir medidas de ciberseguridad que impidan que se exploten clases enteras de vulnerabilidades o que mejoren considerablemente la seguridad general de sistemas de TI específicos. Estas medidas pueden incluir la microsegmentación de la red, la implementación con privilegios mínimos y la adopción de políticas de gestión de cuentas más estrictas.

Un proceso de RBVM implementado correctamente reduce drásticamente la carga sobre los equipos de TI y de seguridad. Dedican su tiempo de forma más eficaz, ya que sus esfuerzos se dirigen principalmente a los fallos que suponen una amenaza real para la empresa. Para comprender la magnitud de estas mejoras en eficiencia y ahorros de recursos, considera este estudio de FIRST. Priorizar las vulnerabilidades usando solo el EPSS te permite concentrarte en solo el 3 % de las vulnerabilidades al tiempo que logras un 65% de eficiencia. En cambio, priorizar según el CVSS-B requiere abordar la friolera de un 57 % de las vulnerabilidades con una pobre efectividad del 4 %. Aquí, “eficiencia” hace referencia a remediar con éxito las vulnerabilidades que realmente se han explotado en entornos reales.