Qu’est-ce que les règles SIGMA : Guide du débutant

Accédez au plus grand ensemble de données de règles de détection au monde

Inscrivez-vous gratuitement

Cet article de blog plaide pour SIGMA en tant que langage de détection, couvre les composants les plus critiques des règles SIGMA (logsource & détection), la taxonomie SIGMA, le test des règles SIGMA, et prépare généralement les analystes nouveaux à SIGMA à écrire leurs premières règles. Une courte discussion sur l’ingénierie de détection avec SIGMA est également fournie à propos du bruit, des idées, des sources de logs, etc.

Plaidoyer pour les Règles SIGMA

Par le passé, les détections SIEM existaient dans des silos spécifiques aux fournisseurs/plateformes. Les partenaires souhaitant partager du contenu de détection devaient souvent traduire une requête d’un fournisseur vers un autre. Ce n’est pas durable, la communauté de la cybersécurité défensive doit améliorer la façon dont nous partageons les détections pour suivre le rythme de nos adversaires en constante évolution.

Tout comme les règles YARA, ou Snort, SIGMA est un autre outil pour le partage ouvert de détections, sauf qu’il est axé sur les SIEM plutôt que sur les fichiers ou le trafic réseau. SIGMA permet aux défenseurs de partager des détections (alertes, cas d’utilisation) dans un langage commun.

Premièrement publié en 2017 par Florian Roth et Thomas Patzke, SIGMA ouvre la voie à la recherche indépendante de plateforme. Avec SIGMA, les défenseurs sont libérés des langages et des dépôts de détection spécifiques aux fournisseurs et aux plateformes et peuvent exploiter la puissance de la communauté pour répondre rapidement aux menaces critiques et aux nouvelles tactiques adverses.

Il existe de nombreuses raisons d’utiliser SIGMA :

• Les chercheurs et équipes de renseignement qui identifient de nouveaux comportements adverses et veulent un moyen neutre de partager les détections
• MSSP / MDR responsables de multiples solutions SIEM / EDR / Log Analytics & taxonomies de données/schémas (ECS, CEF, CIM, etc.)
• Évitez la dépendance aux fournisseurs, en définissant des règles dans un SIGMA, nous pouvons passer plus facilement d’une plateforme à une autre.
• Les chercheurs dans le domaine de la sécurité offensive souhaitant créer des détections basées sur leurs recherches

Remarque : Dans ce blog, SIEM est utilisé pour décrire toute plateforme utilisée pour collecter et rechercher des journaux. J’accepte que beaucoup des plateformes listées ne correspondent pas à votre définition de « SIEM ». Cependant, utiliser les termes « plateforme » ou « plateforme de logs » est trop ambigu.

« Les règles Sigma sont des principes clés qui améliorent la prise de décision et la résolution de problèmes dans différents domaines. Elles soulignent l’importance de comprendre la variabilité des données et d’établir des processus solides. Suivre ces directives aide les équipes à développer des stratégies à la fois efficaces et flexibles face au changement. »

Ruslan MikhalovResponsable de la recherche sur les menaces chez SOC PrimeSuivre

Création de Règles SIGMA

Écrire des règles SIGMA nécessite une connaissance de base du schéma et de la taxonomie SIGMA, d’avoir une idée, d’adapter cette idée à SIGMA, de tester, de partager, et potentiellement de maintenir la règle.

Contexte et arrière-plan recommandés

Malgré la longueur de ce blog, grâce à YAML et à la réflexion prospective des créateurs, SIGMA est facile à comprendre et à écrire. Chez SOC Prime, nous aimons dire « tout le monde peut apprendre SIGMA ». L’art de l’ingénierie de la détection est là où les choses peuvent devenir plus compliquées.

Il existe de nombreuses autres ressources telles que le wiki officiel et quelques guides écrits par des experts SIGMA (listés ci-dessous). Il existe certains pièges tels que la gestion correcte des caractères génériques or des noms de champs incorrects qui peuvent entraîner des règles incorrectes et beaucoup de ces problèmes sont abordés dans ces ressources.

