01 - Ingénierie de la détection : discipline au script en passant par le pipeline
Dans un paysage de cybermenaces en constante évolution, la capacité de détecter l'activité malveillante avant qu'elle ne cause des dommages importants représente le véritable différentiel entre une organisation résiliente et vulnérable. Pendant des décennies, la détection des menaces a été confié à des règles écrites ad hoc, des signatures antivirus et des intuitions individuelles des analystes SOC. Aujourd'hui, cette approche artisanale n'est plus durable : le volume des grumes, la complexité des Les infrastructures cloud natives et la sophistication des attaquants nécessitent une approche ingénierie et systématique.
C'est comme ça qu'il n'est ni l'un ni l'autre Ingénierie de détection: une discipline ici appliquée par les princes la génération de logique et le processus de création, de test, de déploiement et de maintenance de la logique règles de détection. Plus vous avez besoin d'écrire les exigences isolées dans un SIEM, plus vous devez construire chaînes automatiques, versionner les détections sous formes de code, les testeurs avec des femmes simulés et mesurez-les avec des objectifs de mesures.
Ce Que Vous Apprendrez dans Cet Article
- Qu'est-ce que l'ingénierie de détection et pourquoi est-elle devenue une discipline autonome
- L'évolution des scripts ad hoc vers les pipelines CI/CD pour la détection
- Le cycle complet de détection : hypothèse, développement, test, déploiement, ajustement
- Les principaux types de détection : basée sur les signatures, basée sur le comportement, basée sur les anomalies
- Mesures de qualité : taux de vrais positifs, taux de faux positifs, MTTD, MTTR
- L’écosystème SIEM/SOAR et les principales sources de données
- Les concepts de pipelines Detection-as-Code et CI/CD pour les règles de sécurité
- Exemples pratiques avec les règles Sigma, les scripts Python et les configurations YAML
Qu'est-ce que l'ingénierie de détection
La Ingénierie de détection et le processus systématique de conception, de développement, test et maintenance de la logique identifie ici les activités malveillantes en présence de la télémétrie d'une organisation. Ces informations incluent les jours des points financiers, de l'infrastructure cloud, fournisseurs d'identité, applications Web, systèmes réseau et bien plus encore.
Contrairement à l'approche traditionnelle, où un analyste SOC écrivait une requête dans le SIEM en réponse à un incident spécifique, l'Ingénierie de Détection adopte une flux de travail structuré qui rappelle le développement logiciel moderne : versionnage du code, révision du code, tests automatisés, déploiement continu et surveillance des performances en production.
"Detection Engineering is to SOC what Software Engineering is to coding: it transforms an ad-hoc, reactive activity into a systematic, measurable, and continuously improving discipline."
- SANS Institute, 2025 Detection Engineering Survey
Les trois piliers de l'ingénierie de détection
La discipline repose sur trois piliers interconnectés qui définissent ici la maturité :
- Renseignements sur les menaces - Comprendre qui sont les adversaires, quelles techniques ils utilisent (MITRE ATT&CK), et quels actifs de l'organisation sont à risque. Sans une compréhension profondeur des menaces, les détections seront génériques et peu efficaces.
- Ingénierie des données - S'assurer que les journaux nécessaires sont collectés et normalisés et disponible pour analyse. Une détection parfaite et inutile si les données sur lesquelles elle opère ne le sont pas présents ou de mauvaise qualité.
- Génie logiciel - Appliquer les meilleures pratiques de développement logiciel : contrôle de version, tests, CI/CD, documentation, métriques. Les détections doivent être traitées comme code de production.
L'évolution : des scripts ad hoc à la discipline de l'ingénierie
Le chemin qui a conduit à l'ingénierie de détection moderne peut être divisé en quatre Des phases distinctes, chacune caractérisée par un nouveau croissant de maturité et d’automatisation.
Phase 1 : L’ère des signatures (1990-2005)
Les premières formes de détection étaient basées sur signatures statiques: modèles connus de logiciels malveillants, hachages de fichiers malveillants, chaînes spécifiques dans les charges utiles du réseau. Tous les antivirus et IDS (Intrusion Detection System) maintenait une base de données de signatures qui était mise à jour périodiquement. L'approche a fonctionné raisonnablement bien avec les menaces connues, mais était complètement aveugle. à de nouvelles variantes ou à des attaques personnalisées.
Phase 2 : L'ère des scripts SIEM (2005-2015)
Avec la propagation de l'ancien SIEM (Informations de sécurité et gestion d'événements), les analystes ont commencé à rédiger des requêtes et des corrélations personnalisées. Chaque analyste avait le propre approche, propres scripts, propres conventions de dénomination. Des règles ont été créées directement dans l'interface web SIEM, sans versioning, sans tests, sans documentation standardisé. Lorsqu'un analyste quittait l'organisation, ses détections devenaient souvent incompréhensible pour les successeurs.
Phase 3 : La naissance de l'ingénierie de détection (2015-2022)
Entre 2015 et 2022, la communauté de la sécurité commence à reconnaître la nécessité d'une approche plus structurée. Des formats standards naissent tels que Sigma (2017) pour les règles de détection, le cadre ATTAQUE À ONGLET&CK devient la référence universel pour cartographier les techniques des adversaires, et les premières équipes de détection dédiées L'ingénierie apparaît dans les organisations plus matures.
Phase 4 : Détection en tant que code et pipeline CI/CD (2022-présent)
Aujourd’hui, les organisations les plus avancées traitent les détections exactement comme le code d’un logiciel. Les règles sont écrites dans des formats déclaratifs (Sigma, YAML), versionnées dans des dépôts Git, automatiquement testé avec des données simulées, déployé via un pipeline CI/CD et surveillé avec des tableaux de bord dédiés. Selon le Enquête sur l'ingénierie de détection SANS 2025, 60 % des organisations disposent d'équipes d'ingénierie de détection dédiées, dont 70 % d'entreprises de plus de 5 000 salariés ayant déjà constitué des équipes structurées.
| Fase | Periodo | Approccio | Strumenti | Limiti |
|---|---|---|---|---|
| Firme Statiche | 1990-2005 | Correspondance de modèles sur des signatures connues | Antivirus, IDS (Snort) | Zero-day invisibili, alta latenza |
| Script SIEM | 2005-2015 | Requêtes ad hoc dans SIEM | Splunk, ArcSight, QRadar | Connaissances non versionnées, non testées et cloisonnées |
| Detection Engineering | 2015-2022 | Flux de travail structuré avec des normes | Sigma, ATT&CK, ELK | Ancora molti processi manuali |
| Detection-as-Code | 2022-oggi | Pipeline CI/CD, tous versionnés | Git, CI/CD, Sigma, SOAR | Nécessite une maturité organisationnelle |
Le cycle de vie d'une détection
La détection d'un cycle de vie bien défini garantit qualité, efficacité et entretien dans le temps. Le cycle est composé de six phases fondamentales, chacune avec livres et critères de qualité spécifiques.
1. Ipotesi (Hypothesis)
Tout commence par un hypothèse de menace. L'analyste ou l'ingénieur en détection identifie une technique d'attachement spécifique (par exemple, "Un attaquant pourrait utiliser PowerShell pour charger et exécuter des charges utiles de manière malveillante ») et formuler une hypothèse sur son fonctionnement Cette activité se manifestera dans les revues disponibles. Les sources des hypothèses comprennent :
- Renseignements sur les menaces - Rapport sur les campagnes actives, TTP observés
- ATTAQUE À ONGLET&CK - Techniques adaptées à des tactiques spécifiques
- Accident post-mortem - Leçons tirées des incidents précédents
- Red Team findings - Risultati di penetration test e purple teaming
- Analyse des écarts - Techniques ATT&CK sans couverture de détection
2. Sviluppo (Development)
Une fois l'hypothèse définie, l'ingénieur en détection établit la règle de détection. Pois chiches implique le choix du format (Sigma, exigence SIEM native, script Python), la définition des sources quotidiennes nécessaires, la logique de sélection et de filtrage, ainsi que la documentation des métadonnées (auteur, gravité, cartographie ATT&CK, faux positifs connus).
3. Test e Validazione (Testing)
Avant le déploiement, la détection doit être validée par rapport à des données réelles et simulées. Les tests comprennent : test vraiment positif (la règle détecte-t-elle une attaque simulée ?), test faussement positif (la règle génère-t-elle des alertes sur des activités légitimes ?), et tests de performances (la règle est suffisamment efficace sur les volumes de journal de production ?).
4. Deployment
Le déploiement est efficace via des pipelines automatisés qui convertissent le format en format Né du dispositif SIEM, déployez-le dans l'environnement de production et vérifiez son exactitude opération. Dans les environnements matures, le processus est entièrement automatisé via CI/CD.
5. Monitoraggio e Metriche
Une fois en production, la détection est surveillée en permanence. Les indicateurs clés inclure le volume des alertes générales, les ratios vrais/faux positifs, les horaires actuels détection (MTTD) et l’impact sur la charge des analystes SOC.
6. Tuning e Manutenzione
Sur la base des femmes collectées en production, le dépistage est continuellement similaire. Le le réglage peut inclure l'ajout d'exceptions pour les faux positifs récurrents, l'élargissement de logique pour découvrir sans plus attendre les variations de la technique, ou la dépréciation de la règle pertinent.
Meilleure pratique : Purple Teaming
Il équipe violette accélérer compte tenu de la boucle de rétroaction cycle de détection. Combinez les compétences offensives de l'équipe rouge avec les cellules défensives de la Blue Team, il est possible de simuler les techniques d'attaque actuelles et de valider les détections en en temps réel, notamment le délai entre l’hypothèse et la détection validée de plusieurs semaines à queques heures.
Types de détection : de l’IOC au comportement
Les détections peuvent être classées en fonction de la logique de détection utilisée. Chaque type présente des avantages et des limites spécifiques, et un programme de détection mature les combine all in a stratified way.
1. Signature-Based Detection
Recherches de détection basées sur les signatures modèles exacts dans les données : hachage de fichier chaînes connues et spécifiques dans les commandes, les adresses IP ou les domaines malveillants connus (IOC - Indicateurs de compromis). C'est le type le plus simple et le plus rapide, avec un taux de faux positifs très faible, mais totalement inefficace contre les menaces nouvelles ou variantes.
title: Emotet Loader Hash Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects known Emotet loader by file hash
author: Detection Engineering Team
date: 2025/10/15
references:
- https://attack.mitre.org/software/S0367/
logsource:
category: file_event
product: windows
detection:
selection:
Hashes|contains:
- 'SHA256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
- 'SHA256=a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a'
- 'MD5=d41d8cd98f00b204e9800998ecf8427e'
condition: selection
falsepositives:
- Unlikely, known malicious hashes
level: critical
tags:
- attack.execution
- attack.t1204.0022. Behavioral Detection
Les détections comportementales recherchent séquences d'action ou un modèle de comportements qui indiquent une activité suspecte, quels que soient les IOC spécifiques. Par exemple, au lieu de rechercher un hachage spécifique de Mimikatz, une détection comportementale pourrait rechercher n’importe quel processus accédant à la mémoire LSASS pour extraire les informations d’identification. Cette approche est beaucoup plus résistante à l'évasion, car les attaquants peuvent changer leurs propres outils mais peuvent difficilement changer la technique sous-jacente.
title: Suspicious LSASS Process Access - Credential Dumping
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: |
Detects process access to LSASS memory, a common technique
for credential dumping (T1003.001). Focuses on behavior
rather than specific tool signatures.
author: Federico Calo
date: 2025/11/20
references:
- https://attack.mitre.org/techniques/T1003/001/
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
- '0x1038' # Read memory access
- '0x1FFFFF' # PROCESS_ALL_ACCESS
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\csrss.exe' # Client Server Runtime
- '\wmiprvse.exe' # WMI Provider
- '\svchost.exe' # Service Host
filter_system:
SourceUser|contains: 'SYSTEM'
SourceImage|startswith: 'C:\Windows\System32\'
condition: selection and not filter_legitimate and not filter_system
falsepositives:
- Legitimate security tools performing memory scanning
- EDR solutions with high-privilege access
level: high
tags:
- attack.credential_access
- attack.t1003.0013. Anomaly-Based Detection
Les détections basées sur les anomalies établissent un base de normalité e signaler des écarts significatifs. Par exemple, si un utilisateur se connecte généralement depuis un basé en Italie pendant les heures de bureau, une connexion depuis la Chine à 3 heures du matin serait une anomalie. Cette approche permet de détecter des menaces totalement inconnues (zéro jour), mais cela a tendance à générer davantage de faux positifs, notamment dans les environnements dynamiques.
4. Threat Hunting
La chasse aux menaces est un procès proactif et basé sur des hypothèses dans lequel le Les analystes recherchent activement les menaces pouvant être déclenchées par une détection automatique. Contrairement à la détection automatique, la recherche de menaces est souvent explorée et produite Les nouvelles détections ici sont ensuite codées et automatisées.
| Type de détection | Precisione | Copertura Zero-Day | False Positive | Manutenzione | Exemple |
|---|---|---|---|---|---|
| Signature-Based | Très élevé | Nessuna | Très faible | Alta (aggiornare IOC) | Hash file, IP malevoli |
| Behavioral | Alta | Buona | Moderati | Media | Accesso LSASS, lateral movement |
| Anomaly-Based | Variabile | Ottima | Alti | Alta (tuning baseline) | Login anomalo, traffico insolito |
| Threat Hunting | Très élevé | Ottima | Minimi (manuale) | Alta (richiede analisti) | Analyse exploratoire, hypothèses |
Mesures de qualité pour les détections
Une détection n'est pas utile si elle ne l'est pas mesurable. Indicateurs de qualité vous permettent d'évaluer l'efficacité des règles de détection, de guider le processus ajuster et justifier les investissements dans le programme d’ingénierie de détection.
Mesures opérationnelles fondamentales
| Metrica | Description | Target | Comment s'améliorer |
|---|---|---|---|
| MTTD (Mean Time to Detect) | Désormais entre les moments d'activité malveillante et la génération de l'alerte | < 4 ore (top team: < 30 min) | Migliore copertura log, detection real-time |
| MTTR (Mean Time to Respond) | Délai moyen entre la détection et le confinement/résolution | < 4 ore | Automazione SOAR, playbook definiti |
| True Positive Rate (TPR) | Pourcentage d'alertes qui correspondent à des menaces réelles | > 80 % pour critique, > 60 % pour élevé | Réglage continu, filtrage avancé |
| False Positive Rate (FPR) | Pourcentage d'alertes générées pour des activités légitimes | < 25 % pour les critiques | Whitelist, contesto arricchito, correlazione |
| False Negative Rate (FNR) | Pourcentage de menaces réelles non détectées | < 1% | Purple teaming, threat hunting |
| ATT&CK Coverage | Pourcentage de techniques MITRE ATT&CK couvertes par au moins une détection | > 70% de techniques pertinentes | Analyse régulière des écarts, priorisation |
Calcolo del Detection Score
Une approche pratique pour évaluer la qualité globale du programme de détection et Score de maturité de détection, qui combine plusieurs métriques en un seul score normalisé. Voici un exemple de calcul en Python :
from dataclasses import dataclass
from typing import List
@dataclass(frozen=True)
class DetectionMetrics:
"""Immutable snapshot of detection performance metrics."""
rule_id: str
true_positives: int
false_positives: int
false_negatives: int
total_alerts: int
avg_detection_time_minutes: float # MTTD
avg_response_time_minutes: float # MTTR
@property
def precision(self) -> float:
"""TP / (TP + FP) - How many alerts are real threats."""
denominator = self.true_positives + self.false_positives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def recall(self) -> float:
"""TP / (TP + FN) - How many real threats are caught."""
denominator = self.true_positives + self.false_negatives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def f1_score(self) -> float:
"""Harmonic mean of precision and recall."""
p, r = self.precision, self.recall
return 2 * (p * r) / (p + r) if (p + r) > 0 else 0.0
def calculate_maturity_score(metrics_list: List[DetectionMetrics]) -> dict:
"""Calculate overall detection program maturity score.
Returns an immutable dict with aggregated metrics.
"""
if not metrics_list:
return {"score": 0, "grade": "F", "details": {}}
avg_precision = sum(m.precision for m in metrics_list) / len(metrics_list)
avg_recall = sum(m.recall for m in metrics_list) / len(metrics_list)
avg_f1 = sum(m.f1_score for m in metrics_list) / len(metrics_list)
avg_mttd = sum(m.avg_detection_time_minutes for m in metrics_list) / len(metrics_list)
avg_mttr = sum(m.avg_response_time_minutes for m in metrics_list) / len(metrics_list)
# Weighted maturity score (0-100)
precision_score = avg_precision * 25 # 25% weight
recall_score = avg_recall * 25 # 25% weight
f1_component = avg_f1 * 20 # 20% weight
mttd_score = max(0, (240 - avg_mttd) / 240) * 15 # 15% weight (240min = 4h target)
mttr_score = max(0, (240 - avg_mttr) / 240) * 15 # 15% weight
total_score = (precision_score + recall_score + f1_component
+ mttd_score + mttr_score) * 100
grade_thresholds = [
(90, "A"), (80, "B"), (70, "C"), (60, "D")
]
grade = next(
(g for threshold, g in grade_thresholds if total_score >= threshold),
"F"
)
return {
"score": round(total_score, 1),
"grade": grade,
"details": {
"avg_precision": round(avg_precision, 3),
"avg_recall": round(avg_recall, 3),
"avg_f1": round(avg_f1, 3),
"avg_mttd_minutes": round(avg_mttd, 1),
"avg_mttr_minutes": round(avg_mttr, 1),
"total_rules_evaluated": len(metrics_list),
},
}
# Esempio di utilizzo
sample_metrics = [
DetectionMetrics("SIGMA-001", 45, 5, 2, 50, 15.0, 35.0),
DetectionMetrics("SIGMA-002", 120, 30, 8, 150, 8.5, 22.0),
DetectionMetrics("SIGMA-003", 200, 15, 5, 215, 3.2, 12.0),
]
result = calculate_maturity_score(sample_metrics)
print(f"Detection Maturity Score: {result['score']} ({result['grade']})")
print(f"Details: {result['details']}")Attention : mesures de vanité
Évitez de mesurer le succès de votre programme de détection avec le nombre total des règles ou le nombre d'alertes générées. Ce sont des mesures des mesures vaniteuses qui peuvent masquer de graves problèmes. Une organisation de 50 détection haute fidélité et bien plus sécurisée qu'une détection avec 5 000 règles qui génèrent des milliers de faux positifs, provoquant une lassitude des analystes.
L'Ecosistema SIEM/SOAR
Il SIEM (Informations de sécurité et gestion d'événements) et le cœur de l’infrastructure d’ingénierie de détection. Et la plateforme ici collectée, normalisée, Corréler et analyser les revues de toutes les sources de l'organisation. Le MONTER (Security Orchestration, Automation and Response) compléter SIEM automatisez les réponses aux alertes via des playbooks prédéfinis.
Présentation des principales plateformes SIEM
| Piattaforma | Tipo | Linguaggio Query | Points forts | Caso d'Uso Ideale |
|---|---|---|---|---|
| Splunk Enterprise | On-prem / Cloud | SPL | Maturita, ecosistema app, flessibilità | Enterprise complesse, SOC maturi |
| Elastic SIEM | Open Source / Cloud | KQL / EQL / ES|QL | Open source, scalabilità, costo | Équipes cloud natives à petit budget |
| Microsoft Sentinel | Cloud (Azure) | KQL | Intégration Azure/M365, IA intégrée | Organizzazioni Microsoft-centric |
| Google SecOps (Chronicle) | Cloud (GCP) | YARA-L | Retention illimitata, velocità | Gros volumes de données, GCP |
| CrowdStrike Falcon LogScale | Cloud | LogScale Query | Ingestione rapida, compressione | Organizzazioni CrowdStrike |
| Sumo Logic | Cloud | Sumo Logic Query | SaaS nativo, facilita d'uso | Cloud-first, SaaS-heavy |
Sources de données fondamentales
La qualité des détections dépend directement de la qualité et de l'épuisement des femmes disponible. Voici les sources fondamentales des femmes pour un programme de détection efficace :
- Endpoint Telemetry - Log di processo, file system events, registry changes, network connections. Fonti: EDR (CrowdStrike, SentinelOne, Microsoft Defender), Sysmon
- Network Telemetry - NetFlow, DNS queries, HTTP/TLS metadata, PCAP selettivi. Fonti: firewall, IDS/IPS, proxy, DNS resolver
- Identity & Access - Authentication events, privilege escalation, group membership changes. Fonti: Active Directory, Entra ID, Okta, CyberArk
- Cloud Audit Logs - API calls, configuration changes, resource creation. Fonti: AWS CloudTrail, Azure Activity Log, GCP Audit Logs
- Application Logs - Web server access logs, application errors, WAF events. Fonti: Nginx, Apache, CloudFront, applicazioni custom
- Email Security - Phishing attempts, malicious attachments, BEC detection. Fonti: Microsoft Defender for O365, Proofpoint, Mimecast
Normalisation des données : le fondement invisible
Sans normalisation des données, les détections sont fragiles et non portables.
Chaque SIEM et chaque source utilise des formats différents pour les mêmes concepts : un « échec de connexion »
ça peut ressembler à EventID 4625 sous Windows, sshd: Failed password
sous Linux, ou {"eventType": "user.session.start", "outcome": "FAILURE"}
dans Okta. Adopter un schéma de normalisation tel que ECS (schéma commun élastique),
OCSF (cadre de schéma de cybersécurité ouvert) ou le modèle de données de Sigma permet
pour écrire la détection une seule fois et l'appliquer à n'importe quelle source.
Détection en tant que code : le paradigme moderne
Détection en tant que code (DaC) et l'approche qui applique les pratiques de développement logiciel de gestion des règles de détection. Au lieu de créer et de modifier des règles via l'interface graphique SIEM, les détections sont écrites sous forme de code, versionné dans les référentiels Git, soumis à une révision de code via des pull request, testé automatiquement et livré via des pipelines CI/CD.
Avantages de la détection dans de nombreux codes
Par rapport à l'approche traditionnelle
- Gestion des versions - Chaque modification est suivie dans Git, avec possibilité de restauration
- Révision des codes - Les détections sont soumises à un examen par les paires avant le déploiement
- Tests automatisés - Validation automatique avec données positives et négatives
- Reproductibilité - L'état complet des détections peut être reconstitué à partir du référentiel
Benefici Operativi
- Vitesse - Les détections entrent en production en quelques minutes, et non en quelques jours
- Cohérence - Normes de qualité appliquées uniformément
- Pistes d'audit - Traçabilité complète pour la conformité
- Collaboration - Plusieurs équipes peuvent contribuer au même référentiel
Structure d'une référence de détection dans les deux codes
detections/
rules/
credential_access/
lsass_memory_access.yml
brute_force_login.yml
kerberoasting.yml
execution/
powershell_encoded_command.yml
suspicious_wmi_execution.yml
lateral_movement/
psexec_usage.yml
rdp_from_unusual_source.yml
persistence/
scheduled_task_creation.yml
registry_run_key.yml
tests/
credential_access/
lsass_memory_access_test.json
brute_force_login_test.json
execution/
powershell_encoded_command_test.json
config/
sigma_config.yml
siem_mappings.yml
exclusions.yml
pipelines/
ci.yml
cd.yml
docs/
CONTRIBUTING.md
STYLE_GUIDE.md
REVIEW_CHECKLIST.md
README.mdPipeline CI/CD pour les détections
Le pipeline de détection CI/CD automatise l'ensemble des processus, de la validation à la production. Voici un exemple de configuration pour les actions GitHub :
name: Detection CI/CD Pipeline
on:
pull_request:
paths: ['rules/**', 'tests/**']
push:
branches: [main]
paths: ['rules/**']
jobs:
validate:
name: Validate Sigma Rules
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install sigma-cli
run: pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch
- name: Lint Sigma Rules
run: |
sigma check rules/ --validation-config config/sigma_config.yml
echo "All rules pass validation"
- name: Verify ATT&CK Mapping
run: |
python scripts/verify_attack_tags.py rules/
echo "All rules have valid ATT&CK mappings"
test:
name: Test Detection Logic
needs: validate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run True Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type true_positive
- name: Run False Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type false_positive
- name: Generate Coverage Report
run: python scripts/coverage_report.py --output reports/coverage.json
deploy:
name: Deploy to SIEM
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- name: Convert Sigma to Splunk SPL
run: |
sigma convert \
--target splunk \
--pipeline splunk_windows \
rules/ \
--output converted/splunk/
- name: Deploy to Splunk via API
env:
SPLUNK_TOKEN: ${{ secrets.SPLUNK_API_TOKEN }}
SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
run: |
python scripts/deploy_splunk.py \
--rules-dir converted/splunk/ \
--splunk-url "$SPLUNK_URL" \
--token "$SPLUNK_TOKEN"
- name: Update ATT&CK Coverage Map
run: python scripts/update_attack_coverage.pyDétection complète du débit dans les deux codes
- L'ingénieur de détection crée une nouvelle règle Sigma dans une branche Git
- Ouvre une Pull Request avec la règle et les tests associés
- Les pipelines CI effectuent la validation de la syntaxe, les tests TP/FP et la vérification du mappage ATT&CK
- Un évaluateur en binôme approuve le PR après avoir vérifié la logique, la documentation et la couverture
- La fusion dans le pipeline CD actif principal convertit ici la règle et la distribue au SIEM
- Les tableaux de bord de surveillance suivent les performances de détection en production
Scrivere Detection Efficaci: Principi e Pattern
La différence entre une détection médiocre et une excellente détection réside dans la profondeur de la détection compréhension de la technique d'attachement, dans la qualité du filtrage des faux positifs et dans l'exhaustivité de la documentation. Voici les princes de la base.
Prince 1 : Commencez par la technique, pas par l'outil
N'écrivez pas sur la détection de "Mimikatz" - écrivez une détection pour eux technique di dumping des informations d'identification via l'accès à la mémoire LSASS (T1003.001). Cette approche du couvre-chef automatiquement tous les outils ici mettent en œuvre la même technique, et en achètent les futurs ne sont pas encore communs.
Principe 2 : Détections de couches (Pyramide de détection)
Implémentez une détection multi-niveaux pour la même technique. Une détection basée sur la trappe (trivialement évitable), vous pouvez toujours capturer des attaques pour vous avertir, et alors La détection comportementale capture les plus avancées. Cette approche à plusieurs niveaux et connu sous les noms Détection approfondie.
Prince 3 : Toujours documenter le contexte
Chaque détection doit inclure : le motivation (pour cette détection existe), le Cartographie ATT&CK (quelle technique couvre-t-il), je faux points positifs connus (ces activités légales peuvent réduire la règle), et le manuel de réponse (ce qui fait prendre conscience à l'analyste que la détection est claire).
Exemple complet : Détection avec Log Analysis Python
"""
Brute Force Detection Module
MITRE ATT&CK: T1110.001 - Brute Force: Password Guessing
Detects multiple failed login attempts followed by a success.
"""
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from collections import defaultdict
from typing import Optional
@dataclass(frozen=True)
class LoginEvent:
"""Immutable representation of a login event."""
timestamp: datetime
username: str
source_ip: str
success: bool
service: str # 'ssh', 'rdp', 'web', 'vpn'
@dataclass(frozen=True)
class BruteForceAlert:
"""Immutable alert generated by the detector."""
username: str
source_ip: str
failed_count: int
time_window_minutes: int
first_attempt: datetime
last_attempt: datetime
successful_login: bool
severity: str # 'medium', 'high', 'critical'
mitre_technique: str = "T1110.001"
@dataclass(frozen=True)
class DetectionConfig:
"""Immutable configuration for brute force detection."""
failed_threshold: int = 5
time_window_minutes: int = 10
lockout_threshold: int = 20
whitelist_ips: tuple = ()
monitored_services: tuple = ('ssh', 'rdp', 'web', 'vpn')
class BruteForceDetector:
"""Stateless brute force detection engine.
Analyzes login events and produces alerts when
brute force patterns are detected.
"""
def __init__(self, config: Optional[DetectionConfig] = None):
self._config = config or DetectionConfig()
def analyze(self, events: list[LoginEvent]) -> list[BruteForceAlert]:
"""Analyze a batch of login events for brute force patterns.
Returns a new list of alerts (no mutation of input).
"""
# Group events by (source_ip, username)
grouped = defaultdict(list)
for event in events:
if (event.service in self._config.monitored_services
and event.source_ip not in self._config.whitelist_ips):
key = (event.source_ip, event.username)
grouped[key].append(event)
alerts = []
for (source_ip, username), user_events in grouped.items():
sorted_events = sorted(user_events, key=lambda e: e.timestamp)
alert = self._check_brute_force(source_ip, username, sorted_events)
if alert is not None:
alerts.append(alert)
return alerts
def _check_brute_force(
self, source_ip: str, username: str, events: list[LoginEvent]
) -> Optional[BruteForceAlert]:
"""Check if events match a brute force pattern."""
window = timedelta(minutes=self._config.time_window_minutes)
failed_events = [e for e in events if not e.success]
if len(failed_events) < self._config.failed_threshold:
return None
# Check if failures cluster within the time window
for i, start_event in enumerate(failed_events):
window_end = start_event.timestamp + window
window_failures = [
e for e in failed_events[i:]
if e.timestamp <= window_end
]
if len(window_failures) >= self._config.failed_threshold:
# Check for subsequent successful login
success_after = any(
e.success and e.timestamp >= start_event.timestamp
for e in events
)
severity = self._calculate_severity(
len(window_failures), success_after
)
return BruteForceAlert(
username=username,
source_ip=source_ip,
failed_count=len(window_failures),
time_window_minutes=self._config.time_window_minutes,
first_attempt=window_failures[0].timestamp,
last_attempt=window_failures[-1].timestamp,
successful_login=success_after,
severity=severity,
)
return None
def _calculate_severity(self, failed_count: int, success: bool) -> str:
"""Determine alert severity based on pattern characteristics."""
if success and failed_count >= self._config.lockout_threshold:
return "critical" # Many failures + success = likely compromised
if success:
return "high" # Fewer failures + success = suspicious
if failed_count >= self._config.lockout_threshold:
return "high" # Many failures = active attack
return "medium" # Moderate failures = possible attackMITRE ATT&CK : le cadre de référence
Les cadavres FIXER À L'ONGLET&CK (Tactiques, techniques et pratiques adverses Knowledge) et la référence universelle pour cartographe et classer les techniques des adversaires. Pour l'ingénierie de détection, ATT&CK fournit un langage commun pour décrire quoi on cherche une matrice pour le mesurer refuser des nôtres détection.
Comment utiliser ATT&CK pour l'ingénierie de détection
- Priorisation - Toutes les techniques ATT&CK ne sont pas égales pertinent pour votre organisation. Identifier les techniques les plus utilisées par les adversaires dans votre secteur (intelligence sur les menaces) et concentrez vos ressources sur celles-ci.
- Analyse des écarts - Cartographier les détections existantes sur les techniques ATT&CK pour visualiser les zones non couvertes. Utilisez le Navigateur ATT&CK pour créer des cartes thermiques montrant la couverture actuelle.
-
Marquage - Chaque règle Sigma et de détection doit inclure des balises ATT&CK
correspondant (par ex.
attack.t1003.001). Cela vous permet de regrouper les mesures pour la technique et la tactique. - Mesures - Suivre le pourcentage de techniques couvertes pour chaque tactique (Accès Initial, Exécution, Persistance, etc.) et définir des objectifs de couverture réalistes.
| Tactic | Exemples de techniques | Sorgenti Dati Chiave | Difficolta Detection |
|---|---|---|---|
| Initial Access | T1566 Phishing, T1190 Exploit Public App | Email, WAF, proxy | Media |
| Execution | T1059 Command-Line, T1204 User Execution | Sysmon, EDR, process logs | Bassa-Media |
| Persistence | T1053 Scheduled Task, T1547 Boot Autostart | Registry, file system, EDR | Media |
| Privilege Escalation | T1068 Exploitation, T1078 Valid Accounts | EDR, AD logs, cloud audit | Alta |
| Defense Evasion | T1070 Indicator Removal, T1027 Obfuscation | EDR, Sysmon, AMSI | Très élevé |
| Credential Access | T1003 OS Credential Dumping, T1110 Brute Force | EDR, AD logs, auth logs | Media |
| Lateral Movement | T1021 Remote Services, T1570 Lateral Tool Transfer | Network, AD logs, EDR | Alta |
| Exfiltration | T1048 Exfiltration Over Alt Protocol, T1567 Web Service | DLP, proxy, DNS, NetFlow | Très élevé |
Struttura del Team e Ruoli
Un programme d'ingénierie de détection efficace nécessite une combinaison de compétences cela revient rarement à une seule personne. La structure de l'équipe varie détails de l'organisation, mais les rôles spécifiques sont bien définis.
Ruoli Chiave
- Ingénieur Détection - Le rôle central. Écrire, tester et maintenir les règles de détection. Exiger des compétences en termes de compréhension des menaces, des langages et scripts SIEM requis (Python) et familiarité avec les journaux de la plateforme. Selon l'enquête SANS 2025, 60 % des organisations disposent aujourd'hui d'un ingénieur disponible.
- Analyste en renseignement sur les menaces - Fournit un contexte sur les menaces : lesquelles Les groupes APT sont actifs, quelles techniques ils utilisent, quels indicateurs rechercher. Ça les nourrit hypothèse de détection avec une intelligence exploitable.
- Ingénieur de données / Architecte de journaux - Gère la qualité et la disponibilité des données : intégration de nouvelles sources de journaux, normalisation, analyse et gestion des infrastructures de collecte.
- Analyste SOC - L'utilisateur final des détections. Fournit des commentaires fondamental sur la qualité des alertes : trop de faux positifs ? L'alerte n'est pas exploitable ? Informations contextuelles manquantes ?
- Équipe Rouge / Équipe Violette - Simuler les techniques des adversaires pour valider les détections. Le feedback de l’équipe rouge est le mécanisme d’amélioration le plus efficace refus et fidélité aux règles.
Organisation pour petites équipes
Toutes les organisations ne peuvent pas se permettre de disposer d’une équipe d’ingénierie de détection dédiée. Pour les petites équipes de sécurité (3 à 5 personnes), l’approche recommandée est la suivante :
- Attribuer le 20 à 30 % du temps des analystes SOC chez Detection Engineering
- Adoptant Règles de la communauté Sigma comme référence (réf. SigmaHQ)
- Mettre en œuvre un processus de rétroaction structuré du tri des alertes
- Utiliser Détection en tant que code même avec des pipelines simples (Git + script de déploiement)
- Se concentrer sur 10 à 15 techniques ATT&CK les plus pertinentes pour votre secteur
Cas réel : de l’accident au pipeline de détection
Pour concrétiser les concepts ci-dessus, vous trouverez un exemple réaliste pour illustrer jusqu'à la découverte d'une lacune à détecter dans la production.
Scenario: Compromissione via PowerShell Encoded Command
Lors d'un exercice de Purple Teaming, la Red Team parvient à exécuter une charge utile malveillante
en utilisant PowerShell avec une commande codée en Base64 (-EncodedCommand).
L'attaque n'est pas détectée par les détections existantes car elles recherchaient uniquement
des chaînes spécifiques de commandes PowerShell connues, et non le modèle de codage générique.
Step 1: Ipotesi e Analisi
L’ingénieur en détection formule l’hypothèse : "Toute utilisation de PowerShell
-EncodedCommand dans un environnement d'entreprise doit être considéré comme suspect, car
Les logiciels légitimes ont rarement besoin de coder leurs commandes." L'analyse
des logs des 30 derniers jours le confirme : sur 50 000 exécutions PowerShell, seules 12 utilisent
-EncodedCommand, et tous sont attribuables à un script d’automatisation informatique connu.
Step 2: Regola Sigma
title: Suspicious PowerShell Encoded Command Execution
id: f4a3b2c1-d5e6-7890-abcd-ef0123456789
status: test
description: |
Detects execution of PowerShell with encoded commands (-enc,
-EncodedCommand). Legitimate use is rare in enterprise environments.
Attackers commonly use this to obfuscate malicious payloads.
author: Federico Calo
date: 2025/12/01
modified: 2025/12/15
references:
- https://attack.mitre.org/techniques/T1059/001/
- https://attack.mitre.org/techniques/T1027/010/
logsource:
category: process_creation
product: windows
detection:
selection_powershell:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_encoded:
CommandLine|contains:
- '-enc '
- '-EncodedCommand'
- '-encodedcommand'
- '-ec '
filter_known_automation:
ParentImage|endswith: '\sccm_agent.exe'
User|contains: 'SVC_AUTOMATION'
condition: selection_powershell and selection_encoded and not filter_known_automation
falsepositives:
- SCCM automation scripts (filtered)
- Custom IT automation using encoded commands (add to filter)
level: high
tags:
- attack.execution
- attack.t1059.001
- attack.defense_evasion
- attack.t1027.010Step 3: Test, Deploy e Risultati
La règle est testée avec 5 scénarios très positifs (variantes de code de commande) et 20 Scénarios négatifs de faussement (exécutions PowerShell légitimes). Après le déploiement via pipeline CI/CD, en 30 jours la détection a généralement reçu 8 alertes : 6 positifs (scripts suspects à l'analyseur), 1 faux positif (nouveau script d'automatisation à ajouter au filtre) et 1 vous aurez une critique positive conduisant à la découverte d'un accès non autorisé.
Résultats mesurables
- Précision: 87,5% (7 TP sur 8 alertes totales)
- MTTD: réduit de « non détecté » à 4,2 minutes (durée moyenne de génération des alertes)
- Couverture ATT&CK: +2 techniques (T1059.001, T1027.010) ajoutées à la carte
- Impatto reale: 1 compromissione attiva scoperta e contenuta entro 45 minuti
Conclusions et prochaines étapes
L’ingénierie de détection représente un changement de paradigme fondamental en matière de sécurité opérationnel. Ne vous souciez pas d'écrire les meilleures règles dans le SIEM, ne vous souciez pas de les construire un processus d'ingénierie complet qui couvre tout le cycle de vie des détections : de l'hypothèse de menace à la validation en production.
Points clés à retenir :
- La qualité bat la quantité - 50 détections de haute fidélité sont infinies plus utile que 5 000 règles ici génèrent du bruit d'alerte.
- Traiter les détections comme du code - Versioning, revue de code, tests automatisés et les pipelines CI/CD ne sont pas facultatifs, ils sont fondamentaux.
- Mesurez tout - MTTD, MTTR, précision, rappel, couverture ATT&CK. Sans mesures, l’amélioration continue est impossible.
- Commençons par la technique - Cartographier les détections sur MITRE ATT&CK et se concentrer ressources sur les techniques les plus pertinentes pour votre organisation.
- Investissez dans la qualité des femmes - Une détection sûre et inutile sans dissimulation les femmes sur lesquelles opérer. La normalisation et l’intégration des sources quotidiennes sont la priorité. fondement invisible de l’ensemble du programme.
Dans le prochain article
Dans le prochain article de la série, on retrouve les informations détaillées Règlement Sigma: le Format standard pour l'écriture de détections portables. Nous verrons la syntaxe complète, modifications avancées, backends de conversion pour les principes SIEM et nos constructions un ensemble complet de règles pour les techniques ATT&CK et les plus critiques.