volvervolver
Inteligencia artificial en Ciberseguridad

POR:
Federico Pacheco
(I+D+i Manager)

COMPARTIR

Referencias

⦁ Presentación de CVSSv4 en FIRST Conference 2023
https://www.first.org/cvss/v4-0/cvss-v40-presentation.pdf

⦁ CVSS v4.0 Public Preview Documentation & Resources
https://www.first.org/cvss/v4-0/

CVSSv4 y la búsqueda de la precisión

En este post revisamos la nueva versión de CVSS (Common Vulnerability Scoring System) que es una herramienta clave para los profesionales de la ciberseguridad, los administradores de sistemas, y los desarrolladores a la hora de evaluar la gravedad de las vulnerabilidades y determinar la respuesta adecuada. Aquí exploramos su historia, propósito componentes, y mencionamos sus cambios respecto a la versión anterior.

Un breve repaso

El CVSS es un estándar abierto para evaluar la gravedad de las vulnerabilidades de seguridad de los sistemas, que propone una manera de capturar las características principales de una vulnerabilidad y producir una puntuación numérica que refleje su gravedad, y se pueda traducir a una representación cualitativa. Este es desarrollado un grupo de interés especial (SIG, Special Interest Group) de la organización FIRST, y ha tenido varios cambios a lo largo del tiempo. Su objetivo es poder comunicar y compartir detalles sobre vulnerabilidades usando un lenguaje común, mejorando la colaboración y el intercambio de información entre las organizaciones que conforman el ecosistema de la ciberseguridad.

El sistema consta de tres grupos de métricas: las base, en cuanto a características intrínsecas de una vulnerabilidad; las temporales, que son características que cambian con el tiempo, y las ambientales, que son características específicas de un cierto entorno.


Grupos de métricas de CVSSv3.1


Un largo historial

CVSS ha tenido un largo recorrido hasta llegar a la versión actual. Todo comenzó en 2003, cuando el Consejo Asesor de Infraestructura Nacional (NIAC) del gobierno de los Estados Unidos inició la investigación que condujo al lanzamiento de la versión 1 (CVSSv1) en 2005, con el objetivo de crear una clasificación de gravedad para vulnerabilidades de software que sea abierta y universalmente estándar. Lo cierto es que la versión inicial no se sometió a revisión por pares o de otras organizaciones, lo que le impidió alcanzar validez científica. Por esto, el NIAC seleccionó a FIRST (Foro de Equipos de Seguridad y Respuesta a Incidentes) para su mantenimiento y desarrollo futuro.

Los comentarios de las empresas y profesionales que usaban CVSSv1 en producción sugirieron que no era lo suficientemente adecuado, por lo que el mismo año de su lanzamiento, empezó el trabajo sobre la versión 2 (CVSSv2) que se publicó en 2007. Sin embargo, la comunidad que migró al uso de CVSSv2 señalaba la falta de granularidad en varias métricas, que daba como resultado puntajes que no distinguían adecuadamente las vulnerabilidades de diferentes tipos y perfiles de riesgo, y además, requería demasiado conocimiento del impacto, lo cual reducía su precisión. Estas y otras críticas derivaron en el lanzamiento de la versión 3 (CVSSv3) en 2015, luego de 3 años de trabajo. Todo parecía resuelto, pero la mejora continua debía seguir, y CVSSv3 aún tenía debilidades para la calificación de vulnerabilidades en sistemas emergente como Internet de las cosas (IoT) y otros, por eso en 2019 se lanzó una actualización que conformó la versión 3.1.

Esta versión, si bien estaba muy refinada y madura, recibió diversas críticas muy específicas, como ser que la puntuación base se usaba como entrada principal para el análisis de riesgos, que no representaba suficientes detalles en tiempo real sobre amenazas e impactos suplementarios, que era solo aplicable a los sistemas informáticos (sin representar sistemas como los de salud, seguridad humana y control industrial). También se le criticó que las puntuaciones publicadas por los proveedores solían ser altas o críticas, que la granularidad era insuficiente (menos de 99 puntuaciones discretas) y que las métricas temporales no influían de forma efectiva en la puntuación final. Como si fuera poco, se apuntó con frecuencia a que la fórmula y las cuentas eran complicadas y contra intuitivas.