Si vous êtes un chercheur désireux de vous lancer dans SIGMA, le programme de récompense des menaces de SOC Prime est une excellente opportunité pour commencer et gagner un peu d’argent. Les règles soumises passent par un processus de révision approfondi où nous pouvons vous guider et vous aider à comprendre les erreurs et à progresser en tant qu’analyste.

Lectures recommandées :

• Comment Écrire des Règles SIGMA, Florian Roth 2018
• Un Guide des Sources de Logs Génériques, Thomas Patzke 2019

Recommandation de Visionnage :

• Tout Savoir sur SIGMA – Adam Swan
  
  
  

Types de Détections que les Règles SIGMA Peuvent Exprimer

Aujourd’hui, il existe deux types fondamentaux de règles :

• Règles SIGMA basées sur la correspondance, largement supportées, les plus faciles à écrire
• Règles SIGMA basées sur la correspondance et les corrélations simples, support limité, moins facile à écrire

Remarque : Il existe aussi des règles SIGMA multi-yaml, cependant celles-ci ont généralement été abandonnées en faveur des règles spécifiques à la source de logs. L’équipe SOC Prime ne crée généralement pas de règles multi-yaml car elles ajoutent une complexité inutile à la maintenance et au déploiement des règles. Quelqu’un peut créer une règle SIGMA multi-yaml s’il peut créer deux règles SIGMA.

Créons une Règle SIGMA Simple !

Une idée (et quelques réflexions sur l’ingénierie de détection avec SIGMA)

Les utilisateurs et administrateurs conservent souvent des mots de passe sensibles dans des documents en clair tels que des fichiers texte, Excel, Word, etc. Je crains que les adversaires pourraient identifier ces fichiers avant moi dans un environnement. Nous voulons instruire nos utilisateurs sur la façon de stocker correctement les mots de passe avant qu’ils ne soient découverts par un hacker criminel.

Pour de nombreuses règles SIGMA, il est dans l’intérêt de l’auteur d’abstraire l’idée et d’élargir ‘raisonnablement’ la cible. Pour des idées comme celle-ci, nous pouvons faire des suppositions éclairées sur ce que le comportement may pourrait ressembler, pas seulement ce que nous avons observé. Par exemple, nous pouvons faire des suppositions éclairées sur des termes et extensions supplémentaires que les utilisateurs peuvent utiliser pour stocker des mots de passe en clair.

L’idée d’« élargir » une règle est contre-intuitive pour de nombreux analystes. Éliminer tous les « faux positifs » n’est pas nécessairement l’objectif de l’auteur original lorsqu’une règle sera consommée dans des environnements inconnus et peu familiers. Nous pouvons laisser les fournisseurs d’EDR et d’Anti-Virus s’occuper de créer des détections qui ne peuvent pas avoir de faux positifs. Avec les règles SIGMA, nous pouvons les tester dans des environnements et les ajuster facilement.

SIGMA est facilement compréhensible, testable et ajustable. Si un terme comme ‘détails’ est trop bruyant pour un environnement, la personne mettant en œuvre la règle devrait se sentir habilitée à ajuster la règle. Déployer toutes les règles à la fois sans test est une recette pour le désastre. Désactiver des règles au lieu de comprendre et d’ajuster leurs intentions pour un environnement fera manquer à une entreprise des contenus de détection solides.

J’aime donner l’exemple de psexec. Dans certains environnements, psexec est complètement normal et la norme pour les administrateurs afin d’administrer à distance des hôtes. Dans d’autres environnements, psexec est (probablement à juste titre) désapprouvé, bloqué et une infraction passible d’action pour les administrateurs. Alors, une règle SIGMA pour détecter toute utilisation de psexec est-elle ‘bruyante’ ou simplement meilleure pour certains environnements que d’autres. Si vous déployez du contenu sans test, ajuster le bruit sera toujours un problème. Seules les règles identifiées comme ‘critiques’ sont censées être sûres à utiliser sans test.

Revenons à la création de notre règle d’exposition de mot de passe… nous pouvons élargir l’idée pour inclure des noms de fichiers supplémentaires tels que :

