La ciberseguridad ha cambiado, en todos los ámbitos. Desde que se llamaba «Seguridad de la Información», antes de la moda de poner a todo el prefijo «ciber», cuando las empresas implementaban una seguridad de «foso y castillo» centrada en proteger un perímetro físico. Los defensores usábamos otras herramientas, otros métodos.
Los atacantes también han cambiado. Por un lado las motivaciones son diferentes, ahora hablamos de cibercrimen, antes se hablaba más de hacktivismo. Pero también han cambiado las tácticas de ataque, obviamente a la par que la tecnología o las formas de defendernos.
Y en este punto precisamente, tan obvio pero a veces tan olvidado, es donde queremos hacer foco hoy. Está claro que estamos en un escenario cambiante: los atacantes se adaptan y modifican sus estrategias de ataque, y los defensores y las empresas también van evolucionando. Esto se puede ver en el largo plazo a lo largo de los años, pero realmente donde importa mucho es en el corto plazo.
Las empresas despliegan multitud de tecnologías de seguridad, que deberían trabajar en armonía y, desde cierto punto de vista, hasta sincronizadas. Además, se usan estrategias y políticas que intentan atajar riesgos y mejorar el estado de seguridad general de la organización. Y mientras, los atacantes tratan de penetrar en las defensas: malware y multitud de variantes se envían por correo o se ponen en sitios de descargas, escaneos e intentos de explotación de vulnerabilidades desde infinidad de direcciones IPs que van cambiando todos los días, infraestructuras de compromiso y C2C desplegados y usados en intrusiones no autorizadas continuamente…
Es un entorno extremadamente hostil. Las soluciones de seguridad utilizadas se están actualizando continuamente para adaptar su protección: firmas de malware, reglas de nuevas vulnerabilidades, indicadores de compromiso de sitios maliciosos… Pero no es aceptable tener las soluciones de seguridad distribuidas sin saber qué está pasando. Las empresas contratan SOCs (Security Operation Centers) que usan herramientas SIEM (Security Incident & Event Management) para poder centralizar todos los eventos de esos productos y de los eventos que suceden por su infraestructura y poder alertas ante situaciones de riesgo. Incluso los SOC están evolucionando en las herramientas y métodos que usan para adaptarse, aunque esto daría para otro artículo completo…
En medio de toda esta vorágine de información a analizar, surgió de la comunidad la práctica de compartir Indicadores de Compromiso, o IoC de sus siglas en inglés (Indicator of Compromise). Un IoC es aquella información relevante que describe cualquier incidente de ciberseguridad, actividad y/o artefacto malicioso, mediante el análisis de sus patrones de comportamiento. Por ejemplo, direcciones IPs, hashes de ficheros, dominios maliciosos, etc. La idea sobre esto es que, «si conocemos lo que está atacando a otros, podré protegerme antes que me ataquen a mi». Por este motivo, estas listas de IoC se pueden integrar en diferentes soluciones de seguridad, como Firewalls, EDRs/Antivirus, Proxys, SIEM, etc. El problema de este enfoque se resume en lo que denomina «La pirámide de dolor«:
Esta pirámide indica lo «doloroso» que sería para un atacante el descubrimiento y la protección por parte de los defensores de sus medios e infraestructura de ataque. Por ejemplo, cambiar el valor hash de un fichero es trivial, y cambiar de dirección IP desde la que atacan es fácil. Tener este dato nos protege por un período de tiempo muy muy corto y realmente no impacta mucho en la cadena de ataque del adversario. Basar la defensa en indicadores de compromiso es útil y necesario, pero es muy cortoplacista. No debe ser el foco de nuestra actividad de ciberinteligencia, sino un producto más que sabemos que tiene sus limitaciones y que debe ser gestionado adecuadamente.
Así, podemos ir hasta arriba de la pirámide, donde residen aquellos elementos que más daño harían a los atacantes: las técnicas, tácticas y procedimientos (TTPs, Tactics, Techniques and Procedures). Esto es, la forma que tiene el atacante de actuar, su modus operandi. Al fin y al cabo, los atacantes son personas, con sus especializaciones en ciertas técnicas de ataque y en ciertas herramientas. Si somos capaces de bloquear estas técnicas, innovar nuevas le resultará costoso y, por lo tanto, el objetivo atacado dejará de ser rentable.
A través del proyecto «Summiting the Pyramid» de MITRE Engenuity, se puede entender mejor esta pirámide con la «traducción» y capacidad analítica de cada «escalón»:
Para identificar todas las tácticas y técnicas posibles, desde MITRE se desarrolló el marco de trabajo MITRE ATT&CK, que contiene una base de conocimiento de todas aquellas tácticas y técnicas conocidas hasta este momento, disponiéndolas en forma de matriz:
Y es en este momento, una vez introducidas las TTPs, cuando volvemos a un punto anterior de este artículo. Al momento en el que se comentaba que los atacantes se adaptan y evolucionan y los defensores parece que jugamos un eterno juego del gato y el ratón. En este juego, imaginemos ¿qué pasaría si pudiéramos disponer, de forma sistematizada, todos los TTPs descubiertos usados por los atacantes junto a los IoCs de compromiso asociados? Podríamos identificar cómo se adapta el adversario a las nuevas tecnologías de defensa, los cambios que adopta, las nuevas técnicas o procedimientos o herramientas que utilizan los diferentes grupos de adversarios.
¿Y esto para que sirve? Muy sencillo. Si sabemos que existe un actor que realiza cierto tipo de ataques (por ejemplo, ransomware, no vamos a ser muy originales), y que siempre usa como vector de entrada el phishing con un enlace que emula una página de inicio de Office365 para conseguir credenciales, pero que de pronto empieza a usar como vector de entrada las VPNs a través de explotación de vulnerabilidades (caso real), ¿no podemos hacer nada preventivo? ¿Tenemos que esperar, de brazos cruzados, a ver si nos toca? ¿O bien podemos priorizar el parcheo de los dispositivos vulnerables, cambiar la configuración por otra más segura para mitigar o contener el ataque, y proponer controles de monitorización adicionales para identificar intentos de entrada o bien un compromiso en sus fases tempranas? Por supuesto que podemos hacer algo, pero para eso, es necesario conocer que el actor ha cambiado de técnica.
El anterior ejemplo es muy típico, otro que nos gusta poner es el siguiente: si sabemos que el actor PYTA31 descarga un malware llamada «WhiteSnake» desde determinadas direcciones IP y que este malware tiene ciertos hashes (IoCs típicos), podemos bloquearlo y pensar que estamos seguros. Pero como sabemos, cambiar un hash o una IP en un ataque es muy sencillo, con lo que esta defensa no será efectiva. Pero si sabemos que este actor lo que hace es distribuir este malware a través de paquetes PyPI maliciosos y que usa ciertas librerías de python, y que posteriormente descarga un agente OpenSSH (no es un malware, ¡es una herramienta legítima usada para hacer el mal!) y se conecta al sitio serveo.net para mantener la persistencia en sistemas Windows, con esta información podemos protegernos mucho mejor. Por ejemplo, si evitamos las conexiones a serveo.net detenemos el cadena de ataque. ¿Puede usar otra web? Claro, pero ya le resulta más costoso, porque su killchain la ha construido usando esta plataforma. Si evitamos conexiones salientes por SSH desde equipos Windows a internet, también detenemos su técnica de control y persistencia. Si evitamos el uso de python en sistemas que no son necesarios, teniendo un adecuado control de aplicaciones y librerías, también podemos detener el ataque en sus fases tempranas e incluso evitar por completo. Y si monitorizamos todo en el SOC, podemos detectar la actividad anómala de forma temprana. Claro que para poder tomar estas medidas… hay que conocerlas y hay que saber que este actor trabaja así. Estamos en el punto anterior de nuevo.
Este es el principio del concepto «Threat-Informed Defense» (concepto en el que se habló en un artículo anterior). Esto significa que se debe realizar esta actividad de forma sistematizada, conocer cómo actúan los atacantes, descubrir si somos vulnerables y actuar de forma proactiva. Nuestro SOC debe ser dinámico, igual que lo es el ecosistema de amenazas al que nos enfrentamos. Antes hemos puesto un ejemplo con un actor. Hagamos el ejercicio a escala de forma continuada, conociendo y actualizando nuestros conocimientos sobre las técnicas y procedimientos de ataques de los diferentes actores, y propagando esta información a todos los miembros del SOC, lo que nos permite:
- Adaptar de forma continua nuestras defensas a las nuevas técnicas de ataque.
- Saber si nuestros clientes tienen la capacidad de protegerse ante estas técnicas y poder notificar de forma temprana.
- Proponer de manera proactiva mejoras y cambios en la postura de seguridad, basados en datos reales de cómo están atacando, aportando un mayor valor añadido.
- Medir las mejoras en el tiempo. Sabiendo las técnicas que tenemos cubiertas y su madurez en un momento dado (le llamamos hacer un mapeo ATT&CK), podemos compararlo con otra evaluación más adelante y ver cómo hemos mejorado: si las técnicas están más maduras, si cubrimos más técnicas, y los motivos de la inversión realizada.
En Perseus creemos que este es el camino adecuado. Por eso, nuestro SOC ha adoptado el modelo «Threat-Informed Defense», apoyado en una fuerte actividad de Cyber Threat Intelligence, para adaptar las capacidades de protección y detección a las necesidades de cada momento. ¿Quieres verlo? Ven a conocernos y te lo enseñamos.
Referencias
https://mitre-engenuity.org/cybersecurity/center-for-threat-informed-defense/
https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
Miguel Tubía
Responsable del CERT
miguel.tubia@pers.eus | Móv: 664 367 173
PGP KeyID: 0xF51D6746
Parque Tecnológico Edif. 205B | 48170 Zamudio – Bizkaia
