¿Qué son las reglas SIGMA? Guía para principiantes
Tabla de contenidos:
Esta publicación de blog defiende a SIGMA como un lenguaje de detección, cubre los componentes de regla SIGMA más críticos (logsource & detection), la taxonomía SIGMA, las pruebas de Reglas SIGMA, y prepara en general a los analistas nuevos en SIGMA para escribir sus primeras reglas. También se proporciona una breve discusión sobre la 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 proveedores/plataformas. 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 Snort, SIGMA es otra herramienta para el intercambio abierto de detección, excepto que se centra 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.
Liberado por primera vez en 2017 por Florian Roth y Thomas Patzke, SIGMA está marcando el camino hacia una búsqueda independiente de la plataforma. Con SIGMA, los defensores están liberados del lenguaje y los repositorios de detección específicos de proveedor y plataforma y pueden aprovechar el poder de la comunidad para responder oportunamente 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 agnóstica de compartir detecciones
- MSSP / MDR responsables de múltiples soluciones SIEM / EDR / Analytics de registros y taxonomías/esquemas de datos (ECS, CEF, CIM, etc.)
- Evitar el bloqueo de proveedores, al definir reglas en SIGMA podemos movernos más fácilmente entre plataformas.
- Investigadores en el ámbito de la seguridad ofensiva que desean crear detecciones basadas en su investigación
Nota: En este blog, SIEM se utiliza para describir cualquier plataforma usada para recopilar y buscar en registros. Acepto que muchas de las plataformas enumeradas pueden no ajustarse a su definición de “SIEM”. Sin embargo, usar los términos “plataforma” o “plataforma de registros” es demasiado ambiguo.
Creando 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, probar, compartir y potencialmente mantener la regla.
Antecedentes y Contexto Recomendados
A pesar de la longitud de este blog, gracias a YAML y al pensamiento adelantado 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.
Hay muchos otros recursos como el wiki oficial y algunas guías escritas por expertos en SIGMA (enumeradas a continuación). Hay ciertas trampas como la manejo adecuado de comodines or nombres de campo incorrectos que pueden causar reglas rotas y muchas de estas se abordan en estos recursos.
Si eres un investigador que busca adentrarse en SIGMA, el Programa de Recompensas por Amenazas de SOC Prime es una gran oportunidad para comenzar y ganar un poco de dinero. Las reglas enviadas pasan a través de un proceso de revisión exhaustiva donde podemos guiarte y ayudarte a entender errores y crecer como analista.
Lecturas Recomendadas:
- Cómo Escribir Reglas SIGMA, Florian Roth 2018
- Una Guía para Fuentes de Registro Genéricas, Thomas Patzke 2019
Ver Recomendado:
Tipos de Detecciones que las Reglas SIGMA Pueden Expresar
Hoy en día existen actualmente dos tipos básicos de reglas:
- Reglas SIGMA basadas en coincidencias, ampliamente soportadas, más fáciles de escribir
- Reglas SIGMA basadas en coincidencias y correlaciones simples, soporte limitado, menos fáciles de escribir
Nota: También hay reglas SIGMA multi-yaml, sin embargo, estas generalmente han caído en desuso en favor de reglas específicas de fuente de registro. El equipo de SOC Prime generalmente no crea reglas multi-yaml porque añaden una complejidad innecesaria al mantenimiento e implementación 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 en 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 adecuadamente las contraseñas antes de que sean descubiertas por un hacker criminal.
Para muchas reglas SIGMA, es de beneficio para el autor abstraer la idea y ampliar el objetivo ‘razonablemente’. Para ideas como esta, podemos hacer conjeturas informadas sobre cómo se may verán, no solo lo que hemos observado. Por ejemplo, podríamos hacer conjeturas informadas sobre términos adicionales y extensiones que los usuarios pueden usar para almacenar contraseñas en texto plano.
La idea de ‘ampliar’ una regla resulta contradictoria para 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 Anti-Virus 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, comprobable y ajustable. Si un término como ‘detalles’ es demasiado ruidoso para un entorno, la persona que implemente la regla debe sentirse empoderada 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 causará que una tienda pierda contenido sólido de detección.
Me gusta dar el ejemplo de psexec. En algunos entornos, psexec es completamente normal y la norma para que los administradores administren hosts de forma remota. En otros entornos, psexec está (probablemente con razón) no aprobado, bloqueado, y es una ofensa accionable para que los administradores lo usen. Entonces, ¿una regla SIGMA para detectar cualquier uso de psexec es ‘ruidosa’ o simplemente mejor para algunos entornos que para otros? Si despliegas contenido sin probar, ajustar el ruido siempre será un problema. Solo las reglas identificadas como “críticas” están destinadas a ser seguras de usar sin prueba.
Volviendo a crear nuestra regla SIGMA de exposición de contraseñas… podemos expandir la idea para incluir nombres de archivos adicionales como:
- pw
- psw
- pass
- contraseña
- contraseñas
- cuentas
- cuenta
- info
Creado con software como:
- Bloc de notas
- Notepad++
- Wordpad
- Aplicaciones de Office
Una fuente de datos / Una fuente de registros
Una vez que tengamos una idea, necesitaremos una fuente de registros. SIGMA soporta any fuente de registro teóricamente, sin embargo deberíamos identificar una fuente de registros que la mayoría de la gente tenga. Por ejemplo, podríamos ser capaces de escribir una regla para una fuente de registros de Prevención de Pérdida de Datos, pero la Prevención de Pérdida de Datos rara vez se analiza y se ingiere en los SIEMs, y la industria no tiene un claro favorito. Entonces, podemos crear una regla válida, pero no será tan fácilmente adoptada.
Para reglas de puntos finales 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 archivos (file_event en SIGMA).
Construiremos nuestra detección a partir de la creación de procesos ya que es más ampliamente adoptada, asegurando así 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 más útiles / populares usadas en detecciones de puntos finales.
Nota: A menudo las ideas provienen directamente de las propias fuentes de datos. Al revisar los tipos de datos disponibles para ti en tu SIEM / Lab uno puede fácilmente identificar reglas SIGMA que valga la pena escribir. También podemos usar otras fuentes como documentación de proveedores.
Con eventos de creación de procesos Sysmon (ID de Evento 1), un usuario que accede a un archivo que contiene contraseñas puede contener estos campos interesantes:
Imagen: C:WindowsSystem32notepad.exe
Línea de comando: “C:WindowsSystem32NOTEPAD.EXE” C:UsersJohnDesktopcontraseña.txt
Ajustando la idea de detección a SIGMA
Ahora que tenemos una idea y una fuente de datos para trabajar, podemos comenzar a construir nuestra regla.
Esto no está documentado, pero los verdaderos componentes mínimos requeridos para traducir una regla son solo logsource & detección (para algunos backends como Splunk, solo la detección es suficiente). Todo lo demás es ‘solo’ metadatos para ayudar al consumidor de la regla SIGMA. Cuando empiezas, conviene empezar con estos campos mínimos, confirmar que tu lógica funciona y luego agregar campos adicionales y datos SIGMA. Si deseas publicar tu regla en el repositorio público de SIGMA, vale la pena revisar las presentaciones anteriores y emular su formato.
Una regla básica SIGMA con componentes mínimos para una exposición potencial de contraseñas:
título: Exposición Potencial de Contraseñas (a través de cmdline)
autor: Adam Swan
etiquetas:
- attack.t1552.001
- attack.credential_access
logsource:
producto: windows
catergoria: process_creation
detección:
selección:
Imagen|termina en:
- 'notepad.exe'
- 'word.exe'
- 'excel.exe'
- 'wordpad.exe'
- 'notepad++.exe'
Línea de Comando|contiene:
- 'pass' #pass coincidió en contraseña, incluir contraseña es redundante
- 'pwd'
- 'pw.' #pw.txt, etc.
- 'cuenta' #cuentas,
- 'secreto'
- 'detalles' #Incluí detalles en plural basado en experiencia
condición: selección
Componente logsource
The logsource ayuda al traductor de backend SIGMA (SIGMAC) a saber contra qué tipo de datos debe actuar la regla. Empodera al creador de reglas para crear reglas más genéricas. Por ejemplo, al tener logsource siendo “producto: windows, categoría: creación_de_procesos” no necesitamos especificar Ids de eventos (Sysmon 1, Windows 4688, ProcessRollup, etc). El consumidor de la regla puede especificar qué ids de evento, índices, etc. quieren que se asocien a fuentes de registro en la Config SIGMA. Sin especificar índices, ids de eventos, etc. las reglas probablemente será innecesariamente costosas (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 la creación de procesos (Id de Evento 1) comparten el campo de Imagen. La existencia de explorer.exe en el campo de un evento de conexión de red Sysmon es completamente diferente de la existencia de explorer.exe en un evento de creación de procesos. Al proporcionar el componente logsource adecuado damos contexto invaluable a la detección. campo de Imagen. La existencia de explorer.exe en el field of a Sysmon network connection event is completely different from the existence of explorer.exe in a process creation event. By providing the proper logsource component we provide invaluable context to the detection.
Componente de detección
El componente de detección es donde el autor define sus criterios de detección. Esto incluye al menos una componente de selección y una componente de condición. Hay un componente de marco temporal opcional que es necesario para bajo reglas basadas en correlación.
Subcomponente de Selección(es):
Generalmente, esto tomará la forma de Campo A contiene/empieza con/termina en/igual 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 en/igual Valores X, Y, o Z. Esta lógica es siempre insensible al caso.
Hay ‘modificadores’ más avanzados que aumentan la complejidad de la regla o permiten a los autores ser más precisos. Por ejemplo, las expresiones regulares son manejadas a través del operador re y permiten a los autores hacer cosas como escribir consultas respecta de caso. Para propósitos de compatibilidad es mejor atenerse solo a los operadores básicos de expresión regular . ? + * | { } [ ] () “ .
Las selecciones son nombradas (por ej. selección, selección2, selección3, filtro). Las selecciones pueden ser nombradas (casi) como uno quiere. A menudo se usa una variación de selección pero uno puede igualmente nombrar su selección banana y la regla aún funcionará. Generalmente, el término filtro se usa para selecciones que serán excluidas (por ej. selección Y NO filtro).
Subcomponente de Condición:
El componente de condición contiene lógica booleana (AND, OR, NOT) que define cómo cada selección debe ser incluida en la consulta final.
E.G. (selección_a O selección_b) Y NO filtro
Componente de condición con correlación:
Hoy en día hay dos tipos de correlaciones apoyadas por backends. Hay otras correlaciones apoyadas por el esquema SIGMA… pero aún no por los backends disponibles.
Contar() por Y:
Cuenta las instancias únicas de valor de campo Y y compáralo (mayor que, menor que) con un número estático.
Ejemplo: Contar() por src_ip > 2
Contar(X) por Y:
Cuenta las instancias únicas del valor de campo X por el valor Y y compáralo (mayor que, menor que) la cuenta de X con un número estático.
Ejemplo: Contar(EventID) por src_ip > 2
Casos Comunes de Uso de Correcció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 Temporal:
The El componente temporal es usado en conjunción con condiciones que incluyan una correlación. Muchos backends ignoran el marco temporal, sin embargo, generalmente siempre se incluye y se requiere incluir en la mayoría de los repositorios, incluido el de SOC Prime.
Ejemplos Completos Usando Splunk:
Aquí hay algunos ejemplos de SIGMA y sus traducciones para Splunk. Si no está familiarizado con Splunk, los asteriscos son un comodín, por lo que un término rodeado de asteriscos (e.g. *término*) es ‘contiene’, un término con un asterisco inicial (e.g. *término) es termina en, un término con un asterisco final es ‘empieza’ (e.g. 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 Taxonómicas (por ej., qué nombres de campo usar)
Teóricamente puedes usar los nombres de campo que desees, mientras alguien esté dispuesto a dedicar el tiempo para escribir una Config SIGMA para traducir de tus campos… a los suyos.
Nota: ¡Los nombres de campo son sensibles al caso! Línea de Comando and línea de comando son dos valores diferentes. Línea de Comando es parte de la taxonomía existente, línea de comando no lo es.
Dicho esto, es mejor utilizar los nombres de campo 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 de SIGMA especificados en el wiki para categorías
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- El wiki revelará a los lectores que SIGMA utiliza
- los campos SYSMON para reglas de punto final
- Formato de Archivo de Registro Extendido W3C para reglas de servidores web y proxy
- Los campos para firewall, antivirus
- Seguimiento por nombres de campo de SIGMA especificados en las reglas existentes y archivos de config SIGMA
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Esta es realmente la documentación oficial para campos. Los usuarios pueden crear/modificar estos según sea necesario cuando traducen reglas.
- https://github.com/SigmaHQ/sigma/tree/master/rules
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
Y finalmente, si no existen config o reglas, utilizamos los nombres de campo originales de la fuente de registros de origen. Si los nombres de campo provienen de valores anidados (por ej. usuarioIdentidad anidado bajo idCuenta en aws cloudtrail) usamos un punto para indicar que el campo está anidado ya que esto es relativamente consistente entre diferentes SIEMs (por ej. usuarioIdentidad -> idCuenta se convierte en usuarioIdentidad.idCuenta).
Pruebas de Reglas SIGMA
Probar reglas SIGMA es simple. A menudo la gente incluso puede enviar contenido sin probarlo ellos mismos directamente. La mayoría de los investigadores públicos no tienen acceso a entornos diversos para probar reglas contra ‘el conjunto de todos los SIEMs’. En su lugar, uno puede confiar en comentarios públicos, comentarios de partes confiables, etc. Incluso Florian Roth, un co-creador de SIGMA regularmente publica reglas al público por comentarios a través de su Twitter. También he visto a personas publicar directamente en sus blogs personales y LinkedIn, etc. Si crees que tienes una buena regla para compartir, ¡ponla allí, confía en mí si está equivocada (o no) la gente encantadora en internet te lo hará saber! No te tomes demasiado en serio y prepárate para hacer cambios y aprender algo.
Hay algunos pasos básicos que puedes seguir:
- Asegurarse de que la regla se traduce (uncoder o utilizando SIGMAC)
- Verificación de cordura (por ej., asegurarse de que la regla cumple con tu expectativa original, sigue la taxonomía correcta, etc.) – ver trampas:Probar la regla en un entorno de laboratorio Probar la regla en un entorno de laboratorio
- Compartir ampliamente la regla para las pruebas / compartir la regla con el equipo de SOC Prime a través del Program Treat Bounty
- Desde una perspectiva de autor de reglas, generalmente no debes preocuparte por las implementaciones de backends de reglas. Corresponde a los autores de backends SIGMA, y a personas como SOC Prime para asegurarse de que las traducciones cumplen con la intención original de una regla válida. Si se identifica un error, siempre vale la pena enviar un problema a GitHub.
Nota: Llamado a la Acción & Trabajo Futuro
¡Si llegaste hasta aquí, estás más que preparado para escribir y compartir tu primera regla! Si disfrutaste este blog, puede que disfrutes otro que vendrá pronto sobre cómo usar SIGMAC para personalizar contenido.
If you made it this far, you are more than prepared to write and share your first rule! If you enjoyed this blog, you may enjoy another one coming soon about using SIGMAC to customize content.
