Cvss v31 Specification R1.en - Es

TLP: BLANCO
Common Vulnerability Scoring System versión 3.1
Documento con especificaciones
revisión 1
El Common Vulnerability Scoring System (CVSS) es un marco abierto para comunicar las características y gravedad de las
vulnerabilidades de software. CVSS consiste en tres grupos: Base métricas, temporal y del medio ambiente. El grupo base
representa las cualidades intrínsecas de una vulnerabilidad que son constantes a lo largo del tiempo y en los entornos de
usuario, el grupo temporal refleja las características de una vulnerabilidad que cambian con el tiempo, y el grupo ambiental
representa las características de una vulnerabilidad que son únicos para un usuario de ambiente. Las métricas de base
producen una puntuación que varía de 0 a 10, que luego puede ser modificada por meter el métricas ambientales Temporal
y. Una puntuación CVSS también está representado como una cadena de vectores, una representación textual comprimida
de los valores utilizados para obtener la puntuación.
La mayor cantidad de recursos CVSS actuales se pueden encontrar en https://www.first.org/cvss/
CVSS es propiedad y está gestionado por FIRST.Org, Inc. (FIRST), una organización sin ánimo de lucro con sede en Estados Unidos, cuya misión es la
de los equipos de respuesta a incidentes de seguridad informática ayuda en todo el mundo. PRIMERA reserva el derecho a actualizar CVSS y este
documento periódicamente a su discreción. Mientras que el primer posee todos los derechos y el interés en CVSS, obtiene una licencia al público
libremente para su uso, sujeto a las condiciones siguientes. La pertenencia a PRIMERA No se requiere que el uso o aplicación de CVSS. PRIMERA
hace, sin embargo, requiere que cualquier persona o entidad CVSS usando dar la debida atribución, en su caso, que es propiedad de CVSS primero y
utilizado con permiso. Promover, adicional,
Contenido
1. Introducción ............................................... .................................................. .................................... 3
TLP: BLANCO
TLP: BLANCO
1.1. Métricas ................................................. .................................................. .................................. 3

1.2. Puntuación ................................................. .................................................. .................................. 5
2. Métricas Base .............................................. .................................................. ................................... 6
2.1. Las métricas de explotabilidad ................................................ .................................................. .............. 6
2.1.1. Vector de ataque (AV) ............................................. .................................................. .............. 6
2.1.2. Ataque Complejidad (AC) ............................................. .................................................. ...... 8
2.1.3. Privilegios necesarios (PR) ............................................. .................................................. .... 9

2.1.4. Interacción de Usuario (UI) ............................................. .................................................. ........... 9
2.2. Alcance (S) .............................................. .................................................. ............................... 10

2.3. Las métricas de impacto ................................................ .................................................. ...................... 11
2.3.1. Confidencialidad (C) .............................................. .................................................. ............ 11
2.3.2. Integridad (I) .............................................. .................................................. ....................... 12

2.3.3. Disponibilidad (D) .............................................. .................................................. .................. 13
3. Las métricas temporales .............................................. .................................................. .......................... 13
3.1. El código de explotación de vencimiento (E) ............................................ .................................................. ......... 14
3.2. Remediación Nivel (RL) ............................................. .................................................. .......... 15

3.3. Informe de confianza (RC) ............................................. .................................................. ......... 15
4. Las métricas ambientales .............................................. .................................................. .................. dieciséis
4.1. Requisitos de seguridad (CR, IR, AR) ......................................... ............................................. dieciséis
4.2. Modificados Métricas Base ............................................... .................................................. ........... 18
5. cualitativo de gravedad Escala ............................................ .................................................. ... 19

6. Vector de cadena .............................................. .................................................. ................................. 19
7. Ecuaciones CVSS v3.1 ........................................... .................................................. ...................... 21

7.1. Base de Métrica Ecuaciones ............................................... .................................................. ........ 21
7.2. Las métricas temporal Ecuaciones ............................................... .................................................. 22 ..
7.3. Metrics ambientales Ecuaciones ............................................... ........................................... 22

7.4. Los valores métricos ................................................ .................................................. ....................... 23
7.5. Una palabra de CVSS v3.1 Ecuaciones y alcanzaron el ........................................ ............................... 24
Apéndice A - Floating Point Redondeo ............................................ .................................................. 26

Apéndice B - Agradecimientos .............................................. .................................................. ....... 27
Apéndice C - Recursos en línea ........................................... .................................................. ........ 28
1. Introducción
El Common Vulnerability Scoring System (CVSS) captura las características técnicas principales del software, hardware y firmware
vulnerabilidades. Sus productos incluyen puntuaciones numéricas que indican la gravedad de una vulnerabilidad en relación con otras
vulnerabilidades.
CVSS se compone de tres grupos de métricas: Base, temporal y del medio ambiente. La puntuación base refleja la gravedad de una
vulnerabilidad de acuerdo con sus características intrínsecas que son constantes en el tiempo y asume el razonable peor impacto
caso a través de diferentes entornos desplegados.
CVSS v3.1 especificación de documento - Revisión 1

https://www.first.org/cvss/ 2 de 24 TLP: BLANCO
TLP: BLANCO
Las métricas temporales ajustar la gravedad de una vulnerabilidad de base sobre la base de factores que cambian con el tiempo, tales como la
disponibilidad de código de explotación. Las métricas ambientales ajustar los niveles de gravedad de Base y temporal a un entorno informático
específico. Se consideran factores tales como la presencia de mitigaciones en ese entorno.
Decenas de base son producidos normalmente por la organización mantener el producto vulnerables, o una tercera parte de puntuación en
su nombre. Es típico que sólo las métricas base a publicarse ya que estos no cambian con el tiempo y son comunes a todos los entornos.
Los consumidores de CVSS deben complementar la puntuación de base con temporal y ambientales puntuaciones específicas para su uso
del producto vulnerables a producir una gravedad más preciso para su entorno organizacional. Los consumidores pueden utilizar la
información CVSS como entrada a un proceso de gestión de vulnerabilidades de organización que también considera factores que no son
parte de CVSS el fin de clasificar las amenazas a su infraestructura tecnológica y toman decisiones informadas de remediación. Tales
factores pueden incluir: número de clientes en una línea de productos, las pérdidas monetarias por incumplimiento, la vida o los bienes
amenazados, o la opinión pública sobre las vulnerabilidades altamente publicitados. Estos están fuera del alcance de CVSS.
Los beneficios de CVSS incluyen la provisión de un proveedor estandarizada y la plataforma de la metodología de calificación de vulnerabilidad
agnóstico. Es un marco abierto, proporcionando transparencia a las características individuales y la metodología utilizados para obtener una
puntuación.
1.1. Métrica
CVSS se compone de tres grupos de métricas: Base, temporal, y ambiental, que consisten cada uno de un conjunto de métricas, como se
muestra en la Figura 1.
Figura 1: CVSS Metric Grupos
El grupo de métricas Base representa las características intrínsecas de una vulnerabilidad que son constantes en el tiempo y en todos los
entornos de usuario. Se compone de dos conjuntos de indicadores: los indicadores técnicos de explotación y las métricas de impacto.

