Publicada oficialmente la última versión del Sistema Común de Puntuación de Vulnerabilidades (CVSS v4) La versión más reciente y esperada del sistema, brinda mejoras y funcionalidades adicionales que llevarán la evaluación de vulnerabilidades a un nuevo nivel.

CVSS (Common Vulnerability Scoring System) se trata de un sistema de puntuación que proporciona un estándar abierto, el cual ha sido un pilar fundamental en la gestión de vulnerabilidades IT a nivel mundial desde su introducción en 2005. A lo largo de los años, ha experimentado diversas revisiones y actualizaciones para seguir siendo relevante y adaptarse a las cambiantes amenazas y tecnologías.

Los retos propuestos por la versión CVSS v3 y los objetivos a cumplir en esta nueva versión CVSS v4 son los siguientes:

La puntuación base de CVSS usada como entrada para el análisis de riesgo. La puntuación base del CVSS es, en efecto, un factor clave para determinar la gravedad de una vulnerabilidad. Sin embargo, no debería ser el único factor determinante, ya que solo considera los aspectos técnicos de la vulnerabilidad, sin tener en cuenta el contexto empresarial, la criticidad de los activos o el panorama de amenazas, que son igualmente importantes en un análisis de riesgos holísticos.

Solamente es pertinente para sistemas IT. CVSS se diseñó principalmente para sistemas informáticos de software y hardware. Como tal, puede no captar algunos matices específicos de los sistemas no informáticos o de las tecnologías operativas que pueden tener perfiles de riesgo y consecuencias diferentes si se ven comprometidos.

Las puntuaciones publicadas por los proveedores son normalmente altas o críticas (7.0+). Esto puede ser un problema si los vendedores exageran la gravedad de las vulnerabilidades. Sin embargo, este problema radica más en la aplicación del CVSS por parte del proveedor que en el propio sistema.

Falta de precisión – menos de 99 puntuaciones CVSS son discretas en la práctica. Aunque CVSS ofrece un sistema de puntuación basado en decimales, el uso práctico suele dar lugar a pocas puntuaciones discretas, lo que limita su nivel de detalle. Un sistema más granular podría ofrecer una mejor diferenciación entre vulnerabilidades.

Las métricas temporales no tienen un impacto real en la puntuación CVSS. Las métricas temporales en CVSS, que incluyen factores como el estado actual del exploit y el nivel de remediación, suelen tener menos peso en la puntuación final. Aunque su inclusión es importante, su impacto puede no ser tan significativo como sería deseable.

El proceso de cálculo es complicado y contradictorio. La puntuación CVSS implica complejas ecuaciones matemáticas para garantizar una representación equilibrada de diversos factores. Para los usuarios no técnicos, esta complejidad puede resultar abrumadora y parecer contradictoria. La simplificación, sin menospreciar la precisión, podría mejorar la usabilidad y la comprensión del sistema.

Además, el equipo de NIST hace autocrítica e hincapié en la complejidad y la naturaleza aparentemente arbitraria del algoritmo de puntuación CVSS. El sistema de puntuación CVSS fue desarrollado por un equipo diverso de expertos y se basa en una amplia investigación y análisis. Aunque pueda parecer confuso, es el producto de un proceso deliberado para equilibrar una variedad de factores diferentes en la puntuación de vulnerabilidades. Además, hacen énfasis en que siempre debe buscarse la mejora continua y la simplificación.

Actualmente, CVSS se compone de cuatro grupos de métricas: base, amenaza, entorno y complementario, cada uno de ellos, compuestos por una serie de métricas:

1. Grupo Base: captura las cualidades fundamentales de una vulnerabilidad que mantienen su constancia en el tiempo y en todos los contextos de usuario.

2. Grupo Amenaza: refleja las características de una vulnerabilidad que evolucionan con el transcurso del tiempo.

3. Grupo Entorno: se encarga de las características específicas de una vulnerabilidad ligadas a un usuario.

