Los IOC han muerto, ¡larga vida a los IOC!

Un indicador de compromiso (IOC) se define como una pieza de información que puede utilizarse para identificar el posible compromiso de un entorno: desde una simple dirección IP hasta un conjunto de tácticas, técnicas y procedimientos usados por un atacante en una campaña. Aunque cuando hablamos de IOC siempre tendemos a pensar en indicadores como IP o dominios, el concepto va más allá, y en función de su granularidad, podemos encontrar tres tipos de indicadores:

  • Indicadores atómicos: los que no pueden ser descompuestos en partes más pequeñas sin perder su utilidad, como una dirección IP o un nombre de dominio.
  • Indicadores calculados: los que se derivan de datos implicados en un incidente, como el hash de un fichero.
  • Indicadores conductuales: los que a partir del tratamiento de los anteriores, permiten representar el comportamiento de un atacante, sus tácticas, técnicas y procedimientos (TTP).

Las TTP se asocian a inteligencia operacional, mientras que los indicadores atómicos y calculados se asocian a inteligencia táctica, y en este ámbito, con un tiempo de vida muy corto, recaen la mayor parte de indicadores compartidos: más de la mitad de los IOC que se intercambian en plataformas de inteligencia de amenazas son tan simples como hashes, IP y dominios DNS. ¿El problema? El que sabemos desde hace años y se refleja de forma sencilla en aproximaciones como The pyramid of pain: es trivial para un atacante cambiar estos indicadores. De hecho, justo los tres tipos más intercambiados son los más sencillos de alterar, lo que limita considerablemente su utilidad.

Para un atacante, alterar un hash es trivial, desde el tiempo de compilación del artefacto hasta el de ejecución; alterar una IP usada en un sistema de mando y control o en un servidor de exfiltración es muy sencillo, y en relación a los nombres de dominio podemos decir que la complicación es también mínima. Por tanto, un atacante con capacidades básicas puede evadir las detecciones basadas en estos tipos de indicadores, como bien se muestra en el esquema de The pyamid of pain. En cambio, si vamos a a indicadores conductuales, a TTP, modificarlas es mucho más complicado para el atacante, con lo que si somos capaces de detectar estos modus operandi, tenemos más probabilidad de identificar un compromiso.

Entonces, ¿por qué si los indicadores atómicos y calculados son los menos útiles son los más intercambiados? En mi opinión, la respuesta es muy simple: se cargan de forma automática en herramientas de seguridad, con lo que producen resultados visibles e inmediatos. Si recibimos un feed de inteligencia táctica, por ejemplo asociado a nombres de dominio, IP o similares, podemos cargar dicho feed en muchos sistemas perimetrales para detectar actividad asociada a los indicadores. Podemos hacer una query contra el SIEM para ver si ha habido actividad histórica contra los mismos -y podemos dejarla programada para detectar nuevas actividades casi en tiempo real-. En definitiva, no requieren apenas de intervención humana para ser útiles. Por el contrario, si la información que se intercambia está asociada a inteligencia operacional, a las TTP de los atacantes, estos comportamientos suelen venir descritos de manera documental o, cuanto menos, más difícil de automatizar y convertir en actionable que los indicadores atómicos y calculados. Incluso un estándar como STIX, que permite la definición de TTP a través de sus objetos, no es inmediato de convertir en inteligencia automatizable.

¿Cuál es la situación, por tanto? La mayor parte de inteligencia compartida es fácilmente evadirle por un atacante y además tiene un tiempo de vida muy corto, por lo que no parece la más útil. En cambio, la inteligencia operacional, de mayor utilidad y mayor tiempo de vida, ligada a indicadores conductuales, apenas se intercambia, muy posiblemente porque suelen requerir intervención o tratamiento humano. Si queremos causar “daño” al atacante debemos focalizar nuestros IOC en sus TTP, no en sus indicadores de bajo nivel. 

