Formule une hypothèse de détection et sa couverture

01Pars d’un comportement, pas d’un outil

SORIA Distribution veut détecter plusieurs situations : échecs répétés d’authentification Windows, échecs SSH, alertes réseau importantes, balayage répété et exécution de processus inattendue.

Commence par une phrase testable :

Si plusieurs échecs d'authentification visant la même identité apparaissent
sur AST-WIN-01 dans une fenêtre courte,
alors une activité mérite une revue analyste.

La phrase contient un comportement, une portée, une source attendue et un résultat observable. Elle ne dit pas encore « Wazuh », « Sigma » ou « SIEM ».

02Manipule les cinq hypothèses

lab=/tmp/soria-ir-lot2-$USER
bash module2-detection-engineering.sh setup "$lab"
column -s, -t "$lab/source/hypotheses/hypotheses.csv"
column -s, -t "$lab/source/coverage/telemetry-capabilities.csv"

Quatre hypothèses disposent d’une source déclarée AVAILABLE :

windows-auth
linux-auth
network-suricata

La cinquième demande endpoint-edr, mais cette capacité reste GAP.

03Écris le contrat de couverture

Une hypothèse utile indique au minimum :

hypothesis_id
comportement ou risque
source requise
actif concerné
signal attendu
état de couverture
limite

Observe HYP-PROC :

comportement      unexpected-process-execution
source requise    endpoint-edr
actif             AST-LNX-01
signal attendu    process-signal
état              NOT_TESTABLE

Le bon résultat n’est pas de fabriquer un événement de processus pour faire passer la règle. Le bon résultat est de conserver la lacune.

04Distingue trois niveaux de couverture

Le lab prouve le deuxième niveau sur des données synthétiques. Il ne prouve pas le troisième.

05Calcule la couverture sans inventer de source

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

Le résultat attendu contient quatre TESTABLE et un NOT_TESTABLE.

HYP-PROC endpoint-edr NOT_TESTABLE

Cette ligne est une action de sécurité : elle dit précisément ce qu’il faudrait instrumenter avant de prétendre détecter le comportement.

06Relie l’hypothèse à la future règle

Une règle ne doit pas chercher « quelque chose de suspect ». Elle doit être rattachée à une hypothèse et à un signal attendu.

HYP-AUTH-WIN
  ↓
source = windows-auth
  ↓
event_kind = auth_failure
  ↓
group_by = identity_id
  ↓
threshold = 3 / 300 s
  ↓
DET-AUTH-001

Cette chaîne rend la règle explicable et révisable.

07Reconnais les échecs de conception

L’hypothèse est invalide si :

• elle ne nomme aucun comportement observable ;
• elle dépend d’une source absente mais reste marquée TESTABLE ;
• elle ne définit pas la portée d’actif ;
• elle remplace une lacune de télémétrie par une supposition ;
• elle prétend couvrir un SI complet à partir d’un échantillon local.

Le Lot 2 bloque explicitement une règle attachée à une hypothèse NOT_TESTABLE.

08Limite ce que tu conclus

Le lab peut démontrer qu’une hypothèse est testable sur les fixtures fournies. Il ne démontre ni taux de couverture réel, ni détection effective d’une attaque réelle, ni présence d’un EDR.