Et puis on a appris qu'un groupe de passionnés a décidé d'organiser un sprint de deux semainessur l'écriture de règles pour le projet Sigma , qui a été créé pour développer un format unifié de description des règles pour les systèmes SIEM et qui est soutenu par plus de 140 participants. Nous étions intéressés par l'actualité de l'événement, car en tant que fournisseur SIEM, nous suivons de près le développement de la communauté.
Imaginez notre surprise lorsque les organisateurs nous ont contactés et ont invité l'équipe PT Expert Security Center à participer au sprint! Les participants à l'événement ont formé l'Open Security Collaborative Development (OSCD) - une initiative internationale de spécialistes de la sécurité de l'information visant à diffuser les connaissances et à améliorer la sécurité informatique en général. Nous avons volontiers accepté de participer afin de mettre notre expérience au service de la sécurité commune.
Comment cet article est né
Lorsque nous avons commencé à écrire les règles, nous nous sommes rendu compte qu'il n'y avait pas de description exhaustive de la syntaxe des règles Sigma, en particulier en russe. Les principales sources de connaissances sont GitHub et l'expérience personnelle. Il y a plusieurs bons articles (en russe et en anglais ), mais dans ceux-ci l'accent est déplacé de la syntaxe des règles à l'analyse du champ d'application des règles Sigma ou à la création d'une règle spécifique. Nous avons décidé de permettre aux débutants de se familiariser plus facilement avec le projet Sigma, de partager notre propre expérience, de collecter en un seul endroit des informations sur la syntaxe et les fonctionnalités de son utilisation. Et bien sûr, nous espérons que cela contribuera à étendre l'initiative OSCD et à créer une grande communauté à l'avenir.
Comme il y avait beaucoup de matériel, nous avons décidé de publier une description dans une série de trois articles:
- , ( ).
- . , .
- (, , , , ) .
Sigma
Sigma est un format unifié pour décrire les règles de détection basées sur les données des journaux. Les règles sont stockées dans des fichiers YAML séparés. Sigma vous permet d'écrire une règle en utilisant une syntaxe unifiée une fois, puis, à l'aide d'un convertisseur spécial, d'obtenir la règle dans la syntaxe d'un système SIEM pris en charge. Outre la syntaxe des requêtes de divers systèmes SIEM, la création de requêtes des types suivants est prise en charge:
- Requête Elasticsearch,
- ligne de lancement de l'utilitaire grep avec les paramètres requis,
- Chaîne PowerShell des journaux d'audit Windows.
Les deux derniers types se distinguent par le fait qu'ils ne nécessitent pas de logiciel supplémentaire pour analyser les journaux. L'utilitaire grep et l'interpréteur PowerShell sont pris en charge par défaut sur Linux et Windows, respectivement.
L'existence d'un format unifié pour décrire les détections basées sur les journaux facilite le partage des connaissances, le développement de la sécurité open source et aide la communauté de la sécurité de l'information à lutter contre les menaces émergentes.
Syntaxe générale
Tout d'abord, il faut dire qu'il existe des parties obligatoires et facultatives de la règle. Ceci est documenté dans le wiki officiel sur GitHub. Le contour de la règle (source: Wiki officiel) est présenté ci-dessous:
Presque toutes les règles peuvent être divisées en trois parties:
- attributs décrivant la règle (méta-informations);
- attributs décrivant les sources de données;
- attributs décrivant les conditions de déclenchement de la règle.
Chacune des parties correspond aux attributs de haut niveau requis du titre (en plus du titre, le dernier groupe comprend d'autres attributs facultatifs de haut niveau), de la source de journal et de la détection .
Il y a une autre caractéristique de la structure des règles qui mérite d'être évoquée. Étant donné que les règles sont décrites dans le langage de balisage YAML, les développeurs Sigma ont trouvé une certaine utilité pour cela, car le format YAML permet de placer plusieurs documents YAML dans un fichier. Et pour Sigma - plusieurs règles à combiner dans un seul fichier, c'est-à-dire créer des «collections de règles». Cette approche est pratique lorsqu'il existe plusieurs façons de détecter une attaque et que vous ne souhaitez pas dupliquer la partie descriptive (comme cela sera décrit dans la section correspondante, vous pouvez dupliquer non seulement la partie descriptive de la règle).
Dans ce cas, la règle est classiquement divisée en deux parties:
- une partie avec des attributs généraux pour les éléments de collection (généralement tous les champs, à l'exception des sections de source de journal et de détection),
- une ou plusieurs parties décrivant la détection (sections source de journal et détection).
Si le fichier contient une seule règle, cette déclaration est également vraie, car nous obtenons une collection dégénérée à partir d'une règle. Les collections de règles seront discutées en détail dans la troisième partie de cette série d'articles.
Ensuite, nous examinerons un exemple de règle hypothétique. Il est à noter que les commentaires sous cette forme ne sont généralement pas utilisés dans les règles, ici ils ne servent qu'à décrire les champs.
Description de la règle typique
Un exemple de création d'une règle Sigma
Avant de décrire les détails de la syntaxe et de parler des capacités des règles Sigma, considérons un petit exemple de création d'une telle règle afin de préciser d'où viennent en pratique ces ou ces valeurs d'attribut. Il y a un bon article sur ce sujet en anglais. Si vous avez déjà essayé d'écrire vos propres règles et déterminé quelles données vous devez spécifier dans l'attribut du fichier YAML, vous pouvez passer à la section suivante avec une description détaillée de la section des sources d'événements (nous appellerons également cette section sources de journal).
Décrivons comment créer une règle qui détecte l'utilisation de SettingSyncHost.exe en tant que binaire Living Off The Land (LOLBin). La création de règles implique généralement trois étapes:
- mener une attaque et collecter les logs nécessaires,
- description de la détection en règle générale,
- vérification de la règle créée.
Mener une attaque
L'idée de la règle est bien documentée sur le blog Hexacorn . Après une lecture attentive, il devient clair quelles étapes doivent être prises pour répéter le résultat décrit dans l'article:
- Copiez le programme que vous souhaitez exécuter dans n'importe quel répertoire inscriptible. L'article suggère de choisir% TEMP%, mais vous pouvez choisir le chemin de votre choix. Il est utile de considérer qu'un sous-répertoire sera créé dans ce répertoire avec le nom que vous spécifiez à l'étape 4.
- , , , (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). , findstr.exe. , SettingSyncHost.exe Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
- , ( settingsynchost.exe cmd PowerShell,
cd < >). - :
c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <___> - SettingSyncHost.exe.
Sysmon est installé sur le système avec un fichier de configuration du projet sysmon-modular . Ainsi, la collecte des logs a été effectuée automatiquement. Les types de journaux utiles pour écrire une détection seront visibles lors de l'écriture d'une règle.
Description de la détection sous la forme d'une règle Sigma
À cette étape, deux approches sont possibles: trouver une règle existante qui est la plus proche dans la logique de détection et la modifier en fonction de vos besoins, ou écrire une règle à partir de zéro. Dans les premières étapes, il est recommandé de s'en tenir à la première approche. Pour plus de clarté, nous écrirons une règle en utilisant la deuxième approche.
Nous créons un nouveau fichier et essayons de décrire brièvement et succinctement son essence dans le nom. Ici, vous devez respecter le style des règles existantes. Dans notre cas, nous avons choisi le nom win_using_settingsynchost_to_run_hijacked_binary.yml. Ensuite, nous commençons à le remplir de contenu. Commençons par remplir les méta-informations au début de la règle. Nous avons déjà toutes les données nécessaires pour cela.
Nous décrivons brièvement le type d'attaque que la règle détecte sur le terrain
title, des explications plus détaillées - dans le champ de description, pour les nouvelles règles, il est habituel de définir le statut: expérimental. L'identifiant unique peut être généré de plusieurs manières; sous Windows, le moyen le plus simple consiste à exécuter le code suivant dans un interpréteur PowerShell:
PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5fLe reste des champs parlent d'eux-mêmes, je noterai seulement qu'il est conseillé de fournir des liens vers des sources qui ont permis de comprendre l'attaque. Cela aidera les gens qui comprendront davantage cette règle, et c'est aussi un hommage aux efforts déployés par l'auteur de l'étude originale pour décrire l'attaque.
Notre règle à ce stade est la suivante:
Ensuite, vous devez décrire les sources des journaux. Comme mentionné ci-dessus, nous nous baserons sur les journaux Sysmon, cependant, avec l'avènement des catégories génériques, il est habituel d'utiliser la catégorie process_creation pour créer des processus. Plus d'informations sur les catégories généralisées seront discutées ci-dessous. Notez qu'il est habituel d'écrire des commentaires et des conseils sur la configuration des sources dans le champ de définition, tels que les fonctionnalités de configuration Sysmon:
Il est maintenant nécessaire de décrire la logique de détection. C'est la partie la plus longue. Cette attaque peut être détectée par de nombreux critères, notre exemple ne prétend pas couvrir tous les moyens de détection possibles, par conséquent, nous décrirons l'une des options possibles.
Si vous regardez les événements qui se sont produits, vous pouvez créer la chaîne suivante.
Tout d'abord, nous avons démarré le processus (PID: 4712) avec la ligne de démarrage c: \ windows \ system32 \ SettingSyncHost.exe -LoadAndRunDiagScript join_oscd
Notez que le répertoire de travail actuel du processus est le répertoire TEMP de l'utilisateur.
Ensuite, le processus en cours crée un fichier de commandes et démarre son exécution.
Le processus d'exécution des instructions du fichier batch a reçu l'identifiant 7076. Après une analyse plus approfondie des événements, on voit le lancement du fichier ipconfig.exe, qui ne contient pas les métadonnées inhérentes aux fichiers système et, en plus, se trouve dans le dossier avec les fichiers temporaires:
Il est proposé d'envisager le lancement de processus dont les fichiers exécutables ne sont pas localisés dans le répertoire système (C: \ Windows \ System32), et également si la ligne de démarrage du processus parent contient les sous-chaînes "cmd.exe / c", "RoamDiag.cmd" et "-outputpath". Décrivons cela dans la syntaxe Sigma et obtenons la règle finale (une analyse détaillée des constructions pouvant être utilisées pour décrire la logique de détection sera donnée dans la prochaine partie de notre série d'articles sur Sigma):
Vérifier que la règle fonctionne
Nous lançons le convertisseur dans une requête PowerShell: dans
notre cas, cette requête ne donnera pas le résultat souhaité, car le filtre d'exclusion trouve également le chemin vers l'image du fichier exécutable du processus parent. Par conséquent, nous indiquons simplement qu'il ne devrait pas y avoir de lettre t avant le mot Image - la fin du mot Parent:
Nous voyons que notre événement a été trouvé. La règle fonctionne.
C'est ainsi que les règles Sigma sont créées dans la pratique. Ensuite, nous décrirons en détail les champs responsables de la détection, à savoir la description des sources du journal.
Détecter la description
La partie principale de la règle est la description de la détection, car c'est là que sont contenues les informations sur où et comment rechercher des signes d'attaque. Ces informations sont contenues dans les champs des attributs de source de journal (où) et de détection (comment). Dans cet article, nous examinerons de plus près la section de source de journal et décrirons la section de détection dans la prochaine partie de notre série.
Description de la section des sources d'événements (attribut logsource)
La description des sources d'événements est contenue dans la valeur du champ logsource . Cette section décrit les sources de données à partir desquelles les événements de la section de détection seront fournis (l'attribut de détection est abordé dans la section suivante). La section décrit la source elle-même, la plate-forme et l'application nécessaires à la détection. Il peut contenir trois attributs traités automatiquement par les convertisseurs et un nombre arbitraire d'éléments optionnels. Champs de base:
- Catégorie - décrit les classes de produits. Exemples de valeurs pour ce champ: pare-feu, web, antivirus. En outre, le champ peut contenir des catégories généralisées, qui seront décrites ci-dessous.
- Le produit est un produit logiciel ou un système d'exploitation qui crée des journaux.
- Service - restriction des journaux à un certain sous-ensemble de services, par exemple "sshd" pour Linux ou "Security" pour Windows.
- Définition - un champ supplémentaire pour décrire les fonctionnalités de la source, par exemple, les exigences pour la configuration de l'audit (rarement utilisé, un exemple de règle avec ce champ peut être trouvé sur GitHub ). Il est recommandé d'utiliser cet attribut si la source a des spécificités.
Le wiki officiel sur GitHub définit un ensemble de champs qui doivent être utilisés pour que les règles soient multi-produits. Ces champs sont résumés dans le tableau ci-dessous.
| Catégorie | Produit | Un service |
|---|---|---|
| les fenêtres | Sécurité | |
| système | ||
| sysmon | ||
| Planificateur de tâches | ||
| wmi | ||
| application | ||
| Serveur dns | ||
| pilote-cadre | ||
| PowerShell | ||
| PowerShell-classique | ||
| Linux | auth | |
| auditd | ||
| clamav | ||
| apache | accès | |
| Erreur | ||
| process_creation | les fenêtres | |
| Procuration | ||
| pare-feu | ||
| serveur Web | ||
| DNS |
Ensuite, nous décrirons plus en détail certaines sources de journaux, en indiquant les champs d'événement utilisés et donnerons des exemples de règles dans lesquelles ces champs sont utilisés.
Champs d'événement de catégorie proxy
| Catégorie | Produit / Service | Des champs | Exemples |
|---|---|---|---|
| Procuration | c-uri | proxy_ursnif_malware.yml | |
| extension c-uri | proxy_download_susp_tlds_blacklist.yml | ||
| requête c-uri | proxy_susp_flash_download_loc.yml | ||
| c-uri-tige | proxy_susp_flash_download_loc.yml | ||
| c-useragent | proxy_powershell_ua.yml | ||
| cs-octets | - | ||
| cs-cookie | proxy_cobalt_amazon.yml | ||
| cs-hôte | proxy_cobalt_ocsp.yml | ||
| méthode cs | proxy_downloadcradle_webdav.yml | ||
| r-dns | proxy_apt40.yml | ||
| cs-referrer | - | ||
| version cs | - | ||
| sc-octets | - | ||
| sc-status | proxy_ursnif_malware.yml | ||
| src_ip | - | ||
| dst_ip | - |
Description des champs d'événement de cette source
-------------------------------------------------- ------------- c-uri - URI, c-uri-extension - URI. c-uri-query - URI, c-uri-stem - URL ( :) . URIstem - c-useragent - UserAgent HTTP- cs-bytes - , cs-cookie - cookie, cs-host - Host HTTP- cs-method - HTTP- r-dns - DNS- cs-referrer - Referrer HTTP- cs-version - HTTP, sc-bytes - , sc-status - HTTP- src_ip - IP- dst_ip - IP-
Champs d'événement de pare-feu
| Catégorie | Produit / Service | Des champs | Exemples |
|---|---|---|---|
| pare-feu | src_ip | - | |
| src_port | - | ||
| dst_ip | - | ||
| dst_port | net_high_dns_bytes_out.yml | ||
| Nom d'utilisateur | - |
Description des champs d'événement de cette source
--------------------------------------------------------------- src_ip - IP- src_port - , dst_ip - IP- dst_port - , username - ,
Champs d'événement de la catégorie Serveur Web
| Catégorie | Produit / Service | Des champs | Exemples |
|---|---|---|---|
| serveur Web | c-uri | web_cve_2020_0688_msexchange.yml | |
| extension c-uri | - | ||
| requête c-uri | - | ||
| c-uri-tige | - | ||
| c-useragent | - | ||
| cs-octets | - | ||
| cs-cookie | - | ||
| cs-hôte | - | ||
| méthode cs | web_cve_2020_0688_msexchange.yml | ||
| r-dns | - | ||
| cs-referrer | - | ||
| version cs | - | ||
| sc-octets | - | ||
| sc-status | - | ||
| src_ip | - | ||
| dst_ip | - |
Description des champs d'événement de cette source
--------------------------------------------------------------- c-uri - URI, c-uri-extension - URI. c-uri-query - URI, c-uri-stem - URI ( :) . URI stem - c-useragent - UserAgent HTTP- cs-bytes - , cs-cookie - cookie, cs-host - Host HTTP- cs-method - HTTP- r-dns - DNS- cs-referrer - Referrer HTTP- cs-version - HTTP, sc-bytes - , sc-status - HTTP- src_ip - IP- dst_ip - IP-
Catégories généralisées
Étant donné que Sigma est un format généralisé pour décrire les règles de détection basées sur des journaux, la syntaxe de ces règles devrait être en mesure de décrire la logique de détection pour différents systèmes. Certains systèmes utilisent des tableaux avec des données agrégées au lieu d'événements, et des données provenant de différentes sources peuvent entrer pour décrire la même situation. Pour unifier la syntaxe et résoudre des problèmes similaires, un mécanisme générique de sources de journaux a été introduit. Pour le moment, une de ces catégories a été créée - process_creation. Vous pouvez en savoir plus à ce sujet sur le blog patzke.org . La liste des champs pour cette catégorie se trouve sur la page de taxonomie (cette page décrit également d'autres catégories prises en charge).
Champs d'événement de catégorie généralisés process_creation
| Catégorie | Produit | Des champs | Exemples |
|---|---|---|---|
| process_creation | les fenêtres | UtcTime | - |
| ProcessGuid | - | ||
| ProcessId | sysmon_raw_disk_access_using_illegitimate_tools.yml | ||
| Image | win_susp_regsvr32_anomalies.yml | ||
| FileVersion | sysmon_susp_file_characteristics.yml | ||
| La description | sysmon_susp_file_characteristics.yml | ||
| Produit | sysmon_susp_file_characteristics.yml | ||
| Compagnie | sysmon_susp_file_characteristics.yml | ||
| Ligne de commande | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| Répertoire actuel | win_susp_powershell_parent_combo.yml | ||
| Utilisateur | win_susp_schtask_creation.yml | ||
| LogonGuid | - | ||
| LogonId | - | ||
| TerminalSessionId | - | ||
| Niveau d'intégrité | - | ||
| imphash | win_renamed_paexec.yml | ||
| md5 | - | ||
| sha256 | - | ||
| ParentProcessGuid | - | ||
| ParentProcessId | - | ||
| ParentImage | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| ParentCommandLine | win_cmstp_com_object_access.yml |
Description des champs d'événement de cette source
--------------------------------------------------------------- UtcTime - UTC ProcessGuid - GUID ProcessId - PID Image - FileVersion - , Description - , Product - , Company - — , CommandLine - CurrentDirectory - User - , LogonGuid - GUID LogonId - TerminalSessionId - IntegrityLevel - , imphash - - md5 - MD5- , sha256 - SHA256- , ParentProcessGuid - GUID ParentProcessId - PID ParentImage - ParentCommandLine -
METTRE À JOUR
En préparation de cet article, de nouvelles catégories génériques ont été ajoutées:
- network_connection (Exemple sysmon_powershell_network_connection )
- dns_query (Exemple sysmon_regsvr32_network_activity )
- Registry_event (exemple sysmon_rdp_settings_hijack )
- file_creation
- process_access (exemple sysmon_lsass_memdump )
- image_load (exemple sysmon_mimikatz_inmemory_detection )
- processus_terminé
Ils impliquent tous des informations en double dans les événements de journal Windows et les événements de journal Sysmon. Nous vous conseillons d'utiliser les catégories généralisées existantes lors de la rédaction de vos règles. Le projet étant en développement actif, il est conseillé de suivre l'émergence de nouvelles catégories et de mettre à jour vos règles en fonction des innovations ultérieures.
Statistiques d'utilisation de la source d'événements dans les règles existantes
Le tableau ci-dessous présente les constructions les plus courantes pour décrire les sources de journal. Très probablement, vous trouverez parmi eux celui qui convient à votre règle.
Statistiques sur l'utilisation d'une combinaison de champs de description pour certaines des sources les plus courantes (un tiret signifie l'absence de ce champ):
| Nombre de règles | Catégorie | Produit | Un service | Exemple de syntaxe | Un commentaire |
|---|---|---|---|---|---|
| 197 | process_creation | les fenêtres | - | logsource:
catégorie: process_creation produit: windows |
Catégorie généralisée de journaux de création de processus sur les systèmes Windows. Inclut Sysmon EventID
= 1 et le journal des événements de sécurité Windows EventID = 4688 |
| 68 | - | les fenêtres | sysmon | logsource:
produit: service windows : sysmon |
Événements Sysmon |
| 48 | -
|
les fenêtres | Sécurité | logsource:
product: windows service: security |
Windows Security Event Log |
| 24 | proxy | — | — | logsource:
category: proxy |
- |
| 15 | — | windows | system | logsource:
product: windows service: system |
Windows System Event Log |
| 12 | accounting | cisco | aaa | logsource:
category: accounting product: cisco service: aaa |
Cisco AAA Security Services |
| 10 | — | windows | powershell | logsource:
product: windows service: powershell |
Microsoft Windows PowerShell Event Log |
| 9 | — | linux | — | logsource:
product: linux |
Linux |
| 8 | — | linux | auditd | logsource:
produit: service linux : auditd |
Evénements Linux, clarification des logs d'un service spécifique (sous-système AuditD) |
Conseils pour rédiger des règles
Lors de l'écriture d'une nouvelle règle, les situations suivantes sont possibles:
- La source d'événement correcte a déjà été utilisée dans les règles existantes.
- Il n'y a pas une seule règle dans le référentiel qui utilise cette source d'événements.
Si vous êtes confronté au premier cas, utilisez l'une des règles existantes comme modèle. Peut-être que la source de journal requise est déjà utilisée dans d'autres règles, cela signifie que les auteurs de plugins (convertisseurs backend) pour différents systèmes SIEM l'ont très probablement pris en compte dans leur mappage et que votre règle doit être traitée correctement immédiatement.
Dans la seconde situation, il est nécessaire de comprendre comment utiliser les identifiants de catégorie, de produit et de service en utilisant l'exemple des règles existantes. Lors de la création de votre propre source de journal, il est recommandé de l'ajouter à tous les mappages des backends existants. D'autres contributeurs ou même des développeurs peuvent le faire, l'essentiel est d'informer sur un tel besoin.
Nous avons créé une visualisation de la combinaison des champs de description de source de journal dans les règles existantes:
Répartition des sources de journal
Utiliser les statistiques pour les combinaisons de sous-champs d'attribut de source de journal
Dans cet article, nous avons donné un exemple de création d'une règle simple et parlé de la description des sources d'événements. Vous pouvez maintenant appliquer les connaissances acquises, examiner les règles du référentiel Sigma et déterminer quelles sources sont utilisées dans une règle particulière. Suivez nos publications: dans la partie suivante, nous examinerons la partie la plus difficile des règles Sigma - la section décrivant la logique de détection.
Auteur : Anton Kutepov, spécialiste du département des services experts et du développement des technologies positives (PT Expert Security Center)