Écris une règle de détection testable et explicable

01Observe le contrat local

lab=/tmp/soria-ir-lot2-$USER
bash module2-detection-engineering.sh setup "$lab" 2>/dev/null || true
column -s, -t "$lab/source/rules/rules.csv"

Le lab utilise volontairement un mini-format CSV. Ce n’est ni Sigma, ni XML Wazuh, ni une signature Suricata. Il sert à isoler les propriétés qu’une règle doit rendre explicites.

rule_id
version
hypothesis_id
source_type
event_kind
outcome
selector
group_by
threshold
window_seconds
severity
status

02Relie chaque champ à une décision

Pour DET-AUTH-001 :

hypothèse     HYP-AUTH-WIN
source        windows-auth
événement     auth_failure
résultat      FAILURE
groupement    identity_id
seuil         3
fenêtre       300 s
sévérité      high
statut        test
version       2

Chaque valeur peut être discutée et testée. C’est ce qui rend la règle révisable.

03Compare avec Sigma sans confondre les preuves

Une règle Sigma décrit notamment un logsource, une section detection, une condition et peut documenter falsepositives, level et status.

Exemple pédagogique :

title: Repeated authentication failures
status: test
logsource:
  product: windows
  service: security
detection:
  selection:
    outcome: FAILURE
  condition: selection
falsepositives:
  - Approved authentication test
level: high

Le snippet montre une structure. Le lab ne compile pas ce YAML et ne prouve pas qu’un backend SIEM l’interprétera de cette manière.

04Comprends le rôle du statut

experimental → idée prometteuse, bruit possible
test         → logique testée, adaptation environnementale encore nécessaire
stable       → maturité plus forte dans le contexte qui l'a validée

Ne transforme jamais automatiquement test en stable parce que huit fixtures passent.

05Valide la qualité avant le matching

bash module2-detection-engineering.sh run "$lab"
column -s, -t "$lab/output/rule-quality.csv"

Le lab refuse notamment :

hypothèse inconnue
hypothèse NOT_TESTABLE
seuil = 0
fenêtre = 0
sévérité inconnue
ID/version dupliqués

Cela sépare une règle bien formée d’une règle qui « produit juste un résultat ».

06Prépare les tests au même moment

column -s, -t "$lab/source/rules/rule-tests.csv"

Chaque règle possède au moins :

un cas ALERT
un cas NO_ALERT

Une règle testée uniquement avec un événement qui doit matcher peut être beaucoup trop large sans que tu le voies.

07Cartographie vers Wazuh avec prudence

Wazuh permet des règles personnalisées et fournit wazuh-logtest pour tester des événements. En production, le chargement réel dépend du ruleset, des decoders, des champs et de la configuration du manager.

Le lab SORIA ne simule pas ces détails. Il prépare la logique qui devra ensuite être traduite et retestée dans l’outil cible.

08Rédige une fiche de règle maintenable

ID stable
version
hypothèse
sources/champs requis
condition
agrégation ou fenêtre
sévérité
cas positif
cas négatif
faux positifs connus
propriétaire
statut
raison du changement
limite de preuve