4. Grupo de Métricas Complementarias: son nuevas métricas que describen y miden atributos extrínsecos adicionales de una vulnerabilidad.

Calculadora CVSS v4

Al igual que en las métricas, la calculadora de CVSS v4 incorpora varias novedades:

Se usan grupos de métricas para incorporar 15 millones de vectores CVSS en 271 conjuntos equivalentes.
Se ha solicitado la opinión de expertos para comparar los vectores que representan cada conjunto equivalente.
Se calcula el orden de los vectores desde el menos severo al de mayor criticidad.
Se determinan los límites entre las Valoraciones de Severidad Cualitativas (Qualitative Severity Ratings) compatibles con los límites de severidad cualitativos de CVSS v3.X.
Se agrupan los vectores de severidad cualitativa dentro del número de puntuaciones disponibles en un conjunto concreto (por ejemplo, 9.0 a 10.0 para riesgo crítico, 7.0 a 8.9 para riesgo alto, etc.).
Se hace uso de la interpolación para ajustar las puntuaciones en un grupo de vectores, de manera que se aseguren los cambios en el valor de los resultados de cualquier métrica al tener lugar un cambio de puntuación.

El enlace de acceso a esta calculadora se puede encontrar aquí, pero a continuación se presentan una serie de capturas de pantalla que permiten previsualizar lo que los usuarios verán al acceder a la herramienta:

Como se puede observar en la imagen anterior, si se sitúa el cursor sobre cada uno de los valores de las métricas, será posible ver una definición de a qué hace referencia cada una de ellas, de manera que será más sencillo escoger el valor adecuado a la hora de asignar el riesgo.

Esta herramienta ayuda a entender y curiosear esta nueva versión de CVSS y permite comparar los cambios en tiempo real si usamos paralelamente la calculadora de CVSS v3 además de, permitir usar las nuevas métricas de esta nueva versión.

Cambios respecto a las versiones previas:

Fuente: INCIBE y FIRST. Ejemplo de actualización en las métricas base del CVSS 3.1 a la versión 4.0.

¿Cuáles son las novedades de CVSS v4?

A pesar de que en las siguientes secciones se detallarán cuáles son las novedades principales de CVSS v4, de manera genérica se pueden resumir en los siguientes puntos:

Mayor nivel de detalle en las métricas base.
Se eliminan aspectos que causan ambigüedad.
Se simplifican las métricas de amenazas y se mejoran las puntuaciones del nivel de impacto.
Se incorporan atributos complementarios para las respuestas ante vulnerabilidades.

CVSS v4, a diferencia de CVSS v3.X, se puede aplicar a sistemas OT/ICS/IoT.
Teniendo en cuenta estos puntos genéricos, veremos a continuación cuáles son estos cambios de manera más detallada.

1. Nomenclatura

Para subrayar la idea de que CVSS no es solo una puntuación base, se ha adoptado una nueva nomenclatura.

CVSS-B: CVSS Base Score
CVSS-BT: CVSS Base + Threat Score
CVSS-BE: CVSS Base + Environmental Score
CVSS-BTE: CVSS Base + Threat + Environmental Score

2. Nuevos conceptos: sistema vulnerable, sistema subsiguiente y sistemas protegidos por firewalls

Con CVSS 4.0 se introducen estos tres nuevos términos que es conveniente analizar con algunos ejemplos para entender correctamente en qué se diferencian.

Sistema vulnerable:

Aquella aplicación de software, controlador, módulo o dispositivo de hardware que contiene un fallo o debilidad, ya sea en su implementación, diseño, controles internos o procedimientos, los cuales pueden ser explotados por un atacante para violar la política de seguridad de dicho sistema.

Sistema subsiguiente:

Es aquel sistema que sufre las consecuencias de la vulnerabilidad explotada, pudiéndose tratar del mismo sistema vulnerable u otro, como podrían ser las aplicaciones de software, dispositivos hardware, recursos de red y la seguridad de las personas.