Así llegamos a junio de 2023, cuando se lanzó el borrador de la versión 4 para consulta pública, cuyo cierre es próximo el 31 de julio, en tanto que la publicación oficial será durante el último trimestre del año.


Grupos de métricas de CVSSv4


Nuevas características

La versión 4 de CVSS realiza cambios sustanciales al sistema, por lo que debe ser entendida en toda su expresión si es que se espera utilizar. Entre sus nuevas características, se incluyen las que mencionamos a continuación.

Para subrayar que CVSS no es solo la puntuación base, se adoptó una nueva nomenclatura para identificar combinaciones del grupo Base. Estas son: CVSS-B para la puntuación base, CVSS-BT para la puntuación base más puntuación de amenaza, CVSS-BE para la puntuación base más ambiental, y CVSS-BTE para la puntuación base más amenaza más ambiental.


Métricas base de CVSSv4


El grupo de métricas temporales se renombró como grupo de métricas de amenazas, que implica métricas de amenazas simplificadas y aclaradas, eliminación del nivel de remediación (RL) y la confianza del informe (RC), y renombramiento del “exploit code maturity” como Exploit Maturity (E) con valores más claros. La idea es ajustar la puntuación Base del "peor caso razonable" mediante el uso de inteligencia de amenazas para reducir la puntuación CVSS-BTE, abordando la preocupación de que muchos resultados de CVSS (Base) son demasiado altos.

La nueva métrica de “Requisitos de ataque” pretende solucionar el problema de la falta de reflejo de las condiciones de alta complejidad en los valores "bajo" y "alto" de complejidad. Por esto se dividió la definición en dos métricas, denominadas "Complejidad de Ataque" (AC) y "Requisitos de Ataque" (AT) que transmiten respectivamente lo siguiente. El primero refleja la complejidad de ingeniería del exploit necesaria para evadir o eludir las tecnologías defensivas o de mejora de la seguridad (medidas defensivas) y el segundo refleja las condiciones previas del componente vulnerable que hacen posible el ataque.

La métrica “interacción del usuario” se actualizó para permitir una granularidad mayor al considerar la interacción de un usuario con un componente vulnerable, y tiene 3 opciones. Ninguno (N) cuando el sistema puede ser explotado sin interacción de usuarios humanos, salvo el atacante; Pasiva (P) cuando la explotación requiere una interacción limitada por parte del usuario objetivo con el componente vulnerable y el payload del atacante (interacciones involuntarias); y Activa (A) cuando la explotación requiere que el usuario realice interacciones específicas y conscientes.

La métrica “Alcance” (Scope) se retiró, y se dice que fue la menos comprendida de la historia, porque causaba una puntuación inconsistente entre proveedores de productos, e implicaba una "compresión con pérdida" de los impactos de los sistemas vulnerables. Como solución se ampliaron las métricas de impacto en dos conjuntos para su evaluación explícita: Confidencialidad (VC), Integridad (VI), y Disponibilidad (VA) del sistema vulnerable; y Confidencialidad (SC), Integridad (SI), y Disponibilidad (SA) de los sistemas afectados.

Se incorporó un nuevo grupo de métricas suplementarias para transmitir atributos extrínsecos adicionales de una vulnerabilidad que no afectan la puntuación final de CVSS-BTE: Seguridad física y humana (S), Automatizable (A), Recuperación (R), Densidad del Valor (V), Esfuerzo de respuesta (RE), y Urgencia del proveedor (U). El consumidor de la información puede utilizar los valores de estas métricas para tomar medidas adicionales si así lo desea, aplicando la importancia local, con la idea de que ninguna defina el impacto numérico en la puntuación CVSS final. Las organizaciones pueden asignar importancia y/o impacto efectivo de cada métrica (o conjunto de métricas) atribuyéndoles más, menos o ningún efecto en el análisis de riesgo final. Las métricas y los valores simplemente transmitirán características extrínsecas adicionales de la propia vulnerabilidad.

La métrica "Automatizable" captura la respuesta a si un atacante puede automatizar la explotación de esta vulnerabilidad a través de múltiples objetivos basándose en los primeros cuatro de la Kill Chain (reconocimiento, weaponization, entrega y explotación). Por su parte, la métrica “Recuperación” describe la resistencia de un componente o sistema para recuperar servicios, en términos de rendimiento y disponibilidad, después de que se haya producido un ataque. La “Densidad de valor” describe los recursos sobre los que el atacante obtendrá el control con un único evento de explotación, y tiene dos valores posibles: difusa y concentrada.

