Sistema de puntuación de vulnerabilidad común
El Common Vulnerability Scoring System ( CVSS ) es un estándar abierto que se utiliza para calcular puntuaciones cuantitativas de vulnerabilidades de seguridad en un sistema informático, generalmente para comprender la prioridad de solucionarlo.
Las puntuaciones se calculan mediante fórmulas especiales basadas en varias métricas y se aproximan a la facilidad de implementación del exploit y su impacto en el sistema informático. El resultado del cálculo son tres puntuaciones numéricas ( Base Score , Temporal Score y Environmental Score ), cada una de las cuales puede tomar un valor de 0 a 10, donde 10 expresa la máxima peligrosidad.
La última versión del estándar es la 3.1, lanzada en junio de 2019. Por diversas razones, algunas empresas utilizan la versión antigua del estándar CVSSv2, otras utilizan el nuevo CVSSv3 y otras aún combinan el uso de diferentes versiones.
Historia
La investigación realizada en 2003-2004 por el Consejo Asesor de Infraestructura Nacional ( NIAC ) condujo a la primera versión de CVSS en febrero de 2005. El objetivo inicial era proporcionar métodos abiertos y universales para evaluar la gravedad de las vulnerabilidades del software. En abril de 2005, NIAC lanzó el sitio web Forum of Incident Response and Security Teams (FIRST), donde se publicó la primera versión del estándar.
La primera versión del estándar no estuvo sujeta a revisión por pares por parte de terceros, por lo que los comentarios reales de las empresas que se especializaron en el desarrollo de software y trataron de usarlo revelaron muchos problemas graves, en relación con los cuales se lanzó la segunda versión del estándar en junio. 2007. Un mayor desarrollo condujo al lanzamiento de la tercera versión del estándar en junio de 2015.
Destacados
CVSS intenta evaluar la vulnerabilidad desde diferentes ángulos [1] :
- Evaluación cualitativa de la vulnerabilidad, que no depende del tiempo ni del entorno del software, expresada en términos de métricas base ( Base metrics ):
- El vector de acceso (AV) muestra cómo se puede introducir la vulnerabilidad.
- Complejidad de acceso (AC) indica qué tan fácil o difícil es explotar una vulnerabilidad dada.
- La autenticación (Au) estima el número de autenticaciones que debe realizar un atacante antes de explotar una vulnerabilidad.
- El impacto de la vulnerabilidad en el sistema informático ( Impact metrics ):
- La confidencialidad (C) describe el impacto en la privacidad de los datos procesados por el sistema.
- La integridad (I) describe el impacto en la integridad de los datos de un sistema informático.
- Disponibilidad (A) describe el impacto de una vulnerabilidad en la disponibilidad de un sistema informático. Por ejemplo, los ataques que afectan el rendimiento de la red o consumen tiempo de CPU afectan la disponibilidad del sistema.
- Métricas temporales , que tienen en cuenta la reacción del fabricante de un producto vulnerable, que cambian desde el momento en que se descubre una vulnerabilidad hasta el momento en que se soluciona:
- La capacidad de explotación (E) muestra el estado actual de los métodos de explotación de vulnerabilidades, incluidos los automatizados.
- El nivel de remediación (RL) es un número de corrección que le permite suavizar la estimación de tiempo a medida que las correcciones para una vulnerabilidad están disponibles.
- El informe de confianza (RC) le permite medir el nivel de confianza en la existencia de una vulnerabilidad y la confiabilidad de sus datos técnicos.
- Métricas de vulnerabilidad que tienen en cuenta los requisitos de seguridad específicos del sistema en el que se ejecuta el producto vulnerable ( Métricas ambientales ):
- Potencial de daño colateral (CDP) estima el daño potencial a una empresa a partir de una vulnerabilidad dada, como pérdida potencial, daño físico al equipo, etc.
- Target Distribution (TD) estima la proporción de sistemas vulnerables en una red informática.
- El modificador de puntuación secundaria de impacto incluye números de corrección de confidencialidad (CR), integridad (IR) y disponibilidad (AR) que le permiten ajustar las métricas de impacto y la puntuación final a los requisitos de seguridad específicos de un entorno en particular.
Las métricas para el cálculo se toman de las tablas, las cuales brindan su descripción, valores cualitativos y cuantitativos. La siguiente tabla muestra las métricas introducidas desde la segunda versión del estándar [1] .
Tabla dinámica con métricas CVSSv2
Calificación
|
Métrica
|
Descripción
|
puntaje base |
Vector de acceso (AV)
|
Expresión
cualitativa |
expresión
cuantitativa |
Explicación
|
locales (L)
|
0.395
|
El atacante debe tener acceso físico al sistema o tener una cuenta local.
|
Red adyacente (A)
|
0.646
|
El atacante debe tener acceso al canal de transmisión o al dominio de colisión .
|
Red (N)
|
una
|
Interfaz vulnerable que se ejecuta en la capa de red o en una capa superior del modelo OSI
|
|
Complejidad de acceso (AC)
|
Alto (H)
|
0.35
|
Hay algunas condiciones especiales para atacar, como una condición de carrera en el sistema, o se cumplen algunos requisitos de ingeniería social , que pueden ser notados por un especialista informado.
|
Medio (M)
|
0,61
|
Existen algunos requisitos adicionales para el ataque, por ejemplo, se define una fuente de ataque específica o existe un requisito para una configuración especial para el sistema atacado, diferente al estándar.
|
Bajo (L)
|
0.71
|
No hay requisitos especiales para explotar la vulnerabilidad.
|
|
Autenticación (AU)
|
Múltiple (M)
|
0,45
|
Un atacante debe autenticarse al menos dos veces para aprovechar la vulnerabilidad, incluso si se utilizan las mismas credenciales.
|
Soltero (S)
|
0,56
|
Un atacante debe autenticarse una vez para aprovechar la vulnerabilidad.
|
Ninguno (N)
|
0.704
|
No se requiere autenticación para explotar la vulnerabilidad
|
|
Confidencialidad (C)
|
Ninguno (N)
|
0
|
Sin impacto en la privacidad del sistema
|
Parcial (P)
|
0.275
|
Solo una cantidad limitada de datos se divulga ampliamente
|
Completa (C)
|
0.660
|
Divulgación completa de todos los datos del sistema
|
|
integridad (yo)
|
Ninguno (N)
|
0
|
Sin impacto en la integridad del sistema
|
Parcial (P)
|
0.275
|
La cantidad de datos del sistema que se pueden cambiar está claramente limitada
|
Completa (C)
|
0.660
|
El atacante puede cambiar cualquier dato del sistema.
|
|
Disponibilidad (A)
|
Ninguno (N)
|
0
|
Sin impacto en la disponibilidad del sistema
|
Parcial (P)
|
0.275
|
Hay una degradación parcial del rendimiento.
|
Completa (C)
|
0.660
|
Pérdida completa del recurso atacado
|
|
Puntuación temporal |
Explotabilidad (E)
|
No probado (U)
|
0.85
|
El código de explotación no está disponible o la explotación es teórica
|
Prueba de concepto (P)
|
0.9
|
Hay disponible un código de explotación de demostración, pero no es universal y cubre solo uno o unos pocos casos especiales.
|
Funcional (F)
|
0,95
|
El código de explotación está disponible y funciona en la mayoría de las situaciones donde la vulnerabilidad está presente
|
Alto (H)
|
1.0
|
El código de explotación está disponible y se puede introducir en el sistema de forma automática, como en forma de gusano o virus .
|
No definido (ND)
|
1.0
|
Ignorar esta métrica
|
|
Nivel de remediación (RL)
|
Solución oficial (O)
|
0.87
|
El proveedor ofrece una solución completa a la vulnerabilidad, ya sea como una actualización o como un parche .
|
Solución temporal (T)
|
0.90
|
El proveedor tiene una solución alternativa que mitiga parcialmente el impacto de la vulnerabilidad.
|
solución alternativa (W)
|
0,95
|
Solución no oficial o recurso de terceros disponible
|
No disponible (U)
|
1.0
|
No hay solución disponible o no se puede aplicar la solución propuesta. Por lo general, una vulnerabilidad permanece en este estado inmediatamente después del descubrimiento.
|
No definido (ND)
|
1.0
|
Ignorar esta métrica
|
|
Informe de confianza (RC)
|
Sin confirmar (UC)
|
0.9
|
Una fuente no confirmada, o varias fuentes, pero no describen la vulnerabilidad más o menos de la misma manera. Incluyendo rumores sobre vulnerabilidad
|
No corroborado (UR)
|
0,95
|
Varias fuentes que generalmente describen la vulnerabilidad de la misma manera. Los pequeños desacuerdos son aceptables
|
Confirmado (C)
|
1.0
|
La vulnerabilidad es confirmada tanto por el proveedor como por el fabricante del producto afectado
|
No definido (ND)
|
1.0
|
Ignorar esta métrica
|
|
Puntaje ambiental |
Potencial de daños colaterales (CDP)
|
Ninguno (N)
|
0
|
La vulnerabilidad no conlleva pérdidas para los negocios
|
Bajo (L)
|
0.1
|
Pérdida menor de ingresos o rendimiento del sistema
|
Bajo Medio (LM)
|
0.3
|
daño moderado
|
Medio Alto (MH)
|
0.4
|
Daño significativo
|
Alto (H)
|
0.5
|
daño catastrófico
|
No definido (ND)
|
0
|
Ignorar esta métrica
|
|
Distribución objetivo (TD)
|
Ninguno (N)
|
0
|
Los sistemas de destino no existen, o existen en el laboratorio.
|
Bajo (L)
|
0.25
|
1-25% del sistema afectado
|
Medio (M)
|
0.75
|
26-75% del sistema afectado
|
Alto (H)
|
1.0
|
76-100% sistema afectado
|
No definido (ND)
|
1.0
|
Ignorar esta métrica
|
|
Modificador de subpuntuación de impacto
|
Bajo (L)
|
0.5
|
Es probable que la pérdida de (confidencialidad (CR) / integridad (IR) / disponibilidad (AR)) solo tenga un impacto limitado en la organización
|
Medio (M)
|
1.0
|
La pérdida de (Confidencialidad (CR) / Integridad (IR) / Disponibilidad (AR)) puede afectar seriamente a una organización
|
Alto (H)
|
1.51
|
La pérdida de (confidencialidad (CR) / integridad (IR) / disponibilidad (AR)) puede ser desastrosa para una organización
|
No definido (ND)
|
1.0
|
Ignorar esta métrica
|
|
Fórmulas para calcular en CVSSv2
La puntuación se calcula utilizando las siguientes fórmulas. Los valores de los parámetros se seleccionan de la tabla anterior. Los números fraccionarios resultantes deben redondearse al primer decimal, que se expresa en términos de la siguiente función .
![{\displaystyle {\textsf {Puntuación base))}](https://wikimedia.org/api/rest_v1/media/math/render/svg/03af299bcb877665302ff6d9fbb9733358fc29de)
![{\displaystyle {\textsf {roundTo1Decimal}}}](https://wikimedia.org/api/rest_v1/media/math/render/svg/3b875f6d36802a2e1463fa4498a8ca95dbd025fc)
Las siguientes fórmulas se utilizan
para el cálculo .![{\displaystyle {\textsf {TemporalScrore))}](https://wikimedia.org/api/rest_v1/media/math/render/svg/b53ebf41156efcc213c4c31c53130c94b25d7e7d)
Las siguientes fórmulas se utilizan para el cálculo . se calcula usando la misma fórmula que , pero necesita sustituir .
![{\displaystyle {\textsf {Puntuación ambiental))}](https://wikimedia.org/api/rest_v1/media/math/render/svg/4e60fe1fd86172f46f1156e0beb95711438fda8c)
![{\displaystyle {\textsf {Temporal ajustado))}](https://wikimedia.org/api/rest_v1/media/math/render/svg/37619e70bac5506063e83c3eb7f3ee28026a9a9d)
![{\displaystyle {\textsf {puntuación temporal))}](https://wikimedia.org/api/rest_v1/media/math/render/svg/1bea1e1c6a2878abc7968b574632ddeb19773492)
![{\displaystyle {\textsf {Puntuación base))}](https://wikimedia.org/api/rest_v1/media/math/render/svg/03af299bcb877665302ff6d9fbb9733358fc29de)
![{\displaystyle {\textsf {Impacto ajustado}}}](https://wikimedia.org/api/rest_v1/media/math/render/svg/e1abdcd3f772446721bc81fda2b1de0aeb4682c7)
Ejemplo
En 2002, se descubrió una vulnerabilidad CVE -2002-0392 en la aplicación del servidor Apache , que condujo a la corrupción de la memoria del servidor durante la codificación fragmentada de las solicitudes. Sabiendo esto, un atacante puede crear un exploit exitoso que, en algunos casos, puede conducir a una denegación de servicio del servidor y, en otros, a la ejecución de código arbitrario con los privilegios de una aplicación de servidor.
Usando métricas CVSS para calcular la puntuación base , el problema se puede describir de la siguiente manera:
- AV es igual a N porque la solicitud se genera de forma remota en la capa de aplicación del modelo OSI.
- AC es igual a L, porque para la operación exitosa del exploit, es suficiente para formar una solicitud especial para el servidor y no se requieren requisitos especiales del servidor.
- Au es N porque el servidor procesará esta solicitud sin la autenticación del cliente.
- Dado que el resultado final de explotar una vulnerabilidad depende de la solicitud en sí, solo se debe tener en cuenta el caso de explotación más probable. Esto podría ser la ejecución de un código de atacante arbitrario para extraer datos de la base de datos del servidor, como obtener datos de autenticación de otros clientes. En este caso, los parámetros C e I deben configurarse en P ( Parcial ). También es probable que un atacante use un exploit para derribar el servidor, en cuyo caso A debe establecerse en C ( Completo ). En este ejemplo, asumiremos el segundo caso de uso, por lo que estableceremos C e I en N ( Ninguno ), y estableceremos A en C.
Por lo tanto, los parámetros para calcular la calificación base pueden expresarse mediante la siguiente cadena de texto, en la práctica llamada vector :
AV:N/AC:L/Au:N/C:N/I:N/A:C
Dado que la Fundación Apache ha confirmado la vulnerabilidad para las versiones de servidor 1.3 y 2.0, el vector
para Temporal Score será:E:F/RL:O/RC:C
El vector para el puntaje ambiental depende de qué es más importante para la empresa que usa el servidor Apache y qué capacidad tiene. Para este ejemplo, deje que el vector sea así:
CDP:H/TD:H/CR:M/IR:M/AR:H
Sustituyendo los valores cuantitativos de los indicadores de la tabla, obtenemos los siguientes resultados.
Dadas las puntuaciones tan altas para esta vulnerabilidad, deberíamos actualizar nuestros servidores Apache al menos a la versión 2.1 lo antes posible.
Crítica y comparación de versiones de la norma
Varios proveedores de software no están satisfechos con CVSSv2:
- Risk Based Security , que administra la base de datos de vulnerabilidades de código abierto , y Open Security Foundation expresaron su descontento con el estándar en una carta abierta a FIRST [2] . En particular, los autores señalaron la falta de detalle en varias métricas, que no distingue adecuadamente entre vulnerabilidades de diferentes tipos y perfiles de riesgo. También se señaló que el sistema de puntuación requiere demasiado conocimiento sobre el impacto de la vulnerabilidad en el sistema.
- Oracle ha propuesto otro nivel de Confidencialidad , Integridad y Disponibilidad , Parcial+ , para cerrar la gran brecha entre Parcial y Completo [3] .
Para abordar algunas de estas críticas, el desarrollo del estándar CVSSv3 comenzó en 2012 y la versión final se lanzó en junio de 2015. Se han cambiado, agregado y eliminado varios indicadores, y las fórmulas se han corregido ligeramente manteniendo el rango de calificación de 0 a 10.
Las principales diferencias entre CVSSv3 y CVSSv2 son las siguientes:
- Se agregaron nuevas métricas (UI (Experiencia del usuario), PR (Privilegios requeridos)) a la línea de base para ayudar a distinguir entre las vulnerabilidades relacionadas con los privilegios de usuario y administrador ordinarios.
- La métrica S ( alcance ) se ha agregado al vector de puntuación base para distinguir entre las vulnerabilidades que pueden introducirse primero y luego usarse para atacar otras partes del sistema o la red.
- Las métricas Confidencialidad , Integridad y Disponibilidad en la tercera versión tienen diferentes graduaciones: Ninguna, Baja y Alta, en lugar de Ninguna, Parcial y Completa.
- Se cambió el nombre de la métrica Complejidad de acceso a Complejidad de ataque para indicar que los requisitos de derechos de acceso se trasladaron a una métrica separada.
- Físico (P) se agregó a la métrica del vector de acceso para indicar que se requiere acceso físico al hardware para explotar la vulnerabilidad.
- Todas las métricas para Environmental Score se han cambiado por completo para describir con mayor precisión los requisitos de seguridad del sistema. Se han agregado métricas para reflejar la importancia de la confidencialidad, la integridad y la disponibilidad.
En junio de 2019, se lanzó la versión 3.1 [4] . Esta versión no introduce nuevos cambios al estándar, sino que solo detalla la descripción de algunas métricas para una mejor comprensión.
Aplicación
Muchas organizaciones han adoptado varias versiones de CVSS como método principal para cuantificar las vulnerabilidades. Estos son solo algunos ejemplos:
Notas
- ↑ 1 2 Una guía completa para el sistema de puntuación de vulnerabilidad común . www.first.org . Foro de Equipos de Seguridad y Respuesta a Incidentes (junio de 2007). Consultado el 6 de mayo de 2021. Archivado desde el original el 8 de marzo de 2022.
- ↑ CVSSv2 Deficiencias, fallas y formulación de fallas . www.riskbasedsecurity.com . Consultado el 7 de mayo de 2021. Archivado desde el original el 7 de mayo de 2021. (indefinido)
- ↑ Uso de Common Vulnerability Scoring System (CVSS) por Oracle . www.oracle.com . Consultado el 7 de mayo de 2021. Archivado desde el original el 6 de mayo de 2021. (indefinido)
- ↑ Common Vulnerability Scoring System versión 3.1: Documento de especificación . www.first.org . Foro de Equipos de Seguridad y Respuesta a Incidentes (junio 2019). Consultado el 7 de mayo de 2021. Archivado desde el original el 8 de marzo de 2022.
- ↑ Base de datos de vulnerabilidad nacional: sitio oficial . nvd.nist.gov . Consultado el 7 de mayo de 2021. Archivado desde el original el 6 de abril de 2018. (indefinido)
- ↑ Manión, art. Gravedad de la vulnerabilidad mediante CVSS . insights.sei.cmu.edu (12 de abril de 2012). Consultado el 7 de mayo de 2021. Archivado desde el original el 7 de mayo de 2021.
Enlaces