Sistemas protegidos por firewall:

Se refiere a sistemas vulnerables, pero protegidos por firewalls, cuando una vulnerabilidad se puntúa con un vector de ataque (AV) de red (N) y se tiene seguridad de que el sistema vulnerable está desplegado en una red segura que no está disponible desde internet, la métrica “Vector de ataque modificado” (Modified Attack Vector) (MAV, por sus siglas en inglés) se debe marcar como “Adyacente”, reduciendo así la puntuación dada por CVSS v4.0.

**3. Nueva métrica base (base metric): requisitos de ataque (attack requirements) (AT)**

El problema inicial por el que se plantea esta nueva métrica es que los valores de complejidad de ataque (CA) «baja» y «alta» no reflejan diferencias significativas entre las condiciones actualmente comprimidas en la definición de complejidad “alta”. Esta falta de precisión puede ser ejemplificada por la vulnerabilidad identificada como CVE-2021-23017, la cual requiere forjar paquetes DNS siendo necesario para lograrlo que el componente vulnerable tenga una configuración específica y, entonces, se podrá modificar un byte concreto para conseguir RCE (Ejecución Remota de Código). A pesar de esta complejidad involucrada, se clasifica de la misma manera que una vulnerabilidad más simple que solo requiere levantar un servidor («rogue server«, como por ejemplo LDAP Pass-Back u otros casos similares).

La propuesta actual de CVSS v4 pretende solucionar este problema, dividiendo la definición actual de AC en dos métricas, denominadas «Complejidad de ataque (AC)» y «Requisitos de ataque (AT)», que transmiten lo siguiente respectivamente:

Complejidad del ataque: refleja la dificultad del exploit necesario para evadir o eludir las tecnologías defensivas o las mejoras de seguridad en el software. En el ejemplo anterior, el CVE tiene una complejidad mayor debido a que el servidor NGINX requiere una configuración específica para ser vulnerable, mientras que la otra vulnerabilidad solo requiere que el atacante levante un servidor. Se clasifica en dos categorías:
- Baja (L): el ataque no precisa evadir ninguna circunstancia específica del objetivo para explotar la vulnerabilidad.
- Alta (H): el éxito del ataque se basa en la capacidad de evadir o eludir las técnicas de mejora de seguridad implementadas, las cuales, de lo contrario, obstaculizarían el ataque. Estas técnicas incluyen:
  - Evasión de técnicas de mitigación de exploits: el atacante debe tener métodos adicionales disponibles para eludir las medidas de seguridad establecidas. Por ejemplo, eludir la aleatorización del espacio de direcciones (ASLR) o la prevención de la ejecución de datos (Data Execution Prevention) debe llevarse a cabo para que el ataque tenga éxito.
  - Obtención de secretos específicos: la clave para el éxito de un ataque radica en que el atacante logre obtener información específica y secreta del objetivo. Este secreto es cualquier dato que no se pueda obtener a través de ningún tipo de reconocimiento. Para obtenerlo, el atacante debe llevar a cabo ataques adicionales o romper medidas de seguridad sólidas, como la necesidad de conocer una clave secreta para vulnerar un canal criptográfico. Este proceso debe repetirse para cada objetivo que se pretenda atacar.
  - Requisitos del ataque: reflejan las condiciones previas del componente vulnerable que hacen posible el ataque. Esta métrica se puede clasificar en:
    - Ninguna (N): el éxito de un ataque no está determinado por las condiciones específicas en las que se implementa y ejecuta un sistema vulnerable. Un atacante puede contar con la capacidad de explotar la vulnerabilidad y aprovecharla en numerosos casos (si no en todos), donde dicha vulnerabilidad esté presente.
    - Presente (P): el éxito del ataque depende de la existencia de condiciones específicas de implementación y ejecución del sistema vulnerable que permitan llevar a cabo el ataque. Estas condiciones incluyen:
      - Condición de carrera (race condition): la efectividad del ataque está condicionada por circunstancias de ejecución que no están completamente bajo el control del atacante. Puede ser necesario lanzar el ataque varias veces contra un mismo objetivo antes de lograr explotar la vulnerabilidad.
      - Inyección de red (network injection): el éxito del ataque depende de la capacidad del atacante para posicionarse entre la ruta de red y el recurso solicitado por la víctima (por ejemplo, vulnerabilidades que para ser explotadas necesitan que se ejecuten ataques del tipo “Hombre en el Medio” (MitM, por sus siglas en inglés)).