TLP: BLANCO
Las métricas de explotabilidad reflejan la facilidad y medios técnicos mediante los cuales la vulnerabilidad puede ser explotada. Es
decir, que representan características de la Lo que es vulnerable, al cual nos referimos formalmente como el componente vulnerable. Las
métricas de impacto reflejan la consecuencia directa de una explotación exitosa, y representan la consecuencia a la cosa que sufre el
impacto, al cual nos referimos formalmente como el componente afectado.
Mientras que el componente vulnerable es típicamente una aplicación de software, el módulo, controlador, etc (o posiblemente un dispositivo de
hardware), el componente afectado podría ser una aplicación de software, un dispositivo de hardware o un recurso de red. Este potencial para medir
el impacto de una vulnerabilidad que no sea el componente vulnerable, era una característica clave introducida con la versión 3.0 CVSS. Esta
propiedad es capturado por la métrica Alcance, discutido más adelante.
El grupo métrica temporal refleja las características de una vulnerabilidad que pueden cambiar con el tiempo, pero no a través de entornos
de usuario. Por ejemplo, la presencia de un sencillo de usar, explotar kit aumentaría la puntuación CVSS, mientras que la creación de un
parche oficial sería disminuirlo. El grupo ambiental métrica representa las características de una vulnerabilidad que son relevantes y
exclusivos para el entorno de un usuario en particular. Las consideraciones incluyen la presencia de los controles de seguridad que
pueden mitigar algunas o todas las consecuencias de un ataque con éxito, y la importancia relativa de un sistema vulnerable dentro de
una infraestructura de tecnología.
Cada una de estas métricas se discuten en más detalle a continuación. La Guía del usuario contiene rúbricas de puntuación para las métricas de
Base que pueden ser útiles cuando la puntuación.
1.2. Puntuación
Cuando las métricas de base se les asignan valores por un analista, la ecuación Base calcula una puntuación
que van desde 0,0 hasta 10,0 como se ilustra en la Figura 2.
Figura 2: CVSS métricas y Ecuaciones
Específicamente, la ecuación Base se deriva de dos ecuaciones substitución: la ecuación sub-score de explotabilidad, y la ecuación
sub-score Impact. La ecuación sub-score de explotabilidad se deriva de las métricas Base de explotabilidad, mientras que la ecuación de
sub-score de impacto se deriva de las métricas de impacto Base.
La puntuación base puede entonces ser refinado por meter el métricas ambientales Temporal y con el fin de reflejar más exactamente la
gravedad relativa planteado por una vulnerabilidad al entorno de un usuario en un

TLP: BLANCO
punto específico en el tiempo. Anotando la métrica temporal y ambiental no es necesaria, pero se recomienda para las
puntuaciones más precisas.
Generalmente, las métricas de base y temporal se especifican por los analistas de vulnerabilidad de anuncios, proveedores de productos de
seguridad, o los proveedores de aplicaciones, ya que normalmente poseen la información más precisa sobre las características de una
vulnerabilidad. Los indicadores ambientales son especificados por organizaciones de usuarios finales, ya que son más capaces de evaluar el
impacto potencial de una vulnerabilidad dentro de su propio entorno informático.
Anotando métricas CVSS también produce una cadena de vectores, una representación textual de los valores de las métricas utilizadas para
marcar la vulnerabilidad. Esta cadena vector es una cadena de texto con formato específicamente que contiene cada valor asignado a cada
métrica, y siempre se debe mostrar con el marcador de vulnerabilidad. Las ecuaciones de puntuación y cadena vector se explican más adelante.
Tenga en cuenta que todas las métricas deben ser anotados en el supuesto de que el atacante ya ha localizado e identificado la vulnerabilidad.
Es decir, el analista no tendrá que considerar los medios por los que se identificó la vulnerabilidad. Además, es probable que muchos tipos
diferentes de individuos serán vulnerabilidades de puntuación (por ejemplo, proveedores de software, analistas de anuncios de vulnerabilidad,
proveedores de productos de seguridad), sin embargo, nota que la calificación de la vulnerabilidad está destinado a ser agnóstico a la persona y
su organización.
2. Base de Métrica
2.1. Las métricas de explotabilidad
Como se mencionó anteriormente, las métricas de explotabilidad reflejan las características de la Lo que es vulnerable, al cual nos referimos
formalmente como el componente vulnerable. Por lo tanto, cada una de las métricas de explotabilidad que figuran a continuación deben ser
anotado en relación con el componente vulnerable, y reflejan las propiedades de la vulnerabilidad que conducen a un ataque con éxito.
Al puntuar las métricas de base, debe ser asumido que el atacante tiene conocimiento avanzado de las debilidades del sistema de destino, incluyendo los
mecanismos de defensa de configuración y predeterminados generales (por ejemplo, una función de cortafuegos, los límites de frecuencia, el tráfico de
vigilancia). Por ejemplo, la explotación de una vulnerabilidad que resulta en el éxito repetible, determinista debe todavía ser considerada como una
relación de bajo Ataque Complejidad, independiente del conocimiento o las capacidades del atacante. Por otra parte, la mitigación específica de la diana
de ataque (por ejemplo, filtros personalizados firewall, listas de acceso) en su lugar se debe reflejar en el grupo de puntuación métrica ambiental.
Las configuraciones específicas no deben afectar a cualquier atributo que contribuye a la puntuación CVSS base, es decir, si se requiere una
configuración específica para un ataque tenga éxito, el componente vulnerable debe anotó asumiendo que es en esa configuración.
2.1.1. Vector de ataque (AV)
Esta medida refleja el contexto por el cual la explotación de la vulnerabilidad es posible. Este valor de la métrica (y por consiguiente la
puntuación total) serán mayores cuanto más remoto (lógicamente y físicamente) un atacante puede ser el fin de explotar el componente
vulnerable. El supuesto es que el número de atacantes potenciales para una vulnerabilidad que podría ser explotada desde el otro lado de
una red es mayor que el número de atacantes potenciales que podrían aprovechar una vulnerabilidad que requiere el acceso físico a un
dispositivo, y por lo tanto merece una puntuación superior Base. La lista de posibles valores se presenta en la Tabla 1.

