El tamaño no importa, lo que importa es lo que haces con ella

La valoración de las vulnerabilidades informáticas, siempre ha sido algo discutido y discutible. Que una vulnerabilidad tenga una valoración de «baja», «media» o «alta» o su peligrosidad sea medida en una escala del 1 al 10, deja al administrador o incluso a los usuarios, una sensación de confusión en cuanto a la urgencia en la toma de medidas y sobre todo a la priorización de las correcciones o incluso al cierre de servicios.

Por ejemplo, vamos a imaginar que sale una vulnerabilidad que nos permitiría por medio de un SQL Inyection, obtener acceso en modo solo lectura a las tablas de los posts de WordPress. La valoración de un SQL inyection suele ser el de una vulnerabilidad grave, pero en este caso, el impacto es bajo. Además, tenemos que tener en cuenta que es posible que no haya exploit y que se trate de un anuncio que no revela como se puede explotar. Por lo tanto, un administrador de uno o varios sitios con WordPress, puede despriorizar la actualización de sus webs basadas en este software hasta el momento que tenga en su agenda una ventana de actualización.

En cambio, si se publica un exploit o el mecanismo de explotación, y esa misma vulnerabilidad, añadiendo un caracter o codificando la petición permitiese la obtención de la tabla de usuarios y sus passwords, la vulnerabilidad seguiría siendo grave, pero el impacto sería mucho mas alto y el administrador debería tomar medidas tan pronto como sea posible.

Esto también suma un dato a la hora de tratar una vulnerabilidad: Su evolución temporal.

Para el siguiente ejemplo, vamos a usar un servidor de DNS. A grandes rasgos, un servicio DNS sirve para traducir los nombres de servidores que normalmente utilizamos, a direcciones IP que son utilizadas finalmente en la comunicación con el destino. Si mañana saliese un fallo de denegación de servicio que afectara a Linux, teniendo toda nuestra red en este sistema operativo, las máquinas con mayor impacto sobre nuestros servicios serán los DNS. Sin DNS no se resuelven los nombres, no funciona el correo, no se presta servicio de navegacion a usuarios, etc.

Esto último, suma un dato más en la estimación que debemos realizar para con una vulnerabilidad: La medida en la que afecta al resto de componentes de la red.

Resumiendo, tenemos 3 aspectos a valorar de una vulnerabilidad:

La valoración básica
La evolución temporal
El impacto en el entorno

Para valorar todo esto tenemos un estándar de facto, propuesto por el FIRST. El CVSS (Common Vulnerability Scoring System), ya en su versión 2, nos ofrece la posibilidad de incluir otras variables que, a la hora de valorar una vulnerabilidad, nos ayudarán a cuantificar su potencial.

Para valorar una vulnerabilidad, CVSS establece una serie de indicadores, conocidos los cuales se puede dar una puntuación numérica, de 0 a 10, a dicha vulnerabilidad. Estos indicadores se agrupan en tres categorías o métricas:

Grupos de métricas CVSS

“Base metric”: son parámetros que el fabricante establece cuando revela al público una nueva vulnerabilidad. Nunca cambian.
“Temporal metric”: son parámetros que pueden cambiar con el tiempo, pero que no dependen de la organización objetivo del análisis.
“Environmental metric”: representa aquellas características de una vulnerabilidad que son relevantes y únicas en el entorno de la organización objetivo del análisis. Desde el punto de vista de una valoración externa, se parametriza la valoración final con el máximo valor posible.

Mediante la utilización de las tres métricas se consigue una valoración precisa de cada una de las vulnerabilidades: