El proceso de gestión de amenazas en el ámbito de la seguridad cibernética es más un arte que una ciencia, a pesar de la existencia de multiples modelos teóricos que se pueden aplicar para la determinación de la existencia o no de un riesgo para las organizaciones.

Esta realidad hace que el tema no sea visto como algo viable por los oficiales de seguridad cibernética de las organizaciones, ya que cuando se presenta la oportunidad de aplicar un método científico al problema, se entra en un terreno que aparenta ser más un ejercicio académico, que una formula para tratar un problema real y presente; haciendo ver, en las metes de los administrativos, como otro proyecto más de la gente de seguridad, que nadie entiende. La culpa aquí, definitivamente la tenemos los profesionales de la seguridad cibernética, que no tenemos las destrezas necesarias para comunicar problemas complejos a los niveles directivos.

Sin embargo, la noción de que se trata de un tema académico, sin aplicaciones en el mundo real, no puede estar más lejos de la realidad; de hecho, la falta de formalización de un sistema de gestión de amenazas, hace que sea mucho más difícil la justificación de presupuestos para ejecución de proyectos de mejora de la seguridad, debido a que no nos hemos tomado el trabajo de probar científicamente la existencia del riesgo, que dichos proyectos estarían mitigando. Esto básicamente describe el circulo vicioso en el cual se encuentra más de un oficial de seguridad en estos momentos.

Para aclarar un poco las dudas sobre el sistema o modelo de gestión de amenazas que podemos aplicar, a continuación expongo lo que he podido aprender en los últimos meses, con respecto al tema; ya que esto forma parte de un tema más abarcador, que ya trate en un post anterior (falta de procesos en TI).