TLP: BLANCO
Tabla 1: Vector de ataque
Valor métrica Descripción
Red (N) El componente vulnerable se une a la pila de red y el conjunto de posibles atacantes se extiende más allá de las otras
opciones que se enumeran a continuación, hasta e incluyendo la totalidad de Internet. Tal vulnerabilidad a menudo se
denomina “explotable remotamente” y puede ser pensado como un ser explotable ataque a nivel de protocolo uno o
más saltos de red (por ejemplo, a través de uno o más routers). Un ejemplo de un ataque a la red es un atacante
causar una denegación de servicio (DoS) mediante el envío de un paquete TCP especialmente diseñado a través de
una red de área amplia (por ejemplo, CVE-2004-0230).
Adyacente (A) El componente vulnerable se une a la pila de red, pero el ataque se limita a nivel de protocolo a una
topología lógicamente adyacente. Esto puede significar un ataque debe ser lanzado desde el mismo físico
compartido (por ejemplo, Bluetooth o IEEE
802,11) o lógico (por ejemplo, la subred IP local) de red, o desde dentro de un dominio administrativo seguro o de
otro modo limitado (por ejemplo, MPLS, VPN segura a una zona de red administrativa). Un ejemplo de un ataque
Adyacente sería un ARP (IPv4) o descubrimiento de vecinos (IPv6) de inundación que conduce a una denegación
de servicio en el segmento LAN local (por ejemplo, CVE-2013-6014).
Local (L) El componente vulnerable no está vinculado a la pila de red y la ruta del atacante es a través de lectura / escritura /
capacidades de ejecutar. Ya sea:
• el atacante explota la vulnerabilidad mediante el acceso al sistema de destino localmente (por ejemplo,
teclado, consola), o de forma remota (por ejemplo, SSH); o
• el atacante se basa en la interacción con el usuario por otra persona para realizar las acciones necesarias para
explotar la vulnerabilidad (por ejemplo, utilizando técnicas de ingeniería social para engañar a un usuario legítimo
para que abra un documento malicioso).
Física (P) El ataque requiere que el atacante tocar físicamente o manipular el componente vulnerable. La interacción física
puede ser breve (por ejemplo, el mal criada ataque 1) o persistente. Un ejemplo de este tipo de ataque es un ataque de
arranque en frío en el que un atacante obtiene acceso a las claves de cifrado de disco después de acceder
físicamente el sistema de destino. Otros ejemplos incluyen ataques periféricos a través de FireWire / USB acceso
directo a memoria (DMA).
Orientación de puntuación: Al decidir entre la red y al lado, en caso de ataque puede ser lanzado a través de una red de área amplia o
desde fuera del dominio de la red administrativa lógicamente adyacente, utilizar la red. La red se debe utilizar incluso si se requiere que el
atacante a estar en la misma intranet para explotar el sistema sea vulnerable (por ejemplo, el atacante sólo puede explotar la vulnerabilidad
desde el interior de una red corporativa).
2.1.2. Ataque Complejidad (AC)
Esta métrica se describen las condiciones más allá del control del atacante que deben existir a fin de explotar la vulnerabilidad. Como se
describe a continuación, dichas condiciones pueden requerir la colección de más información sobre el objetivo, o excepciones
computacionales. Importante, la evaluación de este excluye métricas cualquier requisito para la interacción del usuario con el fin de explotar
la vulnerabilidad (tales
1 Ver https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html para una descripción de la obra mala limpieza.

TLP: BLANCO
condiciones son capturados en la métrica de interacción del usuario). Si se requiere una configuración específica para un ataque tenga éxito,
las métricas de base deben ser puntuados suponiendo que el componente vulnerable es en esa configuración. La puntuación total es mayor
para los ataques menos complejos. La lista de posibles valores se presenta en la Tabla 2.
Tabla 2: Ataque Complejidad
Baja (L) no existen las condiciones de acceso especializados o circunstancias atenuantes. Un atacante puede
esperar el éxito repetible cuando se ataca el componente vulnerable.
Alta (H) Un ataque con éxito depende de las condiciones más allá del control del atacante. Es decir, un ataque con
éxito no se puede lograr a voluntad, pero requiere que el atacante para invertir en una cierta cantidad medible
de esfuerzo en la preparación o ejecución contra el componente vulnerable antes se puede esperar un ataque
con éxito. 2 Por ejemplo, un ataque con éxito puede depender de un atacante superación de cualquiera de las
siguientes condiciones:
• El atacante debe reunir conocimientos sobre el medio ambiente en el que el destino existe / componente
vulnerable. Por ejemplo, un requisito para recoger información sobre los ajustes de configuración de destino,
números de secuencia o secretos compartidos.
• El atacante debe preparar el entorno de destino para mejorar explotar fiabilidad. Por ejemplo, la
explotación repetida para ganar una condición de carrera, o superando la avanzada explotar
técnicas de mitigación.
• El atacante debe inyectarse en la trayectoria de red lógica entre el objetivo y el recurso
solicitado por la víctima con el fin de leer y / o modificar la red de comunicaciones (por
ejemplo, un hombre en el ataque medio).
Como se describe en la Sección 2.1, conocimiento detallado de la componente vulnerable está fuera del alcance de Ataque Complejidad. Consulte esa
sección para obtener ayuda adicional cuando se calificaron Ataque complejidad a la hora de mitigación de ataques objetivo específico está presente.
2.1.3. Privilegios necesarios (PR)
Esta métrica describe el nivel de privilegios de un atacante debe poseer antes de la explotación de esta vulnerabilidad. La
puntuación total es mayor si no se requieren privilegios. La lista de posibles valores se presenta en la Tabla 3.
2 Tenga en cuenta que no hay comentario se hace con respecto a la cantidad de esfuerzo requerido, solo que una cierta cantidad de esfuerzo adicional debe ser ejercida
con el fin de explotar la vulnerabilidad.

TLP: BLANCO
Tabla 3: privilegios necesarios
Ninguno (N) El atacante no está autorizado antes del ataque, y por lo tanto no requiere ningún acceso a la
configuración o archivos del sistema vulnerables a llevar a cabo un ataque.
Baja (L) El atacante requiere privilegios que proporcionan capacidades básicas de los usuarios que normalmente podrían
afectar sólo la configuración y los archivos de propiedad de un usuario. Por otra parte, un atacante con privilegios bajos
tiene la posibilidad de acceder a los recursos sólo no sensibles.
Alta (H) El atacante requiere privilegios que proporcionan un control significativo (por ejemplo, administrativo) sobre el
componente vulnerable que permite el acceso a la configuración y archivos de todo el componente.
Orientación de puntuación: privilegios necesarios suele ser Ninguno de vulnerabilidades o vulnerabilidades de credenciales no modificables que requieren
ingeniería social (por ejemplo, que se refleja cross-site scripting, petición en sitios cruzados falsificación, o archivo de la vulnerabilidad de análisis en un lector
de PDF).
2.1.4. Interacción de Usuario (UI)
Esta métrica capturas el requisito de un usuario humano, excepto el atacante, para que participen en el compromiso con éxito del
componente vulnerable. Esta métrica determina si la vulnerabilidad puede ser explotada únicamente en la voluntad del atacante, o si un
usuario independiente (o proceso iniciado por el usuario) debe participar en alguna manera. La puntuación total es mayor cuando no se
requiere ninguna interacción del usuario. La lista de posibles valores se presenta en la Tabla 4.
Tabla 4: Interacción de Usuario
Ninguno (N) El sistema vulnerable puede explotarse sin la interacción de cualquier usuario.
Requerido (R) La explotación exitosa de esta vulnerabilidad requiere que un usuario tome alguna acción antes de que
la vulnerabilidad puede ser explotada. Por ejemplo, un ataque exitoso sólo pueden efectuarse durante la
instalación de una aplicación por un administrador del sistema.
2.2. Alcance (S)
Las capturas métricas Ámbito si una vulnerabilidad en uno afecta a los recursos de los componentes vulnerables de los componentes más allá de su ámbito
de la seguridad.
Formalmente, una autoridad de seguridad es un mecanismo (por ejemplo, una aplicación, un sistema operativo, firmware, un entorno de pruebas) que
define y hace cumplir de control de acceso en términos de cómo ciertos sujetos / actores (por ejemplo, usuarios humanos, procesos) pueden acceder a
ciertos objetos / recursos restringidos (por ejemplo, , archivos, CPU, memoria) de una manera controlada. Todos los sujetos y objetos bajo la jurisdicción
de un solo autoridad de seguridad se considera que son menores de un ámbito de la seguridad. Si una vulnerabilidad en un componente vulnerable puede
afectar a un componente que se encuentra en una diferente ámbito de seguridad que la

TLP: BLANCO
componente vulnerable, un cambio Ámbito de aplicación se produce. Intuitivamente, cada vez que el impacto de una vulnerabilidad incumple una
seguridad / límite de confianza y afecta a los componentes fuera del ámbito de seguridad en el que reside el componente vulnerable, se produce un
cambio de alcance.
El ámbito de seguridad de un componente abarca otros componentes que proporcionan funcionalidad exclusivamente a ese componente, incluso si
estos otros componentes tienen su propia autoridad de seguridad. Por ejemplo, una base de datos utilizada únicamente por una sola aplicación se
considera parte del ámbito de la seguridad que la aplicación incluso si la base de datos tiene su propia autoridad de seguridad, por ejemplo, un
mecanismo de control de acceso a registros de la base sobre la base de usuarios de bases de datos y privilegios de base de datos asociados. La
puntuación total es mayor cuando se produce un cambio de alcance. La lista de posibles valores se presenta en la Tabla 5.
Tabla 5: Alcance
Sin cambios (U) Una vulnerabilidad explotada sólo puede afectar a los recursos gestionados por la misma autoridad de
seguridad. En este caso, el componente vulnerable y el componente afectado son o bien el mismo, o
ambos son gestionados por la misma autoridad de seguridad.
Cambiado (C) Una vulnerabilidad explotada puede afectar a los recursos más allá del alcance de seguridad gestionada por
la autoridad de seguridad del componente vulnerable. En este caso, el componente vulnerable y el
componente afectado son diferentes y administrado por diferentes autoridades de seguridad.
2.3. Métricas de impacto
El impacto métricas de captura de los efectos de una vulnerabilidad explotada con éxito en el componente que sufre el peor
resultado que es más directamente y de manera previsible asociado con el ataque. Los analistas deben limitar los impactos a un
resultado razonable, final, que están seguros de que un atacante es capaz de lograr.
Sólo el aumento en el acceso, privilegios adquiridos, u otro resultado negativo como resultado de la explotación exitosa se deben considerar
cuando se calificaron las métricas de impacto de una vulnerabilidad. Por ejemplo, considere una vulnerabilidad que requiere permisos de sólo
lectura antes de ser capaces de explotar la vulnerabilidad. Después de una explotación exitosa, el atacante mantiene el mismo nivel de acceso de
lectura, y las ganancias de acceso de escritura. En este caso, sólo la métrica impacto integridad debe ser anotado, y las métricas de impacto
confidencialidad y disponibilidad debe establecerse como Ninguna. Tenga en cuenta que cuando anotan un cambio en el delta del impacto, el impacto
final debería ser usado. Por ejemplo, si un atacante inicia con un acceso parcial a la información restringida (Confidencialidad baja) y la
explotación exitosa de los resultados de vulnerabilidad en la pérdida completa de la confidencialidad (confidencialidad alta), entonces la resultante
puntuación CVSS base debe hacer referencia al “final del juego” valor de la métrica de impacto (Confidencialidad alta).
Si no se ha producido un cambio de alcance, los indicadores de impacto deben reflejar la confidencialidad, integridad y disponibilidad de los
impactos del componente vulnerable. Sin embargo, si se ha producido un cambio de alcance, entonces las métricas de impacto deben
reflejar la confidencialidad, integridad y disponibilidad a los impactos ya sea el componente vulnerable, o el componente impactado, lo que
sufre el resultado más grave.

