Ocho siglas relacionadas con las vulnerabilidades (III): CVSS

miércoles, 23 de abril de 2014

Uno de los factores críticos sobre el que gira el mundo de la seguridad es el estudio y control de vulnerabilidades. Para conseguirlo de manera objetiva, existen organizaciones como MITRE, FIRST e ICASI, encargadas de parametrizar y estandarizar. Veremos qué estándares utilizan y cómo aprovecharlos para entender mejor los problemas de seguridad. Si en la entrada anterior se cubrieron los CVE, CWA y CAPE, en esta se verá el CVSS.

¿Quién y cómo se valora la gravedad de una vulnerabilidad? ¿Qué es exactamente un riesgo "alto" o una "vulnerabilidad crítica"? ¿Es cierto que según quien describa el fallo, la gravedad parecerá más o menos grave? Resulta complejo valorar el peligro de forma objetiva. Por ejemplo, el fabricante siempre tenderá a hacer hincapié en la mitigación o restarle importancia al problema en su boletín de seguridad. Otros medios, clamarán que se trata de un fallo muy grave en función del titular que necesiten. Y los usuarios verán que arbitrariamente unas vulnerabilidades son "altas" y otras "medias"... pero no saben a qué atenerse. Para solucionar esto nació CVSS (Common Vulnerability Scoring System), un sistema de valoración de vulnerabilidades creado como un método estándar para determinar y clasificar la criticidad de las vulnerabilidades.

Este estándar pertenece a FIRST. Es una confederación internacional de equipos de respuesta a incidentes informáticos que gestionan problemas de seguridad y promueven programas de prevención. FIRST patrocina y apoya el CVSS-SIG, que a su vez es un grupo de profesionales de la seguridad cuyo enfoque se centra en las vulnerabilidades de seguridad y utilizan CVSS como fundamento de su trabajo diario. Este grupo se encarga de actualizar y promover el uso del CVSS y de proporcionar un repositorio central para la documentación de este sistema de valoración.

Para conseguir ser lo más objetivo posible, CVSS se encarga de estudiar las diversas propiedades de una vulnerabilidad y las agrupa en tres métricas diferentes. En la actualidad y desde 2007, se utiliza la segunda versión de este sistema (CVSSv2), aunque en mayo de 2012 ya fuese aprobado el desarrollo de una nueva versión, que se espera en breve. Las tres métricas que arroja este sistema de valoración se denominan Base, Temporal y Métricas dependientes del entorno (enviromental metrics). Se encargan de estudiar la criticidad de las vulnerabilidades desde distintos puntos de vista.

Base Metrics

La única que es común a cualquier vulnerabilidad. Siempre se puede calcular para una vulnerabilidad y así valorarla. Su resultado es común para cualquier caso en donde se presente esta vulnerabilidad.

Métricas de base. Fuente: http://www.first.org/cvss/cvss-guide

A su vez, el primer factor necesario para calcular esta métrica es el que viene asociado al impacto, definido por cómo afecta la vulnerabilidad al activo en cuanto a la confidencialidad, integridad y disponibilidad se refiere, entendiéndose por cada uno de ellos lo siguiente:
  • Confidentiality Impact: Nivel de afectación que pudiera sufrir el activo relacionado a la limitación de acceso a la información y a la comunicación para usuarios autorizados. Cuando la vulnerabilidad permite que se revele información sensible (tradicionalmente del tipo disclosure), este valor aumenta.
  • Integrity Impact: Nivel de afectación que pudiera sufrir el activo relacionado a la fiabilidad y a la veracidad de la información. Cuando la vulnerabilidad permite corromper información sensible o modificarla, este valor aumenta.
  • Availability Impact: Nivel de afectación que pudiera sufrir el activo relacionado a la accesibilidad de los recursos de la información. Si la vulnerabilidad permite agotar los recursos o reiniciar un servicio (cualquier tipo de DoS), este valor aumenta.
