Corrèle identité, hôte, réseau et application dans un dossier

01Inspecte les sources séparément

column -s, -t "$lab/source/events/host-events.csv"
column -s, -t "$lab/source/events/network-events.csv"
column -s, -t "$lab/source/events/application-events.csv"

Chaque ligne conserve des identifiants explicites : event_id, alert_id, asset_id, identity_id et source_type.

02Construis une corrélation traçable

column -s, -t "$lab/output/correlation.csv"

Une ligne dérivée contient aussi source_ref, par exemple :

events/host-events.csv#EV-H001

Cette référence permet de revenir à la ligne source au lieu de dépendre d’un résumé narratif.

03Corrèle par contexte connu

Dans le scénario :

AL-001 → AST-DC-01 → ID-ADMIN → Windows Security
AL-002 → AST-WEB-01 → Suricata + application
AL-003 → AST-LNX-APP → ID-SVC-WEB → Linux + application

Le lien est explicite dans les fixtures. Le lab n’invente pas une identité réseau lorsqu’elle vaut -.

04Construis la chronologie

column -s, -t "$lab/output/timeline.csv"

Le tri est déterministe :

UTC timestamp
puis event_id

Une timeline est une vue dérivée. Elle ne remplace jamais les fichiers source.

05Lis la qualité des horloges

column -s, -t "$lab/source/timeline/clock-notes.csv"

La source application est volontairement :

UNTRUSTED
max uncertainty = 120 seconds

Cela interdit d’utiliser son ordre exact comme preuve indépendante d’une séquence stricte avec les autres sources.

06Évite l’over-correlation

Même IP       ≠ même acteur certain
Même identité ≠ même personne certaine
Même minute   ≠ même causalité
Même alerte   ≠ incident confirmé

Le rôle de la corrélation est de rapprocher les éléments utiles à tester, pas de supprimer l’incertitude.

07Observe les refus

Le lab bloque un événement rattaché à une alerte inconnue, un event_id dupliqué et un timestamp mal formé. Ces erreurs empêchent une chronologie audit-able.