TLP: BLANCO
2.3.1. Confidencialidad (C)
Esta métrica mide el impacto de la confidencialidad de las fuentes de información gestionados por un componente de software debido a
una vulnerabilidad explotada con éxito. La confidencialidad se refiere a la limitación de acceso a la información y la divulgación a sólo los
usuarios autorizados, así como para prevenir el acceso de, o de la divulgación a, los no autorizados. La puntuación total es mayor cuando
la pérdida del componente impactado es más alta. La lista de posibles valores se presentan en la Tabla 6.
Tabla 6: Confidencialidad
Alta (H) Hay una pérdida total de la confidencialidad, lo que resulta en todos los recursos dentro del ser
impactado componente divulgado al atacante. Alternativamente, se obtiene el acceso a sólo algunos
información restringida, pero la información divulgada presenta un impacto directo, serio. Por ejemplo,
un atacante roba la contraseña del administrador, o claves de cifrado privadas de un servidor web.
Baja (L) Hay una cierta pérdida de confidencialidad. Se obtiene acceso a información restringida, pero el
atacante no tiene control sobre lo que se obtiene la información, o la cantidad o tipo de pérdida
se limita. La divulgación de información no causa una pérdida directa, seria para el componente
afectado.
Ninguno (N) No hay pérdida de confidencialidad dentro del componente afectado.
2.3.2. Integridad (I)
Esta métrica mide el impacto de la integridad de una vulnerabilidad explotada con éxito. La integridad se refiere a la fiabilidad y
veracidad de la información. La puntuación total es mayor cuando la consecuencia al componente impactado es más alta. La lista
de posibles valores se presenta en la Tabla 7.
Tabla 7: Integridad
Alta (H) Hay una pérdida total de la integridad, o una pérdida completa de protección. Por ejemplo, el atacante es capaz
de modificar cualquier / todos los archivos protegidos por el componente afectado. Alternativamente, solamente
algunos archivos se pueden modificar, pero la modificación maliciosa presentarían una consecuencia directa,
seria para el componente afectado.
Baja (L) Modificación de los datos es posible, pero el atacante no tener control sobre la consecuencia de
una modificación, o la cantidad de la modificación es limitado. La modificación de datos no tiene
un impacto directo, serio en el componente afectado.
Ninguno (N) No hay pérdida de la integridad dentro del componente afectado.
2.3.3. Disponibilidad (D)
Esta métrica mide el impacto de la disponibilidad de la mercancía resultante componente afectado de una vulnerabilidad explotada con éxito.
Mientras que las métricas de confidencialidad y la integridad de impacto se aplican a

TLP: BLANCO
la pérdida de confidencialidad o la integridad de datos ( por ejemplo, información, archivos) que utiliza el componente impactado, esta métrica se refiere
a la pérdida de la disponibilidad de la misma, el componente afectado, tales como un servicio de red (por ejemplo, web, bases de datos, correo
electrónico). Dado que la disponibilidad se refiere a la accesibilidad de los recursos de información, ataques que consumen ancho de banda, ciclos de
procesador, o espacio en disco todo un impacto en la disponibilidad de un componente afectado. La puntuación total es mayor cuando la consecuencia
al componente impactado es más alta. La lista de posibles valores se presenta en la Tabla 8.
Tabla 8: Disponibilidad
Alta (H) Hay una pérdida total de la disponibilidad, lo que resulta en que el atacante es capaz de negar completamente el
acceso a los recursos en el componente afectado; esta pérdida se mantiene o bien (mientras que el atacante continúa
entregando el ataque) o persistente (la condición persiste incluso después de que el ataque ha terminado). Por otra
parte, el atacante tiene la capacidad de negar cierta disponibilidad, pero la pérdida de presentes sobre la disponibilidad
de una, seria consecuencia directa al componente afectado (por ejemplo, el atacante no puede interrumpir las
conexiones existentes, pero puede impedir nuevas conexiones; el atacante puede explotar en repetidas ocasiones una
vulnerabilidad que, en cada caso de un ataque exitoso, las fugas de una única pequeña cantidad de memoria, pero
después de la explotación repetida hace que un servicio para ser completamente no disponible).
Baja (L) El rendimiento se reduce o hay interrupciones en la disponibilidad de recursos. Incluso si la explotación
repetida de la vulnerabilidad es posible, el atacante no tiene la capacidad de negar por completo el
servicio a los usuarios legítimos. Los recursos en el componente impactado están parcial disponible todo
el tiempo, o totalmente disponible sólo una parte del tiempo, pero en general no hay una consecuencia
directa, seria para el componente afectado.
Ninguno (N) No hay impacto a disponibilidad en el componente afectado.
3. Las métricas temporal
Las métricas temporales miden el estado actual de explotación de técnicas o disponibilidad del código, la existencia de los
parches o soluciones, o la confianza en la descripción de una vulnerabilidad.
3.1. El código de explotación de vencimiento (E)
Esta métrica mide la probabilidad de que la vulnerabilidad de ser atacado, y típicamente se basa en el estado actual de las
técnicas de explotar, explotar disponibilidad del código, o activa la explotación, “in-the-wild”. disponibilidad pública de fácil de usar
código de explotación aumenta el número de atacantes potenciales mediante la inclusión de aquellos que son de obra no
calificada, lo que aumenta la gravedad de la vulnerabilidad. Inicialmente, la explotación real mundo sólo puede ser teórico.
Publicación de código de prueba de concepto, funcional código de explotación, o suficientes detalles técnicos necesarios para
explotar la vulnerabilidad puede seguir. Por otra parte, el código disponible puede pasar de una demostración de prueba de
concepto para explotar código que tiene éxito en la explotación de la vulnerabilidad constantemente explotar. En los casos
graves,

