¿Es CVSS el estándar correcto para la priorización?


Más del 55% de las vulnerabilidades de código abierto se consideran altas o críticas. Para comprender realmente una vulnerabilidad y cómo podría afectar a una organización o producto, necesitamos mucho más que un número.

La creciente dependencia de la industria del desarrollo de application en componentes de código abierto ha llevado a una mayor conciencia de las vulnerabilidades de seguridad de código abierto, lo que resulta en un aumento drástico en el número de vulnerabilidades de código abierto descubiertas, como WhiteSource reporte anual, «El estado de las vulnerabilidades de seguridad de código abierto», muestra.

Frente a un número cada vez mayor de vulnerabilidades de código abierto en nuestra base de código, ¿cómo pueden las organizaciones de desarrollo de program mantenerse al día con la larga lista de alertas de seguridad para asegurarse de que están solucionando primero los problemas más urgentes?

La priorización de las alertas de seguridad se ha convertido en una parte importante de la gestión de vulnerabilidades, y muchas organizaciones buscan CVSS (Sistema de puntuación de vulnerabilidad común) puntuación de vulnerabilidades como un estándar objetivo para priorizar sus vulnerabilidades de seguridad de código abierto. Sin embargo, los datos en el informe de investigación de WhiteSource muestran que depender de la calificación CVSS para la priorización llevará a las organizaciones solo hasta ahora.

¿Qué hay en un puntaje CVSS?
Desde 2005, el CVSS de la buena gente de 1st (el Foro de Equipos de Seguridad y Respuesta a Incidentes) se ha convertido en el estándar para evaluar la gravedad de una vulnerabilidad. En el CVSS, los investigadores examinan las métricas básicas, temporales, de impacto y ambientales de una vulnerabilidad para comprender qué tan difícil es llevar a cabo una explotación y el nivel de daño que puede causar si el atacante tiene éxito.

El CVSS ha seguido evolucionando a lo largo de los años con nuevos y versiones actualizadas mientras la comunidad trabaja para mejorar el sistema de puntuación. Se han agregado nuevos parámetros, como las métricas de Alcance e Interacción del usuario que se incluyeron en CVSS v3 cuando se lanzó en 2015, que proporcionan más información de la que estaba disponible en v2. Más recientemente, CVSS v3.1 fue lanzado para «aclarar y mejorar el estándar existente».

Sin embargo, incluso cuando los cambios realizados en v3 proporcionaron detalles valiosos para ayudar a las organizaciones a determinar mejor la gravedad de una vulnerabilidad dada, hubo una consecuencia significativa del cambio al nuevo estándar.

¿Se crearon todas las vulnerabilidades iguales? Clasificaciones de CVSS a lo largo del tiempo
El informe de investigación de WhiteSource analizó las clasificaciones de CVSS de más de 10,000 vulnerabilidades de código abierto que se informaron entre 2016 y 2019 para comparar el desglose de gravedad de las vulnerabilidades clasificadas por CVSS v2, v3. y v3.1.

Desglose de gravedad: CVSS v2. vs. CVSS v3. vs. CVSS v3.1

Fuente: WhiteSource

Fuente: WhiteSource

Los datos muestran que las puntuaciones v3. y v3.1 son significativamente más altas que las puntuaciones v2. Por ejemplo, una vulnerabilidad con un CVSS 7.6 en v2 puede encontrarse clasificada como 9.8 por los estándares v3.x.

La comparación de los estándares de calificación v2. con los estándares de calificación v3. proporciona una explicación parcial del cambio dramático:

Fuente: WhiteSource

Fuente: WhiteSource

Vulnerabilidades críticas y de alta gravedad están en aumento
Después de demostrar que los puntajes de CVSS v3.x son generalmente más altos, el informe de investigación continúa comparando la distribución de la gravedad de las vulnerabilidades clasificadas con un puntaje de CVSS v3 para comprender mejor el alcance de las vulnerabilidades de código abierto de gravedad alta y crítica.

Desglose de gravedad de CVSS v3 a lo largo del tiempo

Fuente: WhiteSource

Fuente: WhiteSource

Los números para 2019 muestran que más del 55% de los CVE fueron calificados como altos o críticos. El estudio también informó que las vulnerabilidades de código abierto aumentaron un 50% en 2019, lo que significa que no solo se clasifican más CVE como altas y críticas, sino que hay muchas más vulnerabilidades con las que lidiar en standard.

El primer y más destacado cambio que presentó el CVSS v3.1 lanzado recientemente fue que midió la gravedad, no el riesgo. Se suponía que este cambio proporcionaría a los usuarios un contexto más completo y preciso y una comprensión compartida del puntaje de gravedad de una vulnerabilidad para permitir que más usuarios aprovechen la información. Los datos muestran que a medida que el método de puntuación continúa evolucionando, los desarrolladores y los equipos de seguridad se ven obligados a abordar un gran volumen de vulnerabilidades de gravedad alta y crítica con herramientas limitadas para la priorización.

Existen varias razones para el desequilibrio en la distribución de los puntajes de gravedad. Estos van desde el enfoque intensificado de la comunidad de seguridad en temas críticos y altos hasta la dificultad para crear CVE, que requieren mucho tiempo y hacen que algunos los eviten por problemas de menor gravedad. La pregunta sigue siendo: ¿cómo pueden los equipos de desarrollo y seguridad abordar este desequilibrio?

Las calificaciones de CVSS deben figurar en la priorización de la corrección de vulnerabilidades
A medida que el panorama de seguridad continúa evolucionando, sabemos que para comprender realmente una vulnerabilidad y cómo podría afectar a una organización o producto, necesitamos mucho más que un número.

V3.1 se basa en el entendimiento de que la puntuación CVSS no debe tomarse como el único parámetro. Factores como las dependencias vulnerables o la arquitectura y configuración de la crimson, por nombrar algunos, requieren consideración al evaluar el riesgo de una vulnerabilidad de seguridad en nuestros activos.

Todavía depende de los equipos de DevSecOps garantizar que el inventario de software package, los entornos de nube y la estructura de purple de su organización se tengan en cuenta como parte de la evaluación de vulnerabilidades.

Contenido relacionado:

Jeffrey Martin ha pasado los últimos 15 años en roles de productos, ayudando tanto a las organizaciones para las que trabajó como a sus clientes a transformar y medir sus procesos comerciales, desarrollo y control de calidad. Él disfruta especialmente las transformaciones culturales y de mentalidad por su capacidad de … Ver biografía completa

Lectura recomendada:

Más tips





Enlace a la noticia authentic