¿Qué es la inteligencia en ciber?

Como estaba preparando material para algunos máster que imparto, y como en el día a día a veces me encuentro con situaciones donde veo caras de póker cuando hablamos de inteligencia, voy a aprovechar para escribir un artículo básico que espero os sea de ayuda.

Vamos a ser serios. Coger un feed de IPs y meterlo en el SIEM no es hacer inteligencia. Y a veces tristemente las empresas de servicios venden la inteligencia así. A veces parece que se venden los IOCs a kilo. Eso sí, cuando como analista de IR me toca ir a un incidente, esos feeds nunca levantan alertas. Es más, en muchos casos, cuando pregunto para qué hacen inteligencia, me miran con cara de cervatillo en mitad de la carretera. Una vez escuché: «Porque es lo que está de moda ahora».

En otros casos, nos aproximamos a clientes para añadir nuestra inteligencia a sus procesos de ciberseguridad. No creáis que es fácil mantener la compostura cuando te recriminan que les cobres por un feed de inteligencia cuando en internet hay muchos gratuitos.

Vamos a hacer un pequeño repaso a las bases. Como referencia, siempre recomiendo el libro que redacta la empresa de inteligencia Recorded Future. El Intelligence Handbook. Lo podéis encontrar aquí.

La base para la inteligencia

Antes de empezar, tres definiciones básicas basadas en el glosario del NIST:

• Seguridad: Establecimiento y mantenimiento de medidas protectoras que permiten a una organización desempeñar su misión o funciones críticas a pesar de los riesgos planteados por las amenazas al uso de sus sistemas. Las medidas protectoras pueden implicar una combinación de disuasión, evitación, prevención, detección, recuperación y corrección, las cuales deben formar parte del enfoque de gestión de riesgos de la organización.
• Inteligencia: El producto resultante de la recopilación, procesamiento, integración, análisis, evaluación e interpretación de la información disponible relativa a países o áreas extranjeras; o información y conocimiento sobre un adversario obtenido mediante la observación, investigación, análisis o comprensión.
• Amenaza (Threat): Cualquier circunstancia o evento con el potencial de impactar negativamente en las operaciones organizacionales (incluyendo la misión, funciones, imagen o reputación), activos organizacionales o individuos, a través de un sistema de información mediante el acceso no autorizado, destrucción, divulgación, modificación de la información y/o denegación de servicio.

CTI = Cyber Threat Intelligence

Por tanto, según el mismo glosario de la NIST, la CTI es la información sobre ciberamenazas que ha sido agregada, transformada, analizada, interpretada o enriquecida para proporcionar el contexto necesario para los procesos de toma de decisiones. Por tanto, y por favor dejadme insistir en esto, una lista de «IPs malas» no es inteligencia. Un «bloquea este hash» que lo he leído por ahí, no es inteligencia. Esto ni está agregado, ni enriquecido, ni mucho menos sirve para la toma de decisiones.

Por este motivo, cuando leemos o hacemos cursos de Intel, siempre nos dan las mismas definiciones. La clásica foto del embudo. Cómo el dato pasa a ser información y cómo la información pasa a ser inteligencia. Aunque sea muy clásica, este es el trabajo de inteligencia: pasar de la recopilación de datos a tener una información estructurada que sirva para tomar decisiones.

• Dato: Hechos concretos o agregados en base a estadística.
  • Conexión correcta hacia la IP_A
• Información: La información es un conjunto de datos contextualizados. La información es Dato + Contexto.
  • IP_A se usó como C&C por el malware_A en una campaña de hace 2 meses
• Inteligencia: Recopilación de datos e información recopilada y agrupada que sirve para la toma de decisiones.
  • IP_A y malware_A son usadas por el actor identificado como Actor_A que tiene foco principal en compromiso de sistemas informáticos de procesos electorales dentro de países de Europa.

Conclusión: Como analista de inteligencia en un equipo dedicado a hacer CTI, vamos a recopilar datos, relacionarlos para crear información. La respuesta a las preguntas que nos planteemos es la inteligencia. Y recordad que no es solo inteligencia, es inteligencia basada en amenazas. Es CTI. Nos interesa saber quién, cómo y por qué ataca y cómo usar esa información para tomar decisiones para protegerme.

El proceso de CTI