TLP: BLANCO
La lista de posibles valores se presentan en la Tabla 9. El más fácilmente una vulnerabilidad puede ser explotada, mayor será la puntuación
vulnerabilidad.
Tabla 9: el código de explotación de Madurez
No Definido (X) Asignación de este valor indica no hay suficiente información para elegir uno de los otros valores,
y no tiene ningún impacto en el Score Temporal en general, es decir, tiene el mismo efecto en la
puntuación como la asignación de alta.
Alta (H) existe código autónoma funcional, o ninguna hazaña es necesario (disparador manual) y los detalles están
ampliamente disponibles. El código de explotación funciona en todas las situaciones, o activamente se está
entregando a través de un agente autónomo (como un gusano o un virus). sistemas conectados a la red es
probable que de escaneo encuentro o de explotación intentos. desarrollo de explotar ha alcanzado el nivel
de herramientas fiables, ampliamente disponible y fácil de usar automatizados.
Funcional (F) Funcional código de explotación está disponible. El código funciona en la mayoría de las situaciones en las que existe
la vulnerabilidad.
Prueba de concepto (P) Prueba de concepto de código de explotación está disponible, o una demostración de ataque no es
práctico para la mayoría de los sistemas. El código o técnica no es funcional en todas las situaciones y
pueden requerir modificación sustancial por un atacante experto.
No probada (U) No hay código de explotación está disponible, o un exploit es teórica.
3.2. Remediación Nivel (RL)
El nivel de remediación de una vulnerabilidad es un factor importante para el establecimiento de prioridades. La vulnerabilidad típico es sin parche
cuando se publicó inicialmente. Soluciones o revisiones pueden ofrecer remediación provisional hasta que se emita un parche oficial o
actualización. Cada una de estas etapas respectivas ajusta a la baja las Score temporales, lo que refleja la urgencia decreciente a medida que la
recuperación sea firme. La lista de posibles valores se presenta en la Tabla 10. La solución menos un oficial y permanente, mayor será la
puntuación vulnerabilidad.
Tabla 10: Nivel de remediación
No Definido (X) Asignación de este valor indica no hay suficiente información para elegir uno de los otros
valores, y no tiene ningún impacto en el Score Temporal en general, es decir, tiene el mismo
efecto en la puntuación como asignar disponible.
No Disponible (U) O bien no hay solución disponible o es imposible de aplicar.
Solución alternativa (W) No es una solución no oficial, no proveedor disponible. En algunos casos, los usuarios de la
tecnología afectada crearán un parche de su propia o proporcionar medidas para evitar o
mitigar la vulnerabilidad de otra manera.

TLP: BLANCO
Arreglo temporal (T) No es una solución oficial pero temporal disponible. Esto incluye los casos en que el proveedor
emita una revisión temporal, herramienta o solución.
Fix Oficial (O) Una solución completa de proveedores está disponible. O bien el proveedor ha emitido un parche oficial, o
una actualización está disponible.
3.3. Informe de confianza (RC)
Esta métrica mide el grado de confianza en la existencia de la vulnerabilidad y la credibilidad de los detalles técnicos
conocidos. A veces sólo se hace público la existencia de vulnerabilidades, pero sin detalles específicos. Por ejemplo, un
impacto puede ser reconocido como indeseable, pero la causa raíz puede no ser conocida. La vulnerabilidad puede ser
corroborado más tarde por la investigación que sugiere que la vulnerabilidad puede estar, aunque la investigación puede
no ser cierta. Por último, una vulnerabilidad puede confirmarse mediante el reconocimiento por el creador o el proveedor de
la tecnología afectada. La urgencia de una vulnerabilidad es mayor cuando una vulnerabilidad se sabe que existe con
certeza. Esta medida también sugiere el nivel de conocimientos técnicos disponibles para los posibles atacantes. La lista
de posibles valores se presenta en la Tabla 11.
Tabla 11: Informe de confianza
No Definido (X) Asignación de este valor indica no hay suficiente información para elegir uno de los otros valores, y no tiene
ningún impacto en el Score Temporal en general, es decir, tiene el mismo efecto en la puntuación como la
asignación confirmada.
Confirmado (C) existen informes detallados, o reproducción funcional es posible (exploits funcionales pueden proporcionar
esto). El código fuente está disponible para verificar de forma independiente las afirmaciones de la
investigación, o el autor o vendedor del código afectado ha confirmado la presencia de la vulnerabilidad.
Razonable (R) detalles significativos son publicadas, pero los investigadores o bien no tienen plena confianza en la causa,
o no tienen acceso al código fuente para confirmar plenamente todas las interacciones que pueden
conducir al resultado. existe razonable confianza, sin embargo, que el error es reproducible y por lo menos
un impacto es capaz de ser verificada (exploits prueba de concepto pueden proporcionar este). Un ejemplo
es un relato detallado de la investigación de una vulnerabilidad con una explicación (posiblemente
ofuscado o “deja como ejercicio para el lector”) que da garantías sobre la manera de reproducir los
resultados.
Desconocido (T) Hay informes de impactos que indican una vulnerabilidad está presente. Los informes indican que la causa
de la vulnerabilidad es desconocida, o informes pueden diferir de la causa o impactos de la vulnerabilidad.
Los reporteros no están seguros de la verdadera naturaleza de la vulnerabilidad, y hay poca confianza en
la validez de los informes o si una puntuación base estática puede aplicarse teniendo en cuenta las
diferencias descritas. Un ejemplo es un informe de fallo que señala que un accidente intermitente, pero no
reproducible se produce, con evidencia de corrupción de memoria que sugiere que la denegación de
servicio, o posibles impactos más graves, pueden resultar.

TLP: BLANCO
4. Métrica ambiental
Estas métricas permiten al analista de personalizar la puntuación CVSS dependiendo de la importancia del activo que afectaba a la
organización de un usuario, medido en términos de controles de seguridad alternativos / complementarios en su lugar, confidencialidad,
integridad y disponibilidad. Las métricas son el equivalente modificada de métricas de base y se asignan valores basado en la colocación de los
componentes dentro de la infraestructura de la organización.
4.1. Requisitos de seguridad (CR, IR, AR)
Estas métricas permiten al analista de personalizar la puntuación CVSS dependiendo de la importancia del activo que afectaba a la organización de un usuario,
medido en términos de confidencialidad, integridad y disponibilidad. Es decir, si un activo Es compatible con una función de negocio para el que la disponibilidad es
más importante, el analista puede asignar un valor mayor a disponibilidad relativa a la confidencialidad y la integridad. Cada requisito de seguridad tiene tres valores
posibles: Baja, Media o Alta. El efecto total de la puntuación del medio ambiente está determinado por las mediciones del impacto de base modificada
correspondientes. Es decir, estas métricas modifican la puntuación del medio ambiente volviendo a ponderar la confidencialidad Modificado, integridad y disponibilidad
métricas de impacto. Por ejemplo, el impacto modificado Confidencialidad (MC) métrica ha aumentado de peso si el requisito de confidencialidad (CR) es alta.
Asimismo, la confidencialidad métrica de impacto modificado ha disminuido de peso si el requisito de confidencialidad es Baja. La ponderación métrica impacto
confidencialidad modificada es neutral si el requisito de confidencialidad es Medio. Este mismo proceso se aplica a la integridad y requisitos de disponibilidad. Tenga
en cuenta que el requisito de confidencialidad no afectará a la puntuación del medio ambiente si el (Modificado Base) impacto confidencialidad se establece en
Ninguno. Además, el aumento de la prescripción de confidencialidad de medio a alto no va a cambiar la puntuación del Medio Ambiente (cuando la base modificada)
Sistema de medición de impacto se establece en Alta. Esto es porque el Impacto Sub-Score Modificado (parte de la base modificada Puntuación que calcula impacto)
ya está en un valor máximo de 10. La confidencialidad de la métrica de impacto modificado se ha reducido el peso si el requisito de confidencialidad es baja. La
ponderación métrica impacto confidencialidad modificada es neutral si el requisito de confidencialidad es Medio. Este mismo proceso se aplica a la integridad y
requisitos de disponibilidad. Tenga en cuenta que el requisito de confidencialidad no afectará a la puntuación del medio ambiente si el (Modificado Base) impacto
confidencialidad se establece en Ninguno. Además, el aumento de la prescripción de confidencialidad de medio a alto no va a cambiar la puntuación del Medio
Ambiente (cuando la base modificada) Sistema de medición de impacto se establece en Alta. Esto es porque el Impacto Sub-Score Modificado (parte de la base
modificada Puntuación que calcula impacto) ya está en un valor máximo de 10. La confidencialidad de la métrica de impacto modificado se ha reducido el peso si el requisito de confidencia
La lista de valores posibles se presenta en la Tabla 12. Por razones de brevedad, la misma tabla se utiliza para los tres métricas. Cuanto mayor
es el requisito de seguridad, mayor será la puntuación (recordemos que es considerado el Medio defecto).
Tabla 12: Requisitos de seguridad
No Definido (X) Asignación de este valor indica no hay suficiente información para elegir uno de los otros valores, y no
tiene ningún impacto en el Score medioambiental global, es decir, tiene el mismo efecto en la
puntuación como la asignación Medium.
Alta (H) La pérdida de [Confidencialidad | integridad | Disponibilidad] es probable que tenga un efecto adverso
catastrófico en la organización o individuos asociados con la organización (por ejemplo, empleados,
clientes).
Medio (M) La pérdida de [Confidencialidad | integridad | Disponibilidad] es probable que tenga un efecto
adverso en la organización o individuos asociados con la organización (por ejemplo, empleados,
clientes).
Baja (L) La pérdida de [Confidencialidad | integridad | Disponibilidad] es probable que tenga un efecto adverso
limitado en la organización o individuos asociados con la organización (por ejemplo, empleados,
clientes).

