création-de-règles-de-détection-avec-sigma

Création de règles de détection avec Sigma

Quand l'utiliser

Utilisez cette compétence lorsque :

• Des ingénieurs SOC doivent créer des règles de détection portables sur plusieurs plateformes SIEM
• Des rapports de renseignement sur les menaces décrivent des TTP nécessitant une nouvelle couverture de détection
• Des règles existantes spécifiques à un fournisseur doivent être standardisées dans un format partageable
• L'équipe adopte Sigma comme standard de détection en tant que code dans les pipelines CI/CD

Ne pas utiliser pour la détection en streaming en temps réel (Sigma est destiné aux recherches par lots/planifiées) ou lorsque le SIEM cible dispose de fonctionnalités de détection natives que Sigma ne peut pas exprimer (par exemple, le scoring de risque RBA de Splunk).

Prérequis

• Python 3.8+ avec pySigma et les backends appropriés (pySigma-backend-splunk, pySigma-backend-elasticsearch, pySigma-backend-microsoft365defender)
• Dépôt de règles Sigma cloné : git clone https://github.com/SigmaHQ/sigma.git
• Connaissance du framework MITRE ATT&CK pour le mappage des techniques
• Compréhension des mappings de champs de sources de journaux du SIEM cible

Flux de travail

Étape 1 : Définir la logique de détection à partir du renseignement sur les menaces

Commencez par un rapport de menace ou une technique ATT&CK. Exemple : détection de l'exfiltration d'identifiants par Mimikatz (T1003.001 — Mémoire LSASS) :

title: Exfiltration d'identifiants Mimikatz via accès LSASS
id: 0d894093-71bc-43c3-8d63-bf520e73a7c5
status: stable
level: high
description: Détecte l'accès à la mémoire de lsass.exe, indicatif d'outils d'exfiltration d'identifiants comme Mimikatz
references:
    - https://attack.mitre.org/techniques/T1003/001/
    - https://github.com/gentilkiwi/mimikatz
author: mahipal
date: 2024/03/15
modified: 2024/03/15
tags:
    - attack.credential_access
    - attack.t1003.001
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'
            - '0x1038'
            - '0x1fffff'
            - '0x40'
    filter_main_svchost:
        SourceImage|endswith: '\svchost.exe'
    filter_main_csrss:
        SourceImage|endswith: '\csrss.exe'
    filter_main_wininit:
        SourceImage|endswith: '\wininit.exe'
    condition: selection and not 1 of filter_main_*
falsepositives:
    - Outils de sécurité légitimes accédant à LSASS
    - Analyse Windows Defender
    - Capteur CrowdStrike Falcon

Étape 2 : Valider la syntaxe de la règle Sigma

Utilisez sigma check pour valider la règle :

# Installez pySigma et les validateurs
pip install pySigma pySigma-validators-sigmaHQ

# Validez la règle
sigma check rule.yml

Sinon, validez avec Python :

from sigma.rule import SigmaRule
from sigma.validators.core import SigmaValidator

rule = SigmaRule.from_yaml(open("rule.yml").read())
validator = SigmaValidator()
issues = validator.validate_rule(rule)
for issue in issues:
    print(f"{issue.severity}: {issue.message}")

Étape 3 : Convertir en requête SIEM cible

Conversion en Splunk SPL :

from sigma.rule import SigmaRule
from sigma.backends.splunk import SplunkBackend
from sigma.pipelines.splunk import splunk_windows_pipeline

pipeline = splunk_windows_pipeline()
backend = SplunkBackend(pipeline)

rule = SigmaRule.from_yaml(open("rule.yml").read())
splunk_query = backend.convert_rule(rule)
print(splunk_query[0])

Sortie :

TargetImage="*\\lsass.exe" (GrantedAccess="*0x1010*" OR GrantedAccess="*0x1038*"
OR GrantedAccess="*0x1fffff*" OR GrantedAccess="*0x40*")
NOT (SourceImage="*\\svchost.exe") NOT (SourceImage="*\\csrss.exe")
NOT (SourceImage="*\\wininit.exe")

Conversion en requête Elastic (Lucene) :

from sigma.backends.elasticsearch import LuceneBackend
from sigma.pipelines.elasticsearch import ecs_windows_pipeline

pipeline = ecs_windows_pipeline()
backend = LuceneBackend(pipeline)
elastic_query = backend.convert_rule(rule)
print(elastic_query[0])

Conversion en Microsoft Sentinel KQL :

from sigma.backends.microsoft365defender import Microsoft365DefenderBackend

backend = Microsoft365DefenderBackend()
kql_query = backend.convert_rule(rule)
print(kql_query[0])

Étape 4 : Mapper à MITRE ATT&CK et ajouter des métadonnées de couverture

Étiquetez chaque règle avec les identifiants de technique ATT&CK dans le champ tags :

tags:
    - attack.credential_access        # Tactique
    - attack.t1003.001                # Sous-technique
    - attack.t1003                    # Technique parente

Suivez la couverture de détection à l'aide du navigateur ATT&CK Navigator :

import json

# Générer une couche ATT&CK Navigator à partir des règles Sigma
layer = {
    "name": "Couverture de détection SOC",
    "versions": {"attack": "14", "navigator": "4.9", "layer": "4.5"},
    "domain": "enterprise-attack",
    "techniques": []
}

# Analyser le répertoire des règles Sigma pour les balises de technique
import os
from sigma.rule import SigmaRule