La métrica “Esfuerzo de respuesta” a la vulnerabilidad proporciona información complementaria sobre la dificultad que supone para los consumidores dar una respuesta inicial al impacto de las vulnerabilidades de los productos y servicios de su infraestructura. Así, el consumidor puede tener en cuenta esta información adicional sobre el esfuerzo necesario a la hora de aplicar mitigaciones o programar la remediación. Finalmente, la métrica “Urgencia del proveedor” busca facilitar un método estandarizado para incorporar una evaluación adicional proporcionada por el proveedor, que puede ser cualquier actor de la cadena de suministro, aunque el más cercano al consumidor estará en una mejor posición para proveer esta información específica.


Métricas suplementarias de CVSSv4


También se introdujeron y adoptaron sistemas de puntuación adicionales para tratar aspectos complementarios de la evaluación de vulnerabilidades y la prioridad de los parches. Se trata de dos adiciones a la puntuación de vulnerabilidades, que proporciona cierta capacidad de predicción y apoyo a la toma de decisiones. La primera es EPSS (Exploit Prediction Scoring System), un sistema de puntuación de predicción de exploits, que es un esfuerzo basado en datos para estimar la probabilidad de que una vulnerabilidad de software sea explotada en un plazo de 30 días. La segunda es SSVC (Stakeholder-Specific Vulnerability Categorization), una categorización de vulnerabilidades específica de las partes interesadas, que es un sistema de árbol de decisiones para priorizar acciones durante la gestión de vulnerabilidades.

La era de OT en CVSS

Uno de los agregados más notables de esta versión se encuentra en el nuevo enfoque en OT (Operation Technology) a través de las métricas y valores de seguridad física y humana (Safety). Hoy en día, muchas vulnerabilidades tienen impactos fuera de la tríada tradicional C/I/A de impacto lógico. Cada vez es más común la preocupación de que, mientras que los impactos lógicos pueden o no ser reconocidos en un sistema vulnerable o afectado, es posible que se produzcan daños tangibles a los seres humanos como resultado de la explotación de una vulnerabilidad. Los sectores de IoT, ICS (Industrial Control Systems) y salud en particular se preocupan mucho por poder identificar este tipo de impacto para ayudar a impulsar la priorización de problemas alineados con sus preocupaciones en aumento.

Para esto se analizan valores de seguridad ambiental suministrados por el consumidor y por el proveedor. En el primer caso, cuando un sistema no tiene un uso previsto o un propósito alineado directamente con la seguridad física, pero puede tener implicaciones de seguridad física en una cuestión de cómo o dónde se despliega, es posible que la explotación de una vulnerabilidad dentro de ese sistema pueda tener impacto de seguridad física y humana que pueden ser representados en el grupo de métricas ambientales. Este valor mide el impacto sobre un actor humano o participante que pueda resultar herido como consecuencia de una vulnerabilidad. A diferencia de otros valores de la métrica de impacto, la seguridad física solo puede asociarse al conjunto de “Impacto Sistemas Subsiguientes”, y debe considerarse además de los valores de impacto para las métricas de Disponibilidad e Integridad. En la “Integridad modificada del sistema subsiguiente: Seguridad física” (MSI:S), la explotación compromete la integridad del sistema vulnerable (por ejemplo, el cambio en la dosis de un dispositivo médico) lo que resulta en un impacto a la salud y seguridad humanas. En la “Disponibilidad modificada del sistema posterior: Seguridad física” (MSA: S) la explotación compromete la disponibilidad del sistema vulnerable (por ejemplo, la indisponibilidad del sistema de frenos de un vehículo) lo que provoca un impacto en la salud y la seguridad humanas.

