Articulo de referencia

Sistema común de puntuación de vulnerabilidades

El Sistema de puntuación de vulnerabilidades comunes ( CVSS ) es un estándar técnico para evaluar la gravedad de las vulnerabilidades en los sistemas informáticos. Las puntuacio...

El Sistema de puntuación de vulnerabilidades comunes ( CVSS ) es un estándar técnico para evaluar la gravedad de las vulnerabilidades en los sistemas informáticos. Las puntuaciones se calculan en función de una fórmula con varias métricas que aproximan la facilidad y el impacto de una vulnerabilidad. Las puntuaciones van de 0 a 10, siendo 10 la más grave. Si bien muchos utilizan solo la puntuación base del CVSS para determinar la gravedad, también existen puntuaciones temporales y ambientales para tener en cuenta la disponibilidad de mitigaciones y la extensión de los sistemas vulnerables dentro de una organización, respectivamente.

La versión actual de CVSS (CVSSv4.0) se lanzó en noviembre de 2023. [1]

CVSS no está pensado para utilizarse como método de priorización de la gestión de parches , pero se utiliza como tal independientemente de ello. [2]

Historia

Las investigaciones realizadas por el Consejo Asesor de Infraestructura Nacional (NIAC) en 2003/2004 condujeron al lanzamiento de la versión 1 de CVSS (CVSSv1) en febrero de 2005, [3] con el objetivo de que estuviera "diseñada para proporcionar clasificaciones de gravedad abiertas y universalmente estándar de las vulnerabilidades del software". Este borrador inicial no había sido sometido a revisión por pares ni a revisión por parte de otras organizaciones. En abril de 2005, el NIAC seleccionó al Foro de Equipos de Seguridad y Respuesta a Incidentes ( FIRST ) para que se convirtiera en el custodio de CVSS para el desarrollo futuro. [4] [5]

Los comentarios de los vendedores que utilizan CVSSv1 en producción sugirieron que había "problemas importantes con el borrador inicial de CVSS". El trabajo en la versión 2 de CVSS (CVSSv2) comenzó en abril de 2005 y la especificación final se lanzó en junio de 2007. [6]

Los comentarios posteriores dieron como resultado que se comenzara a trabajar en la versión 3 de CVSS [7] en 2012, y que finalizara con el lanzamiento de CVSSv3.0 en junio de 2015. [8] [3]

Terminología

La evaluación CVSS mide tres áreas de preocupación:

  1. métricas base para cualidades intrínsecas a una vulnerabilidad,
  2. métricas temporales para características que evolucionan a lo largo de la vida de la vulnerabilidad, y
  3. Métricas ambientales para vulnerabilidades que dependen de una implementación o entorno particular.

Se genera una puntuación numérica para cada uno de estos grupos de métricas. Una cadena vectorial (o simplemente "vector" en CVSSv2) representa los valores de todas las métricas como un bloque de texto.

Versión 2

La documentación completa de CVSSv2 está disponible en FIRST. [9] A continuación se proporciona un resumen.

Métricas base

Vector de acceso

El vector de acceso (AV) muestra cómo se puede explotar una vulnerabilidad.

Complejidad de acceso

La métrica de complejidad de acceso (AC) describe qué tan fácil o difícil es explotar la vulnerabilidad descubierta.

Autenticación

La métrica de autenticación (Au) describe la cantidad de veces que un atacante debe autenticarse en un objetivo para explotarlo. No incluye (por ejemplo) la autenticación en una red para obtener acceso. En el caso de vulnerabilidades explotables localmente, este valor solo debe establecerse en Única o Múltiple si se requiere una autenticación adicional después del acceso inicial.

Métricas de impacto

Confidencialidad

La métrica de confidencialidad (C) describe el impacto en la confidencialidad de los datos procesados ​​por el sistema.

Integridad

La métrica Integridad (I) describe el impacto en la integridad del sistema explotado.

Disponibilidad