Los valores que pueden tomar son "bajo", "medio" y "alto" para cada uno de ellos. El segundo de los factores es el de la explotabilidad, que viene definido por el vector de acceso, la complejidad del proceso y la autenticación necesaria para llevar a cabo un ataque que aproveche la vulnerabilidad, entendiéndose por cada una estos factores lo siguiente:
  • Access Vector: este factor proporciona información sobre la ubicación del atacante en el instante de llevar a cabo la explotación de la vulnerabilidad. Normalmente, será remoto o local.
  • Access Complexity: este factor hace referencia a la complejidad del ataque del proceso que lleva a cabo el atacante para explotar la vulnerabilidad. Quizás el valor más subjetivo, valora la complejidad de que se acceda a los sistemas vulnerables.
  • Authentication: este factor suministra información relacionada al número de veces que un atacante debe autenticarse en un objetivo antes de poder explotar una vulnerabilidad. Por ejemplo, explotar la vulnerabilidad puede requerir que el usuario esté autenticado (elevación de privilegios, por ejemplo) o no (acceso anónimo por la web).
Temporal Metrics 

Una vulnerabilidad puede considerarse igual de grave si existe parche o si no, si está siendo explotada por atacantes o si se ha revelado de forma responsable... incluso, durante las primeras horas desde que se conoce la vulnerabilidad, el nivel de confirmación "oficial" es relevante para valorarla. Existen factores que pueden cambiar con el tiempo.

Métricas temporales. Fuente: http://www.first.org/cvss/cvss-guide


 Dentro de los factores para valorar la métrica temporal, se encuentran:
  • Exploitability: Este factor mide el nivel de información accesible acerca de la vulnerabilidad. Pretende valorar qué técnicas, informes, exploits funcionales están disponibles, etc.
  • Remediation Level: Este factor está relacionado con tipo de solución disponible para la vulnerabilidad que se está valorando. Puede que exista parche oficial (bajaría su gravedad), solo se conozca alguna contramedida... o no haya remedio más que no usar el producto o servicio.
  • Report Confidence: este factor establece el grado de confianza en la existencia de la vulnerabilidad y la credibilidad de los detalles técnicos conocidos y reportados sobre ella. Especialmente útil cuando se revelan vulnerabilidades en foros, sin ningún tipo de comprobación oficial sobre la veracidad o alcance de la información.

Enviroment Métric

Se encarga de estudiar las características que afectan al entorno en donde se encuentra la vulnerabilidad. Los factores de esta métrica dependen estrictamente del entorno que sufre el problema y su relación con los usuarios en él. En realidad, esta métrica resulta en un "ejercicio personal" de los afectados y sus circunstancias únicas. No existe un valor "universal" para esta métrica, como es el de la base, sino que cada administrador podrá calcular el suyo.

Métricas de entorno. Fuente: http://www.first.org/cvss/cvss-guide

  • Collateral Damage Potential: Mide el potencial de pérdidas de vidas o bienes materiales a través del daño o robo de los activos, además de la pérdida económica de la productividad o de los ingresos. ¿Cuánto daño me haría la explotación de esta vulnerabilidad?
  • Target Distribution: Mide la proporción de los sistemas vulnerables. Se encarga de expresar una aproximación del porcentaje de sistemas que podrían verse afectados por la vulnerabilidad.
  • Security Requirements: Permite personalizar el valor de la métrica de entorno dependiendo de la importancia del activo, medido en términos de confidencialidad, integridad y disponibilidad.

Cómo calcularlo

Entre las webs más conocidas que almacenan esta información se encuentran: National Vulnerability Database (NVD), Open Sourced Vulnerability Database (OSBDV), CVE Details o Qualys Security Alerts. Muchas de estas webs suelen almacenar además información general de las vulnerabilidades, incluyendo documentación, pruebas de concepto, soluciones, versiones a las que afecta, etc.

Ejemplo de CVE Details con clasificación de vulnerabilidad

Para calcular el valor CVSS de una vulnerabilidad, existen numerosas herramientas. Las disponibles vía web son, por ejemplo:
Además, los programas de análisis y catalogación de vulnerabilidades más reputados, deben usar estos estándares para ofrecer la información más completa y objetiva a sus clientes. Sin ir más lejos, FaasT utiliza estos estándares, y ofrece información adicional de cómo ha sido calculado y por qué.

Ejemplo en FaasT de vulnerabilidad con métricas estándar


* Ocho siglas relacionadas con las vulnerabilidades (I): CVE
Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC
* Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS
Umberto Francesco Schiavo
umberto.schiavo@11paths.com

1 comentario: