Tengo muchas preguntas, no sé si suficientes respuestas ni si son correctas, pero las comparto para la reflexión.
Antes repasemos un poco que es una vulnerabilidad y cómo se calcula su criticidad. Dicen los manuales algo asi como:
Una vulnerabilidad sobre un activo es una falla que puede ser explotada por un atacante para ejecutar acciones sobre un equipo.
Estas afectan la Confidencialidad, Integridad y Disponibilidad de la información si lo vemos desde el punto de vista de la Seguridad de la Información.
Mejor aún si ampliamos a la visión de Dependability (ni idea de cómo traducir a algo lindo eso), tambien afecta a Safety, que es una visión mejor, pues dentro de la primera triada, ¿dónde entra que se bloquéen los frenos de un auto en la ruta a 120 kmph? Quizas la información del vehículo no se destruye aunque si sus ocupantes.
Ok, entonces, en términos de impacto sobre esas palabritas, se puede determinar la criticidad de una vulnerabilidad. Unos intentos pretéritos cercanos fueron DREAD y STRIDE, el primero ya abandonado y el segundo se sigue usando según entiendo para modelado de riesgos.
- Damage – qué tan malo puede ser el ataque?
- Reproducibility – qué tan fácil es de reproducir?
- Exploitability – cuánto trabajo implica el ataque?
- Affected users – a cuánta gente le pega?
- Discoverability – qué tan fácil es descubrir que tenés esa vulnerabilidad?
Estas ambas metodologías no son muy precisas y no contemplan muchos, muchos factores y son bastante subjetivas.
| Amenaza | en spanish | Se arregla con.. |
|---|---|---|
| Spoofing | hacerse pasar por... | Autenticidad |
| Tampering | Adulteración | Integridad |
| Repudiation | Yo no lo hice... | No Repudio |
| Information disclosure | Pérdida de información | Confidencialidad |
| Denial of Service | Denegación de servicio | Disponibilidad |
| Elevation of Privilege | Elevación de privilegios | Autorization |
Fijate que STRIDE ya contempla Confidencialidad, Integridad y Disponibilidad. De ahora en más, la llamaré "CIA".
Para remediar esas falencias, el estado actual metodológico se llama CVSS versión 3.1 pero voy a usar la 3.0 pues los valores actuales están más en esa y estoy más familiarizado. Y me gusta más la de FIRST, voy a ir alternando las capturas para molestarte un poquito.
Te recomiendo que abras una o dos pestañas con ambas calculadoras y vayas probando, partiendo de esta situación:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
La calculadora tiene tres zonas de métrica, una de base que es la vulnerabilidad en abstracto, como es completamente aislada de las circunstancias y el tiempo.
¿Qué quiere decir esto? Que si la vulnerabilidad es altísima y es de un protocolo que no tenés no deja de ser altísima pues si instalaras ese protocolo la tendrías. Que si ya existe corrección, si no la aplicás, sigue siendo altísima.
La otra zona es la del entorno concreto que aplica en tus circunstancias. En ésta determinás como te pega a vos realmente, no sólo a tu sistema si no a cada punto. Podés tener dos equipos con la misma vulnerabilidad pero distintos requerimientos de seguridad, cambia la criticidad. O siendo iguales uno puede estar expuesto a Internet y el otro no, ahí cambia.
Supongamos una vulnerabilidad con 10 de puntaje, es explotable desde tal lejos como Internet. Pero si tu máquina está desconectada de la red, disminuye.
Recordá, para el puntaje de base no vale "ah, pero a mi...", no. Es en condiciones de laboratorio.
El núcleo de CVSS es el impacto CIA. Jugá con los parámetros y vas a ver que si el impacto en CIA es cero, la criticidad es cero. Eso tambien ocurre con el puntaje de entorno (Environmental), podés bajarla a cero si VOS no tenés impacto.
El detalle de cada elemento lo dejaré para otra oportunidad, quizás nunca, así no se hace tan largo esto, sin embargo voy a hacer unos mínimos comentarios por si el tema es nuevo para vos. Si pasás el cursor del mouse sobre los botones de las calculadoras te explica. Si no te alcanza, me preguntás y voy agregando detalle.
Attack Vector (AV)
Vector de ataque tiene que ver con las condiciones de acceso, va desde Internet a tener que ponerle las manos encima al equipo.
Attack Complexity (AC)
Complejidad de ataque, si hay condiciones fuera del control del atacante, si hay que ponerse en el camino de red por ejemplo.
Privileges Required (PR)
Privilegios requeridos, ¿hace falta ser admin? usuario normal, nada?
User Interaction (UI)
Interacción del usuario, puedo plantar un ejecutable en un servidor, pero luego tengo que hacer que un usuario lo ejecute, mediante una comunicación falsa que así lo solicite.
Scope (S)
Alcance, ¿el ataque afecta este componente o hace sapito? En caso de sapito lo que sigue se debe definir para el blanco final. Por ejemplo, si puedo hace que un componente haga denegación de servicio contra otro, cambia el alcance.
(Este es un punto que nunca me termina de cerrar, por que si en esta denegación de servicio el componente de entrada tambien es afectado ¿tambien es víctima...?)
Confidentiality (C) Integrity (I) Availability (A)
Son nuestras viejas conocidas.
En la zona de puntaje de entorno, es adaptar a tus circunstancias como ya expliqué. La diferencia es que la parte base por lo general la recibís, las otras tenés que ajustarlas vos.
Hay un grupito extra, los CIA requirements. Este sirve para hacer un ajuste extra que es este.
Primero tenemos que el impacto CIA es el abstracto de base, luego lo ajustamos con los Modified, que tiene que ver con que quizás no tengo información alcanzable por la explotación de esa vulnerabilidad. Finalmente, quizás tenga información alcanzable, pero NO ME IMPORTE.
¿Hay más?
Lo que he notado con el tiempo es que hay dimensiones que no han sido consideradas explícitamente, por ejemplo:
¿A quién afecta?
No es lo mismo a un operador final que a un administrador de sistemas.
¿Quién es el responsable?
No es lo mismo un producto externo que hay que esperar el parche a un producto interno que hay que elaborarlo, o si la falla se manifiesta en el browser completamente bajo el control del atacante o en la db, bajo nuestro control. Si está expresado en "Scope", es muy retorcido.
¿Quién reporta?
No es "Report Confidence", es si te la reportó un cliente quizás sea más importante resolverla antes que lo que viene por un EH, pues este cliente puede generar impacto reputacional si no está contento con la resolución.
Esto está más desarrolado en otras notas.
Y ahora, por fín, llego al tema que quería:
El tiempo
En CVSS el tiempo está contemplado de las siguientes maneras
Report Confidence (RC)
Confianza en el reporte, a medida que pasa el tiempo debería crecer, de un rumor a una comunicación oficial del owner del producto, aumenta el puntaje.
Remediation Level (RL)
Solución disponible, comienza con un hack, termina con una nueva versión bien corregida e integrada, disminuye el puntaje.
Exploit Code Maturity (E)
Madurez del ataque, va desde "es teóricamente posible" a un script que puede usar cualquiera, aumenta el puntaje.
Mi cuarto factor es el tiempo de vida de la vulnerabilidad, ¿pero cual?
- desde que existe la vulnerabilidad
- desde que está presente en mi sistema
- desde que fue detectada
- desde que fue incorporada al sistema de seguimiento
Evidentemente la última no es, el sistema de seguimiento debe tomar al menos la fecha de detección, pudo haber venido en un batch corrido hace un mes.
Y acá es donde llega el momento de pensar y que aún no me decido, veamos un ejemplo:
Detecto una vulnerabilidad en un sistema legacy que está instalado hace diez años y la vulnerabilidad tiene once, ponele.
¿Es crítica? ¿Tiene sentido que salga corriendo a corregirla si han habido diez años de oportunidad para explotarla? Esto haría que el tiempo atenúe la criticidad.
Si acabo de instalar el sistema SI es crítico que lo arregle ya. Esto es congruente con que ante una crítica de algo que ayer era un Zero Day, tengo que arreglarlo ya mismo.
Entonces me estaría quedando con que el tiempo es el de presencia, atenuante.
Por otro lado, a medida que pasa el tiempo aumentan la probabilidades de que sea explotada y fundamentalmente aumenta el nerviosismo de las altas esferas, ¿¿¿¿cómo puede ser que tengamos esa vulnerabilidad desde hace tanto tiempo??? Este había sido el motor de este aspecto en mis pensamientos precristalizados.
Quiza la forma es creciente durante un tiempo y luego atenuante.
Expresaré con grafiquitos lo dicho hasta ahora:
El tiempo pasado entre la existencia pública de la vulnerabilidad y la detección en el sistema, el reporte, es breve:
sistema =========================================
vulnerabilidad ===============================
reporte ++=============================
crece crece decrece
La vulnerabilidad está presente hace mucho en el sistema pero recién nos enteramos: sistema
sistema =========================================
vulnerabilidad ===================================
reporte +++++++++++++++====================
decrece decrece
La parametrización de esos crecen y decrecen, para mi debe ser resultado de un estudio estadístico de qué ha ocurrido en la realidad, probablemente exista pero no me muero de ganas de buscarlo ahora (en realidad busqué y no apareció nada rápido). Si no existe, puede ser el tema de tu tesis, no te olvides de mencionar que yo te dí la idea.
De paso te digo que cuanto mayor haya sido el tiempo de exposición, mayor esfuerzo hay que dedicar a determinar si la vulnerabilidad ha sido explotada.
Y lo que nunca te puede pasar esto:
sistema =============================
vulnerabilidad =====================================
Versión en inglés precario
No hay comentarios:
Publicar un comentario