CVSS como marco, no como puntuación



El venerable sistema nos ha servido bien, pero ahora está desactualizado. No es que sea hora de deshacerse del sistema, utilícelo como un marco para medir el riesgo utilizando métodos modernos basados ​​en el contexto.

Durante más de 15 años, los proveedores han utilizado el sistema de clasificación Prevalent Vulnerability Scoring Technique (CVSS) para describir la gravedad y el alcance de las fallas de seguridad. El conocido formato de puntuación de a 10 nos ha sido de gran utilidad, pero ya no refleja la forma en que se crean, mantienen y atacan las redes y aplicaciones modernas. Se necesita algo con más contexto, profundidad y flexibilidad para mostrar dónde se encuentran las empresas riesgo del negocio.

Dicho esto, no debemos ignorar el cuerpo de trabajo que representa el CVSS. En cambio, deberíamos aprovechar el CVSS como un marco para medir el riesgo utilizando métodos modernos basados ​​en el contexto.

Lo que funcionó entonces no funciona ahora
Adoptado en 2005, CVSS es utilizado por el Instituto Nacional de Estándares y Tecnología para asignar a las fallas de seguridad una calificación numérica de a 10 que describe su riesgo y severidad. Las vulnerabilidades se clasifican en función de factores tales como cómo se expone el componente susceptible (por ejemplo, si puede ser atacado de forma remota o requiere acceso regional), qué tan difícil y confiable podría ser un ataque y qué impacto podría tener un exploit exitoso en la confidencialidad e integridad y / o disponibilidad.

Todo esto tiene sentido en la superficie, pero hay algunos problemas técnicos graves con el esquema de calificación. Considere este histograma de puntuaciones foundation CVSS para todas las vulnerabilidades y exposiciones comunes (CVE) registradas hasta la fecha:

Este es un desglose bastante extraño. Para cualquier histograma derivado de un proceso organic (es decir, lo que sucede en el mundo authentic), esperaría ver una distribución conocida, como un distribución regular o distribución lognormal. Eso es especialmente cierto cuando se trata de grandes conjuntos de datos (hasta la fecha se han registrado más de 150.000 CVE).

Tenga en cuenta que solo un pequeño subconjunto de CVE realmente ha desarrollado exploits de prueba de concepto (de forma privada o pública). Entonces, si intentamos crear una métrica que mida riesgo, esperaríamos que la proporción de CVE que reciben un 9 o 10 sea muy pequeña en comparación con los otros rangos. Pero en la distribución de puntuaciones de CVSS, hay más vulnerabilidades con puntuaciones de 9 o más que aquellas con valores de a 4, ¡combinados! Además, ¿por qué no muchas puntuaciones tienen un valor de 8 a 9, mientras que muchas más aparecen en los rangos de 7 a 8 y 9 a 10? Eso no tiene mucho sentido. Ninguna de estas cosas prueba que el CVSS es inexacto, pero arroja dudas sobre la fórmula de calificación.

Sin embargo, es importante no ser demasiado crítico con el esfuerzo de estandarización de CVSS. Desde que se concibió el sistema, el número de EVC que se notifican ha aumentado aproximadamente 12% anual, cada año, y el mundo está ahora en un lugar diferente.

Datos CVSS como primer paso del análisis
El CVSS ha sido un gran punto de partida para la industria, pero hay tantos detalles a considerar en cada categoría que su fórmula demasiado simplista ya no puede proporcionar el nivel de precisión que necesitamos. La buena noticia: todavía podemos hacer un buen uso de CVSS como marco para guiarnos sobre dónde comienzo nuestro análisis.

Considere los elementos de «explotabilidad» de un Puntaje base CVSS 3.1:

Vector de ataque (AV)
Básicamente, esto captura los prerrequisitos relacionados con la pink que los atacantes deben satisfacer para aprovechar la falla. ¿Pueden explotar la falla de forma remota sin autenticación, o es necesario que los atacantes ya estén ejecutando código en un host?

Complejidad de ataque (AC)
Esta categoría es una especie de bolsa de sorpresas que dificulta la explotación en la práctica en función de una variedad de consideraciones técnicas.

Privilegios requeridos (PR)
Esta categoría captura los derechos de acceso necesarios para explotar la falla. Clasifica los privilegios en depósitos «ninguno», «usuario con pocos privilegios» y «usuario con muchos privilegios».