• pw
• psw
• pass
• mot de passe
• mots de passe
• comptes
• compte
• info

Créé avec des logiciels tels que :

• Notepad
• Notepad++
• Wordpad
• Applications Office
  
  
  

Une source de données / Une source de journaux

Une fois que nous avons une idée, nous aurons besoin d’une source de journaux. SIGMA supporte any théoriquement, cependant nous devrions identifier une source de journaux que la plupart des gens ont. Par exemple, nous pourrions être capables d’écrire une règle pour une source de journaux de prévention des pertes de données mais la prévention des pertes de données est rarement analysée et ingérée dans les SIEM et l’industrie n’a pas de favori clair. Donc, nous pouvons créer une règle valide, mais elle ne sera pas aussi facilement adoptée.

Pour les règles de point d’extrémité Windows, Sysmon est un excellent point de départ. Sysmon est couramment déployé dans les environnements, et de nombreuses sources de journaux fournissent des données synonymes (EDRs, etc.). Avec Sysmon, il y a deux principales options, la création de processus (process_creation dans SIGMA) et la création de fichier (file_event dans SIGMA).

Nous baserons notre détection sur la création de processus car elle est plus largement adoptée, garantissant ainsi que notre règle soit aussi utile que possible. La création de processus est une excellente source de journaux pour apprendre et c’est l’une des sources de journaux les plus utiles/populaires utilisées dans les détections d’endpoints.

Remarque : Souvent, les idées viennent directement des sources de données elles-mêmes. En examinant les types de données disponibles dans votre SIEM / laboratoire, vous pouvez facilement identifier des règles SIGMA qui valent la peine d’être écrites. Nous pouvons également utiliser d’autres sources comme la documentation des fournisseurs.

Avec les événements de création de processus sysmon (ID d’événement 1), un utilisateur accédant à un fichier contenant des mots de passe peut contenir ces champs intéressants :

Image: C:\Windows\System32\notepad.exe
CommandLine: “C:\Windows\System32\NOTEPAD.EXE” C:\Users\John\Desktop\password.txt

Adapter l’idée de détection à SIGMA

Maintenant que nous avons une idée et une source de données sur laquelle travailler, nous pouvons commencer à construire notre règle.

Cela n’est pas documenté, mais les vrais éléments minimaux nécessaires pour traduire une règle sont juste & logsource (pour certains backends comme Splunk, seule la détection suffit). Tout le reste est ‘juste’ des métadonnées pour aider le consommateur de règles SIGMA. Lorsque vous commencez, il est dans votre intérêt de commencer avec ces champs minimaux, de confirmer que votre logique fonctionne, puis d’ajouter des champs et des données SIGMA supplémentaires. Si vous souhaitez publier votre règle dans le dépôt public de SIGMA, il est utile de vérifier les soumissions précédentes et d’émuler leur formatage. détection (for some backends like Splunk, just detection is enough). Everything else is ‘just’ metadata to help the SIGMA rule consumer. When you start it is in your interest to start with these minimal fields, confirm your logic is working and then add additional SIGMA fields & data. If you want to publish your rule to the public SIGMA repo it is worth checking previous submissions and emulating their formatting. 

Une règle SIGMA de base avec des composants minimaux pour une exposition potentielle de mots de passe :

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

Composant Logsource

The logsource le composant aide le traducteur SIGMA backend (SIGMAC) à savoir à quel type de données la règle devrait être appliquée. Il permet au créateur de la règle de créer des règles plus génériques. Par exemple, avec logsource étant  »produit : windows, catégorie : process_creation », nous n’avons pas besoin de spécifier les IDs d’événements (Sysmon 1, Windows 4688, ProcessRollup, etc.). Le consommateur de la règle peut spécifier quels EventIDs, indexes, etc. ils veulent associer aux sources de logs dans le Config SIGMA. Sans spécifier les indexes, EventIDs, etc., les règles seront probablement inutilement coûteuses (en termes de performance) pour le consommateur.