TLP: BLANCO
4.2. Métricas de base modificada
Estas métricas permiten al analista para anular las métricas de base individuales basándose en las características específicas de entorno de
un usuario. Características que afectan explotabilidad, alcance o impacto puede reflejarse a través de un objetivo ambiental, convenientemente
modificada.
El efecto total de la puntuación del Medio Ambiente está determinado por las correspondientes métricas de base. Es decir, estas métricas
modifican la puntuación Ambiental anulando Base valores métricos, antes de la aplicación de los requisitos de seguridad ambiental. Por
ejemplo, la configuración por defecto de un componente vulnerable puede ser para ejecutar un servicio de escucha con privilegios de
administrador, para lo cual una solución de compromiso podría conceder un atacante confidencialidad, integridad y disponibilidad impactos
que son todos de alta. Sin embargo, en el entorno del analista, ese mismo servicio de Internet se esté ejecutando con privilegios reducidos; en
ese caso, la confidencialidad Modificado, Modificado integridad y disponibilidad Modificado pueden cada uno ser Baja.
Por razones de brevedad, sólo se mencionan los nombres de las métricas base modificada. Cada métrica Ambiental Modificado tiene los mismos
valores que su correspondiente métrica Base, además de un valor de no definido. No está definido es el valor predeterminado y utiliza el valor de
la métrica de la Base asociado métrica. La intención de esta métrica es definir las medidas de mitigación en el lugar para un entorno
determinado. Es aceptable el uso de las métricas modificadas para representar situaciones que aumentan la puntuación base. Por ejemplo, la
configuración por defecto de un componente puede requieren altos privilegios para acceder a una función particular, pero en el entorno del
analista puede no haber privilegios necesarios. El analista puede establecer privilegios necesarios para Alta y Modificado privilegios necesarios
para Ninguno para reflejar esta condición más grave en su entorno particular.
La lista de posibles valores se presenta en la Tabla 13.
Tabla 13: Modificado Base Métrica
Modificado Metric Base Los valores correspondientes
Modificado Ataque vectorial (MAV)
Ataque modificado Complejidad Alcance (MAC) Los
privilegios modificada que se precise (MPR) modificado
interacción del usuario (MUI) modificado (MS) Los mismos valores que el correspondiente Metric Base (véase Métrica
base anterior), así como no definido (el valor predeterminado).
Confidencialidad modificado (MC) modificado Integridad
(MI) modificado disponibilidad (MA)

TLP: BLANCO
5. Cualitativa de gravedad Escala

Para algunos propósitos es útil tener una representación textual de la base numérica, temporal y anota ambientales. Todas las
puntuaciones se pueden asignar a las calificaciones cualitativas definidas en la Tabla 14. 3
Tabla 14: Cualitativa escala de calificación de la gravedad
Clasificación Puntuación CVSS
Ninguna 0.0
Bajo 0,1-3,9
Medio 4,0-6,9
Alto 7,0-8,9
Crítico 9,0-10,0
Como un ejemplo, una puntuación CVSS Base de 4,0 tiene una clasificación de gravedad asociado de medio. El uso de estas clasificaciones
de gravedad cualitativos es opcional, y no hay ningún requisito para incluirlos al publicar las puntuaciones CVSS. Están destinados a
organizaciones de ayuda para valorar correctamente y dar prioridad a sus procesos de gestión de vulnerabilidades.
6. vector cadena
La cadena del vector CVSS v3.1 es una representación de texto de un conjunto de métricas CVSS. Se utiliza comúnmente para grabar o transferencia
CVSS información métrica de una forma concisa.
La cadena del vector CVSS v3.1 comienza con la etiqueta “CVSS:” y una representación numérica de la versión actual, “3.1”. información
Metric sigue en la forma de un conjunto de métricas, cada uno precedido por una barra, “/”, que actúa como un delimitador. Cada métrica es un
nombre de la métrica en forma abreviada, un colon, “:”, y su valor de métrica que se asocia de forma abreviada. Las formas abreviadas se
definen anteriormente en esta memoria descriptiva (entre paréntesis después de cada nombre de la métrica y el valor métrico), y se resumen
en la siguiente tabla.
Una cadena vector debe contener métricas en el orden mostrado en la Tabla 15, aunque otros ordenamientos son válidos. Todas las métricas
de base deben ser incluidos en una cadena de vectores. Temporales y ambientales métricas son opcionales, y se consideran métricas omitidas
para tener el valor de no definido (X). Métricas con un valor de No Definido pueden incluirse explícitamente en una cadena de vectores si se
desea. Programas de lectura cuerdas vector CVSS v3.1 deben aceptar métricas en cualquier orden y tratar no especificado Temporal y de
ambiente que no definidos. Una cadena de vectores no debe incluir la misma métrica más de una vez.
3 Tenga en cuenta que esta correspondencia entre los resultados cuantitativos y cualitativos se aplica si sólo la base, o la totalidad de la base, temporal
y grupos métricas ambientales, se anotó.

TLP: BLANCO
Tabla 15: Base, temporal y vectores ambientales
Nombre métrica (y forma Valores

Grupo métrica abreviada) posibles ¿Obligatorio?
Base Vector de ataque (AV) [N, A, L, P] si
Ataque Complejidad (AC) [L, H] si
Privilegios necesarios (PR) [N, L, H] si
Interacción de Usuario (UI) [N, R] si
Alcance (S) [U, C] si
Confidencialidad (C) [H, L, N] si
Integridad (I) [H, L, N] si
Disponibilidad (D) [H, L, N] si
Temporal El código de explotación de vencimiento (E) [X, H, F, P, U] No
Remediación Nivel (RL) [X, U, W, T, O] No
Informe de confianza (RC) [X, C, R, T] No
Ambiental Confidencialidad Requisito (CR) [X, H, M, L] No
Integridad Requisito (IR) [X, H, M, L] No
Requisito de disponibilidad (AR) [X, H, M, L] No
Modificado Ataque vectorial (MAV) [X, N, A, L, P] No
Modificado Ataque Complejidad (MAC) [X, L, H] No
Los privilegios de modificación requerida (MPR) [X, N, L, H] No
Modificado interacción del usuario (MUI) [X, N, R] No
Alcance de modificación (MS) [X, U, C] No
La confidencialidad de modificación (MC) [X, N, L, H] No
Modificado Integridad (MI) [X, N, L, H] No
Disponibilidad Modificado (MA) [X, N, L, H] No
Por ejemplo, una vulnerabilidad con los valores de indicadores de base de “Vector de ataque: Red, Ataque Complejidad: Baja, privilegios
necesarios: Altas, la interacción del usuario: Ninguno, Alcance: Sin cambios, la confidencialidad: Bajo, Integridad: Low, Disponibilidad:
Ninguno” y no especifica métricas temporales o ambientales producirían el siguiente vector:
CVSS: 3,1 / AV: N / AC: L / PR: H / UI: N / S: U / C: L / I: L / A: N
El mismo ejemplo con la adición de “explotabilidad: Functional, Remediation Level: No Definido” y con las métricas en una
ordenación no preferida produciría el siguiente vector:

