Conoce la cumbre de la pirámide
Exploración de la metodología Summit of the Pyramid (SoP) para análisis de detección basada en la Pirámide del Dolor de David Bianco.
El objetivo de detectar indicadores es responder a ellos, y una vez que puedes responder a ellos lo suficientemente rápido, le has negado al adversario el uso de esos indicadores cuando te ataca. Sin embargo, no todos los indicadores son iguales y algunos de ellos son mucho más valiosos que otros.
—David Bianco, La pirámide del dolor
La metodología de la Cumbre de la Pirámide se basa en un modelo bidimensional. Las filas representan categorías de indicadores (similares a la Pirámide del Dolor), y las columnas representan las fuentes de datos para el análisis de detección. Los observables pueden asignarse a ubicaciones dentro de la cuadrícula, lo que representa visualmente la dificultad y el coste para los adversarios de evitar la creación de ese observable. Un defensor puede utilizar este modelo para analizar la robustez y capacidad de evasión de los análisis existentes, así como para diseñar análisis nuevos y mejorados.
Por ejemplo, un defensor puede utilizar una analítica que alerte si se detecta un determinado hash. Un adversario puede eludir fácilmente la detección recompilando sus herramientas con una diferencia de un byte. Esto se representa visualmente colocando el observable en la primera fila.
Deconstrucción de la Pirámide
Descompongamos la pirámide en los distintos tipos de actividad en torno a los que un defensor puede construir su análisis.
Los cuatro primeros niveles de la pirámide se centran en valores efímeros que son fáciles de cambiar para un adversario. El siguiente nivel no se centra en los valores, sino en los tipos de herramientas que un adversario intentará utilizar durante un ataque. Por último, el nivel superior se centra estrictamente en los comportamientos que un adversario demostrará durante un ataque.
Páginas de mapeo de modelos
El modelo define cinco niveles de solidez analítica y tres columnas de solidez de eventos. (Ver: Definiciones)
Nivel 5: Del núcleo a la subtécnica o técnica
Descripción: Observables asociados con “puntos de estrangulamiento” o “comportamientos invariantes” de la (Sub)Técnica, inevitables mediante cualquier implementación.
Nivel 4: Núcleo de algunas implementaciones de (sub)técnica
Descripción: Observables asociados con comportamientos de baja varianza de la (Sub)Técnica, inevitables sin una implementación sustancialmente diferente.
Nivel 3: Núcleo de herramientas preexistentes
Descripción: Los observables asociados con una herramienta o funcionalidad que existía en el sistema antes del compromiso, pueden ser administrados por la organización defensora y difíciles de modificar para un adversario.
Nivel 2: Herramienta fundamental para el adversario
Descripción: Observables que están asociados con herramientas que utiliza un adversario para realizar un ataque.
Nivel 1: Valores efímeros
Descripción: Observables que son triviales para que un adversario los cambie, o que cambian incluso sin la intervención del adversario.
Columnas: Categorías de robustez de eventos
Hay tres columnas que representan dónde se originan los datos de eventos dentro del sistema operativo.
Columna A: Aplicación
Descripción: Observables asociados con el uso de aplicaciones disponibles para los defensores antes de que el adversario las use y difíciles de modificar para el adversario.
Columna U: Modo de usuario
Descripción: Observables asociados con la actividad del sistema operativo en modo de usuario.
Columna K: Modo kernel
Descripción: Interfaz directa con el anillo 0 en el sistema operativo. Los observables están en modo kernel.
Cómo empezar
Para empezar, lea el sitio web del proyecto. Ofrece una visión general de los objetivos y metodologías, define todos los términos clave y contiene ejemplos muy detallados.
- Project Website: Documentación completa del proyecto
- Spreadsheet: Un resumen de las analíticas puntuadas por el equipo del proyecto
Ejemplo: T1053.005 Scheduled Tasks
https://attack.mitre.org/techniques/T1053/005/
La analítica original detecta el nombre de un proceso recién creado en combinación con el argumento de la línea de comandos /create. Las referencias a los campos en esta analítica existen en Sysmon EventID 1 y no en Windows Event ID 4688 para la creación de procesos, por lo tanto, sabemos que la intención era utilizar datos de Sysmon. Anteriormente calificamos el ID de evento 1 de Sysmon como operativo en modo de usuario, ya que se activa cuando se llama a la función CreateProcessA de la API de Win32.
El ejecutable schtasks puede ser fácilmente copiado y renombrado por un adversario, por lo que se coloca en el nivel Efímero. El argumento de la línea de comando es más difícil de evadir para un adversario, ya que probablemente necesitaría el código fuente para cambiar estos argumentos. Sin embargo, dado que las schtasks existen en el sistema operativo antes de que el sistema se vea comprometido y no hay ningún código fuente disponible, el argumento de la línea de comandos observable se coloca en “Core to Pre-existing Tool”. Teniendo en cuenta la lógica booleana de SoP, esta analítica finalmente obtiene una puntuación de 1U porque un adversario puede simplemente cambiar el nombre de la imagen y evitar la detección con Image|endswith: '\\schtasks.exe'.
Definiciones clave
Precisión: La fracción de eventos maliciosos relevantes entre todos los eventos coincidentes con una analítica.
Recuperación: La fracción de eventos maliciosos relevantes que detecta una analítica.
Robustez: Mide el esfuerzo que necesita un adversario para evadir una analítica.
Observable: Un evento, ya sea benigno o malicioso, que se genera en una red o sistema y es visible para un defensor.