De plus, la télémétrie peut souvent contenir des champs similaires mais impliquer des comportements totalement différents. Par exemple, les événements de connexion réseau Sysmon (ID d’événement 3) et la création de processus (ID d’événement 1) partagent le champ Image L’existence d’explorer.exe dans le champ de l’événement de connexion réseau Sysmon est complètement différente de l’existence d’explorer.exe dans un événement de création de processus. En fournissant le composant logsource approprié, nous fournissons un contexte inestimable à la détection. Image 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.

Composant détection

Le composant de détection est l’endroit où l’auteur définit ses critères de détection. Cela inclut au moins un composant de sélection et un composant de condition. Il y a un composant optionnel période qui est requis pour les règles basées sur la corrélation.

Sous-composant de sélection :

• Généralement, cela prendra la forme Champ A contient/commence par/termine par/égal à Valeur B. Bien sûr, comme observé dans la règle d’exemple ci-dessus, si un auteur le souhaite, il peut étendre et inclure une logique telle que Champ A contient/commence par/termine par/égal à Valeurs X, Y ou Z. Cette logique est toujours insensible à la casse.
  
  
• Il existe des ‘modificateurs’ plus avancés qui augmentent la complexité de la règle, ou permettent aux auteurs d’être plus précis. Par exemple, les expressions régulières sont gérées par l’opérateur re et permettent aux auteurs de faire des choses telles qu’écrire des requêtes sensibles à la casse. Pour des raisons de compatibilité, il est préférable de n’utiliser que les opérateurs d’expression régulière de base . ? + * | { } [ ] ()  » .
  
  
• Les sélections sont nommées (par exemple sélection, sélection2, sélection3, filtre). Les sélections peuvent être nommées (presque) comme vous le souhaitez. Souvent une variation de sélection est utilisée, mais on peut tout aussi bien nommer sa sélection banane et la règle fonctionnerait toujours. Généralement, le terme filtre est utilisé pour les sélections qui seront exclues (par exemple, sélection ET NON filtre).
  

Sous-composant de condition :

• Le composant condition contient la logique booléenne (ET, OU, NON) définissant comment chaque sélection doit être incluse dans la requête finale.
  
  
• Par exemple (sélection_a OU sélection_b) ET NON filtre

Composant de condition avec corrélation: 

Il existe deux types de corrélations prises en charge par les backends aujourd’hui. Il existe d’autres corrélations prises en charge par le schéma SIGMA.. mais pas encore par les backends disponibles.

Count() par Y :
Compter les instances uniques de valeurs de champ Y et les comparer (supérieur, inférieur) à un nombre statique.
Exemple : Count() par src_ip > 2
Count(X) par Y :
Compter les instances uniques de valeur de champ X par valeur Y et comparer (supérieur, inférieur) le nombre de X à un nombre statique.
Exemple : Count(EventID) par src_ip > 2

Cas d’utilisation courants de corrélation :

Composant de période :

• The période le composant est utilisé conjointement avec des conditions qui incluent une corrélation. De nombreux backends ignorent la période, cependant, elle est généralement toujours incluse et requise pour être incluse dans la plupart des référentiels, y compris celui de SOC Prime.

Exemples Complets Utilisant Splunk :

• Voici quelques exemples de SIGMA et leurs traductions pour Splunk. Si vous n’êtes pas familier avec Splunk, les astérisques sont des caractères génériques donc un terme entouré d’astérisques (par ex. *terme*) est ‘contient’, un terme avec un astérisque de tête (par ex. *terme) est ‘termine par’, un terme avec un astérisque en queue est ‘termine par’ (par ex. terme*).

Questions de Taxonomie (par ex. quels noms de champs utiliser)

Théoriquement, vous pouvez utiliser les noms de champs que vous souhaitez, tant que quelqu’un est prêt à consacrer le temps nécessaire pour écrire une configuration SIGMA pour traduire de vos champs.. vers les leurs.

Remarque : Les noms de champs sont sensibles à la casse ! CommandLine and commandline sont deux valeurs différentes. CommandLine fait partie de la taxonomie existante, commandline n’en fait pas partie.