Para poder identificar TTP se requieren relaciones entre eventos analizables; estas relaciones suelen ser temporales, pero también pueden estar asociadas a dependencias entre actividades, por ejemplo. Para poder detectarlas de forma automática necesitamos dos elementos; el primero de ellos es una capacidad de adquisición y procesamiento donde se registren acciones no sólo ligadas a alertas (a usos indebidos o anomalías) sino también a las actividades “normales” en el entorno. Esta capacidad suele ser el SIEM, donde se centraliza la información útil para la seguridad de las diferentes plataformas tecnológicas -desde el endpoint hasta la red-. 

Con la información ya adquirida y procesada, necesitamos una capacidad automática de análisis: algo que permita interrogar al SIEM y extraer TTP (mediante relaciones) de la información que almacena; diferentes fabricantes utilizan diferentes aproximaciones: Microsoft ha definido KQL, Kusto Query Language, mientras que Elastic proporciona también reglas para la caza de TTP en su tecnología. Pero cada una de estas aproximaciones funciona en el ecosistema de su fabricante y no en los demás, lo que impide un intercambio de inteligencia efectivo. SIGMA trata de aportar una aproximación genérica, independiente, y quizás pueda convertirse en un estándar de facto a corto plazo. Pero SIGMA tampoco permite de forma nativa la especificación de algunas TTP conocidas en actores avanzados, por lo que debería mejorarse o complementarse con capacidades de post proceso para poder ampliar el abanico de sus capacidades de detección.

En definitiva, intercambiamos la inteligencia más fácilmente usable, pero no la mejor; para detectar movimientos significativos de amenazas avanzadas tenemos que intercambiar inteligencia de más valor, y para eso necesitamos de una forma un otra que esta inteligencia sea procesada de forma automática y común a todos los entornos, en forma de estándar. Hasta que no consigamos esto, seguiremos focalizados en indicadores de poco valor. Eso sí, estos indicadores son también útiles y debemos seguir compartiéndolos como hasta ahora: aunque no sean lo mejor para la detección, tampoco están de más. “Simplemente” debemos ampliar nuestras capacidades, no desechar las actuales e implantar otras completamente diferentes.

Ver también en:

Comments

  1. Buenas,
    Muy interesante el artículo, pero me faltan ejemplos reales y prácticos en el artículo sobre esa inteligencia táctica. Al igual que en la inteligencia operacional hablas de IOCs con sus IPs o dominios, ¿Podrías mostrar ejemplos de TTPs tal y como comentas?

  2. Buenas!!
    Me alegro de que te interese el post :)
    Aunque hay discusión en los términos, la inteligencia táctica está ligada a IOC y hashes, p.e., y la operativa a TTP.
    Un ejemplo de TTP: táctica (ATT&CK) “Command and Control”, técnica “Dynamic resolution (T1568)”, subtécnica “DGA (.002)”. Un grupo como APT41 usa dominios dinámicos y cambia sus C2 mensualmente. El indicador atómico -el nombre de dominio- nos serviría un mes, aprox. Para detectar la técnica, más allá del IOC atómico concreto que pierde pronto su utilidad, tiramos de SIEM: vemos la navegación, p.e. recibiendo eventos del proxy, y buscamos DGA.
    Para buscar estos DGA tenemos que ir a queries que busquen por ejemplo entropías, p.e. si tuviéramos una regla SIGMA -este caso concreto no sé si se puede- que más allá de un dominio concreto (el indicador atómico) devolviera los dominios que superen una determinada entropía (el indicador conductual) y sean visitados N veces, podríamos detectar la técnica concreta con independencia del dominio usado.
    Espero haber sido de utilidad. Saludos!!
    Toni

  3. Saludos,
    Sin duda un tema muy interesante ya que con estos indicadores se trabajan todos los dias, como conclusion se debe de mejorar los indicadores operativos en cuanto a la automatizacion y que en parte se lo realiza con reglas SIGMA y me surge la pregunta, tienes ideas o formas de como mejorar esto y como podriamos colaborar con eso.

    Gracias, buen articulo.

  4. Hola James
    Una idea a la que estoy dándole vueltas es al tratamiento de los datos del SIEM vía lenguajes de programación, para disponer de toda la potencia de python, p.e., para poder especificar estos indicadores conductuales… es solo una idea y tengo que darle alguna vuelta adicional, ya iré comentando por aquí avances -si los hay-

    Gracias!
    Toni