Qualifie événement, signal, alerte et incident avec des critères explicites

01Observe les quatre candidats

column -s, -t "$lab/source/classification/candidates.csv"
column -s, -t "$lab/source/classification/criteria.csv"
column -s, -t "$lab/output/classification.csv"

Le résultat contient exactement les quatre classes:

EVENT
SIGNAL
ALERT
INCIDENT

Ces mots ont ici une définition pédagogique déclarée dans criteria.csv. Une organisation réelle doit fixer ses propres seuils, responsabilités et processus.

02EVENT — un fait enregistré

CAND-001 référence une connexion réseau attendue, faible confiance et faible impact.

Elle reste EVENT.

Cela ne signifie pas « sans valeur ». Un événement banal peut devenir important plus tard lorsqu’un autre élément le corrèle.

03SIGNAL — quelque chose mérite d’être rapproché

CAND-002 contient un échec d’authentification privilégiée.

Il dépasse le seuil de signal mais n’a qu’une source et une confiance limitée.

Décision:

SIGNAL

Action adaptée: conserver, enrichir, rechercher répétition ou contexte. Pas encore ouvrir automatiquement un incident critique.

04ALERT — le triage devient nécessaire

CAND-003 relie le verrouillage du compte et une observation réseau. Deux sources et une confiance de 70 atteignent le seuil d’alerte.

Décision:

ALERT

Une alerte signifie ici: un analyste ou un processus de triage doit déterminer ce qui se passe.

Elle ne prouve pas encore la compromission.

05INCIDENT — le scénario représente suffisamment d’éléments

CAND-004 combine:

connexion sortante observée
changement de rôle administratif
export de commandes
3 sources
confiance 90
impact HIGH
compromise=yes dans le scénario synthétique

Les critères déclarés produisent INCIDENT.

Le mot reste borné au scénario. Le lab ne confirme aucun incident réel sur SORIA.

06Rends la décision explicable

Évite:

score élevé → incident

Préfère:

faits observés
+ qualité des sources
+ corroboration
+ confiance
+ impact
+ critère de déclaration
→ décision

Cette chaîne est auditable et peut être révisée si un fait change.

07Conserve la possibilité de revenir en arrière

Une classification n’est pas immuable.

Une alerte peut devenir:

false positive
incident confirmé
activité autorisée
cas non résolu

Un incident peut être requalifié si une preuve essentielle est invalidée. Le système doit conserver la justification de la transition.

Le Lot 3 approfondira cette discipline avec hypothèses et dossier d’investigation.

08Ferme le Lot 1 sans sur-promettre

bash module1-telemetry-timeline-qualification.sh validate "$lab"
cat "$lab/output/decision.txt"
cat "$lab/output/proof-boundaries.md"

Le lot termine par:

TELEMETRY_READY_WITH_ACTIONS

Cela signifie:

• corpus synthétique intègre;
• contrôles qualité reproductibles;
• timeline traçable;
• qualification explicable;
• huit défauts négatifs refusés;
• une lacune de couverture encore visible.

Cela ne signifie pas qu’un SIEM, Wazuh ou Suricata réel est opérationnel, ni qu’une capacité de détection réelle est démontrée.