Cela étant dit, il est préférable d’utiliser les noms de champs documentés par SIGMA. Il existe trois endroits où le référentiel SIGMA public documente la taxonomie.

En règle générale, nous utilisons les noms de champs SIGMA spécifiés dans le wiki pour les catégories

• https://github.com/SigmaHQ/sigma/wiki/Taxonomy
• Le wiki révélera aux lecteurs que SIGMA utilise
  — Champs SYSMON pour les règles de points d’extrémité
  — Format de fichier de log étendu W3C pour les règles de serveur web & proxy
  — Les champs pour le pare-feu, l’antivirus

Suivi par les noms de champs SIGMA spécifiés dans les règles existantes & fichiers de configuration SIGMA

• https://github.com/SigmaHQ/sigma/tree/master/tools/config
  • Vraiment la documentation officielle pour les champs. Les utilisateurs peuvent créer/modifier ceux-ci si nécessaire lorsqu’ils traduisent des règles.
  • https://github.com/SigmaHQ/sigma/tree/master/rules
    
    

Enfin, si aucune configuration ou règle n’existe, nous utilisons les noms de champs d’origine de la source de journaux d’origine. Si les noms des champs proviennent de valeurs imbriquées (par ex. userIdentity imbriqué sous accountId dans aws cloudtrail) nous utilisons un point pour indiquer que le champ est imbriqué car c’est relativement cohérent à travers différents SIEM (par ex. userIdentity -> accountId devient userIdentity.accountId).

Tester les Règles SIGMA

Tester les règles SIGMA est simple. Souvent, les gens sont même capables de soumettre du contenu sans le tester directement eux-mêmes. La plupart des chercheurs publics n’ont pas accès à divers environnements pour tester les règles contre ‘l’ensemble de tous les SIEM’. Au lieu de cela, on peut se fier aux retours publics, aux retours de parties de confiance, etc. Même Florian Roth, un co-créateur de SIGMA, publie régulièrement des règles pour recueillir des retours sur Twitter. J’ai également vu des gens publier directement sur leurs blogs personnels et LinkedIn, etc. Si vous pensez avoir une bonne règle à partager, publiez-la, croyez-moi si elle est mauvaise (ou non) les gentils gens sur Internet vous le feront savoir ! Ne vous prenez pas trop au sérieux et soyez prêt à faire des changements et à apprendre quelque chose.

Il y a certaines étapes de base que vous pouvez suivre :

1. S’assurer que la règle se traduit (uncoder ou en utilisant SIGMAC)
2. Vérification de la logique (par exemple s’assurer que la règle répond à votre attente initiale, suit la taxonomie correcte, etc.) – voir les pièges : https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
3. Vérification de la règle dans un environnement de laboratoire
4. Partage de la règle largement pour test / partage de la règle avec l’équipe SOC Prime via le programme de récompense des menaces

Remarque : Du point de vue d’un auteur de règle, généralement, vous ne devriez pas vous soucier des mises en œuvre des règles backend. C’est aux auteurs des backends SIGMA et aux équipes comme SOC Prime de s’assurer que les traductions respectent l’intention originale d’une règle valide. Si un bug est identifié, cela vaut toujours la peine de soumettre un problème sur GitHub.

À propos de SOC Prime

Vétérans de l’Industrie

• Fondé l’industrie Detection-as-Code en 2015
• Partenariat avec Fortune 100 + MDRs mondiaux

Interface Al pour les Opérations SOC

• Couvrant tout le pipeline, de la détection à la simulation
• Recherche de menaces magique au lieu de filtres

Le plus grand ensemble de données d’intelligence de détection au monde

• 650 000+ règles de détection
• Nouvelles menaces quotidiennes

100 Go / Jour par Pipeline en Temps Réel

• Détection ETL à la Vitesse de la Ligne
• Détection Shift-Left, Bien Fait

Accédez au plus grand ensemble de données de règles de détection au monde

Inscrivez-vous gratuitement

Adam SwanIngénieur Senior en Chasse aux Menaces chez SOC PrimeSuivre

Recherche sur les menaces et détections pour les expliquer aux ingénieurs.