Los podcast del Internet Storm Center suelen ser muy buenos y no duran más de 5 minutos por resumen diario, sugiero que lo escuchen en camino al trabajo (https://isc.sans.edu/podcast.html). Escuchando dicho podcast me encontré con una discusión sobre Threat Modeling y si valía la pena entrar en todo el esfuerzo de tratar de aplicar un modelo científico a un problema tan complejo como las amenazas, vulnerabilidades, bugs, y todo lo que esto significa para las organizaciones; si esto era mejor a continuar con la tendencia de crear pánico cada vez que se devela una vulnerabilidad nueva, con la esperanza de que esto nos mantenga relevantes al momento de solicitar presupuestos.

Un ejemplo reciente de lo descrito anteriormente es el reciente fallo descubierto en la implementación de algunos clientes de correo, al momento de usar PGP para el cifrado de los correos.

En resumen, se realizo una divulgación no coordinada de una supuesta vulnerabilidad en PGP, y al momento de que se realiza el análisis se descubre que la falla esta en la implementación de algunos clientes de correo y su integración con PGP, y no en el método de cifrado en si; sin embargo esto no impidió que la noticia se esparciera, sembrado temor, incertidumbre y dudas (FUD por sus siglas en inglés) a través de todo Internet.

We have a responsibility in our positions where the world really listens to us as experts when we identify exposures that have impact on real world things.

Creating alarm and hype for issues that aren’t extremely critical or impactful hurts that credibility. #efail

— Dave Kennedy (ReL1K) (@HackingDave) May 14, 2018

Todo esto con el afán de ganar credibilidad o reputación en la comunidad mundial de seguridad de la información; hasta tiene un sitio web y un logo. Este es solo el ejemplo más reciente, sin olvidar Meltdown y Spectre a principios de este año.

Estas mismas técnicas, son las que típicamente se han utilizado a lo interno de las organizaciones para “vender” el tema de seguridad, sin entender, que lo que se esta haciendo es un daño a la comunidad de seguridad en general, al presentarnos como poco profesionales, llegando a conclusiones sin soporte científico o razonamiento económico verificable.

Para esto existe el modelaje de amenazas o Threat Modeling. La verdad el proceso no es complejo, solo largo, pero el resultado final es un nivel de riesgo, calculado en base a la realidad de la organización para la que se realiza el análisis. Desgraciadamente, esto es algo que no aplica por igual para todo el mundo, por lo cual su implementación es diferente para cada organización (no silver bullet), pero la metodología si puede ser la misma. Lo que he podido ver hasta ahora es que los componentes parecen ser:

  1. Modelaje de amenza
  2. Clasificación de amenazas
  3. Inventario de sistemas
  4. Identificación de vulnerabilidades
  5. Mapeo de amenazas

Modelaje de amenazas (Threat Modeling)

El modelo más famoso es STRIDE, y solo se trata de poder clasificar las amenazas en categorías estándar, es decir, un sistema informático es vulnerable a una de las siguientes amenazas:

  1. [S]poofing Identity (falsificación de identidad)
  2. [T]ampering with data (modificación de datos)
  3. [R]epudiation (no repudio)
  4. [I]nformation Disclosure (Perdida de Información/Imagen)
  5. [E]levation of Privilege (Elevación de privilegios)

Algunas de estas amenazas se pueden relacionar directamente con conductas criminales, tales como, acceso no autorizado, abuso de sistemas, fraude, entre otros.

Una vez tengamos claras las categorías de amenazas que deseamos manejar en nuestro modelo, entonces podemos continuar con su clasificación.

Clasificación de amenazas

Originalmente utilizado por Microsoft, el modelo de evaluación de amenazas DREAD, es ahora parte de OpenStack, y provee 5 categorías para clasificar las amenazas

  1. [D]amage (Daño potencial)
  2. [R]eproducibility (facilidad de reproducción)
  3. [E]xploitability (facilidad de ejecución)
  4. [A]ffected users (usuarios afectados)
  5. [D]iscoverability (facilidad de descubrimiento de la amenaza)

Inventario de sistemas

Creo que esto se explica por si solo, sin embargo, debemos recalcar que no estamos hablando de CMDBs, ni ningún otro inventario que operaciones pueda tener para efectos de gestión de sistemas; sino inventarios de equipos, producido por el descubrimiento activo utilizando herramientas de seguridad.

La razón para no re-utilizar los inventarios de operaciones, es que generalmente los mismos están des actualizados y tienen un propósito distinto. Dichos inventarios nos sirve para correlacionar lo encontrado en la red vs. lo que creemos que tenemos conectado en la red, pero es importante que el inventario de seguridad sea levantado de manera independiente.

Identificación de vulnerabilidades

Ya esto es territorio más familiar para los oficiales de seguridad, ya que casi todas las organizaciones cuentan con herramientas o servicios que les permiten realizar un levantamiento de las vulnerabilidad presentes en sus sistemas (inventariados en el paso anterior).

Esto es importante, pero no representa un fin por si solo, ya que nos falta el paso más importante.

Mapeo de vulnerabilidades

Asumiendo que tenemos el inventario lo más actualizado posible, hemos podido identificar las vulnerabilidades presentes en los sistemas con un cierto grado de confianza, y que dichas vulnerabilidades han sido amarradas a una amenaza especifica, previamente clasificada (STRIDE/DREAD), entonces podemos agregar un componente financiero a la formula, y estimar las perdidas, en caso de que la amenaza se llegue a materializar; efectivamente estimando el riesgo financiero relacionado con la gestión de amenazas.

El proceso puede parecer largo o tedioso, pero la verdad es que es muy fácil de reproducir, una vez se practica, digamos, con los 5 sistemas más críticos de la organización. Como todo ejercicio, una vez se practica lo suficiente, es muy fácil extender su aplicabilidad a todos los sistemas de la organización.

Ahora imagínense estar en una reunión de junta directiva, y poder realizar un calculo en vivo, relacionado con la aparición de una nueva vulnerabilidad, y que significa esto en términos financieros. Croe que esta es una mucho mejor manera de conseguir fondos y/o atención que crear pánico en nuestras organizaciones.

Agree! Causing people to run around like their hair is on fire yields little benefit.

— Jim Nitterauer (@JNitterauer) May 14, 2018