La métrica de disponibilidad (A) describe el impacto en la disponibilidad del sistema de destino. Los ataques que consumen ancho de banda de red, ciclos de procesador, memoria o cualquier otro recurso afectan la disponibilidad de un sistema.

Cálculos

Estas seis métricas se utilizan para calcular los subíndices de explotabilidad e impacto de la vulnerabilidad. Estos subíndices se utilizan para calcular el puntaje base general.

Explotabilidad = 20 × AccesoVector × Complejidad de acceso × Autenticación {\displaystyle {\textsf {Explotabilidad}}=20\times {\textsf {Vector de acceso}}\times {\textsf {Complejidad de acceso}}\times {\textsf {Autenticación}}}

Impacto = 10.41 × ( 1 ( 1 ConfImpacto ) × ( 1 Impacto integral ) × ( 1 Impacto disponible ) ) {\displaystyle {\textsf {Impacto}}=10,41\veces (1-(1-{\textsf {ImpactoConf}})\veces (1-{\textsf {ImpactoInteg}})\veces (1-{\textsf {ImpactoDisponibilidad}}))}

F ( Impacto ) = { 0 , si  Impacto  = 0 1.176 , de lo contrario  {\displaystyle f({\textsf {Impacto}})={\begin{cases}0,&{\text{si }}{\textsf {Impacto}}{\text{ = 0}}\\1.176,&{\text{en caso contrario }}\end{cases}}}

Puntuación base = redondear a 1 decimal ( ( ( 0.6 × Impacto ) + ( 0,4 × Explotabilidad ) 1.5 ) × F ( Impacto ) ) {\displaystyle {\textsf {BaseScore}}={\textsf {roundTo1Decimal}}(((0,6\times {\textsf {Impacto}})+(0,4\times {\textsf {Explotabilidad}})-1,5)\times f({\textsf {Impacto}}))}

Las métricas se concatenan para producir el vector CVSS para la vulnerabilidad.

Ejemplo

Una vulnerabilidad de desbordamiento de búfer afecta al software del servidor web que permite a un usuario remoto obtener control parcial del sistema, incluida la capacidad de provocar su apagado:

Esto daría una puntuación parcial de explotabilidad de 10 y una puntuación parcial de impacto de 8,5, lo que daría una puntuación base general de 9,0. El vector de la puntuación base en este caso sería AV:N/AC:L/Au:N/C:P/I:P/A:C. La puntuación y el vector normalmente se presentan juntos para permitir que el destinatario comprenda completamente la naturaleza de la vulnerabilidad y calcule su propia puntuación ambiental si es necesario.

Métricas temporales

El valor de las métricas temporales cambia a lo largo de la vida de la vulnerabilidad, a medida que se desarrollan, divulgan y automatizan exploits y se ponen a disposición mitigaciones y soluciones.

Explotabilidad

La métrica de explotabilidad (E) describe el estado actual de las técnicas de explotación o el código de explotación automatizado.

Nivel de remediación

El nivel de remediación (RL) de una vulnerabilidad permite que la puntuación temporal de una vulnerabilidad disminuya a medida que se encuentran disponibles mitigaciones y soluciones oficiales.

Informe de confianza

El informe de confianza (RC) de una vulnerabilidad mide el nivel de confianza en la existencia de la vulnerabilidad y también la credibilidad de los detalles técnicos de la vulnerabilidad.

Cálculos

Estas tres métricas se utilizan junto con la puntuación base que ya se ha calculado para producir la puntuación temporal de la vulnerabilidad con su vector asociado.

La fórmula utilizada para calcular la puntuación temporal es:

Puntuación temporal = redondear a 1 decimal ( Puntuación base × Explotabilidad × Nivel de remediación × Informe de confianza ) {\displaystyle {\textsf {Puntuación temporal}}={\textsf {redondeado a 1 decimal}}({\textsf {Puntuación base}}\times {\textsf {Explotabilidad}}\times {\textsf {Nivel de remediación}}\times {\textsf {Confianza del informe}})}

Ejemplo

Para continuar con el ejemplo anterior, si el proveedor fue informado por primera vez sobre la vulnerabilidad mediante una publicación de código de prueba de concepto en una lista de correo, la puntuación temporal inicial se calcularía utilizando los valores que se muestran a continuación:

Esto daría una puntuación temporal de 7,3, con un vector temporal de E:P/RL:U/RC:UC (o un vector completo de AV:N/AC:L/Au:N/C:P/I:P/A:C/E:P/RL:U/RC:UC).

Si el proveedor luego confirma la vulnerabilidad, la puntuación aumenta a 8,1, con un vector temporal de E:P/RL:U/RC:C.

Una solución temporal del proveedor reduciría la puntuación a 7,3 (E:P/RL:T/RC:C), mientras que una solución oficial la reduciría aún más a 7,0 (E:P/RL:O/RC:C). Como no es posible estar seguro de que se haya reparado o parcheado cada sistema afectado, la puntuación temporal no puede reducirse por debajo de un cierto nivel en función de las acciones del proveedor, y puede aumentar si se desarrolla un exploit automatizado para la vulnerabilidad.

Métricas ambientales

Las métricas ambientales utilizan la puntuación temporal base y actual para evaluar la gravedad de una vulnerabilidad en el contexto de la forma en que se implementa el producto o software vulnerable. Esta medida se calcula de forma subjetiva, generalmente por las partes afectadas.

Potencial de daños colaterales

La métrica del potencial de daño colateral (CDP) mide la pérdida o el impacto potencial sobre activos físicos, como equipos (y vidas), o el impacto financiero sobre la organización afectada si se explota la vulnerabilidad.

Distribución de objetivos

La métrica de distribución de objetivos (TD) mide la proporción de sistemas vulnerables en el entorno.

Modificador de subpuntuación de impacto

Tres métricas adicionales evalúan los requisitos de seguridad específicos de confidencialidad (CR), integridad (IR) y disponibilidad (AR), lo que permite ajustar la puntuación ambiental según el entorno de los usuarios.

Cálculos

Las cinco métricas ambientales se utilizan junto con las métricas base y temporales evaluadas previamente para calcular la puntuación ambiental y producir el vector ambiental asociado.

Impacto ajustado = mín. ( 10 , 10.41 × ( 1 ( 1 ConfImpacto × ConfReq ) × ( 1 Impacto integral × Requerimiento de integración ) × ( 1 Impacto disponible × Solicitud de disponibilidad ) ) ) {\displaystyle {\textsf {ImpactoAjustado}}=\min(10,10.41\times (1-(1-{\textsf {ImpactoConf}}\times {\textsf {ReqConf}})\times (1-{\textsf {ImpactoInteg}}\times {\textsf {ReqInteg}})\times (1-{\textsf {ImpactoDisponibilidad}}\times {\textsf {ReqDisponibilidad}})))}

Temporal ajustado = Puntuación temporal  recalculado con el  Puntuación base Impacto  subecuación reemplazada por la  Impacto ajustado  ecuación {\displaystyle {\textsf {AdjustedTemporal}}={\textsf {TemporalScore}}{\text{ recalculado con la }}{\textsf {BaseScore}}{\text{s }}{\textsf {Impact}}{\text{ subecuación reemplazada con la }}{\textsf {AdjustedImpact}}{\text{ ecuación}}}

Puntuación ambiental = redondear a 1 decimal ( ( Temporal ajustado + ( 10 Temporal ajustado ) × Potencial de daño colateral ) × Distribución de objetivos ) {\displaystyle {\textsf {Puntuación ambiental}}={\textsf {redondeado a 1 decimal}}(({\textsf {Temporal ajustado}}+(10-{\textsf {Temporal ajustado}})\times {\textsf {Potencial de daño colateral}})\times {\textsf {Distribución objetivo}})}

Ejemplo

Si un banco utilizara el servidor web vulnerable mencionado anteriormente para proporcionar servicios bancarios en línea y el proveedor pudiera ofrecer una solución temporal, entonces la puntuación ambiental podría evaluarse de la siguiente manera:

Esto daría una puntuación ambiental de 8,2 y un vector ambiental de CDP:MH/TD:H/CR:H/IR:H/AR:L. Esta puntuación se encuentra dentro del rango de 7,0 a 10,0 y, por lo tanto, constituye una vulnerabilidad crítica en el contexto del negocio del banco afectado.

Crítica de la versión 2

Varios proveedores y organizaciones expresaron su insatisfacción con CVSSv2.

Risk Based Security, que gestiona la base de datos de vulnerabilidades de código abierto , y la Open Security Foundation publicaron conjuntamente una carta pública a FIRST en relación con las deficiencias y los fallos de CVSSv2. [10] Los autores citaron una falta de granularidad en varias métricas, lo que da como resultado vectores y puntuaciones CVSS que no distinguen adecuadamente las vulnerabilidades de diferentes tipos y perfiles de riesgo. También se observó que el sistema de puntuación CVSS requiere demasiado conocimiento del impacto exacto de la vulnerabilidad.

Oracle introdujo el nuevo valor métrico "Partial+" para Confidencialidad, Integridad y Disponibilidad, para llenar los vacíos percibidos en la descripción entre Parcial y Completo en las especificaciones oficiales CVSS. [11]

Versión 3

Para abordar algunas de estas críticas, en 2012 se inició el desarrollo de la versión 3 de CVSS. La especificación final se denominó CVSSv3.0 y se publicó en junio de 2015. Además de un documento de especificación, también se publicaron una guía del usuario y un documento de ejemplos. [12]

Se modificaron, agregaron y eliminaron varias métricas. Las fórmulas numéricas se actualizaron para incorporar las nuevas métricas, pero conservando el rango de puntuación existente de 0 a 10. Se definieron clasificaciones de gravedad textuales de Ninguna (0), Baja (0,1-3,9), Media (4,0-6,9), Alta (7,0-8,9) y Crítica (9,0-10,0) [13] , similares a las categorías NVD definidas para CVSSv2 que no formaban parte de ese estándar. [14]

Cambios respecto a la versión 2

Métricas base

En el vector base, se agregaron las nuevas métricas Interacción del usuario (UI) y Privilegios requeridos (PR) para ayudar a distinguir las vulnerabilidades que requerían interacción del usuario o privilegios de usuario o administrador para ser explotadas. Anteriormente, estos conceptos eran parte de la métrica del vector de acceso de CVSSv2. La UI puede tomar los valores Ninguno o Requerido; los ataques que no requieren iniciar sesión como usuario se consideran más graves. La PR puede tomar los valores Ninguno, Bajo o Alto; de manera similar, los ataques que requieren menos privilegios son más graves.

El vector Base también vio la introducción de la nueva métrica Scope (S), que fue diseñada para aclarar qué vulnerabilidades pueden ser explotadas y luego utilizadas para atacar otras partes de un sistema o red. Estas nuevas métricas permiten que el vector Base exprese más claramente el tipo de vulnerabilidad que se está evaluando.

Las métricas de Confidencialidad, Integridad y Disponibilidad (C, I, A) se actualizaron para tener puntuaciones que consisten en Ninguna, Baja o Alta, en lugar de Ninguna, Parcial y Completa de CVSSv2. Esto permite una mayor flexibilidad para determinar el impacto de una vulnerabilidad en las métricas de CIA.

La complejidad de acceso pasó a llamarse complejidad de ataque (AC) para dejar en claro que los privilegios de acceso se trasladaron a una métrica independiente. Esta métrica ahora describe cuán repetible puede ser la explotación de esta vulnerabilidad; la AC es alta si el atacante requiere una sincronización perfecta u otras circunstancias (aparte de la interacción del usuario, que también es una métrica independiente) que pueden no duplicarse fácilmente en intentos futuros.

Attack Vector (AV) vio la inclusión de un nuevo valor métrico de Físico (P), para describir vulnerabilidades que requieren acceso físico al dispositivo o sistema para funcionar.

Métricas temporales

Las métricas temporales se mantuvieron esencialmente sin cambios respecto a CVSSv2.

Métricas ambientales

Las métricas ambientales de CVSSv2 se eliminaron por completo y se reemplazaron con una segunda puntuación base, conocida como el vector modificado. La base modificada tiene como objetivo reflejar las diferencias dentro de una organización o empresa en comparación con el mundo en su conjunto. Se agregaron nuevas métricas para capturar la importancia de la confidencialidad, la integridad y la disponibilidad para un entorno específico.

Crítica de la versión 3

En una publicación de blog de septiembre de 2015, el Centro de Coordinación CERT analizó las limitaciones de CVSSv2 y CVSSv3.0 para su uso en la puntuación de vulnerabilidades en sistemas de tecnología emergentes como la Internet de las cosas. [15]

Versión 3.1

El 17 de junio de 2019 se publicó una actualización menor de CVSS. El objetivo de CVSSv3.1 era aclarar y mejorar el estándar CVSSv3.0 existente sin introducir nuevas métricas ni valores de métricas, lo que permitía una adopción sin problemas del nuevo estándar tanto por parte de los proveedores de puntuación como de los consumidores de puntuación. La usabilidad fue una consideración primordial al realizar mejoras en el estándar CVSS. Varios de los cambios que se están realizando en CVSSv3.1 tienen como objetivo mejorar la claridad de los conceptos introducidos en CVSSv3.0 y, por lo tanto, mejorar la facilidad de uso general del estándar.

FIRST ha utilizado los aportes de expertos en la materia de la industria para seguir mejorando y refinando el CVSS para que sea cada vez más aplicable a las vulnerabilidades, productos y plataformas que se han desarrollado durante los últimos 15 años y más. El objetivo principal del CVSS es proporcionar una forma determinista y repetible de puntuar la gravedad de una vulnerabilidad en muchos grupos de personas diferentes, lo que permite a los consumidores del CVSS utilizar esta puntuación como entrada para una matriz de decisiones más amplia de riesgo, remediación y mitigación específica para su entorno particular y tolerancia al riesgo.

Las actualizaciones de la especificación CVSSv3.1 incluyen la aclaración de las definiciones y la explicación de las métricas base existentes, como el vector de ataque, los privilegios requeridos, el alcance y los requisitos de seguridad. También se definió un nuevo método estándar para ampliar CVSS, denominado Marco de extensiones CVSS, que permite a un proveedor de puntuación incluir métricas y grupos de métricas adicionales, manteniendo las métricas base, temporales y ambientales oficiales. Las métricas adicionales permiten que sectores industriales como la privacidad, la seguridad, la automoción, la atención sanitaria, etc., puntúen factores que están fuera del estándar CVSS básico. Por último, se ha ampliado y perfeccionado el Glosario de términos CVSS para que abarque todos los términos utilizados en la documentación CVSSv3.1.

Versión 4.0

La versión 4.0 se lanzó oficialmente en noviembre de 2023 [1] y está disponible en FIRST. [16] Entre varias aclaraciones, los cambios más notables son la nueva métrica base Requisitos de ataque que complementa la métrica Complejidad del ataque con una evaluación de qué condiciones del lado objetivo son necesarias para explotar una vulnerabilidad. Además, las métricas de impacto se dividen en impacto en el sistema vulnerable en sí e impacto en sistemas posteriores (esto reemplaza la métrica Alcance de las versiones anteriores).

Las métricas base ahora son las siguientes.

  • Vector de ataque (AV): ¿De qué manera (física) se puede explotar una vulnerabilidad? [N] red , [A] adyacente (es decir, limitada a conexiones directas), [I] interacción (por ejemplo, a través de SSH o teclado) o [P] física (por ejemplo, manipular u observar hardware).
  • Complejidad del ataque (AC): ¿Existen otras contramedidas que el atacante debe eludir y qué tan difícil es hacerlo? [ L] baja o [H] alta (por ejemplo, prevención de ejecución de datos).
  • Requisitos de ataque (AT): ¿Existen condiciones necesarias para un ataque sobre las que el atacante no pueda influir? [N] ninguna , o [P] presente (por ejemplo, se debe ganar una condición de carrera o el sistema está en un estado específico).
  • Privilegios requeridos (PR): ¿Es necesario tener algún privilegio en el sistema de destino? [N] ninguno (no autenticado) , [L] bajo (usuario normal) o [H] alto (acceso administrativo).
  • Interacción del usuario (UI): ¿El usuario (legítimo) del sistema necesita hacer algo para que el ataque sea posible? [N] ninguno , [P] pasivo (por ejemplo, visitar accidentalmente un sitio web malicioso) o [A] activo (por ejemplo, ejecutar una macro de Office maliciosa).
  • Impacto de confidencialidad del sistema vulnerable (VC): [N] ninguno , [L] bajo o [H] alto .
  • Impacto en la integridad del sistema vulnerable (VI): [N] ninguno , [L] bajo o [H] alto .
  • Impacto en la disponibilidad del sistema vulnerable (VA): [N] ninguno , [L] bajo o [H] alto .
  • Impacto posterior en la confidencialidad del sistema (SC): [N] ninguno , [L] bajo o [H] alto .
  • Impacto posterior en la integridad del sistema (SI): [N] ninguno , [L] bajo o [H] alto .
  • Impacto posterior en la disponibilidad del sistema (SA): [N] ninguno , [L] bajo o [H] alto .

Además de estas métricas básicas, existen métricas opcionales relacionadas con la disponibilidad pública de un exploit, el modelado de subprocesos específicos del entorno, la recuperación del sistema y otras.

Ejemplo

Supongamos que hay una inyección SQL en una tienda web en línea. El usuario de la base de datos del software de la tienda en línea solo tiene acceso de lectura a la base de datos. Además, la inyección se realiza en una vista de la tienda que solo es visible para los clientes registrados. El vector base CVSS 4.0 es el siguiente.

  • AV:N ya que la vulnerabilidad puede activarse a través de la web
  • AC:L como inyecciones SQL se puede explotar de forma fiable mediante scripts (asumiendo que la tienda online no tiene contramedidas).
  • AT:N ya que el ataque no depende de condiciones específicas del sistema
  • PR:L como los atacantes necesitan estar autenticados como usuarios normales, pero no se necesitan derechos administrativos
  • UI:N ya que no hay otros usuarios involucrados
  • VC:H ya que los atacantes pueden leer todas las tablas de la base de datos
  • VI:N ya que los atacantes no tienen acceso de escritura
  • VA:L ya que los atacantes podrían ejecutar consultas largas en la base de datos que temporalmente hacen que la base de datos sea más lenta o no responda.
  • SC:N (no tenemos más información sobre sistemas posteriores)
  • SI:N (no tenemos más información sobre sistemas posteriores)
  • SA:L podemos esperar que otros sistemas involucrados en la gestión de pedidos y logística se vean afectados por una base de datos que no responde.

Esto da como resultado el vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:L

Adopción

Una amplia gama de organizaciones y empresas han adoptado versiones de CVSS como el método principal para cuantificar la gravedad de las vulnerabilidades, entre las que se incluyen:

Véase también

Referencias

  1. ^ ab "FIRST ha publicado oficialmente la última versión del Common Vulnerability Scoring System (CVSS v4.0)". FIRST. Archivado desde el original el 1 de noviembre de 2023.
  2. ^ Spring, JM; Hatleback, E.; Manion, A.; Shick, D. (diciembre de 2018). "Hacia la mejora del CVSS" (PDF) . Informes técnicos de la Universidad Carnegie Mellon .
  3. ^ ab Johnson, Pontus; Lagerstrom, Robert; Ekstedt, Mathias; Franke, Ulrik (1 de noviembre de 2018). "¿Se puede confiar en el sistema común de puntuación de vulnerabilidades? Un análisis bayesiano". IEEE Transactions on Dependable and Secure Computing . 15 (6): 1002– 1015. doi :10.1109/TDSC.2016.2644614. ISSN  1545-5971. S2CID  53287880.
  4. ^ "Archivo CVSS v1". First.org, Inc. Consultado el 15 de noviembre de 2015 .
  5. ^ "CONSEJO ASESOR NACIONAL DE INFRAESTRUCTURA / ORDEN DEL DÍA DE LA REUNIÓN / Martes 12 de abril de 2005 / 13:30 a 16:30 horas / Club Nacional de Prensa / Washington, DC" (PDF) . Agencia de Seguridad de Infraestructura y Ciberseguridad . 2005-04-12 . Consultado el 2022-07-18 . Tanto MITRE como CERT/CC aportan un valor distinto pero importante. Con base en esas propuestas, el Grupo de Trabajo sugiere firmemente que estas organizaciones trabajen bajo el paraguas proporcionado por Global FIRST para el CVSS.
  6. ^ "Historial de CVSS v2". First.org, Inc. Consultado el 15 de noviembre de 2015 .
  7. ^ "Anuncio del grupo de interés especial de CVSS para el desarrollo de CVSS v3". First.org, Inc. Archivado desde el original el 17 de febrero de 2013 . Consultado el 2 de marzo de 2013 .
  8. ^ "Sistema de puntuación de vulnerabilidades comunes, actualización de desarrollo V3". First.org, Inc. Consultado el 13 de noviembre de 2015 .
  9. ^ "Documentación completa de CVSS v2". First.org, Inc. Consultado el 15 de noviembre de 2015 .
  10. ^ "CVSS - Deficiencias, fallos y fallas" (PDF) . Seguridad basada en riesgos. 2013-02-27. Archivado desde el original (PDF) el 2022-03-11 . Consultado el 2015-11-15 .
  11. ^ "Sistema de puntuación CVSS". Oracle. 2010-06-01 . Consultado el 2015-11-15 .
  12. ^ "Documento de especificación CVSS v3.0". FIRST, Inc. Recuperado el 15 de noviembre de 2015 .
  13. ^ "Sistema de puntuación de vulnerabilidades comunes v3.0: Documento de especificaciones (escala de clasificación de gravedad cualitativa)". First.org . Consultado el 10 de enero de 2016 .
  14. ^ "NVD Common Vulnerability Scoring System Support v2" (Soporte del sistema de puntuación de vulnerabilidades comunes NVD v2). Base de datos de vulnerabilidades nacional . Instituto Nacional de Estándares y Tecnología . Consultado el 2 de marzo de 2013 .
  15. ^ "CVSS y la Internet de las cosas". Centro de coordinación CERT. 2015-09-02 . Consultado el 2015-11-15 .
  16. ^ "Guía del usuario de CVSS v4.0". FIRST — Foro de equipos de seguridad y respuesta a incidentes . Consultado el 5 de octubre de 2024 .
  17. ^ "Página de inicio de la base de datos de vulnerabilidades nacionales". Nvd.nist.gov . Consultado el 16 de abril de 2013 .
  18. ^ "Base de datos de vulnerabilidades de código abierto". OSVDB . Consultado el 16 de abril de 2013 .
  19. ^ "Gravedad de vulnerabilidades mediante CVSS". Centro de coordinación CERT. 2012-04-12 . Consultado el 2015-11-15 .
  • Sitio CVSS del Foro de Equipos de Respuesta a Incidentes y Seguridad (FIRST)
  • Sitio CVSS de la Base de datos nacional de vulnerabilidades (NVD)
  • Calculadora del sistema de puntuación de vulnerabilidades comunes v2
Retrieved from "https://en.wikipedia.org/w/index.php?title=Common_Vulnerability_Scoring_System&oldid=1258756686"