Interacción del usuario (UI)
Este elemento indica si un atacante necesitaría convencer a un ser humano para que realice una acción específica para aprovechar la vulnerabilidad. Los ejemplos más comunes son: convencer a un usuario de que visite un sitio world wide web malicioso o de que abra un archivo adjunto de correo electrónico.

El siguiente paso es relacionar estos elementos con su propio entorno. ¿Hay formas en que podamos recopilar más información en cada una de estas áreas para ayudar a eliminar falsos positivos o retrasar la solución de problemas que es muy poco probable que se aprovechen en su situación?

Suponga que recibe un lote de 120 vulnerabilidades el martes de parches, donde muchos de esos CVE afectan a unos pocos miles de sistemas. ¿Cuál de esos CVE tiene un requisito de interfaz de usuario? Probablemente bastantes. De las máquinas afectadas en su entorno, ¿cuál de ellas tiene usuarios activos que podrían ser susceptibles? Por ejemplo, ¿qué sucede si tiene muchos servidores que se enumeran como vulnerables a alguna vulnerabilidad «crítica» del navegador, pero sabe por cierto que nadie navega por la World wide web desde esas máquinas? Significa que la probabilidad de explotación es extremadamente pequeña, y podría excluirlos de su lista de prioridades urgentes. Lo difícil es demostrarlo.

Una forma de hacerlo sería recopilar los registros de uso de la navegación web de su proxy o de las máquinas individuales, preparar algunos scripts para compararlos con la salida del escáner de vulnerabilidades, y ahora tiene una forma repetible de despriorizar muchas instancias de un Categoría muy común de CVE.

Como otro ejemplo, considere el caso de las fallas de escalada de privilegios locales. Pueden ser una herramienta muy importante en la caja de herramientas de un atacante, pero solo son útiles si un atacante puede obtener acceso a un host para empezar. Si el campo Privilegios requeridos de un CVE es «Bajo», entonces puede compararlos con los hosts afectados y determinar si algún usuario no administrativo (humanos o cuentas de servicio) tiene acceso a la máquina. Si no hay ninguno, entonces no parece muy possible que la falla pueda usarse en una secuencia de ataque exitosa.

Esto es lo que queremos decir con el uso de CVSS como marco. Puede utilizar la información limitada proporcionada en el vector de puntuación para impulsar la recopilación de datos ambientales adicionales y la estimación de riesgos basándose en una comprensión outstanding de la vulnerabilidad en el contexto de su infraestructura.

El futuro de la priorización de vulnerabilidades
Quizás se pregunte qué hacer con los otros elementos de una puntuación foundation de CVSS: alcance (S), confidencialidad (C), integridad (I) y disponibilidad (A). Desafortunadamente, esta es un área donde CVSS comienza a fallar. Después de analizar miles de CVE, rápidamente queda claro que tratar de estimar el riesgo comercial de un CVE de forma aislada es esencialmente imposible. Las redes modernas están demasiado interconectadas para eso. En cambio, todo lo que podemos hacer honestamente con los CVE individuales es estimar la probabilidad de que una vulnerabilidad determinada pueda usarse en ataques según nuestra comprensión de los requisitos previos de explotación y qué vulnerabilidades podrían ser más útiles para nuestros adversarios.

La frontera genuine de la priorización de vulnerabilidades radica en comprender las interconexiones entre las configuraciones del sistema, los derechos de acceso del usuario, las restricciones de acceso a la red, cómo se relacionan con sus activos sensibles y cómo los atacantes podrían encadenar múltiples ataques para tener acceso a esos activos.

Una vez que pueda hacer eso, puede comenzar a asociar detalles técnicos específicos con el verdadero riesgo que enfrenta una empresa. Este es un problema difícil de resolver y su automatización requerirá herramientas y tecnologías especializadas, pero cuanto más aprovechemos el contexto técnico para pensar en las vulnerabilidades en términos de su riesgo para nuestro negocio, en lugar de una noción «difusa» de riesgo técnico, el mejor seremos capaces de alinear nuestros programas de gestión de vulnerabilidades con lo que más importa a nuestras organizaciones: la reducción objetiva del riesgo empresarial.

Tim Morgan es el fundador y CTO de DeepSurface Stability, un nuevo e innovador producto de gestión de vulnerabilidades basado en riesgos que ayuda a los equipos de seguridad a obtener una comprensión mucho más profunda de las complejas relaciones presentes en sus infraestructuras digitales. Después de comenzar su … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia unique