Discrepancias descubiertas en las calificaciones de gravedad de vulnerabilidad



Un nuevo estudio de esta semana seguramente generará más preguntas para los equipos de seguridad empresarial sobre la sabiduría de confiar solo en los puntajes de vulnerabilidad en la Base de datos nacional de vulnerabilidades (NVD) para tomar decisiones de priorización de parches.

Un análisis realizado por VulnCheck de 120 CVE con puntajes CVSS v3 asociados muestra que casi 25 000, o alrededor del 20 %, tenían dos puntajes de gravedad. Una puntuación fue del NIST, que mantiene el NVD, y la otra del proveedor del producto con el error. En muchos casos, estos dos puntajes diferían, lo que dificultaba que los equipos de seguridad supieran en cuál confiar.

Alto índice de conflicto

Aproximadamente el 56 %, o 14 000, de las vulnerabilidades con dos puntajes de gravedad tenían puntajes contradictorios, lo que significa que el puntaje asignado por el NIST y el puntaje del proveedor no coincidían. Cuando un proveedor podría haber evaluado una vulnerabilidad particular como de gravedad moderada, el NIST podría haberla evaluado como grave.

Como ejemplo, VulnCheck señaló CVE-2023-21557, una vulnerabilidad de denegación de servicio en el Protocolo ligero de acceso a directorios (LDAP) de Windows. Microsoft asignó a la vulnerabilidad una calificación de gravedad «alta» de 7,5 en la escala CVSS de 10 puntos. NIST lo dio una puntuación de 9,1, lo que la convierte en una vulnerabilidad «crítica». La información sobre la vulnerabilidad en el NVD no proporcionó información sobre por qué las puntuaciones diferían, dijo VulnCheck. La foundation de datos de vulnerabilidades está salpicada de muchas otras instancias similares.

Esa alta tasa de conflicto puede hacer retroceder los esfuerzos de remediación para las organizaciones que tienen recursos limitados en los equipos de gestión de vulnerabilidades, dice Jacob Baines, investigador de vulnerabilidades en VulnCheck. «Un sistema de gestión de vulnerabilidades que se basa en gran medida en la puntuación de CVSS a veces dará prioridad a las vulnerabilidades que no son críticas», dice. «Dar prioridad a las vulnerabilidades incorrectas desperdiciará el recurso más crítico de los equipos de gestión de vulnerabilidades: el tiempo».

Los investigadores de VulnCheck encontraron otras diferencias en la forma en que el NIST y los proveedores incluyeron información específica sobre fallas en la foundation de datos. Decidieron analizar las vulnerabilidades de secuencias de comandos entre sitios (XSS) y falsificación de solicitudes entre sitios (CSRF) en NVD.

El análisis mostró que la fuente principal, generalmente NIST, asignó 12 969 de los 120 000 CVE en la base de datos como una vulnerabilidad XSS, mientras que las fuentes secundarias enumeraron 2091 mucho más pequeños como XSS. VulnCheck descubrió que era mucho menos possible que las fuentes secundarias indicaran que una falla XSS requiere la interacción del usuario para explotarla. Las puntuaciones de defectos CSRF mostraron diferencias similares.

«Las vulnerabilidades XSS y CSRF siempre requieren la interacción del usuario», dice Baines. «La interacción del usuario es un elemento de puntuación de CVSSv3 y está presente en el vector CVSSv3». Examinar con qué frecuencia las vulnerabilidades XSS y CSRF en NVD incluyen esa información proporciona una notion de la escala de errores de puntuación en la foundation de datos, dice.

Las puntuaciones de gravedad por sí solas no son la respuesta

Los puntajes de gravedad basados ​​en la Escala de gravedad de vulnerabilidad común (CVSS) están destinados a brindar a los equipos de administración de vulnerabilidades y parches una forma sencilla de comprender la gravedad de una vulnerabilidad de software package. Informa al profesional de la seguridad si una falla presenta un riesgo bajo, medio o severo y, a menudo, brinda contexto en torno a una vulnerabilidad que el proveedor de application podría no haber proporcionado al asignar un CVE a la falla.

Numerosas organizaciones utilizan el estándar CVSS cuando asignan puntuaciones de gravedad a las vulnerabilidades de sus productos, y los equipos de seguridad suelen utilizar las puntuaciones para decidir el orden en que aplican los parches al software vulnerable del entorno.

A pesar de su popularidad, muchos han advertido anteriormente que no se debe confiar únicamente en los puntajes de confiabilidad de CVSS para la priorización de parches. En una sesión de Black Hat Usa 2022, Dustin Childs y Brian Gorenc, ambos investigadores de Zero Working day Initiative (ZDI) de Development Micro, señalaron múltiples problemas como la falta de información sobre la capacidad de explotación de un error, su omnipresencia y cuán accesible podría ser para ataque como razones por las que las puntuaciones CVSS por sí solas no son suficientes.

«Las empresas tienen recursos limitados, por lo que normalmente tienen que priorizar qué parches implementan», dijo Childs a Darkish Studying. «Sin embargo, si obtienen información contradictoria, pueden terminar gastando recursos en errores que es poco probable que alguna vez sean explotados».

Las organizaciones a menudo confían en productos de terceros para ayudarlos a priorizar las vulnerabilidades y decidir qué parchear primero, señala Childs. A menudo, tienden a dar preferencia al CVSS del proveedor en lugar de otra fuente como NIST.

“Pero no siempre se puede confiar en que los proveedores sean transparentes sobre el riesgo authentic. Los proveedores no siempre entienden cómo se implementan sus productos, lo que puede generar diferencias en el riesgo operativo para un objetivo”, dice.

Childs y Bains abogan por que las organizaciones consideren la información de múltiples fuentes al tomar decisiones sobre la remediación de vulnerabilidades. También deben considerar factores tales como si un error tiene una explotación pública en la naturaleza o si se está explotando activamente.

«Para priorizar con precisión una vulnerabilidad, las organizaciones deben poder responder las siguientes preguntas», dice Baines. «¿Esta vulnerabilidad tiene un exploit público? ¿Se ha explotado esta vulnerabilidad en la naturaleza? ¿Esta vulnerabilidad está siendo utilizada por ransomware o APT? ¿Es possible que esta vulnerabilidad esté expuesta a Internet?»



Enlace a la noticia authentic