El embudo está bonito. Pero no pasa solo. En ciberseguridad manejamos mucha información, muchos datos; aportar contexto no siempre es fácil, y tener una herramienta que nos permita trabajar de manera colaborativa en convertir los datos en información e inteligencia no es trivial. En ciberseguridad he aprendido que es más complejo aportar coherencia y orden que el reto técnico que la cuestión supone.

Es por esto que la CTI debe seguir un proceso. Normalmente identificamos 6 fases en este proceso (pongo sus nombres en inglés, que aunque me duela, creo que se entienden mejor):

1. Direction: Se traduce por la dirección. No es más que saber a dónde vamos. Qué objetivos nos marcamos con el proceso de inteligencia. Un error muy frecuente en empresas que he visto que empiezan a usar openCTI. Hacer inteligencia no es un fin en sí mismo, hay que tener claro para qué. Y desplegar un openCTI y meter feeds porque está de moda o porque está guay te lleva a muchos errores. Porque empiezas a configurar la herramienta y a agregar los datos sin tener en mente el uso que le vas a dar luego.
2. Collection: Una vez que está claro qué queremos hacer, abordamos esta fase, la de recopilar los datos. No recopilamos datos infinitos. El qué recopilar viene determinado por los objetivos que nos hemos marcado en la fase anterior. Aquí entra el concepto de fuentes de inteligencia que veremos luego.
3. Processing: En el procesado, cogemos la información que hemos recopilado y la transformamos en un formato común y procesable por el resto de fases. Cada fuente es de su padre y de su madre, y sin un procesado no podemos trabajar con ella. No es fácil correlacionar la info que sale en un PDF de un reporte con un listado de IPs en formato CSV.
4. Analysis: Ya tenemos la información seleccionada (fase 1), recopilada (fase 2) y transformada para ser procesada (fase 3). Recordad el embudo o el cono. El objetivo es pasar del dato a la inteligencia. La fase de análisis es el core de este proceso. En el análisis tomamos los datos y damos respuesta a las preguntas que surjan en base a los objetivos planteados. Es la parte más manual. Requiere relacionar la información, agruparla, ampliar información…
5. Dissemination: Esta fase es por decirlo de alguna manera, el final del flujo. Es depositar la inteligencia allá donde debe ser consumida en el formato y estilo concreto que el destino requiere. Y como la inteligencia se puede usar en casi todos los procesos, esta fase juega un papel fundamental. No es lo mismo la inteligencia aportada a una lista de bloqueo de mi FW que a un comité ejecutivo que debe decidir dónde repartir la inversión en materia de ciberseguridad. En esta fase desarrollamos también las vías tecnológicas y los criterios por los cuales desplegar la inteligencia que hemos generado.
6. Feedback: Esta fase es vital. Esto no para. Ningún proceso de inteligencia debe ser estático. La pregunta base debe ser: ¿El output que hemos generado en la fase de análisis y entregado en la fase de dissemination cumple y en qué medida cumple los objetivos que nos hemos propuesto en la fase de dirección? Las conclusiones que obtengamos al plantearnos esta pregunta debe hacer mejorar nuestro flujo completo.

Esto parece un rollo teórico, pero de verdad, es fundamental. Fijaros que estas fases son abiertas, y en cada proceso, cada organización se implementará de una manera o de otra. Dependiendo de los objetivos, el desarrollo será diferente. Pero las fases siempre se deben dar. Si miramos nuestro flujo y no somos capaces de ver estas fases, tendremos problemas tarde o temprano. Creedme que es muy frustrante dar una información y que te digan «no es lo que esperaba» o «no le veo valor».

Fuentes de inteligencia

Crear o usar fuentes de inteligencia es lo que hacemos en la fase 2 del ciclo. En la fase de collection. No es lo mismo recopilar el informe finalizado de un vendor de ciberseguridad sobre una investigación de la manera de proceder de un nuevo actor que un listado de IPs que se actualiza cada día que identifica nodos de salida de la red Tor.

No hay una definición formal de tipo de fuentes de inteligencia. Para hacer un repaso y hacer una clasificación, vamos a usar la que define el ODNI (Office of the Director of National Intelligence) de Estados Unidos. Está centrado en una definición para la inteligencia militar, pero aplica al contexto de CTI. El ODNI define 6 tipos de fuentes:

• SIGINT: Se centra en la interceptación y análisis del tráfico de red, protocolos de comunicación y captura de paquetes (PCAP) para identificar exfiltración de datos o comunicaciones con servidores de comando y control (C2). Es normalmente inteligencia interna. Recopilar correos entrantes y salientes, tráfico de red entrante y saliente, incluso de documentos generados y recibidos…
• IMINT: Es fuentes basadas en imágenes o video. En ciber se usa menos. Pero tampoco es despreciable. Las imágenes de notas o pantalla de rescate de un ransomware, por ejemplo, son fuentes de inteligencia que se almacenan.
• MASINT: Se aplica a la «huella digital» única, como el análisis de certificados SSL, huellas de servidores (JARM), firmas de archivos (hashes) o el comportamiento específico (heurística) que identifica a una herramienta o grupo de ataque. Un hash de un malware o el certificado SSL usado para una conexión contra C&C.
• HUMINT: Consiste en la interacción directa con actores de amenazas en foros cerrados o canales de mensajería (como Telegram) mediante identidades encubiertas para obtener información sobre sus motivaciones, objetivos y próximos ataques.
• OSINT: Es la recolección de datos técnicos de acceso público, como registros de dominios (WHOIS), bases de datos de vulnerabilidades (CVE), repositorios de código (GitHub) y menciones de amenazas en redes sociales o blogs de seguridad. Es una ciencia en sí misma, ya que de fuentes abiertas se puede obtener una gran cantidad de información
• GEOINT: Se utiliza para geolocalizar la infraestructura del atacante (IPs, centros de datos) y correlacionar ataques digitales con eventos físicos o tensiones geopolíticas en regiones específicas del mundo.

Quedaos principalmente con HUMINT y OSINT como fuentes de investigación, y SIGINT y MASINT como referencia al tipo de datos que recopilamos. Pero insisto en que esto es muy militar/gubernamental. Es solo algo de info para que os suenen las palabras.

Indicadores de compromiso (IoCs)

En este punto está bien que comencemos a hablar de qué es un indicador de compromiso. Una definición que me gusta: un IoC es cualquier evidencia digital que nos indica, con un alto nivel de confianza, que un sistema o red ha sido vulnerado.

Hay muchos tipos de indicadores. Una comunicación observada hacia una IP, una resolución de un dominio, un hash de un fichero, un payload de una conexión de red… En inteligencia establecemos una pirámide para los IOCs que llamamos la pirámide del dolor. Metemos los tipos de indicadores en una clasificación.

En la base tenemos los indicadores volátiles. Son baratos de obtener para nosotros, pero triviales de rotar para el atacante; un simple cambio de un bit en un archivo genera un hash nuevo y tu detección muere. A medida que escalamos, dejamos de mirar valores estáticos para observar comportamientos. En la cúspide, donde el ‘dolor’ es real, identificamos patrones que el adversario no puede cambiar sin quemar meses de desarrollo o entrenamiento. Si detectas un TTP o una manera de proceder con una herramienta, vas a detectar a este atacante por mucho tiempo.

No vamos a entrar a explicar qué es una IP o un dominio. Creo que queda bastante claro. Lo que sí vamos a ver es algunos aspectos a tener en cuenta cuando hablamos de IOC.

TTP

En CTI, cuando hablamos de TTPs (Tactics, Techniques, and Procedures), estamos diseccionando el comportamiento del atacante. Es la cúspide de la Pirámide del Dolor porque, a diferencia de una IP, un atacante no puede cambiar su forma de trabajar de la noche a la mañana sin una inversión enorme en tiempo y entrenamiento.

• Tactics (Tácticas): Es el «qué» busca el atacante. El objetivo de alto nivel. Ejemplos: «Acceso Inicial», «Persistencia», «Exfiltración».
• Techniques (Técnicas): Es el «cómo» pretende lograr esa táctica. Por ejemplo, para lograr «Persistencia», el atacante puede usar una técnica de «Scheduled Task» (Tareas programadas).
• Procedures (Procedimientos): Es la implementación específica. El nivel de detalle técnico puro. Por ejemplo: El actor usa el comando schtasks /create /sc minute /mo 30 /tn 'OneDrive Update' /tr 'C:\Users\Public\update.exe'

Imaginemos que estamos analizando una amenaza y nos damos cuenta de que el atacante procede de la siguiente forma: cuando el actor obtiene acceso inicial a la máquina, se descarga un fichero txt. Este fichero txt es un código base64. El actor ejecuta un decode del base64 y luego usa una clave en XOR para obtener el contenido real. Resulta que el contenido real es un script de PowerShell que le sirve para ejecutar las acciones maliciosas.

