Un
incidente de seguridad se define como un evento adverso que compromete o intenta comprometer la confidencialidad, integridad o disponibilidad de la información. De acuerdo con este concepto, la clave para determinar si un comportamiento “anormal” (ya sea real o sospechado) se trata de un incidente de seguridad o no, está en el
análisis preliminar del estado del sistema en dicho momento, que involucra la revisión de múltiples variables (aumento del tráfico de red, alto consumo de CPU o de memoria RAM, lentitud en la respuesta de procesos, ejecución de binarios extraños, cambios en los ficheros de configuración, etc.), que en conjunto permiten detectar o inferir que algo extraño está ocurriendo y de forma paralela empezar a perfilar una respuesta acorde con la tipología del evento.
Lamentablemente, el principal enemigo en este tipo de análisis preliminares es el tiempo, ya que la información del potencial incidente puede provenir de diferentes fuentes (revisiones manuales del sistema por parte del administrador, notificaciones de usuarios, alertas de diferentes herramientas de seguridad y monitorización instaladas (antivirus, FIM, IDS/IPS), etc.) y ser recibida y procesada por diferentes actores. Durante la ventana de tiempo en la cual se obtienen estos datos, se correlacionan y se analizan, el sistema estará expuesto a que el incidente esté amplificando su impacto o simplemente se trate de un falso positivo, desgastando injustificadamente al equipo encargado de la respuesta a incidentes.
Como resultado de esta primera fase de análisis, se deben iniciar los procesos de contención, erradicación y recuperación asociados. No obstante, si no hay definida una fase metodológica de detección o hay fallos procedimentales, documentales y/o técnicos en el proceso, la respuesta no será efectiva y cualquier acción adicional puede ser contraproducente (destrucción no intencional de evidencia, ejecución de programas maliciosos, etc.). Igual sucederá si el incidente vuelve a ocurrir y no se ha realizado una sesión de lecciones aprendidas y mejora continua que permitan optimizar el plan de respuesta a incidentes en el futuro.
Si ponemos en contexto todos estos elementos, los tiempos de respuesta a incidentes e investigación forense se verían claramente optimizados si se contara con una herramienta automatizada que permitiera una detección y clasificación rápida con base en comportamientos analizados de incidentes (“modus operandi”) involucrando diferentes elementos ya conocidos como direcciones IP, hashes de procesos maliciosos, cookies, cambios en el registro de Windows, controladores de hardware, puertos TCP/UDP, correos electrónicos, procesos en ejecución, ficheros en el disco, etc.
Frente a ello, han surgido múltiples iniciativas técnicas, dentro de las cuales resaltan los IoC (Indicators of Compromise – Indicadores de Compromiso). Se trata de un modelo basado por lo general en metalenguajes que permite registrar, parametrizar, comparar, categorizar y compartir la información conocida del comportamiento de incidentes analizados previamente desde una perspectiva holística, cubriendo todas las variables clave y propiedades que pueden dar pie a una detección y clasificación efectiva, analizando exclusivamente aquellos elementos relacionados sin perder el tiempo en análisis adicionales “a ciegas” que no ofrezcan valor en las conclusiones.
Modelos de Implementación de IoC
Desde la perspectiva de la industria han surgido diferentes modelos de implementación del concepto de IoC. A pesar que no existe un estándar de facto, a continuación se presentan algunos de los modelos más importantes que pueden ser empleados dependiendo de las necesidades de la organización:
Caso de Estudio: HACKING TEAM
En Julio de 2015 la compañía italiana Hacking Team ( http://www.hackingteam.it/) anunció públicamente que sus sistemas informáticos fueron comprometidos, incluyendo el código fuente de sus herramientas de monitorización y explotación, empleadas por múltiples entidades gubernamentales a nivel mundial. Este software utilizaba vulnerabilidades conocidas y de día cero (“zero day”) para instalarse de forma silenciosa y sin autorización del usuario afectado en los dispositivos objetivo.
Debido a la gran cantidad de atención mediática que recibió este evento, muchos ciudadanos de los países clientes de Hacking Team querían validar si sus sistemas eran monitorizados por esta solución. Una de las alternativas más óptimas para esta revisión estuvo basada en el uso de OpenIoC a través del aplicativo MILANO ( https://github.com/RookLabs/milano) provisto por la empresa Rook Security ( https://www.rooksecurity.com), que aprovecha las capacidades de los indicadores de compromiso para registrar, comparar y alertar de la existencia de binarios asociados al software de Hacking Team.
Posterior al análisis del código fuente del software de Hacking Team, se identificaron y perfilaron los binarios asociados (40+) y se incluyeron sus nombres y hashes (MD5, SHA1 y SHA256) dentro de un fichero XML siguiendo la estructura de OpenIoC (hackingteam_openIOC1-1.ioc). Para analizar su estructura, se puede emplear el aplicativo MANDIANT IoC Editor ( https://www.fireeye.com/services/freeware/ioc-editor.html):
Como se puede observar, el esquema XML establecido por OpenIoC permite la inclusión de múltiples características asociadas a elementos de un sistema que pueden estar afectadas por un incidente en particular. El listado exhaustivo de valores a parametrizar se puede encontrar en http://openioc.org/terms/Current.iocterms y http://schemas.mandiant.com/:
En el caso de MILANO, Rook Security creó su propio XML y desarrolló una herramienta propia para que las variables descritas en el fichero de OpenIoC fueran analizadas en el sistema y se reportaran los hallazgos para que el propio usuario tomara las acciones que considerara prudentes:
No obstante, el mismo fichero XML/IoC puede ser empleado con otras herramientas como MANDIANT IoC Finder ( https://www.fireeye.com/services/freeware/ioc-finder.html) o MANDIANT RedLine ( https://www.fireeye.com/services/freeware/redline.html), lo cual demuestra la portabilidad del formato, que es uno de los criterios básicos de esta iniciativa. Este mismo concepto se ha utilizado para la identificación de malware como Zeus, Stuxnet y Duqu y ha sido compartido para uso de la comunidad en el sitio de OpenIoC ( http://openioc.org) u otros como Flamer ( https://www.alienvault.com/open-threat-exchange/blog/flamer-indicators-of-compromise-openioc) y Red October ( https://www.alienvault.com/open-threat-exchange/blog/red-october-indicators-of-compromise-and-mitigation-data), provistos por AlienVault, quienes también han integrado el concepto de IoC como base de su plataforma Open Threat Exchange ( https://otx.alienvault.com/).
Otros repositorios de IoC se pueden encontrar en OpenIoCDB https://openiocdb.com/downloads/ y OpenIoC Bucket ( https://www.iocbucket.com/), así como integración con plataformas como MISP ( www.misp-project.org) y MANTIS (Model-based Analysis of Threat Intelligence Sources) Framework ( https://github.com/siemens/django-mantis).
Uso de IoC en conjunto con otras herramientas de identificación de Malware
Debido a las características de los IoC, su funcionalidad puede ser complementada con otras herramientas orientadas a la detección de malware como YARA ( http://plusvic.github.io/yara/), que permite la identificación de malware con base en la identificación de patrones de texto o binarios y el uso de expresiones booleanas para determinar su lógica:
Un ejemplo de integración entre reglas de IoC y reglas de YARA se puede encontrar en el aplicativo LOKI IOC Scanner ( https://github.com/Neo23x0/Loki), que usa la definición de IoC en el uso de hash de binarios y sus nombres y ubicaciones y la lógica de YARA para la identificación de patrones:
Adicionalmente, en OpenIoC se pueden insertar firmas de YARA dentro de la propia definición del formato XML para ser usadas de forma combinada. Esta inserción se puede realizar empleando el paquete openioc_to_yara, incorporado dentro del IoC Writter de MANDIANT ( https://github.com/mandiant/ioc_writer/tree/master/examples/openioc_to_yara).
Conclusión
La minimización de la ventana de exposición entre el tiempo de detección de un incidente y su respuesta es un factor clave en el proceso de respuesta a incidentes. Debido a la gran cantidad de información que se requiere para esta detección y la generación se conclusiones y/o inferencias que den paso a acciones de contención, corrección y recuperación, es necesario un procedimiento automatizado que facilite la identificación de incidentes ya analizados y permita compartir dichos hallazgos con la comunidad para una actuación global. Como respuesta a esta necesidad han surgido los IoC (Indicators of Compromise), que permiten perfilar un incidente, crear una línea base para la identificación de diferentes variables asociadas a ese incidente en particular y comparar un dispositivo potencialmente afectado contra dichos parámetros para dar una respuesta rápida y efectiva.
Autor: David Eduardo Acosta - CISSP, CISA, CISM, CRISC, PCI QSA, CCNA Security, OPST, CHFI Trainer, BS25999 L.A.
Departamento de Consultoría
Lamentablemente, el principal enemigo en este tipo de análisis preliminares es el tiempo, ya que la información del potencial incidente puede provenir de diferentes fuentes (revisiones manuales del sistema por parte del administrador, notificaciones de usuarios, alertas de diferentes herramientas de seguridad y monitorización instaladas (antivirus, FIM, IDS/IPS), etc.) y ser recibida y procesada por diferentes actores. Durante la ventana de tiempo en la cual se obtienen estos datos, se correlacionan y se analizan, el sistema estará expuesto a que el incidente esté amplificando su impacto o simplemente se trate de un falso positivo, desgastando injustificadamente al equipo encargado de la respuesta a incidentes.
 |
| Imagen 1. “Ventana de exposición” en la respuesta a incidentes |
Como resultado de esta primera fase de análisis, se deben iniciar los procesos de contención, erradicación y recuperación asociados. No obstante, si no hay definida una fase metodológica de detección o hay fallos procedimentales, documentales y/o técnicos en el proceso, la respuesta no será efectiva y cualquier acción adicional puede ser contraproducente (destrucción no intencional de evidencia, ejecución de programas maliciosos, etc.). Igual sucederá si el incidente vuelve a ocurrir y no se ha realizado una sesión de lecciones aprendidas y mejora continua que permitan optimizar el plan de respuesta a incidentes en el futuro.
Si ponemos en contexto todos estos elementos, los tiempos de respuesta a incidentes e investigación forense se verían claramente optimizados si se contara con una herramienta automatizada que permitiera una detección y clasificación rápida con base en comportamientos analizados de incidentes (“modus operandi”) involucrando diferentes elementos ya conocidos como direcciones IP, hashes de procesos maliciosos, cookies, cambios en el registro de Windows, controladores de hardware, puertos TCP/UDP, correos electrónicos, procesos en ejecución, ficheros en el disco, etc.
Frente a ello, han surgido múltiples iniciativas técnicas, dentro de las cuales resaltan los IoC (Indicators of Compromise – Indicadores de Compromiso). Se trata de un modelo basado por lo general en metalenguajes que permite registrar, parametrizar, comparar, categorizar y compartir la información conocida del comportamiento de incidentes analizados previamente desde una perspectiva holística, cubriendo todas las variables clave y propiedades que pueden dar pie a una detección y clasificación efectiva, analizando exclusivamente aquellos elementos relacionados sin perder el tiempo en análisis adicionales “a ciegas” que no ofrezcan valor en las conclusiones.
Modelos de Implementación de IoC
Desde la perspectiva de la industria han surgido diferentes modelos de implementación del concepto de IoC. A pesar que no existe un estándar de facto, a continuación se presentan algunos de los modelos más importantes que pueden ser empleados dependiendo de las necesidades de la organización:
- OASIS Cyber Threat Intelligence (CTI) https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti: Esta iniciativa está respaldada por algunos de los principales fabricantes de soluciones de seguridad y está orientada hacia la definición y estandarización de un conjunto de representaciones de información y protocolos para gestionar la necesidad de analizar, modelar y compartir datos de inteligencia contra amenazas informáticas. Está compuesto por tres subcomités: STIX (Structured Threat Information Expression - https://stixproject.github.io), TAXII (Trusted Automated Exchange of Indicator Information) y CybOX (Cyber Observable Expression - https://cybox.mitre.org).
- IODEF (Incident Object Description Exchange Format) – RFC 5070 www.ietf.org/rfc/rfc5070.txt: En diciembre de 2007 se publicó la RFC 5070, que contiene la descripción básica del esquema XML para el registro de variables técnicas relacionadas con incidentes conocidos para ser empleados principalmente por centros de respuesta a incidentes (CSIRT), orientado hacia la automatización en el procesamiento de datos de incidentes y la gestión de un formato común para construir herramientas interoperables para la gestión de incidentes.
- The OpenIoC (Open Indicators of Compromise) Framework http://www.openioc.org: OpenIoC es un esquema extensible de XML publicado bajo los términos de la licencia Apache 2, que permite describir las características técnicas que identifican una amenaza conocida, la metodología de un atacante u otra evidencia de compromiso para la detección rápida de brechas de seguridad en un sistema. Esta iniciativa surgió como parte de las estrategias de gestión de incidentes de MANDIANT (http://www.mandiant.com), quienes son reconocidos por sus análisis de casos de ciberespionaje a nivel mundial. Actualmente se encuentra en su versión 1.0 y la versión 1.1 se encuentra en formato DRAFT (https://github.com/mandiant/OpenIOC_1.1).
 |
| Imagen 2. Extracto de un fichero XML empleando OpenIoC para la identificación del malware Duqu |
Caso de Estudio: HACKING TEAM
En Julio de 2015 la compañía italiana Hacking Team ( http://www.hackingteam.it/) anunció públicamente que sus sistemas informáticos fueron comprometidos, incluyendo el código fuente de sus herramientas de monitorización y explotación, empleadas por múltiples entidades gubernamentales a nivel mundial. Este software utilizaba vulnerabilidades conocidas y de día cero (“zero day”) para instalarse de forma silenciosa y sin autorización del usuario afectado en los dispositivos objetivo.
Debido a la gran cantidad de atención mediática que recibió este evento, muchos ciudadanos de los países clientes de Hacking Team querían validar si sus sistemas eran monitorizados por esta solución. Una de las alternativas más óptimas para esta revisión estuvo basada en el uso de OpenIoC a través del aplicativo MILANO ( https://github.com/RookLabs/milano) provisto por la empresa Rook Security ( https://www.rooksecurity.com), que aprovecha las capacidades de los indicadores de compromiso para registrar, comparar y alertar de la existencia de binarios asociados al software de Hacking Team.
 |
| Imagen 3. Pantalla inicial de MILANO |
Posterior al análisis del código fuente del software de Hacking Team, se identificaron y perfilaron los binarios asociados (40+) y se incluyeron sus nombres y hashes (MD5, SHA1 y SHA256) dentro de un fichero XML siguiendo la estructura de OpenIoC (hackingteam_openIOC1-1.ioc). Para analizar su estructura, se puede emplear el aplicativo MANDIANT IoC Editor ( https://www.fireeye.com/services/freeware/ioc-editor.html):
 |
| Imagen 4. Edición del fichero OpenIoC para la detección del malware de Hacking Team empleando MANDIANT IoC Editor |
Como se puede observar, el esquema XML establecido por OpenIoC permite la inclusión de múltiples características asociadas a elementos de un sistema que pueden estar afectadas por un incidente en particular. El listado exhaustivo de valores a parametrizar se puede encontrar en http://openioc.org/terms/Current.iocterms y http://schemas.mandiant.com/:
 |
| Imagen 5. Parámetros de configuración en OpenIoC (extracto) |
En el caso de MILANO, Rook Security creó su propio XML y desarrolló una herramienta propia para que las variables descritas en el fichero de OpenIoC fueran analizadas en el sistema y se reportaran los hallazgos para que el propio usuario tomara las acciones que considerara prudentes:
 |
| Imagen 6. Pantalla final de MILANO |
No obstante, el mismo fichero XML/IoC puede ser empleado con otras herramientas como MANDIANT IoC Finder ( https://www.fireeye.com/services/freeware/ioc-finder.html) o MANDIANT RedLine ( https://www.fireeye.com/services/freeware/redline.html), lo cual demuestra la portabilidad del formato, que es uno de los criterios básicos de esta iniciativa. Este mismo concepto se ha utilizado para la identificación de malware como Zeus, Stuxnet y Duqu y ha sido compartido para uso de la comunidad en el sitio de OpenIoC ( http://openioc.org) u otros como Flamer ( https://www.alienvault.com/open-threat-exchange/blog/flamer-indicators-of-compromise-openioc) y Red October ( https://www.alienvault.com/open-threat-exchange/blog/red-october-indicators-of-compromise-and-mitigation-data), provistos por AlienVault, quienes también han integrado el concepto de IoC como base de su plataforma Open Threat Exchange ( https://otx.alienvault.com/).
Otros repositorios de IoC se pueden encontrar en OpenIoCDB https://openiocdb.com/downloads/ y OpenIoC Bucket ( https://www.iocbucket.com/), así como integración con plataformas como MISP ( www.misp-project.org) y MANTIS (Model-based Analysis of Threat Intelligence Sources) Framework ( https://github.com/siemens/django-mantis).
Uso de IoC en conjunto con otras herramientas de identificación de Malware
Debido a las características de los IoC, su funcionalidad puede ser complementada con otras herramientas orientadas a la detección de malware como YARA ( http://plusvic.github.io/yara/), que permite la identificación de malware con base en la identificación de patrones de texto o binarios y el uso de expresiones booleanas para determinar su lógica:
 |
| Imagen 7. Regla de YARA para la detección del malware Zeus |
Un ejemplo de integración entre reglas de IoC y reglas de YARA se puede encontrar en el aplicativo LOKI IOC Scanner ( https://github.com/Neo23x0/Loki), que usa la definición de IoC en el uso de hash de binarios y sus nombres y ubicaciones y la lógica de YARA para la identificación de patrones:
 |
| Imagen 8. Pantalla de inicio de LOKI IOC Scanner |
Adicionalmente, en OpenIoC se pueden insertar firmas de YARA dentro de la propia definición del formato XML para ser usadas de forma combinada. Esta inserción se puede realizar empleando el paquete openioc_to_yara, incorporado dentro del IoC Writter de MANDIANT ( https://github.com/mandiant/ioc_writer/tree/master/examples/openioc_to_yara).
Conclusión
La minimización de la ventana de exposición entre el tiempo de detección de un incidente y su respuesta es un factor clave en el proceso de respuesta a incidentes. Debido a la gran cantidad de información que se requiere para esta detección y la generación se conclusiones y/o inferencias que den paso a acciones de contención, corrección y recuperación, es necesario un procedimiento automatizado que facilite la identificación de incidentes ya analizados y permita compartir dichos hallazgos con la comunidad para una actuación global. Como respuesta a esta necesidad han surgido los IoC (Indicators of Compromise), que permiten perfilar un incidente, crear una línea base para la identificación de diferentes variables asociadas a ese incidente en particular y comparar un dispositivo potencialmente afectado contra dichos parámetros para dar una respuesta rápida y efectiva.
Autor: David Eduardo Acosta - CISSP, CISA, CISM, CRISC, PCI QSA, CCNA Security, OPST, CHFI Trainer, BS25999 L.A.
Departamento de Consultoría