**4. Métrica base actualizada: interacción del usuario (User interaction) (UI)**

Esta métrica permite un mayor nivel de detalle al considerar la interacción de un usuario como un componente vulnerable. Los posibles niveles de interacción del usuario son los siguientes:

Ninguna (N): el sistema vulnerable puede explotarse sin interacción de ningún usuario, salvo el atacante.

Pasiva (P): la explotación con éxito de esta vulnerabilidad requiere que el usuario objetivo del ataque tenga algún tipo de interacción con el componente vulnerable y el payload del atacante. Estas interacciones se consideran involuntarias y no requieren que el usuario altere de manera activa las protecciones integradas en el componente vulnerable.

Activa (A): la explotación exitosa de esta vulnerabilidad requiere que el usuario objetivo del ataque interactúe de forma específica y consciente con el componente vulnerable y el payload del atacante. En su defecto, dicha interacción alterará de forma activa los mecanismos de protección que conducirán a la explotación de la vulnerabilidad.

La actualización de esta métrica amplía el uso anteriormente implementado en el modelo CVSS v3, permitiendo aportar una capa adicional de información, pasando de una decisión binaria consistente en si se requiere o no algún tipo de interacción por parte del usuario, a tres opciones posibles que miden el carácter de esta interacción.
Un ejemplo aplicable de esta nueva forma de tomar en consideración la métrica UI podría ser la diferenciación entre un XSS almacenado que requiera acceder a un punto concreto de la aplicación, y un XSS reflejado que requiera que el usuario pulse un enlace con el payload, cosa que CVSS v3 no contemplaba.

**5. Métrica eliminada: alcance (scope) (S)**

La métrica que hace referencia al alcance del ataque en CVSS v3 presenta dos problemas principalmente. En primer lugar, da lugar a incoherencias en la puntuación proporcionada por los proveedores de productos. En segundo lugar, impedía una correcta interpretación y evaluación del impacto potencial de la vulnerabilidad en sistemas subsiguientes.

Para solucionar este problema, CVSS v4 divide las métricas de impacto en dos grupos: las relativas al sistema vulnerable y las que afectan a otros sistemas debido a su relación o conexión con el sistema vulnerable.

Sistema vulnerable
- Confidencialidad (VC): mide el impacto potencial de una vulnerabilidad en la confidencialidad de la información. Un ataque exitoso podría resultar en el acceso no autorizado a datos sensibles.

Integridad (VI): se refiere a la fiabilidad y precisión de los datos. Una vulnerabilidad podría permitir a un atacante alterar, modificar o destruir información sin autorización.

Disponibilidad (VA): esta métrica mide el impacto potencial de una vulnerabilidad en la disponibilidad de un sistema o servicio. Un ataque exitoso podría resultar en una interrupción del servicio, un retraso en su entrega, o la completa inhabilidad del servicio para realizar su función prevista.

Sistema(s) posterior(es)

Confidencialidad (SC): mide si el atacante puede explotar la vulnerabilidad para acceder a información sensible en los sistemas subsiguientes. Por ejemplo, un atacante podría explotar una vulnerabilidad en un servidor web para acceder a una base de datos de clientes en un sistema posterior relacionado.

