Seguir 
Resumen
- SIGMA es un formato de reglas de detección independiente de la plataforma que permite a los equipos compartir detecciones SIEM entre diferentes proveedores.
- Para escribir una regla, comienza con una idea de detección, elige una fuente de registro común y mapea en SIGMA (mínimo:
logsource+detection). logsourceespecifica a qué registros se aplica la regla para que los traductores puedan orientar el tipo de backend/datos correcto.detectionconsiste en selecciones (coincidencias de campo/valor + modificadores) más una condición (lógica booleana), opcionalmente con corrección/marco temporal.- Usa convenciones de campo SIGMA (sensible a mayúsculas), traduce/prueba la regla, luego compártela y actúa en función del feedback.
Este blog presenta argumentos a favor de SIGMA como lenguaje de detección, cubre los componentes más críticos de las reglas SIGMA (logsource y detección), taxonomía SIGMA, prueba de reglas SIGMA, y en general prepara a los analistas nuevos en SIGMA para escribir sus primeras reglas. También se proporciona una breve discusión sobre ingeniería de detección con SIGMA respecto al ruido, ideas, fuentes de registro, etc.
El Caso de las Reglas SIGMA
En el pasado, las detecciones SIEM existían en silos específicos de proveedor/plataforma. Los socios que deseaban compartir contenido de detección a menudo tenían que traducir una consulta de un proveedor a otro. Esto no es sostenible, la comunidad de ciberseguridad defensiva debe mejorar cómo compartimos detecciones para mantener el ritmo con nuestros adversarios en constante evolución.
Al igual que YARA o las Reglas de Snort, SIGMA es otra herramienta para el intercambio abierto de detección, pero enfocada en SIEM en lugar de archivos o tráfico de red. SIGMA permite a los defensores compartir detecciones (alertas, casos de uso) en un lenguaje común.
Lanzado por primera vez en 2017 por Florian Roth y Thomas Patzke, SIGMA está abriendo el camino hacia una búsqueda independiente de plataforma. Con SIGMA, los defensores se liberan del lenguaje de detección y los repositorios específicos de proveedor y plataforma, y pueden aprovechar el poder de la comunidad para responder a tiempo a amenazas críticas y nuevas tácticas de adversarios.
Hay muchas razones para usar SIGMA:
- Investigadores y equipos de inteligencia que identifican nuevos comportamientos de adversarios y quieren una forma independiente de compartir detecciones
- MSSP/MDR responsables de múltiples soluciones SIEM/EDR/Analítica de Registros y taxonomías/esquemas de datos (ECS, CEF, CIM, etc.)
- Evita el bloqueo del proveedor, al definir reglas en un SIGMA podemos movernos más fácilmente entre plataformas.
- Investigadores en el ámbito de la seguridad ofensiva que quieren crear detecciones basadas en su investigación
Nota: En este blog, SIEM se utiliza para describir cualquier plataforma usada para recolectar y buscar registros. Acepto que muchas de las plataformas listadas pueden no encajar en tu definición de “SIEM”. Sin embargo, usar los términos “plataforma” o “plataforma de registros” es demasiado ambiguo.
SeguirCreación de Reglas SIGMA
Escribir reglas SIGMA requiere tener conocimientos básicos sobre el esquema y la taxonomía de SIGMA, tener una idea, ajustarla a SIGMA, testearla, compartirla y potencialmente mantener la regla.
Antecedentes y Contexto Recomendados
A pesar de la extensión de este blog, gracias a YAML y la visión a futuro de los creadores, SIGMA es fácil de entender y escribir. En SOC Prime nos gusta decir ‘cualquiera puede aprender SIGMA’. El arte de la ingeniería de detección es donde las cosas pueden complicarse más.
Existen muchos otros recursos como el wiki oficial y algunas guías escritas por expertos en SIGMA (listadas a continuación). Hay ciertas trampas como manejo adecuado de comodines or nombres de campo incorrectos que pueden causar reglas rotas y muchos de estos aspectos se abordan en estos recursos.
Si eres un investigador buscando adentrarte en SIGMA, el Programa de Recompensas de Amenazas de SOC Prime es una gran oportunidad para comenzar y ganar un poco de dinero. Las reglas presentadas pasan por un proceso de revisión exhaustivo donde podemos guiarte y ayudarte a entender los errores y crecer como analista.
Lecturas Recomendadas:
- Cómo Escribir Reglas SIGMA, Florian Roth 2018
- Guía para Fuentes de Registro Genéricas, Thomas Patzke 2019
Recomendación para ver:
Tipos de Detecciones que las Reglas SIGMA Pueden Expresar
Actualmente existen dos tipos básicos de reglas:
- Reglas SIGMA basadas en coincidencias, ampliamente soportadas, fáciles de escribir
- Reglas SIGMA basadas en coincidencias y correlaciones simples, soporte limitado, menos fáciles de escribir
Nota: También existen reglas SIGMA multi-yaml, sin embargo, estas generalmente han caído en desuso en favor de reglas específicas para fuentes de registro. El equipo de SOC Prime generalmente no crea reglas multi-yaml porque añaden complejidad innecesaria al mantenimiento y despliegue de reglas. Alguien puede crear una regla SIGMA multi-yaml si puede crear dos reglas SIGMA.
¡Vamos a Crear una Regla SIGMA Simple!
Una idea (y algunos pensamientos sobre la ingeniería de detección con SIGMA)
Los usuarios y administradores a menudo mantienen contraseñas sensibles en documentos de texto plano, como archivos de texto, excel, word, etc. Me preocupa que los adversarios puedan identificar estos archivos antes que yo en un entorno. Queremos instruir a nuestros usuarios sobre cómo almacenar contraseñas adecuadamente antes de que sean descubiertas por un hacker criminal.
Para muchas reglas SIGMA es un beneficio para el autor abstraer la idea y ampliar el objetivo ‘razonablemente’. Para ideas como esta, podemos hacer suposiciones educadas de cómo se verá el comportamiento, no solo lo que hemos observado. Por ejemplo, podemos hacer suposiciones sobre términos adicionales y extensiones que los usuarios pueden usar para almacenar contraseñas en texto plano. may La idea de ‘ampliar’ una regla es contraria a los instintos de muchos analistas. Eliminar todos los ‘falsos positivos’ no es necesariamente el objetivo del autor original cuando una regla será consumida en entornos desconocidos y poco familiares. Podemos dejar que los proveedores de EDR y antivirus se preocupen por crear detecciones que no puedan tener falsos positivos. Con SIGMA, las reglas pueden ser probadas en entornos y ajustadas fácilmente.
SIGMA es fácilmente comprensible, testable y ajustable. Si un término como ‘detalles’ es demasiado ruidoso para un entorno, la persona que implementa la regla debe sentirse capacitada para ajustar la regla. Desplegar todas las reglas a la vez sin probar es una receta para el desastre. Apagar las reglas en lugar de digerir y ajustar sus intenciones para un entorno hará que un lugar no aproveche contenido sólido de detección.
Me gusta dar el ejemplo de psexec. En algunos entornos, psexec es completamente normal y el status quo para que los administradores administren hosts remotamente. En otros entornos, psexec está (probablemente con razón) desaprobado, bloqueado, y es una ofensa accionable para que los administradores usen. Entonces, ¿es una regla SIGMA para detectar cualquier uso de psexec ‘ruidosa’ o simplemente mejor para algunos entornos que para otros? Si despliegas contenido sin probarlo, afinar el ruido siempre será un problema. Solo aquellas reglas identificadas como “críticas” están destinadas a ser seguras de usar sin probar.
Volviendo a crear nuestra regla SIGMA de exposición de contraseñas.. podemos expandir la idea para incluir nombres de archivo adicionales como:
Back to creating our password exposure SIGMA rule.. we can expand the idea to include additional file names such as:
- pw
- psw
- pass
- password
- passwords
- accounts
- account
- info
Creado con software como:
- Bloc de Notas
- Notepad++
- Wordpad
- Aplicaciones de Office
Una fuente de datos / Una fuente de registros
Una vez que tenemos una idea, necesitaremos una fuente de registros. SIGMA soporta teóricamente cualquier fuente de registros, sin embargo, deberíamos identificar una fuente de registros que la mayoría de las personas tenga. Por ejemplo, podríamos escribir una regla para una fuente de log de Prevención de Pérdida de Datos, pero la Prevención de Pérdida de Datos rara vez se analiza e ingiere en los SIEMs, y la industria no tiene un claro favorito. Por lo tanto, podemos crear una regla válida, pero no será fácilmente adoptada. any Para reglas de endpoints de Windows, Sysmon es un gran lugar para comenzar. Sysmon se despliega comúnmente en entornos, y muchas fuentes de registros proporcionan datos sinónimos (EDRs, etc.). Con Sysmon hay dos opciones principales, creación de procesos (process_creation en SIGMA) y creación de archivo (file_event en SIGMA).
Construiremos nuestra detección a partir de la creación de procesos ya que es más ampliamente adoptada, asegurando que nuestra regla sea lo más útil posible. La creación de procesos es una gran fuente de registros para aprender y es una de las fuentes de registros más útiles / populares utilizadas en detecciones de endpoints.
A menudo las ideas vienen directamente de las propias fuentes de datos. Al revisar los tipos de datos disponibles en tu SIEM / Lab, puedes identificar fácilmente reglas SIGMA que valga la pena escribir. También podemos usar otras fuentes como la documentación del proveedor.
Nota: Often ideas come directly from data sources themselves. By reviewing the types of data available to you in your SIEM / Lab one can easily identify SIGMA rules worth writing. We can also use other sources like vendor documentation.
Con eventos de creación de procesos de sysmon (ID de Evento 1), un usuario que accede a un archivo que contiene contraseñas puede contener estos campos interesantes:
Image: C:\Windows\System32\notepad.exe
CommandLine: “C:\Windows\System32\NOTEPAD.EXE” C:\Users\John\Desktop\password.txt
Ajustando la idea de detección a SIGMA
Ahora que tenemos una idea y una fuente de datos con la que trabajar, podemos comenzar a construir nuestra regla.
Esto no está documentado, pero los verdaderos componentes mínimos componentes requeridos para traducir una regla son simplemente logsource y detección (para algunos backends como Splunk, solo la detección es suficiente). Todo lo demás es ‘solo’ meta información para ayudar al consumidor de la regla SIGMA. Cuando comienzas, es de tu interés comenzar con estos campos mínimos, confirmar que tu lógica está funcionando y luego añadir campos y datos adicionales de SIGMA. Si deseas publicar tu regla en el repositorio público de SIGMA, vale la pena revisar presentaciones anteriores y emular su formato.
Una regla SIGMA básica con componentes mínimos para la exposición potencial de contraseñas:
title: Potential Password Exposure (via cmdline)
author: Adam Swan
tags:
- attack.t1552.001
- attack.credential_access
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith:
- '\notepad.exe'
- '\word.exe'
- '\excel.exe'
- '\wordpad.exe'
- '\notepad++.exe'
CommandLine|contains:
- 'pass' #pass will match on password, including password is redundant
- 'pwd'
- 'pw.' #pw.txt, etc.
- 'account' #accounts,
- 'secret'
- 'details' #I included plural details based on experience
condition: selection
Componente logsource
The logsource el componente ayuda al traductor del backend SIGMA (SIGMAC) a saber qué tipo de datos debe ser aplicado a la regla. Empodera al creador de la regla para crear reglas más genéricas. Por ejemplo, con logsource siendo “producto: windows, categoría: creación de procesos” no necesitamos especificar IDs de evento (Sysmon 1, Windows 4688, ProcessRollup, etc.). El consumidor de la regla puede especificar qué IDs de evento, índices, etc. quiere asociar con las fuentes de registros en la Configuración SIGMA. Sin especificar índices, IDs de evento, etc., las reglas probablemente serán innecesariamente costosas (en rendimiento) para el consumidor.
Además, a menudo la telemetría puede contener campos similares pero implicar comportamientos completamente diferentes. Por ejemplo, los eventos de conexión de red de Sysmon (ID de Evento 3) y creación de procesos (ID de Evento 1) comparten el campo Imagen . La existencia de explorer.exe en el Imagen campo de un evento de conexión de red de Sysmon es completamente diferente de la existencia de explorer.exe en un evento de creación de procesos. Proporcionando el componente logsource adecuado, proporcionamos un contexto invaluable a la detección.
Componente de detección
El componente de detección es donde el autor define sus criterios de detección. Esto incluye al menos un componente de selección componente de selección y un componente de condición componente de condición. Hay un componente opcional de marco temporal componente del marco temporal que es requerido para reglas basadas en correlación.
Subcomponente de selección:
- Generalmente, esto tomará la forma Campo A contiene/empieza con/termina con/igual a Valor B. Por supuesto, como se observa en la regla de ejemplo anterior, si un autor lo necesita puede expandir e incluir lógica como Campo A contiene/empieza con/termina con/igual a Valores X, Y, o Z. Esta lógica siempre es insensible a mayúsculas.
- Hay ‘modificadores’ más avanzados que incrementan la complejidad de la regla, o permiten a los autores ser más precisos. Por ejemplo, las expresiones regulares se manejan a través del operador re y permiten a los autores hacer cosas como escribir consultas sensibles a mayúsculas. Para propósitos de compatibilidad, es mejor limitarse sólo a los operadores básicos de expresiones regulares . ? + * | { } [ ] () » .
- Las selecciones tienen nombre (por ejemplo, selección, selección2, selección3, filtro). Las selecciones pueden llamarse (casi) como quieras. A menudo se utiliza una variación de selección pero uno puede llamar su selección solo tan fácilmente banana y la regla todavía funcionaría. Generalmente, el término filtro se usa para selecciones que se excluirán (por ejemplo, selección Y NO filtro).
Subcomponente de condición:
- El componente de condición contiene lógica booleana (Y, O, NO) que define cómo debe incluirse cada selección en la consulta final.
- E.G. (selección_a O selección_b) Y NO filtro
Componente de condición con correlación:
Hay dos tipos de correlaciones soportadas por los backends hoy en día. Hay otras correlaciones soportadas por el esquema SIGMA… pero aún no por los backends disponibles.
Contar() por Y:
Cuenta las instancias únicas del valor del campo Y y compara (mayor que, menor que) a un número estático.
Ejemplo: Contar() por src_ip > 2
Contar(X) por Y:
Cuenta las instancias únicas del valor del campo X por valor Y y compara (mayor que, menor que) la cuenta de X con un número estático.
Ejemplo: Contar(EventID) por src_ip > 2
Casos de Uso Comunes de Correlación:
Count() by src_ip > 10 | Count unique matching events by the source IP. |
Count() by dst_ip > 10 | Count unique matching events by the destination IP |
Count(EventID) by ComputerName | This will let you search for unique instances of eventid. For instance, if you want to chain sysmon event ids 1 (process creation) AND event id 5. e.g. a process is created and terminated in less than 1 min. |
Subcomponente del Marco Temporal:
- The el componente marco temporal se usa en conjunto con condiciones que incluyen una correlación. Muchos backends ignoran el marco temporal, sin embargo, generalmente siempre se incluye y requiere ser incluido en la mayoría de los repositorios, incluyendo el de SOC Prime.
Ejemplos Completos Usando Splunk:
- Aquí hay algunos ejemplos de SIGMA y sus traducciones para Splunk. Si no estás familiarizado con Splunk, los asteriscos son un comodín por lo que un término rodeado por asteriscos (por ejemplo, *término*) es ‘contiene’, un término con un asterisco delante (por ejemplo, *término) es termina con, un término con un asterisco detrás es ‘comienza con’ (por ejemplo, término*).
SIGMA detection component | Splunk Translation (Asterisk is a wildcard) |
detection: selection: fieldX: 'suspicious' condition: selection | fieldX="suspicious" |
detection: selection: fieldY|contains: - 'suspicious' - 'malicious' - 'pernicious' condition: selection | (fieldY="*suspicious*" OR fieldY="*malicious*" OR fieldY="*pernicious*") |
detection: selection: - fieldX: 'icious' - fieldX: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern")) |
detection: selection: - FieldX|endswith: 'icious' - FieldX|startswith: - 'susp' - 'mal' - 'pern' condition: selection | (FieldX="*icious" AND (FieldX="susp*" OR FieldX="mal*" OR FieldX="pern*")) |
detection: selection: FieldX|endswith: 'icious' filter: FieldX|startswith: - 'del' - 'ausp' condition: selection AND NOT filter | (FieldX="*icious" AND NOT ((FieldX="del*" OR FieldX="ausp*"))) |
detection: selection: FieldX: 'suspicious' timeframe: 1m condition: selection | count by src_ip > 3 | FieldX="suspicious" | eventstats count as val by src_ip| search val > 3 #notice splunk ignores the timeframe value, the value must be set at search by the user |
detection: selection: FieldX: 'suspicious' condition: selection | count(ComputerName) by src_ip > 3 | FieldX="suspicious" | eventstats dc(ComputerName) as val by src_ip | search val > 3 |
Preguntas de Taxonomía (por ejemplo, qué nombres de campo usar)
Teóricamente puedes usar cualquier nombre de campo que desees, siempre que alguien esté dispuesto a tomarse el tiempo para escribir una Configuración SIGMA para traducir de tus campos… a los de ellos.
Nota: ¡Los nombres de campo distinguen entre mayúsculas y minúsculas! Línea de Comando and líneaDeComando son dos valores diferentes. Línea de Comando es parte de la taxonomía existente, líneaDeComando no lo es.
Dicho esto, lo mejor es usar nombres de campos que estén documentados por SIGMA. Hay tres lugares donde el repositorio público de SIGMA documenta la taxonomía.
Como regla general, usamos los nombres de campo SIGMA especificados en la wiki para categorías
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- La wiki revelará a los lectores que SIGMA usa
— campos SYSMON para reglas de endpoints
— Formato de Archivo de Registro Extendido W3C para reglas de servidores web y proxy
— Los campos para firewall, antivirus
Seguido por nombres de campo SIGMA especificados en reglas existentes y archivos de configuración SIGMA
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Realmente la documentación oficial para los campos. Los usuarios pueden crear/modificar estos según sea necesario cuando traducen reglas.
- https://github.com/SigmaHQ/sigma/tree/master/rules
Y finalmente, si no existen configuraciones o reglas, usamos los nombres de campo originales de la fuente de registro de origen. Si los nombres de campo provienen de valores anidados (por ejemplo, identidadDeUsuario anidado bajo IdDeCuenta en aws cloudtrail) usamos un punto para indicar que el campo está anidado, ya que esto es relativamente consistente entre diferentes SIEMS (por ejemplo, identidadDeUsuario -> IdDeCuenta se convierte en identidadDeUsuario.IdDeCuenta).
Probando Reglas SIGMA
Probar reglas SIGMA es simple. A menudo, las personas pueden incluso enviar contenido sin probarlo directamente ellos mismos. La mayoría de los investigadores públicos no tiene acceso a entornos diversos para probar reglas contra ‘el conjunto de todos los SIEMs’. En cambio, uno puede confiar en la retroalimentación pública, retroalimentación de partes de confianza, etc. Incluso Florian Roth, un co-creador de SIGMA, regularmente sube reglas al público para recibir retroalimentación a través de su Twitter. También he visto personas publicar directamente en sus blogs personales y LinkedIn, etc. Si crees que tienes una buena regla para compartir, ¡ponla ahí, créeme, si está mal (o no) las personas amables de internet te lo harán saber! No te tomes muy en serio e estate preparado para hacer cambios y aprender algo.
Hay algunos pasos básicos que puedes tomar:
- Asegúrate de que la regla se traduzca (uncoder o usando SIGMAC)
- Verificación de cordura (por ejemplo, asegurarse de que la regla cumple con tu expectativa original, sigue la taxonomía correcta, etc.) – ver trampas: https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
- Probando la regla en un entorno de laboratorio
- Compartiendo la regla ampliamente para las pruebas / compartiendo la regla con el equipo de SOC Prime a través del Programa de Recompensas de Amenazas
Nota: Desde la perspectiva del autor de la regla, generalmente no deberías preocuparte por las implementaciones de los backends de las reglas. Depende de los autores del backend SIGMA, y personas como SOC Prime asegurarse de que las traducciones cumplan con la intención original de una regla válida. Si se identifica un error, siempre vale la pena enviar un problema a GitHub.
Acerca de SOC Prime
- Fundaron la industria de Detección como Código en 2015
- Asociados con Fortune 100 + MDRs globales
- Cubriendo toda la tubería desde la detección hasta la simulación
- Búsqueda de amenazas mágica en lugar de filtros
- 650,000+ reglas de detección
- Nuevas amenazas diarias
- ETL de Velocidad de Línea de Detección
- Detección Shift-Left, Bien Hecha
FAQ
¿Qué es una regla SIGMA?
Una regla SIGMA es una detección neutral al proveedor escrita en YAML que describe actividad sospechosa en registros. Puedes traducirla en consultas para muchos SIEMs y herramientas de registro.
¿Cuáles son las dos partes imprescindibles de una regla SIGMA?
Incluir logsource y detección. logsource define el tipo de registros (como creación de procesos de Windows), y detección contiene la lógica de coincidencia y condición.
¿Cómo escribes una condición de detección SIGMA?
Crea una o más “selecciones” que coincidan campos y valores, luego combínalas en la condición usando Y/O/NO. Esto te permite expresar coincidencias simples y lógica más compleja.
¿Cómo eliges una buena fuente de registros para tu primera regla SIGMA?
Elige algo ampliamente desplegado para que otros puedan usarlo. Para detecciones de endpoints de Windows, Sysmon es una elección común, y la creación de procesos (process_creation) es un punto de partida práctico.
¿Cómo pruebas una regla SIGMA antes de usarla en producción?
Tradúcela a tu plataforma objetivo (por ejemplo, con un convertidor SIGMA), ejecútala contra datos reales o de laboratorio, y ajústala para reducir falsos positivos antes de implementarla de forma amplia.
