« Une alerte IDS de sévérité élevée est forcément un incident. »
Une signature qui matche produit une alerte. La décision d’incident exige encore contexte, confiance et corroboration.
01Pars de l’export synthétique
lab=/tmp/soria-ir-lot2-$USER
column -s, -t "$lab/source/network/suricata-eve-alerts.csv"Le fichier représente des champs extraits d’EVE :
timestamp
src_ip
dest_ip
dest_port
proto
signature_id
signature
category
severity
flow_idLe lab utilise du CSV pour rester sans dépendance JSON. Il ne prétend pas remplacer le format EVE réel.
02Conserve les identifiants utiles
L’événement N-001 contient :
signature_id = 900001
category = Malware-Command-Control
severity = 1
flow_id = 1001Dans EVE, signature_id permet d’identifier la signature qui a matché et flow_id aide à relier des événements appartenant au même flux.
Une alerte dérivée qui ne conserve que « malware détecté » perd une grande partie de sa traçabilité.
03Surface une alerte prioritaire
DET-NET-001 sélectionne la signature synthétique 900001.
bash module2-detection-engineering.sh run "$lab"
grep 'DET-NET-001' "$lab/output/network-alerts.csv"Le résultat est high, mais il reste une alerte à examiner. Le lab ne transforme pas ce match en INCIDENT.
04Détecte la répétition d’un scan représenté
Trois événements utilisent signature_id=900010 depuis 198.51.100.45 dans 120 secondes :
N-002 → port 22
N-003 → port 80
N-004 → port 443DET-NET-002 groupe par src_ip et déclenche au troisième événement.
grep 'DET-NET-002' "$lab/output/network-alerts.csv"05Vérifie l’événement isolé
203.0.113.77 ne produit qu’un scan représenté.
Le test attend :
NO_ALERTCela vérifie la fenêtre et le seuil plutôt qu’un simple match de signature.
06Relie le flow au service
column -s, -t "$lab/source/network/flow-context.csv"Le catalogue relie les flow_id synthétiques à des services SORIA représentés : checkout-api, ssh-management, http-service, https-service.
Le contexte métier n’annule pas une alerte. Il aide à décider sa priorité et les vérifications suivantes.
07Comprends le thresholding sans le simuler comme réel
Suricata possède ses propres mécanismes threshold et detection_filter. Le lab reproduit seulement l’idée pédagogique d’une agrégation déterministe sur un export offline.
Il ne prouve ni la syntaxe d’une signature, ni son chargement, ni la visibilité du capteur, ni le comportement d’un moteur Suricata réel.
08Prépare le triage réseau
Pour chaque alerte, conserve :
événement source
signature_id
signature/category
sévérité
src/dst/port/proto
flow_id
règle qui a agrégé
fenêtre/seuil
contexte de service
limite de preuveAnalyse deux alertes réseau
Compare DET-NET-001 et DET-NET-002. Explique pourquoi l’une dépend d’une signature précise et l’autre d’une répétition dans le temps, puis liste les informations manquantes avant toute qualification d’incident.
✓À retenir
Une alerte réseau doit rester reliée à son événement et à son flux. Priorité et répétition guident l’analyse; elles ne constituent pas à elles seules une preuve d’incident.