Automatización de pruebas ATT&CK con SOAR y Atomic Red Team

 

MITRE ATT&CK es el marco de facto para que las organizaciones midan su postura de defensa. ATT&CK proporciona verticales categóricas en forma de táctica, que se alinean con las metodologías comunes que utilizan los atacantes. Dentro de estas verticales, hay un conjunto (y subconjuntos) de formas comunes en las que los atacantes implementan una táctica (vertical). Estas se conocen como técnicas.

Algunas técnicas pueden ser comunes en varios sistemas operativos. Esto suele equivaler a una definición amplia de técnica. Como defensores, esto significa que debemos comprender cómo una sola técnica puede implementarse en múltiples plataformas, lo cual puede resultar difícil para muchos, incluyéndome a mí. Afortunadamente, organizaciones como Red Canary han proporcionado a nuestra comunidad un marco de trabajo completo para facilitar la prueba de estas técnicas.

Red Canary ha abierto el código del equipo Atomic Red Proyecto lanzado hace varios años para ayudar a la comunidad de seguridad proporcionando un conjunto de pruebas atómicas (Atómicas) asignadas al marco MITRE ATT&CK. Cada prueba atómica se asigna a una técnica específica dentro de ATT&CK y proporciona una o más pruebas que pueden ejecutarse en un sistema. Estas pruebas atómicas están diseñadas para simular o emular cómo un atacante usa una técnica contra su entorno.

Además de proporcionar un conjunto de pruebas ejecutables, Red Canary también ofrece múltiples marcos de ejecución que nos permiten ejecutar estas pruebas. Estos marcos están escritos en Python, PowerShell (Core) y Ruby, pero sin duda el más actualizado (y activo) es el marco de PowerShell (Core). Como nota al margen, Reescribí el marco de PowerShell en septiembre de 2018., pero ha tenido muchos cambios desde entonces.

La idea es usar uno de los marcos de ejecución para ejecutar una o más pruebas atómicas en un sistema. A cambio, su EDR, SIEM, etc., activaría alertas/detecciones y comenzaría a medir su eficacia frente a técnicas específicas dentro de su entorno. Sin embargo, este proceso manual ha demostrado ser difícil, tedioso y lento.

Como fanático de Red Canary y su proyecto Atomic Red Team desde hace mucho tiempo, me propuse dos objetivos principales:

1. Para invocar pruebas de forma remota en múltiples tipos de sistemas operativos utilizando un único marco.
2. Para asociar detecciones/alertas con pruebas atómicas dentro de un entorno.

Recientemente presenté cómo pude lograr estos objetivos usando Swimlane SOAR. Además, quería retribuir a la comunidad de seguridad publicando un componente de este caso de uso como código abierto.

Caso de uso

El caso de uso principal consiste en varias aplicaciones dentro de un único espacio de trabajo. Pude analizar Atomic Red Team Atomics en un solo registro dentro de un... Atomística Aplicación. Como mencioné antes, cada Atomic puede tener varias pruebas asociadas, y es posible que esas pruebas no sean para un solo tipo de sistema operativo. Por lo tanto, creé una aplicación secundaria llamada Pruebas atómicas, que contiene los detalles de cada prueba y está asociado con el registro principal de Atomics.

El principal punto de entrada que utilizaría un analista es el Anfitrión Aplicación. La aplicación host contiene información sobre el host en el que se desea ejecutar una prueba. Un analista creará un registro y proporcionará (como mínimo) un nombre, una dirección (IP o DNS) y el tipo de sistema operativo. Una vez que esta nueva Anfitrión Una vez guardado el registro, el analista debe elegir qué pruebas desea ejecutar. Para ello, utiliza un registro de referencia. Pruebas atómicas Aplicación. Una vez agregadas las pruebas, pueden optar por ejecutar una o más pruebas asociadas con el registro.

timón

Quizás te preguntes: "¿Cómo van a ejecutar estas pruebas de forma remota?" Bueno, me gustaría presentar una nueva herramienta de código abierto llamada timón. timón es un paquete de Python que ejecuta comandos de forma remota en Windows, macOS o *nix, y es multiplataforma.