Podemos registrar el hash final del script y añadirlo como IOC. Pero, ¿cuánto le cuesta al actor cambiar un carácter y cambiar el hash? Nada. En cambio, si registramos el comportamiento completo como un IOC, ya obligamos al actor a cambiar su manera de proceder. Eso ya no es tan sencillo. Y ese es el valor de la TTP y por qué está en lo más alto de la pirámide.

Para tener cierto orden en registrar las TTPs y darles una clasificación común que todos manejemos, existe MITTRE ATT&CK. Define una clasificación para las TTPs que nos hace más fácil su clasificación, compartición y uso.

Muchas veces, cuando leemos un informe de un ataque o de una campaña de un actor, vemos que a las accciones que describen les asocian un código. Algo como T1059. Esto se refiere al código de la TTP de MITTRE ATT&CK.

Ciclo de vida de un IoC

Yo he trabajado muchas veces en un SOC. Y es muy habitual cometer (entre otros) este error. Y es el de añadir a los sistemas indicadores de compromiso y no ponerles una caducidad. Me ha pasado en multitud de ocasiones que llamen al nivel 3 por una alerta escalada porque ha saltado un IoC y es crítico. Resulta que el IoC es una IP que se añadió hace 6 años de un incidente que tuvieron. En el 100% de los casos se trata de un falso positivo. Esa IP evidentemente ya no la usaba el atacante. En muchos casos el atacante ya ni se encuentra activo.

Por este motivo es vital establecer un ciclo de vida para los indicadores. Debemos de tener en cuenta cosas como:

• Criticidad: Establecer reglas de criticidad. No todo IoC que salte puede ser crítico. Me pasa mucho con los nodos de red TOR. Cualquier proceso, anuncio de navegador… hace saltar conexiones contra nodos de red TOR. No podemos «ensuciar» nuestro tratamiento de alertas dándole a todo la máxima criticidad. Hay que establecer criterios, normalmente en forma de score o severidad.
• Enriquecerlos y contextualizarlos: No meterlos a los sistemas sin contexto. De verdad que luego te vuelves loco. Usemos las herramientas que tenemos para decir por qué se añade la IP, con qué está relacionada. Y si podemos hacer una consulta whois para añadir más datos, mejor.
• Reglas de decay: En muchos sistemas nos dejan establecer reglas de decay. Según el tipo de IoC, reglas que nos permitan ir bajando su criticidad con el paso del tiempo. En openCTI podemos establecer reglas. Que una IP reduzca su score a 0 tras 3 meses, pero que si se observa en la red y se confirma que sigue activa, renueve el contador. Esto es vital

El criterio que yo uso en la mayoría de casos (esto no es ninguna Biblia, solo un criterio personal):

Hay veces que me preguntan por qué no dejar los hashes indefinidamente. Un hash es inequívoco; si se detecta, es que es el fichero que pretendíamos detectar. Con el paso del tiempo he visto que:

• Tras más de un año, es muy poco probable que veamos ese hash en ningún sitio. Los atacantes casi siempre varían el hash incluso dentro de la misma intrusión. En incidentes vemos cómo el despliegue del malware de control remoto cambia el hash para cada máquina que infecta.
• Normalmente, las máquinas disponen de sistemas de protección anti malware o EDR. A lo largo de un año es muy posible que ese hash ya esté incorporado a las firmas de dichos sistemas.
• Los sistemas suelen tener una capacidad limitada de IoCs. Aunque suele ser grande, con el paso del tiempo se va acumulando mucha información. Luego repasar los IOCs para decidir cuál dejar y cuál quitar es un dolor. Es mejor que se vayan renovando solos y caducando con el paso del tiempo. Hasta los hashes.

Por este motivo los dejamos caducar al año y mantenemos los sistemas lo más limpios posible de ruido

Defang de IOCs

A la hora de indicar y compartir IOCs usamos un formato que llamamos defang. Defang es algo similar a «quitar los colmillos». Lo que pretendemos es que a la hora de compartir los IOCs, los sistemas de procesado de texto no transformen el IOC en algo clicable y comprometamos un equipo. Por ejemplo, si pasamos una URL, que el PDF, Word o Email no transforme la URL en un enlace clicable, haciendo que quien reciba la información pueda acceder a la URL maliciosa por error.

A mí me gusta hacer los defag con CyberChef, pero hay muchas herramientas.

Tipos de inteligencia