for root, dirs, files in os.walk("sigma/rules/windows/"):
    for f in files:
        if f.endswith(".yml"):
            rule = SigmaRule.from_yaml(open(os.path.join(root, f)).read())
            for tag in rule.tags:
                if str(tag).startswith("attack.t"):
                    technique_id = str(tag).replace("attack.", "").upper()
                    layer["techniques"].append({
                        "techniqueID": technique_id,
                        "color": "#31a354",
                        "score": 1
                    })

with open("coverage_layer.json", "w") as f:
    json.dump(layer, f, indent=2)

Étape 5 : Tester la règle avec des données d'exemple

Créez des données de test et validez que la règle détecte les événements attendus :

# Utilisez le framework de test sigma
sigma test rule.yml --target splunk --pipeline splunk_windows

# Ou testez manuellement dans Splunk avec des données d'exemple
# Téléchargez un journal process_access Sysmon avec une signature Mimikatz connue

Validez le taux de faux positifs en exécutant la règle sur 7 jours de données de production dans une recherche sauvegardée non alertante.

Étape 6 : Déployer sur le SIEM de production

Déployez la requête convertie en tant que recherche planifiée ou règle de corrélation :

Recherche de corrélation Splunk ES :

| tstats summariesonly=true count from datamodel=Endpoint.Processes
  where Processes.process_name="*\\lsass.exe"
  by Processes.src, Processes.user, Processes.process_name, Processes.parent_process_name
| `drop_dm_object_name(Processes)`
| where count > 0

Règle de sécurité Elastic (format TOML) :

[rule]
name = "Accès à la mémoire LSASS - Exfiltration d'identifiants"
description = "Détecte l'accès suspect à la mémoire du processus LSASS"
risk_score = 73
severity = "high"
type = "eql"
query = '''
process where event.action == "access" and
  process.name == "lsass.exe" and
  not process.executable : ("*\\svchost.exe", "*\\csrss.exe")
'''

[rule.threat]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "Exfiltration d'identifiants du système d'exploitation"

Étape 7 : Contrôle de version et intégration CI/CD

Stockez les règles dans Git avec des tests automatisés :

# .github/workflows/sigma-ci.yml
name: CI pour règles Sigma
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install pySigma pySigma-validators-sigmaHQ
      - run: sigma check rules/
      - run: sigma convert -t splunk -p splunk_windows rules/ > /dev/null

Concepts clés

Terme	Définition
Sigma	Format de règle de détection indépendant du fournisseur (basé sur YAML) qui se compile en requêtes SIEM spécifiques via des backends
pySigma	Bibliothèque Python remplaçant l'ancien sigmac pour la conversion, la validation et le traitement des pipelines de règles
Backend	Plugin pySigma qui traduit la logique de détection Sigma dans le langage de requête de la plateforme cible (SPL, KQL, Lucene)
Pipeline	Configuration de mappage de champs qui traduit les noms de champs génériques Sigma en noms de champs spécifiques au SIEM
Logsource	Section de la règle Sigma définissant la catégorie (process_creation, network_connection) et le produit (windows, linux) des données cibles
Détection en tant que code	Pratique de gestion des règles de détection dans un système de contrôle de version avec des tests CI/CD et un déploiement automatisé

Outils et systèmes

• SigmaHQ : Dépôt officiel de règles Sigma avec plus de 3 000 règles de détection maintenues par la communauté sur GitHub
• pySigma : Framework de traitement de règles Sigma basé sur Python avec des backends et pipelines modulaires
• ATT&CK Navigator : Outil MITRE pour visualiser la couverture de détection mappée aux techniques ATT&CK
• Uncoder.IO : Convertisseur de règles Sigma basé sur le Web prenant en charge plus de 30 plateformes SIEM pour une traduction rapide

Scénarios courants

• Détection de nouvelle CVE : Écrire une règle Sigma pour les indicateurs d'exploitation (par exemple, les motifs de recherche JNDI Log4Shell dans les journaux Web)
• Promotion de règle de chasse : Convertir une requête de chasse Splunk ad hoc en règle Sigma pour une détection automatisée continue
• Migration multi-SIEM : Conversion de plus de 500 recherches de corrélation Splunk en Sigma pour une migration vers Elastic Security
• Résultat de l'équipe violette : Convertir les conclusions de l'équipe rouge en règles Sigma pour une couverture défensive immédiate
• Opérationnalisation du renseignement sur les menaces : Transformer les rapports de menaces basés sur des IOC en règles Sigma comportementales

Format de sortie

RAPPORT DE DÉPLOIEMENT DE RÈGLE SIGMA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ID de règle :    0d894093-71bc-43c3-8d63-bf520e73a7c5
Titre :          Exfiltration d'identifiants Mimikatz via accès LSASS
ATT&CK :         T1003.001 - Mémoire LSASS
Sévérité :       Élevée
Statut :         Déployé en production

Conversions :
  Splunk SPL :    RÉUSSI — Recherche sauvegardée "sigma_lsass_access" créée
  Elastic EQL :   RÉUSSI — Règle de détection elastic-0d894093 activée
  Sentinel KQL :  RÉUSSI — Règle d'analytique déployée via modèle ARM

Tests :
  Vrais positifs :        4/4 cas de test correspondants
  Faux positifs :         2 sur 7 jours de test (cas marginal svchost — filtre ajouté)
  Performance :           Temps d'exécution moyen 3,2 s sur 50 M d'événements/jour