Para poder utilizar timón, debe proporcionarle un conjunto de credenciales que puedan utilizar PowerShell Remoting/WinRM (Administración remota de Windows) o SSH en el host deseado.

Una vez que haya proporcionado un conjunto de credenciales dentro de nuestro Almacén de claves, Puedes ejecutar pruebas en varios hosts y sistemas operativos desde Swimlane. Para cada prueba ejecutada en un host, creamos un registro histórico en otra aplicación llamada Historial de pruebas. Esta aplicación contiene registros de cada prueba realizada en un host, junto con la respuesta del sistema. Cada prueba se asocia con el host donde se ejecutó, lo que proporciona información contextual histórica.

Una vez ejecutada una prueba en un host, comenzamos inmediatamente a buscar alertas/detecciones entrantes similares a las de nuestra prueba. Para ello, analizamos las aplicaciones proporcionadas y los campos específicos que se deben supervisar. También consideramos los siguientes datos al tomar una decisión (todos ellos se pueden modificar o personalizar fácilmente según las necesidades de su organización):

1. Comparación de marcas de tiempo
   1. Los tiempos de inicio de la búsqueda se basan en la marca de tiempo en la que se invocó la prueba en el host
   2. La duración final es configurable, pero por defecto la hemos mantenido en 3 horas desde que se ejecutó la prueba.
2. Comparación de direcciones
   1. Observamos los campos proporcionados y verificamos si el nombre/dirección del host de alerta es la misma dirección en la que se ejecutó la prueba.
3. Comparación de ejecución
   1. Normalización de los detalles de las pruebas y alertas atómicas
      1. Minúsculas
      2. Eliminar caracteres (por ejemplo, |, \\, etc.)
   2. Compare dos listas de comandos para encontrar la diferencia porcentual entre cadenas y valores similares.
   3. Opcional:
      1. Ofrecimos la capacidad de usar cálculos de distancia de Levenstein y comparaciones de hash SSDeep, pero son costosos y se utilizan mejor con valores de origen y destino similares.

Una vez realizada la comparación y determinada la similitud entre una alerta y una detección y nuestra prueba, asociamos ese registro de alerta a nuestro registro único de historial de pruebas. En este punto, creamos un registro o asociamos nuestro registro de historial de pruebas con otra aplicación llamada Registros de mapas de calor.

A Registro de mapa de calor Se utiliza para rastrear, informar y mostrar datos sobre nuestra capacidad para detectar (o no) técnicas específicas en las que hemos realizado pruebas. Si se realizó una prueba y no se identificó ninguna alerta, seguimos rastreando este evento, pero nuestros informes serán ligeramente diferentes a los que generaríamos si hubiéramos podido detectar con precisión una técnica en todas las pruebas históricas.

Una vez que se crean estos registros o se asocia un registro del historial de pruebas con una técnica, podemos comprender visualmente dónde podemos detectar actividades maliciosas y dónde nos estamos quedando cortos.

Arriba se muestra una imagen del widget del panel MITRE ATT&CK de Swimlane. Este panel extrae datos de nuestro Registros de mapas de calor y mostrándolo dinámicamente. Si un cuadro de cuadrícula no tiene color, significa que no hemos realizado pruebas para esta técnica específica. El azul más oscuro significa que hemos realizado al menos una prueba y hemos podido detectarla. A medida que se identifican más pruebas y detecciones, el color se aclara al azul agua alrededor. En (Windows). Si se ha ejecutado una prueba y no se ha identificado ninguna detección, esa técnica estará en rojo.

Mediante el uso El equipo rojo atómico de Red Canary Con Swimlane SOAR, puede automatizar sus pruebas ATT&CK y, al mismo tiempo, obtener visibilidad de sus capacidades de detección y brechas. Olvídese de las pruebas, revisiones y correlaciones manuales. Con este caso práctico, puede identificar brechas rápidamente y comenzar a realizar nuevas pruebas en cuestión de minutos.