Hasta el momento, la versión 3.0 del framework CVSS (Common Vulnerability Scoring System) era la última publicada por la organización responsable de su creación, el FIRST (Forum of Incident Response and Security Teams). Este marco de referencia abierto establece unas métricas para la comunicación de las características, impacto y severidad de vulnerabilidades que afectan a elementos del entorno de seguridad TI. En el blog de INCIBE-CERT ya publicamos una entrada de CVSS 3.0 explicando las métricas y ecuaciones de esa versión, y comparándola con la anterior, en ese caso, con la 2. Ahora revisamos los cambios de la recientemente publicada versión 3.1 respecto a su predecesora.

Principales cambios de CVSS 3.1 respecto a CVSS 3.0

La versión 3.1 no introduce nuevas métricas o valores ni realiza cambios importantes en las fórmulas existentes respecto a la versión anterior, sino que se centra en aclarar y mejorar el estándar existente. A continuación, se explican las modificaciones más significativas:

CVSS mide la gravedad, no el riesgo

Esta versión resalta que el CVSS está diseñado para medir la severidad de una vulnerabilidad y, por ello, no debe ser utilizado como única herramienta para evaluar el riesgo. El documento de especificación CVSS v3.1 ahora establece claramente que la puntuación base de CVSS (Base Score) representa sólo las características intrínsecas de una vulnerabilidad que son constantes en el tiempo y son comunes a los distintos entornos de usuario. Para llevar a cabo un análisis de riesgos sistemático, esta puntuación base debe complementarse con un análisis contextual aprovechando las métricas temporales y del entorno, y con otros factores externos no contemplados por el CVSS como exposición y amenaza.

Cambios en Attack Vector y en Modified Attack Vector

Se reformulan las descripciones de los valores (Network, Adjacent, Local y Physical) de la métrica vector de ataque o Attack Vector (AV) para hacerlos más familiares a los proveedores y consumidores generales del CVSS, evitando referencias al modelo OSI. También se incluye una sección de guía para el uso de esta métrica cuando los recursos están tras un cortafuegos.

El valor Adjacent (A) de la métrica Attack Vector (AV), del grupo de métricas Base Score, según estaba definido en CVSS 3.0 causaba ambigüedad para el caso de redes lógicamente adyacentes o de confianza (MPLS, VPN, etc.). Para abordar esta imprecisión se amplía la definición de Adjacent, incluyendo estas redes de acceso limitado.

Cambios en la guía de puntuación

El documento de especificaciones y la guía del usuario han sido actualizados para ayudar a los analistas de CVSS a realizar puntuaciones consistentes y defendibles en varias situaciones que antes se podían ser ambiguas, entre ellas:

• El documento de especificaciones ha sido actualizado para aclarar que, al puntuar Base Metrics, se debe asumir que el atacante tiene un conocimiento avanzado de las debilidades del sistema objetivo, incluyendo configuración general y mecanismos de defensa por defecto.
• Se aclara que al puntuar las métricas de impacto de una vulnerabilidad se deben considerar exclusivamente las consecuencias negativas que sean el resultado de una explotación exitosa (por ejemplo, el aumento en el nivel de acceso o los nuevos privilegios obtenidos) sobre el componente vulnerable o el impactado, el que sufra el resultado peor. Este cambio se ha de puntuar en las Impact Metrics (Confidentiality, Integrity y Availability). Si no se ha producido un cambio en el alcance (Scope), los impactos de Confidencialidad, Integridad y Disponibilidad reflejan las consecuencias para el componente vulnerable, de lo contrario, reflejan las consecuencias para el componente que sufre el mayor impacto.
• En la explicación de la métrica Attack Complexity se ha eliminado el texto ambiguo: "la presencia de ciertos ajustes de configuración del sistema". Si para que un ataque tenga éxito se requiere una configuración específica del componente vulnerable, se debe puntuar asumiendo que tiene esa configuración, siempre que esta sea una configuración apropiada (no deben utilizarse configuraciones que están explícitamente contraindicadas).
• Se reformulan para aclararlos, la explicación de la métrica Scope del documento de especificaciones y los conceptos de Vulnerable Component (elemento que es vulnerable) e Impacted Component (elemento que sufre el impacto). Se añade un apartado en la guía de usuario con ejemplos.

Diagrama de puntuación de la métrica Scope.
Fuente: guía de usuario de CVSS 3.1