TLP: BLANCO
CVSS: 3,1 / S: U / AV: N / AC: L / PR: H / UI: N / C: L / I: L / A: N / E: F / RL: X
7. CVSS v3.1 Ecuaciones
Las ecuaciones CVSS v3.1 se definen en las sub-secciones siguientes. Se basan en funciones de ayuda definidos de la siguiente manera:
• Mínimo devuelve el menor de sus dos argumentos.
• Redondeo devuelve el número más pequeño, especificado a 1 decimal, que es igual o superior a su entrada. Por ejemplo, Roundup
(4.02) devoluciones 4.1; y Roundup (4.00) devoluciones
4.0. Para asegurar resultados consistentes a través de los lenguajes de programación y el hardware, consulte el Apéndice A para el asesoramiento a
los ejecutores en evitar pequeñas inexactitudes introducidas en algunas implementaciones de coma flotante.
Sustituir métricas individuales utilizadas en las ecuaciones con la constante asociadas enumeradas en la Sección 7.4.
7.1. Base de Métrica Ecuaciones
La Base Score fórmula depende de sub-fórmulas de Impacto Sub-Score (ISS), impacto y de explotabilidad, todos los cuales se
definen a continuación:
= ISS 1 - [(1 - Confidencialidad) × (1 - Integridad) × (1 - Disponibilidad)]
= impacto
Si alcance es Sin cambios 6,42 × ISS
Si se cambia Alcance 7,52 × (ISS - 0.029) - 3,25 × (ISS - 0.02) 15
explotabilidad = 8.22 × × AttackVector AttackComplexity × ×

PrivilegesRequired UserInteraction
Si BaseScore =
Impacto <= 0 0, más
Si alcance es Sin cambios Roundup (mínimo [(Impact + explotabilidad), 10])
Si se cambia Alcance Roundup (mínimo [1,08 × (Impact + explotabilidad), 10])
7.2. Las métricas temporal Ecuaciones

TemporalScore = Roundup (BaseScore × ExploitCodeMaturity × ×
RemediationLevel ReportConfidence)
7.3. Métrica Ambiental Ecuaciones
The Score Ambiental fórmula depende de sub-fórmulas de impacto modificado Sub-Score (extraño), ModifiedImpact, y
ModifiedExploitability, todos los cuales se definen a continuación:

TLP: BLANCO
= SRTA Mínimo (1 -
[(1 - ConfidentialityRequirement × ModifiedConfidentiality) × (1 -

IntegrityRequirement × ModifiedIntegrity) × (1 - AvailabilityRequirement ×
ModifiedAvailability)], 0.915)
ModifiedImpact =
Si no se ha modificado ModifiedScope 6,42 × SRTA
Si se cambia la ModifiedScope 7,52 × (Miss - 0.029) - 3,25 × (Miss ×

0.9731 - 0.02) 13
ModifiedExploitability = 8.22 × × ModifiedAttackVector ModifiedAttackComplexity × ×

ModifiedPrivilegesRequired ModifiedUserInteraction
Nota que el exponente en el extremo de la ModifiedImpact sub-fórmula es 13, que difiere de v3.0 CVSS. Ver la Guía del
usuario para más detalles de este cambio.
EnvironmentalScore = Si
ModifiedImpact <= 0 0, más
Si no se ha modificado Roundup (Roundup

ModifiedScope [mínimo
([ModifiedImpact + ModifiedExploitability], 10)] x
ExploitCodeMaturity × ×
RemediationLevel
ReportConfidence)
Si se cambia la Roundup (Roundup

ModifiedScope [mínima (1,08 ×
[ModifiedImpact + ModifiedExploitability], 10)] x
ExploitCodeMaturity × ×
RemediationLevel
ReportConfidence)
7.4. Los valores métricos
Cada valor de la métrica tiene una constante asociada que se utiliza en las fórmulas, tal como se define en la Tabla
dieciséis.
Tabla 16: Valores de métricas
Métrico Valor métrica Valor numérico
Vector de ataque / Modificado Red 0.85

Ataque Vector
Adyacente 0.62

TLP: BLANCO
Local 0.55
Físico 0.2
Ataque Complejidad / Modificado Bajo 0,77

ataque Complejidad
Alto 0.44
Privilegios necesarios privilegios / Ninguna 0.85

modificada que se precise
Bajo 0,62 (o 0,68 si Alcance / Alcance de modificación se
cambia)
Alto 0,27 (o 0,5 si Alcance / Alcance de modificación se cambia)
Interacción de usuario / Modificado de Ninguna 0.85

interacción de usuario
Necesario 0.62
Confidencialidad / integridad / Alto 0.56

disponibilidad / Modificado
Confidencialidad / integridad Modificado /
Bajo 0.22
Disponibilidad Modificado
Ninguna 0
El código de explotación Madurez No definida 1
Alto 1
Funcional 0.97
Prueba de concepto 0.94
no probada 0.91
Nivel de remediación No definida 1
Indisponible 1
Solución del problema 0.97
arreglo temporal 0.96
Fix oficial 0.95
informe de confianza No definida 1
Confirmado 1
Razonable 0.96
Desconocido 0.92
Requisito confidencialidad / integridad No definida 1

Requisito / requisito de disponibilidad
Alto 1.5

TLP: BLANCO
Medio 1
Bajo 0.5
7.5. Una palabra de CVSS v3.1 y ecuaciones de puntuación
La fórmula CVSS v3.1 proporciona una aproximación matemática de todas las combinaciones posibles métricas clasificados en orden de gravedad
(una tabla de consulta vulnerabilidad). Para producir la fórmula CVSS v3.1, el Grupo de Interés Especial CVSS (SIG) enmarca la tabla de consulta
mediante la asignación de valores de indicadores a las vulnerabilidades reales, y un grupo severidad (baja, media, alta y crítica). Habiendo definido
los rangos numéricos aceptables para cada nivel de gravedad, el SIG entonces colaboró con Deloitte & Touche LLP para ajustar parámetros de la
fórmula con el fin de alinear las combinaciones métricas a la clasificación de gravedad propuestas por el SIG.
Dado que hay un número limitado de resultados numéricos (101 resultados, que van desde 0,0 a
10.0), múltiples combinaciones de puntuación pueden producir el mismo resultado numérico. Además, algunas puntuaciones numéricas
pueden omitirse porque los pesos y los cálculos se derivan de la clasificación de las combinaciones métricas gravedad. Además, en algunos
casos, las combinaciones métricas pueden desviarse del umbral de gravedad deseado. Esto es inevitable y una simple corrección no está
fácilmente disponible debido a los ajustes realizados a un valor métrico o parámetro de la ecuación con el fin de corregir una desviación, causa
otras desviaciones, potencialmente más graves.
Por consenso, y como se hizo con v2.0 CVSS, la desviación aceptable era un valor de 0,5. Es decir, todas las combinaciones de valores
métricos utilizados para derivar los pesos y cálculo producirá una puntuación numérica dentro de su nivel de gravedad asignado, o dentro
de 0,5 de que el nivel asignado. Por ejemplo, una combinación espera que sea calificado como un “alto” puede tener una puntuación
numérica entre 6,6 y 9,3. Finalmente, v3.1 CVSS retiene el intervalo 0,0 a 10,0 para la compatibilidad hacia atrás.

TLP: BLANCO
Apéndice A - Floating Point Redondeo

implementaciones simples de la función Roundup definidos en la Sección 7 es probable que conduzcan a resultados diferentes a través de los
lenguajes de programación y plataformas de hardware. Esto es debido a pequeños errores que se producen al utilizar la aritmética de coma
flotante. Por ejemplo, aunque el resultado intuitiva de
0,1 + 0,2 es 0,3, implementaciones de JavaScript en muchos sistemas de retorno ,30000000000000004. Una simple aplicación de
Roundup redondear esto hasta que 0,4, que es contrario a la intuición. Los ejecutores de las fórmulas CVSS deben tomar medidas para
evitar este tipo de problemas. Diferentes técnicas pueden ser necesarios para diferentes lenguajes y plataformas, y algunos pueden
ofrecer funcionalidad estándar que minimiza o evita totalmente este tipo de problemas.
Un enfoque sugerido es para la función de Roundup a primera multiplican su entrada en 100.000 y convertirlo al más cercano entero.
El redondeo a continuación, se debe realizar usando sólo aritmética de enteros, que no está sujeto a inexactitudes de punto flotante.
Un ejemplo de pseudocódigo para tal implementación es un:
1 función Roundup (entrada):

