Tres dimensiones extra en la evaluación de vulnerabilidades

Esta entrada es una actualización y extensión de algo que escribí hace rato. No quiero repetir lo que ya había dicho, pero como es bastante largo, haré un resumen. En el artículo original entro en mucho más detalle y agrego unas interminables reflexiones.

El tema es que en las fórmulas que suelo ver hay dimensiones como:

• Cercanía al objetivo (CVSS v3)
• Impacto de Confidencialidad, Integridad y Disponibilidad (todas).
• Facilidad/complejidad/costo/reproducibilidad del ataque (DREAD)
• Interacción con usuarios (CVSS v3)

En particular DREAD contempla "usuarios afectados", pero en términos cuantitativos. La primera dimensión que me resultaba interesante es entonces "tipo de usuario afectado", que apunta a la calidad. No en términos de cambio de permisos, escalamiento, eso ya lo tiene de algún modo CVSS v3 con "Scope". Me refiero a que no es lo mismo comprometer a un cliente, un empleado raso, un adminstrador de sistemas, un director. Dependiendo del objetivo y el tipo de persona afectado puede producirse fuga de información, transferencias de dinero, acceso a planes estratégico.

De algún modo está en "environmental" de CVSS v3, pero no produce un texto acompañante más expresivo tipo:

"La vulnerabilidad permite tomar el control de los nodos bajo Plan 9, que es lo que usan los administradores de sistemas".

La segunda tiene que ver con la responsabilidad: es algo mío o de un tercero. ¿Es una mala configuración mía o estoy usando una librería o componente fallado? ¿Es en mi sistema o en el sistema del cliente? En el caso de XSS, quizás el navegador es tan viejo que no puedo protegerlo completamente.

Otro ejemplo es uso repetido de credenciales por parte de los usuarios en distintos sistemas. Por más que yo le pida una credencial fuerte y limite los intentos, no tengo casi control, salvo pedir regeneración periódica, que si mal no interpreto el NIST no está del todo de acuerdo. Fijate que dice:

"Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise."

La nueva

La tercera es "quién reporta" tiene que ver el tratamiento hacia quien ha efectuado y comunicado el hallazgo.



Si descubro la vulnerabilidad yo mismo, no pasa nada, no es público que yo tenga esa vulnerabilidad, no tengo que dar una respuesta por fuera del circuito o procedimiento de resolución.

Si esta vulnerabilidad figura en un boletín o en CVSS por que se trata de un componente ajeno, si es público que la tengo, pues al atacante le alcanza con saber que tengo el componente.

Si es por resultado de un Pentest y es propia, estamos entre pares. Seguimos dentro del contrato. Me tengo que ocupar sin duda pues si el Pentest la encontró en un sistema productivo, un atacante probablemente tambien lo haga.

Queda el caso de que un usuario o investigador independiente reporte, que es muy distinto y marca el máximo valor de esta dimensión, que puede tener muy importantes implicancias de impacto de imagen, daño reputacional.


Con un poco de suerte, el investigador independiente se puede manejar con Responsible Disclosure: tenés este problema, confirmalo y decime cuando lo vas a arreglar para darte tiempo antes de hacerlo público.

El usuario simplemente avisa y si no se le da respuesta quizás insista, quizás se olvide o quizás difunda en una red social "avisé y no me dieron respuesta o no lo arreglaron" y eso produce daño reputacional, aunque la vulnerabilidad haya sido un falso positivo.



Estas dimensiones o la visión que propongo quizás sea un poco menos "científicas" de algún modo, pues son menos cuantificable. Pero me parece que es un agregado más práctico, más de oficio. De todos modos no es un reemplazo, es una extensión al análisis.