Integridad (SI): determina la capacidad de un atacante de alterar o destruir información en otros sistemas subsiguientes distintos al vulnerable.

Disponibilidad (SA): esta métrica mide hasta qué punto se ve afectada la disponibilidad de sistemas subsiguientes. Por ejemplo, una vulnerabilidad en un portal de inicio de sesión podría suponer la denegación de servicio en sistemas que hagan uso del mismo.

**6. Nuevo nombre para el grupo de métricas “Temporal”: grupo de métricas de amenaza (threat metric group)**

Las métricas relativas al nivel de amenaza eran innecesariamente complejas, por lo que la nueva métrica “Madurez del Exploit” (Exploit Maturity) ha reemplazado y unificado las anteriores: “Madurez del código del exploit” (Exploit Code Maturity), “Nivel de remediación” (Remediation Level) y “Fiabilidad del reporte” (Report Confidence).

Esta nueva métrica adquiere los siguientes posibles valores:

No definido (X): la métrica no está definida. No se dispone de información para determinar las características de madurez del exploit.
Atacado (A): basado en la inteligencia de amenazas, hay informes de ataques sobre esta vulnerabilidad o existen herramientas o soluciones públicas o privadas para explotarla.

Prueba de concepto (P): a raíz de la información de inteligencia disponible, existe una prueba de concepto, no hay ataques reportados que exploten esta vulnerabilidad, y no hay herramientas o soluciones públicas ni privadas.

No reportado (U): no se tiene conocimiento de que exista una prueba de concepto, de que la vulnerabilidad esté siendo explotada ni de que existan soluciones o herramientas destinadas a su explotación.

7. Nuevo en CVSS4: métricas complementarias

CVSS v4 permite la creación de nuevas métricas que describen y evalúan atributos externos adicionales de una vulnerabilidad. La persona que recibe la información puede utilizar los valores de estas métricas para tomar acciones adicionales si así lo desea, otorgando mayor importancia a los valores obtenidos según sea necesario

Ninguna métrica definirá el impacto numérico en la puntuación final calculada del CVSS (por ejemplo, CVSS-BTE). Las organizaciones pueden asignar la importancia y el impacto real de cada métrica, o del conjunto/combinación de métricas, dándoles una mayor, menor, incluso ninguna importancia en el análisis final de riesgos. Las métricas y sus valores simplemente proporcionarán información adicional sobre características externas de la vulnerabilidad en cuestión.

Nota: todas las métricas complementarias proporcionadas por el proveedor de información son opcionales.

¿Cuáles son las métricas de CVSS v4

En total se recogen seis métricas adicionales: seguridad, automatizable, recuperación, densidad del valor, esfuerzo de respuesta ante una vulnerabilidad, y urgencia del proveedor. Todas ellas se detallan a continuación.

Seguridad (safety) (S): esta métrica indica el nivel de impacto en la seguridad de una persona que pueda sufrir lesiones previsibles como resultado de la explotación de la vulnerabilidad. Las categorías de consecuencias definidas en la norma IEC 61508 son las siguientes (a la fecha de redacción de este documento): catastrófica (pérdida de múltiples vidas), crítica (pérdida de una vida), marginal (lesiones graves a una o más personas) e insignificante: (lesiones leves en el peor de los casos). Los valores que esta métrica puede tomar se detallan a continuación:

Presente (present) (P): las consecuencias de la vulnerabilidad cumplen la definición de las categorías de consecuencias de la norma IEC 61508 «marginal«, «crítica» o «catastrófica«.

Insignificante (negligible) (N): Las consecuencias de la vulnerabilidad cumplen la definición de la categoría de consecuencias «insignificante» de la IEC 61508.

Automatizable (automatable) (AU): esta métrica responde a la pregunta de si un atacante puede automatizar la explotación de esta vulnerabilidad en múltiples objetivos, basándose en los pasos 1-4 de la cadena letal (kill chain) : reconocimiento (reconnaissance), armamento (weaponization), entrega (delivery) y explotación (exploitation). Dependiendo de si la respuesta es sí o no, se consideran diferentes escenarios.

No: los atacantes no pueden automatizar de forma fiable todos los pasos. Esto se puede deber a diferentes razones:

El sistema vulnerable no permite que se hagan búsquedas ni ser enumerado.
Contar con métodos de explotación requiere implicación humana para cada uno de los objetivos.
El proceso de entrega hace uso de canales bloqueados por las configuraciones de seguridad de la red.
No se puede llevar a cabo una explotación con un mínimo de fiabilidad, ya que existen técnicas que previenen el proceso.

Sí: los atacantes pueden automatizar de forma fiable todos los pasos. Se puede dar el caso en que la vulnerabilidad permita una inyección de comandos o RCE sin autenticación previa. En su defecto, los analistas deberán proporcionar razones o demostrar que se pueden automatizar los pasos.

Recuperación (recovery) (R): esta métrica describe la resiliencia de un componente/sistema para recuperar los servicios (en términos de rendimiento y disponibilidad) después de que se haya producido un ataque. Sus posibles valores son:

Automático (automatic) (A): el componente/sistema se recupera automáticamente después de un ataque.
Usuario (user) (U): el componente/sistema requiere la intervención manual del usuario para recuperar los servicios después de un ataque.
Irrecuperable (irrecoverable) (I): el componente/sistema es irrecuperable por el usuario después de que se produzca un ataque.

Densidad del valor (value density) (V): describe los recursos sobre los que el atacante obtendrá el control con un único intento de explotación. Tiene dos valores posibles: impreciso (difuse) y concentrado (concentrated).

Impreciso (difuse) (D): el sistema vulnerable tiene recursos limitados. Es decir, los recursos sobre los que el atacante obtendrá el control con un único intento de explotación son relativamente pequeños. Algunos ejemplos de este tipo de sistemas son cuentas de correo electrónico, cuentas bancarias, teléfonos móviles, etc.
Concentrado (concentrated) (C): el sistema que contiene el componente vulnerable posee numerosos recursos. Desde un punto de vista práctico, estos sistemas suelen ser responsabilidad directa de los «operadores del sistema» (es decir, profesionales responsables del mantenimiento de los sistemas) y no de los usuarios. Algunos ejemplos de este tipo de sistemas son bases de datos, servidores Kerberos, servidores que alojan páginas de inicio de sesión, y proveedores de servicios en la nube.

Esfuerzo de respuesta ante una vulnerabilidad (vulnerability response effort) (RE): proporciona información complementaria sobre la dificultad que supone para los usuarios dar una respuesta inicial al impacto de las vulnerabilidades de los productos y servicios desplegados en la infraestructura. Si lo ven necesario, los usuarios pueden tener en cuenta esta información adicional sobre el esfuerzo necesario a la hora de aplicar medidas de mitigación o programar la corrección. Los posibles valores de esta métrica son:

Bajo (low) (L): el esfuerzo requerido para responder a una vulnerabilidad es bajo/trivial. Esto puede hacer referencia a la instalación de un parche de seguridad proporcionado por el proveedor del software para solucionar la vulnerabilidad.
Moderado (moderate) (M): las acciones necesarias para responder a una vulnerabilidad requieren cierto esfuerzo por parte del usuario y tienen un impacto mínimo en el servicio. Por ejemplo, al encontrar una vulnerabilidad en el sistema de gestión de contraseñas de una organización, la solución implica implementar una política de contraseñas más robusta y capacitar a los empleados sobre las mejores prácticas de seguridad.
Alto (high) (H): las acciones necesarias para responder a una vulnerabilidad son significativas y/o difíciles, y posiblemente puedan causar un impacto prolongado y programado en el servicio. Alternativamente, la respuesta a la vulnerabilidad no es posible de forma remota, siendo la única solución a la vulnerabilidad una sustitución física. En algunos casos, la única solución posible es la sustitución física de un componente para mitigar la vulnerabilidad.