• La nueva guía explica cómo calificar el impacto de una vulnerabilidad en librerías y similares. Dada la dificultad del analista para conocer las formas en que puede utilizarse una librería, este ha de presuponer el peor escenario de implementación razonable y detallar estos supuestos cuando sea posible.
• Esta nueva guía permite explícitamente generar múltiples puntuaciones CVSS Base Scores para una vulnerabilidad que afecta a múltiples versiones de productos, plataformas y sistemas operativos.
• El grupo de métricas de entorno, Environmental Metrics Group, incluye tres métricas de requisitos de seguridad:
  
  • Confidentiality Requirement (CR) o requisito de confidencialidad, que se basa en la clasificación de los datos (público, uso interno, confidencial...) almacenados o utilizados por las aplicaciones que se ejecutan en el sistema objetivo, teniendo en cuenta que de estar cifrados disminuye este requisito.
  • Integrity Requirement (IR) o requisito de integridad, que se enfoca en la importancia de la precisión de los datos que almacena o utiliza. No se considera este requisito si los datos pasan sin ser consumidos a través del sistema objetivo. No se debe tener en cuenta el cifrado.
  • Availability Requirement (AR) o requisito de disponibilidad, que se basa en los requisitos de redundancia y tiempo de actividad del dispositivo o de las aplicaciones que aloja. Si existe redundancia este requisito será bajo.

Guía para puntuar Attack Vector: consideraciones

Al puntuar la métrica Attack Vector, se ha de utilizar el valor Adjacent o Network, según corresponda, siempre que se requiera una conexión de red para que un ataque tenga éxito, incluso si el ataque no se lanza a través de una red. Por ejemplo, cuando un programa local con privilegios es engañado para enviar datos sensibles a través de una red.

Las vulnerabilidades en las que los datos maliciosos se reciben a través de una red por un componente y luego se pasan a otro componente separado con una vulnerabilidad deben puntuarse con un Attack Vector de Local. Por ejemplo, un navegador que descarga un documento de Office malicioso, lo almacena en disco e inicia una aplicación de Office que lo lee.

En los casos en que la funcionalidad vulnerable es parte del componente que recibe los datos maliciosos, el Attack Vector debe ser calificado como Network. Por ejemplo, un navegador con una vulnerabilidad propia o de un plug-in o extensión que se inicia cuando recibe los datos maliciosos.

El marco de extensiones de CVSS

Se define un método estándar para extender el CVSS e incluir métricas y grupos de métricas adicionales, conservando al mismo tiempo los grupos de métricas oficiales Base, Temporal y Environmental. Las métricas adicionales permiten a los sectores industriales relacionados con la privacidad, la seguridad, la sanidad, la automoción, etc., puntuar factores que están fuera del estándar CVSS básico.

Cambios en la formulación

Las fórmulas utilizadas para calcular las puntuaciones Base, Temporal y Environmental se han modificado de las siguientes maneras:

• Las fórmulas se han reestructurado para hacerlas más claras y eliminar la ambigüedad causada por la definición de la subpuntuación de impacto para diferentes propósitos. Estas son únicamente aclaraciones y no alteran la puntuación.
• La función Round up de CVSS 3.0 ha sido renombrada a Roundup en CVSS 3.1, y ahora se define con mayor precisión para minimizar la posibilidad de que las implementaciones generen puntuaciones diferentes debido a pequeñas imprecisiones de punto flotante. Esto puede suceder debido a las diferencias en la aritmética de punto flotante entre los diferentes lenguajes de programación y plataformas hardware.
• En CVSS 3.0, ciertos conjuntos de métricas Environmental tienen la propiedad contraintuitiva de que al cambiar las métricas Security Requirement o Modified Impact a valores que deberían producir una Environmental Score más alta, resulta en una puntuación más baja. El problema sólo se produce si se cambia Modified Scope y, al menos, una de las métricas de Security Requirements es High. Esto se resuelve introduciendo una constante en la fórmula Modified Impact que se utiliza cuando se modifica el Modified Scope.

Actualización de Version Identifier (identificador de versión) en la representación Vector String

Se actualiza Vector String (representación en texto comprimida de los valores utilizados para obtener la puntuación final) para que comience con CVSS:3.1 en lugar de con CVSS:3.0. La representación Vector String queda como sigue:

Representación de Vector String.
Fuente: guía de usuario de CVSS 3.1
Esta cadena (Vector String) también se obtiene, además de la puntuación final, de la calculadora de CVSS 3.1 del FIRST.

Desde su lanzamiento inicial en 2004, CVSS ha disfrutado de una amplia aceptación. En septiembre de 2007, CVSS v2.0 fue adoptado como parte del Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS). En 2007, el Instituto Nacional de Estándares y Tecnología (NIST) incluyó CVSS v2.0 como parte de su Protocolo de Automatización de Contenidos de Seguridad (SCAP). En marzo de 2016, CVSS v3.0 fue adoptado formalmente como un estándar internacional para calificar vulnerabilidades (UIT-T X.1521).

La guía de usuario complementa el documento de especificación del sistema de puntuación de vulnerabilidad común (CVSS) versión 3.1, con información adicional que incluye los cambios más significativos con respecto a la versión 3.0 de CVSS. Se espera que a finales de 2019 esté disponible en la plataforma de FIRST el curso para esta nueva versión.

Fuente: INCIBE-CERT