Qu’est-ce que les règles SIGMA : Guide du débutant
Table des matières :
Cet article de blog plaide en faveur de SIGMA en tant que langage de détection, couvre les composants de règles SIGMA les plus critiques (source de journal & détection), la taxonomie SIGMA, le test des règles SIGMA, et prépare généralement les analystes qui sont nouveaux à SIGMA à écrire leurs premières règles. Une brève discussion sur l’ingénierie de détection avec SIGMA est également proposée concernant le bruit, les idées, les sources de journal, etc.
Le cas des règles SIGMA
Dans le passé, les détections SIEM existaient dans des silos spécifiques aux vendeurs / plateformes. Les partenaires souhaitant partager du contenu de détection devaient souvent traduire une requête d’un vendeur à un autre. Cela 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 YARA ou les règles Snort, SIGMA est un autre outil pour le partage ouvert de détection, sauf qu’il se concentre sur les SIEM au lieu des fichiers ou du trafic réseau. SIGMA permet aux défenseurs de partager des détections (alertes, cas d’utilisation) dans un langage commun.
Lancé pour la première fois en 2017 par Florian Roth et Thomas Patzke, SIGMA ouvre la voie à une recherche indépendante de la plateforme. Avec SIGMA, les défenseurs sont libérés du langage de détection et des dépôts spécifiques aux vendeurs & plateformes et peuvent exploiter la puissance de la communauté pour répondre rapidement aux menaces critiques et aux nouvelles techniques adverses.
Il y a de nombreuses raisons d’utiliser SIGMA :
- Les chercheurs et les équipes de renseignement qui identifient de nouveaux comportements d’adversaires et veulent un moyen agnostique de partager des détections
- MSSP / MDR responsables de multiples solutions SIEM / EDR / Log Analytics & taxonomies/schémas de données (ECS, CEF, CIM, etc.)
- Éviter l’enfermement propriétaire, en définissant des règles dans un SIGMA, nous pouvons naviguer plus facilement entre les plateformes.
- Chercheurs dans le domaine de la sécurité offensive voulant créer des détections basées sur leurs recherches
Note : Dans ce blog, le terme SIEM est utilisé pour décrire toute plateforme utilisée pour collecter et rechercher des journaux. Je reconnais que de nombreuses plateformes listées peuvent ne pas correspondre à votre définition de « SIEM ». Cependant, utiliser les termes « plateforme » ou « plateforme de journalisation » est trop ambigu.
Création de règles SIGMA
Écrire des règles SIGMA nécessite des connaissances de base sur le schéma et la taxonomie SIGMA, avoir une idée, adapter cette idée à SIGMA, tester, partager et potentiellement maintenir la règle.
Contexte et arrière-plan recommandés
Malgré la longueur de ce blog, grâce à YAML et à la vision prospective des créateurs, SIGMA est facile à comprendre et à écrire. Chez SOC Prime, nous aimons dire que « tout le monde peut apprendre SIGMA ». L’art de l’ingénierie de détection est là où les choses peuvent devenir plus compliquées.
Il existe beaucoup d’autres ressources telles que le wiki officiel et certains guides écrits par des experts SIGMA (listés ci-dessous). Il y a certains pièges tels que la gestion appropriée des jokers or noms de champs incorrects qui peuvent causer des règles défaillantes et beaucoup de ces points sont abordés dans ces ressources.
Si vous êtes un chercheur cherchant à vous initier à SIGMA, le Programme de prime à la menace de SOC Prime est une excellente opportunité pour commencer et gagner un peu d’argent. Les règles soumises sont soumises à un processus d’examen 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 journal génériques, Thomas Patzke 2019
Regarder recommandé :
Types de détections que les règles SIGMA peuvent exprimer
Aujourd’hui, il existe actuellement deux types de règles de base :
- Règles SIGMA basées sur des correspondances, largement supportées, les plus faciles à écrire
- Règles SIGMA basées sur des correspondances et des corrélations simples, support limité, moins faciles à écrire
Note : Il existe également des règles SIGMA multi-yaml, cependant celles-ci ont généralement perdu de la faveur au profit des règles spécifiques aux sources de journal. L’équipe SOC Prime ne crée généralement pas de règles multi-yaml parce qu’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 simple règle SIGMA !
Une idée (et quelques réflexions sur l’ingénierie de détection avec SIGMA)
Les utilisateurs et les administrateurs gardent souvent des mots de passe sensibles dans des documents en texte clair tels que des fichiers texte, excel, word, etc. Je suis préoccupé par le fait que des adversaires puissent 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 criminel.
Pour de nombreuses règles SIGMA, il est préférable pour l’auteur d’abstraire l’idée et de l’élargir de manière ‘raisonnable’. Pour des idées comme celle-ci, nous pouvons faire des suppositions éclairées sur ce à quoi le comportement may ressemble, pas seulement ce que nous avons observé. Par exemple, nous pouvons faire des suppositions éclairées sur des termes supplémentaires et des extensions que les utilisateurs peuvent utiliser pour stocker les mots de passe en texte clair.
L’idée d’« élargir » une règle est contre-intuitive pour les instincts 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 étrangers. Nous pouvons laisser les fournisseurs d’EDR et d’anti-virus s’inquiéter de créer des détections qui ne peuvent avoir aucun faux positif. Avec les règles SIGMA, on peut 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 en même temps sans les tester est une recette pour un désastre. Désactiver les règles au lieu de digérer et d’ajuster leurs intentions pour un environnement fera manquer à un magasin un contenu de détection solide.
J’aime donner l’exemple de psexec. Dans certains environnements, psexec est complètement normal et le statu quo pour les administrateurs qui administrent à distance les hôtes. Dans d’autres environnements, psexec est (probablement à juste titre) non autorisé, bloqué et constitue une infraction pour les administrateurs d’utiliser. 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 le tester, le réglage du bruit sera toujours un problème. Seules les règles identifiées comme “critiques” sont censées être sûres à utiliser sans test.
Retour à la création de notre règle SIGMA d’exposition aux mots 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 journal
Une fois que nous avons une idée, nous aurons besoin d’une source de journal. SIGMA prend en charge la source any de journal théoriquement, cependant, nous devrions identifier une source de journal que la plupart des gens ont. Par exemple, nous pourrions être capables d’écrire une règle pour une source de journal 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 facilement adoptée.
Pour les règles de point d’extrémité Windows, Sysmon est un bon point de départ. Sysmon est couramment déployé dans les environnements, et de nombreuses sources de journal fournissent des données synonymes (EDRs, etc.). Avec Sysmon, il y a deux options principales, la création de processus (process_creation dans SIGMA) et la création de fichiers (file_event dans SIGMA).
Nous bâtirons notre détection à partir de 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 journal pour apprendre et c’est l’une des plus utiles / populaires sources de journaux utilisées dans les détections de point d’extrémité.
Note : 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, on peut facilement identifier les règles SIGMA valables à écrire. 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:WindowsSystem32notepad.exe
CommandLine : “C:WindowsSystem32NOTEPAD.EXE” C:UsersJohnDesktoppassword.txt
Adapter l’idée de détection à SIGMA
Maintenant que nous avons une idée, et une source de données avec laquelle travailler, nous pouvons commencer à construire notre règle.
Cela n’est pas documenté mais les véritables composants nécessaires pour traduire une règle sont juste logsource & détection (pour certains backends comme Splunk, seule la détection est suffisante). Tout le reste est juste du métadata pour aider le consommateur de la règle SIGMA. Lorsque vous commencez, il est dans votre intérêt de commencer par ces champs minimaux, de confirmer que votre logique fonctionne et ensuite d’ajouter des champs SIGMA et des données supplémentaires. Si vous voulez publier votre règle dans le référentiel public SIGMA, il vaut la peine de vérifier les soumissions précédentes et d’imiter leur formatage.
Une règle SIGMA de base avec des composants minimaux pour une exposition potentielle des mots de passe :
titre : Exposition potentielle des mots de passe (via cmdline)
auteur : Adam Swan
étiquettes :
- attack.t1552.001
- attack.credential_access
source de journal :
produit : windows
catégorie : création de processus
détection :
sélection :
Image|se termine par:
- 'notepad.exe'
- 'word.exe'
- 'excel.exe'
- 'wordpad.exe'
- 'notepad++.exe'
CommandLine|contient :
- 'pass' #pass correspondra à password, inclure password est redondant
- 'pwd'
- 'pw.' #pw.txt, etc.
- 'account' #accounts,
- 'secret'
- 'details' #J'ai inclus les détails au pluriel basé sur l'expérience
condition : sélection
Composant logsource
The logsource Le composant aide le traducteur de back-end SIGMA (SIGMAC) à savoir sur quel type de données la règle doit être appliquée. Il permet au créateur de règle de créer des règles plus génériques. Par exemple, avec logsource étant “produit : windows, catégorie : création de processus”, nous n’avons pas besoin de spécifier les EventIDs (Sysmon 1, Windows 4688, ProcessRollup, etc.). Le consommateur de la règle peut spécifier quels identifiants d’événements, index, etc. qu’ils souhaitent associer avec les sources de journaux dans la Config SIGMA. Sans spécification des index, des identifiants d’événements, etc., les règles seront probablement inutilement coûteuses (performance) pour le consommateur.
De plus, souvent, la télémétrie peut 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 de explorer.exe dans le Image champ d’un événement de connexion réseau Sysmon est complètement différente de son existence dans un événement de création de processus. En fournissant le composant de source de journal approprié, nous fournissons un contexte inestimable pour la détection.
Composant de détection
Le composant de détection est là où l’auteur définit leurs 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 de délai qui est requis pour les règles basées sur la corrélation.
Sous-composant de sélection(s) :
Généralement, cela prendra la forme Champ A contient/commence par/se termine par/équivaut Valeur B. Bien sûr, comme observé dans la règle d’exemple ci-dessus, si un auteur en a besoin, il peut étendre et inclure une logique telle que Champ A contient/commence par/se termine par/équivaut 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 traité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 ne s’en tenir qu’aux 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 voulez. Souvent une variation de sélection est utilisée, mais on peut tout aussi facilement nommer sa sélection banane et la règle fonctionnerait toujours. En général, 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 de 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 supportées par les backends aujourd’hui. Il existe d’autres corrélations supportées par le schéma SIGMA.. mais pas encore par les backends disponibles.
Count() par Y :
Compter les instances uniques de la valeur du champ Y et la comparer (plus grand que, inférieur à) à un nombre statique.
Exemple : Count() par src_ip > 2
Count(X) par Y :
Compter les instances uniques de la valeur du champ X par Y et comparer (plus grand que, inférieur à) le nombre de X à un nombre statique.
Exemple : Count(EventID) par src_ip > 2
Utilisations courantes de la corrélation :
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. |
Sous-composant de délai :
The délai le composant est utilisé en conjonction avec des conditions qui incluent une corrélation. De nombreuses backends ignorent le délai, cependant, il est généralement toujours inclus et requis pour être inclus dans la plupart des référentiels, y compris celui de SOC Prime.
Exemples complets utilisant Splunk :
Voici quelques exemples de SIGMA et de leurs traductions pour Splunk. Si vous n’êtes pas familier avec Splunk, les astérisques sont un joker donc un terme entouré d’astérisques (par exemple, *terme*) est ‘contient’, un terme avec un astérisque en tête (par exemple, *terme) est se termine par, un terme avec un astérisque de queue est ‘se termine par’ (par exemple, terme*).
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 |
Questions de taxonomie (par exemple, quels noms de champs utiliser)
Théoriquement, vous pouvez utiliser n’importe quels noms de champs que vous souhaitez, tant que quelqu’un est prêt à consacrer du temps pour écrire une Configuration SIGMA pour traduire de vos champs.. aux leurs.
Note : Les noms de champs sont sensibles à la casse ! CommandLine and commandline sont deux valeurs différentes. CommandLine fait partie de la taxonomie existante, commandline ne l’est pas.
Cela étant dit, il est préférable d’utiliser les noms de champs documentés par SIGMA. Il y a trois endroits où le référentiel public SIGMA documente la taxonomie.
- En général, 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 des
- champs SYSMON pour les règles de point d’extrémité
- Format de fichier journal é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 & les fichiers de configuration SIGMA
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
- Véritablement la documentation officielle pour les champs. Les utilisateurs peuvent créer / modifier ceux-ci au besoin lorsqu’ils traduisent des règles.
- https://github.com/SigmaHQ/sigma/tree/master/rules
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
Enfin, si aucune configuration ou règle n’existe, nous utilisons les noms de champs originaux de la source de journal d’origine. Si les noms de champs proviennent de valeurs imbriquées (par exemple, userIdentity imbriqué sous accountId dans aws cloudtrail) nous utilisons un point pour indiquer que le champ est imbriqué car c’est relativement cohérent entre différents SIEMS (par exemple, userIdentity -> accountId devient userIdentity.accountId).
Test des règles SIGMA
Tester les règles SIGMA est simple. Souvent, les gens peuvent même soumettre du contenu sans le tester directement eux-mêmes. La plupart des chercheurs publics n’ont pas accès à des environnements diversifiés pour tester les règles contre ‘l’ensemble de tous les SIEM’. Au lieu de cela, on peut compter sur les retours publics, les retours de parties de confiance, etc. Même Florian Roth, un co-créateur de SIGMA publie régulièrement des règles au public pour des avis via son Twitter. J’ai également vu des personnes publier directement sur leurs blogs personnels et LinkedIn, etc. Si vous pensez que vous avez une bonne règle à partager, mettez-la en ligne, croyez-moi, si elle est fausse (ou non) les charmants internautes vous le feront savoir ! Ne vous prenez pas trop au sérieux et préparez-vous à apporter des modifications et à apprendre quelque chose.
Il y a quelques étapes de base que vous pouvez suivre :
- S’assurer que la règle se traduit (uncoder ou en utilisant SIGMAC)
- Vérification de bon sens (par exemple, s’assurer que la règle répond à votre attente initiale, respecte la taxonomie correcte, etc.) – voir les pièges :https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
- Vérifier la règle dans un environnement de laboratoire
- Partager largement la règle pour les tests / partager la règle avec l’équipe SOC Prime via le Programme de primes de menace
Note : D’un point de vue auteur de règle, généralement, vous ne devriez pas vous soucier des implémentations de back-end de règles. Il revient aux auteurs de back-end SIGMA, et aux personnes comme SOC Prime, de s’assurer que les traductions répondent à l’intention originale d’une règle valide. Si un bug est identifié, il vaut toujours la peine de soumettre un problème sur GitHub.
Appel à l’action & Travail futur
Si vous êtes arrivé jusqu’ici, vous êtes plus que prêt à écrire et partager votre première règle ! Si vous avez apprécié ce blog, vous pourriez apprécier un autre à venir sur l’utilisation de SIGMAC pour personnaliser le contenu.