Urgencia del proveedor (provider urgency) (U): esta métrica se ha añadido para facilitar un método estandarizado que incorpore una evaluación adicional del proveedor. Para este valor se ha utilizado el método Penultimate Product Provider (PPP) al considerarse el más adecuado; los posibles valores son:

Rojo (Red): el proveedor considera que el impacto de la vulnerabilidad tiene una urgencia alta.
Ámbar (Amber): el proveedor considera que el impacto de la vulnerabilidad tiene una urgencia moderada.
Verde (Green): el proveedor considera que el impacto de la vulnerabilidad tiene poca urgencia.
Blanco (Clear): el proveedor considera que el impacto de la vulnerabilidad es bajo o simplemente informativo.

Hay que destacar que todas las métricas mencionadas con anterioridad tienen el posible valor común “No definido” (not defined) (X). Una métrica adquiere este valor en los casos en los que no ha sido evaluada.

8. Se pone el foco en sistemas OT

En la actualidad, se reconoce que muchas vulnerabilidades pueden tener impactos más allá de la tradicional tríada de Confidencialidad, Integridad y Disponibilidad (C/I/A). Cada vez más, existe la preocupación de que, aunque los impactos lógicos en un sistema vulnerable pueden o no ser reconocidos, puede haber daños tangibles para los seres humanos como resultado de la explotación de una vulnerabilidad.

Los sectores de IoT, Sistemas de Control Industrial (ICS) y atención médica en particular están muy preocupados por poder identificar este tipo de impacto como parte de la especificación del Sistema de Puntuación de Vulnerabilidad Común (CVSS), con el fin de impulsar la priorización de problemas alineados con sus crecientes preocupaciones.

Cuando un sistema no está destinado o diseñado específicamente para ser utilizado con fines de seguridad, pero su despliegue en ciertos modos o lugares puede tener implicaciones para la seguridad, es posible que la explotación de una vulnerabilidad en ese sistema tenga repercusiones en términos de seguridad. Estas repercusiones pueden ser representadas a través de las métricas de entorno que evalúan el impacto en la seguridad del sistema.

Esta métrica de seguridad evalúa el impacto en la seguridad de las personas que podrían resultar heridas como resultado de la explotación de la vulnerabilidad. A diferencia de otras métricas de impacto, esta métrica solo se puede asociar al conjunto de sistemas que le siguen y debe considerarse junto a los valores «Ninguno«, «Bajo» y «Alto» en relación a las métricas de disponibilidad e integridad.

Por lo tanto, en lo que respecta a la seguridad del entorno del consumidor, existen dos métricas OT:

Integridad modificada de los sistemas subsiguientes (MSI:S): una explotación exitosa compromete la integridad del sistema afectado (por ejemplo, cambios en las dosis de una medicación), resultando en un impacto directo en la salud de la persona.
Disponibilidad modificada de los sistemas subsiguientes (MSA:S): una explotación exitosa compromete la disponibilidad del sistema afectado (por ejemplo, si los frenos de un vehículo dejan de funcionar), resultando en un impacto directo en la salud de la persona.

Además de las métricas OT relacionadas con la seguridad del entorno del consumidor, también podemos identificar las métricas del entorno del proveedor. Cuando un sistema no está destinado a un uso específico o no cumple con las prácticas de seguridad, es posible que la explotación de una vulnerabilidad en ese sistema tenga un impacto en la seguridad, el cual puede ser evaluado a través de un conjunto de métricas complementarias.

En este caso, los posibles valores de estas métricas han sido descritos anteriormente al hacer mención a la nueva métrica complementaria denominada “Seguridad”.

Nota: los proveedores no tienen la obligación de proporcionar métricas complementarias. Su suministro es opcional y se basa en la discreción del proveedor para decidir qué información transmitir en cada caso según sea necesario.