Recordad lo que hablábamos antes. La fase 1 de la inteligencia es marcar la dirección. Qué necesidades tenemos y qué queremos que aporte la inteligencia. Muchas veces se plantea de la siguiente forma: Qué preguntas queremos que la inteligencia nos responda. Y una de las últimas fases es la de Dissemination. Es decir, saber generar los resultados y las respuestas en la forma correcta para cada receptor.

Aunque hay muchas formas de ejecutar el flujo, de plantearnos las preguntas y de generar inteligencia, las podemos agrupar en dos grandes bloques:

• Inteligencia OPERACIONAL: Es básicamente el conocimiento sobre las amenazas que se están produciendo. Vulnerabilidades, incidentes, actores y su forma de proceder, variantes de malware… El objetivo de la inteligencia operacional es decirles a los equipos de seguridad qué están haciendo los malos.
• Inteligencia ESTRATÉGICA: Si la inteligencia operacional aporta qué está pasando ahora, la inteligencia estratégica aporta una visión a más largo plazo. Analiza patrones de ataque, eventos geopolíticos, tendencias… Suele servir para proporcionar una visión más amplia y menos técnica que favorezca la toma de decisiones

Algunos me diréis que se me ha olvidado la táctica. Creo que agrupando la inteligencia en estos dos bloques nos entendemos todos mejor. A veces la línea entre táctica y operacional es muy fina y, dividiendo en estos dos grandes bloques, simplificamos la cosa.

Extra: El riesgo

Os dejo este capítulo extra para hablar del riesgo y cómo la inteligencia es clave en este proceso.

Cuando empezamos en ciber, no queremos líos. Dame la terminal y el nmap. Dame ese log que lo mire… Pero conforme vas avanzando, sabes que en ciber es imposible cubrirlo todo. Que todo se basa en priorizar y cubrir las cosas que más te afectan. Pero, ¿cómo valoramos qué es lo que más nos afecta? Aquí entra en juego el concepto de riesgo, y es algo sobre lo que la inteligencia tiene mucho que decir.

La fórmula habitual para valorar el riesgo de algo es una multiplicación de dos factores:

• Probabilidad de que el hecho se materialice
• Impacto o daño que me causa si el hecho se da

El riesgo de salir a la calle y que me caiga un meteorito es bajo. Aunque el impacto sea muy alto si el meteorito me cae, la probabilidad de ocurrencia es extremadamente baja. Esto hace que mi dedicación a prepararme para ese evento sea menor que otro hecho con un riesgo mayor, como que me moje si llueve. Aunque el impacto sea menor, la probabilidad es mucho más alta. En la toma de decisiones, es más sensato que priorice llevarme un paraguas antes que comprar un búnker antimeteoritos.

En este aspecto, la inteligencia juega un papel fundamental. ¿El riesgo de que me dé una insolación por la calle o de que me moje por lluvia es el mismo siempre? ¿Cómo valoro el riesgo de ambos eventos y cómo priorizo la medida? ¿Me echo crema o me llevo un paraguas? Si es agosto en el hemisferio norte me echo crema, pero si es en el sur, lo mismo debo llevarme un paraguas. Y si estamos en Vietnam en época de monzón, lo mismo la medida del paraguas no es suficiente.

Es la inteligencia la que nos debe dar los datos. Tomar primero datos desagregados, construir porcentajes y tendencias, y finalmente usarlos para la toma de decisiones. El famoso cono. Este es el proceso de la inteligencia.

El riesgo en ciber

En el caso de la ciberseguridad, no es un meteorito lo que nos puede afectar. Es que una amenaza aproveche una vulnerabilidad para causar un daño a la seguridad de la información. Por eso la fórmula que usamos en ciber es:

Es por tanto la CTI la que debe dar los datos sobre las amenazas, vulnerabilidades y la probabilidad. Y que estos datos sirvan para construir los mapas de riesgos y ayuden en la toma de decisiones.

La inteligencia nos va a permitir definir con precisión las vulnerabilidades y las amenazas, la probabilidad de ocurrencia según quién seamos y dónde estemos, la probabilidad de que nos ataque un actor u otro según nuestro negocio… Esto nos va a permitir ser mucho más precisos en nuestra fórmula de valoración de los riesgos. Y medir bien los riesgos es clave para protegernos de lo que de verdad nos importa.

Es clave que en ciberseguridad prioricemos llevarnos un paraguas antes que gastarnos millones en un búnker antimeteoritos.