Por otro lado tenemos la seguridad suplementaria suministrada por el proveedor, que aplica cuando un sistema tiene un uso previsto alineado a la seguridad, por lo que es posible que la explotación de una vulnerabilidad pueda tener un impacto en la seguridad física, que puede representarse en el grupo de métricas suplementarias. Sus valores posibles son: Presente (P) cuando las consecuencias de la vulnerabilidad cumplen la definición de las categorías de consecuencias de la norma IEC 61.508 de "marginal", "crítica" o "catastrófica"; Insignificante (N), cuando las consecuencias de la vulnerabilidad cumplen la definición de la categoría de consecuencias de la misma norma para "insignificantes"; y No definido (X) cuando el valor no se ha definido para dicha vulnerabilidad. Debemos notar que los proveedores no están obligados a suministrar métricas suplementarias, y pueden facilitarse según sea necesario, basándose únicamente en lo que el proveedor decida comunicar en cada caso.


Los sistemas industriales fueron considerados en CVSSv4


La fórmula del sistema

La matemática detrás del cálculo en el sistema CVSS fue largamente criticada hasta la versión 3.1, por lo que uno de los aspectos más interesantes es el desarrollo de un nuevo sistema de puntuación, que consistió en un proceso relativamente complejo respecto a la manera (más dudosa) en que se había realizado anteriormente. El proceso comenzó por tomar los 15 millones de vectores CVE-BTE en 270 conjuntos de equivalencia, pedir a expertos comparar los vectores que representan cada uno, calcular un orden de vectores desde el menos grave hasta el más grave, y volver a pedir opinión de expertos para decidir qué grupo representa el límite entre las puntuaciones cualitativas de gravedad para que sean compatibles con los límites cualitativos de puntuación de gravedad de CVSS v3.x. Luego se comprimieron los grupos de vectores en cada intervalo de gravedad cualitativa en el puntaje de ese intervalo (por ejemplo, 9 a 10 para crítico, 7 a 8.9 para alto, etc.) y se creó un factor de modificación que ajusta los puntajes dentro de un grupo de vectores para que un cambio de cualquier valor de métrica resulte en un cambio de puntaje. La intención es que el cambio de puntaje no sea mayor que la incertidumbre en la clasificación de los grupos de vectores según se recopila de los datos de comparación.

De la misma forma que en versiones anteriores, se pone a disposición una calculadora online que facilita la visualización de los atributos de cada grupo de métricas, y a su vez funciona como recurso didáctico para diseñar escenarios simulados que requieran ser cuantificados.


Calculadora de CVSSv4 (Link)


Vulnerabilidades versus riesgos

Otra de las cuestiones que se han planteado como inconvenientes en la aplicación potencialmente liviana o descontextualizada del CVSS es la gravedad técnica frente al riesgo. Por un lado, las puntuaciones CVSS Base (CVSS-B) representan la severidad a nivel técnico, sólo tiene en cuenta los atributos de la propia vulnerabilidad, y no se recomienda utilizarla por sí sola para determinar la prioridad de remediación. Por otro lado, el riesgo puede analizarse con los atributos completos de CVSS-BTE (puntuación base, amenaza asociada, y controles del entorno) de forma que si se usan correctamente, estas puntuaciones pueden representar con más precisión el conjunto de atributos para puntuaciones de riesgo, incluso más que algunas metodologías.

Finalmente, vale destacar que FIRST recomienda una serie de mejores prácticas para un uso adecuado del CVSS. Primeramente, usar fuentes y bases de datos para automatizar el enriquecimiento de la información de vulnerabilidades, como NVD (National Vulnerability Database) para métricas base, base de datos de activos para métricas ambientales, e inteligencia de amenazas, para métricas de amenazas. También propone encontrar maneras de ver la información de vulnerabilidades según atributos importantes y puntos de vista, como desde los equipos de soporte, las aplicaciones críticas, la mirada interna versus externa, las unidades de negocio, o los requisitos regulatorios.

Conclusiones

La versión 4 de CVSS trae consigo un nivel de madurez muy alto en relación a sus predecesoras. Si se hubiera querido llegar a este mismo punto en un tiempo muy anterior, posiblemente no hubiera sido una opción válida, ya que las comunidades, organizaciones, y profesionales debieron crecer con las versiones, y junto a los requerimientos de la industria. La responsabilidad de FIRST al publicar este tipo de trabajos es desmedidamente grande considerando los múltiples entornos en los que el sistema de scoring se utiliza, y pese a las críticas a las versiones anteriores, siempre lograron hacer un trabajo adecuado para la necesidad de cada momento.