2 int_input = round_to_nearest_integer (entrada * 100 000) 3 Si
(int_input% 10000) == 0: 4
volver int_input / 100000.0 5 más:
6
retorno (piso (int_input / 10000) + 1) / 10,0
los suelo función en la línea 6 representa la división entera, es decir, el valor entero más grande menor que o igual a su entrada. Muchos lenguajes de
programación se incluye una función del suelo como estándar. Línea 3 comprueba si los menos significativos cuatro dígitos del número entero son
todos ceros, por ejemplo, una entrada de

1.200003 sería convertido por la línea 2 en 120 003, haciendo que el resultado de la operación módulo 0 y por lo tanto la Si declaración
es condición cierto. Si cierto, no se requiere redondeo adicional. Si falso,
el número entero se incrementa en 0,1 antes de ser devuelta, aunque la línea 6 realiza esto en los números de veces diez más grande que el
resultado será el fin de utilizar aritmética de enteros.

TLP: BLANCO
Apéndice B - Agradecimientos
PRIMERA reconoce sinceramente las contribuciones de los siguientes miembros (SIG) CVSS grupo de interés especial, en
orden alfabético: Adam Maris (Red Hat) Arkadeep Kundu (Dell) Arnold Yoon (Dell) Art Manion (CERT / CC) Bruce
Lowenthal (Oracle) Bruce Monroe (Intel) Charles Wergin (NIST) Christopher Turner (NIST) Cosby Clark (IBM)
Dale enriquecido (Depository Trust & Clearing Corporation) Damir

'Gaus' Rajnovic (Panasonic) Daniel Sommerfeld (Microsoft) Darío
Wiles (Oracle) de Dave Dugal (Juniper) Deana Shick (CERT / CC)
Fabio Oliva Leite (Red Hat) James Kohli (GE Cuidado de la salud)
Jeffrey Heller (Sandia National Laboratories) John

Stuppi (Cisco) Jorge Orchilles (Citi)
Karen Scarfone (Scarfone Ciberseguridad) Luca Allodi

(Universidad Tecnológica de Eindhoven)
Masato Terada (Agencia de Promoción de la Información-Tecnología, Japón) Max Heitman
(Citi)
Melinda Rosario (SecureWorks) Nazira
Carlage (Dell) Rani Kejat (Radiflow)
Renchie Abraham (SAP)
Sasha Romanosky (Carnegie Mellon University) de Scott

Moore (IBM) Troy Fridley (Cisco)
Vijayamurugan Pushpanathan (Schneider Electric) Wagner

Santos (UFCG)
En primer lugar sería también agradecer a Abigail Palacios y Vivian Smith de Conrad Inc. por su trabajo incansable facilitar las
reuniones CVSS SIG.

TLP: BLANCO
Apéndice C - Recursos en línea

página principal CVSS - https://www.first.org/cvss/
La página web principal para todos los recursos CVSS, incluyendo la versión más reciente del estándar CVSS.
Documento con especificaciones - https://www.first.org/cvss/specification-document
La última revisión de este documento, la definición de la cadena métricas, fórmulas, escala de valoración cualitativa y vectorial.
Guía del usuario - https://www.first.org/cvss/user-guide
Un compañero de la Especificación, la Guía del usuario incluye, además, la discusión de la norma CVSS incluyendo casos particulares de uso,
directrices sobre la puntuación, rúbricas de puntuación, y un glosario de los términos utilizados en los documentos de especificación y guía del
usuario.
Ejemplos de documentos - https://www.first.org/cvss/examples
Incluye decenas de vulnerabilidades públicas y explicaciones de por qué se eligieron determinados valores métricos.
Calculadora - https://www.first.org/cvss/calculator/3.1
Una implementación de referencia de la norma CVSS que se puede utilizar para las puntuaciones de generación. El código subyacente se
documenta y se puede utilizar como parte de otras implementaciones.
JSON y esquemas XML - https://www.first.org/cvss/data-representations
representaciones de datos para las métricas CVSS, partituras y cuerdas de vectores en JSON de esquemas y representaciones de
definición de esquemas XML (XSD). Éstos se pueden utilizar para almacenar y transferir información CVSS en formatos JSON y XML
definidos.


Cvss v31 Specification R1.en - Es

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cvss v31 Specification R1.en - Es

Încărcat de

Drepturi de autor:

Formate disponibile

TLP: BLANCO

Common Vulnerability Scoring System versión 3.1

Documento con especificaciones

La mayor cantidad de recursos CVSS actuales se pueden encontrar en https://www.first.org/cvss/

1.1. Métricas ................................................. .................................................. .................................. 3

2. Métricas Base .............................................. .................................................. ................................... 6

2.1. Las métricas de explotabilidad ................................................ .................................................. .............. 6

2.1.1. Vector de ataque (AV) ............................................. .................................................. .............. 6

2.1.2. Ataque Complejidad (AC) ............................................. .................................................. ...... 8

2.1.3. Privilegios necesarios (PR) ............................................. .................................................. .... 9

2.2. Alcance (S) .............................................. .................................................. ............................... 10

2.3.1. Confidencialidad (C) .............................................. .................................................. ............ 11

2.3.2. Integridad (I) .............................................. .................................................. ....................... 12

3. Las métricas temporales .............................................. .................................................. .......................... 13

3.1. El código de explotación de vencimiento (E) ............................................ .................................................. ......... 14

3.2. Remediación Nivel (RL) ............................................. .................................................. .......... 15

4.1. Requisitos de seguridad (CR, IR, AR) ......................................... ............................................. dieciséis

4.2. Modificados Métricas Base ............................................... .................................................. ........... 18

5. cualitativo de gravedad Escala ............................................ .................................................. ... 19

7. Ecuaciones CVSS v3.1 ........................................... .................................................. ...................... 21

7.2. Las métricas temporal Ecuaciones ............................................... .................................................. 22 ..

7.3. Metrics ambientales Ecuaciones ............................................... ........................................... 22

7.5. Una palabra de CVSS v3.1 Ecuaciones y alcanzaron el ........................................ ............................... 24

Apéndice A - Floating Point Redondeo ............................................ .................................................. 26

CVSS v3.1 especificación de documento - Revisión 1

Figura 1: CVSS Metric Grupos

CVSS v3.1 especificación de documento - Revisión 1

que van desde 0,0 hasta 10,0 como se ilustra en la Figura 2.

Figura 2: CVSS métricas y Ecuaciones

CVSS v3.1 especificación de documento - Revisión 1

2.1. Las métricas de explotabilidad

2.1.1. Vector de ataque (AV)

CVSS v3.1 especificación de documento - Revisión 1

Tabla 1: Vector de ataque

Valor métrica Descripción

2.1.2. Ataque Complejidad (AC)

1 Ver https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html para una descripción de la obra mala limpieza.

CVSS v3.1 especificación de documento - Revisión 1

Tabla 2: Ataque Complejidad

Valor métrica Descripción

2.1.3. Privilegios necesarios (PR)

con el fin de explotar la vulnerabilidad.

CVSS v3.1 especificación de documento - Revisión 1

Tabla 3: privilegios necesarios

Valor métrica Descripción

2.1.4. Interacción de Usuario (UI)

Tabla 4: Interacción de Usuario

Valor métrica Descripción

2.2. Alcance (S)

CVSS v3.1 especificación de documento - Revisión 1

Valor métrica Descripción

2.3. Métricas de impacto

CVSS v3.1 especificación de documento - Revisión 1

2.3.1. Confidencialidad (C)

Valor métrica Descripción

Ninguno (N) No hay pérdida de confidencialidad dentro del componente afectado.

2.3.2. Integridad (I)

Valor métrica Descripción

Ninguno (N) No hay pérdida de la integridad dentro del componente afectado.

2.3.3. Disponibilidad (D)

CVSS v3.1 especificación de documento - Revisión 1

Valor métrica Descripción

Ninguno (N) No hay impacto a disponibilidad en el componente afectado.