Détection et réponse aux incidents · Étape 01

Construis une chronologie corrélée multi-source

Ordonne les événements normalisés, conserve leur provenance et distingue proximité temporelle de relation causale.

Durée indicative · ~2 hNiveau avancéPrérequis conseillé · Leçon 3 — normalisation traçablePratique · TP
L’idée reçue

« Deux événements proches dans le temps prouvent qu’ils appartiennent à la même attaque. »

La proximité est une piste de corrélation. La causalité exige davantage de contexte et de preuve.

01Produis la chronologie

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

Le lab trie par:

1. timestamp
2. event_id comme départage déterministe

Un ordre déterministe est important pour comparer deux exécutions, écrire des tests et éviter qu’une variation de l’outil donne l’impression que les faits ont changé.

02Lis une séquence sans conclure trop tôt

Extrait du scénario:

09:03 EVT-W-002 échec d'authentification privilégiée
09:04 EVT-W-003 verrouillage du compte
09:05 EVT-N-002 alerte du capteur réseau
09:06 EVT-L-002 sudo réussi
09:07 EVT-N-003 connexion sortante observée
09:07:30 EVT-A-002 changement de rôle
09:08 EVT-A-003 export de commandes

Cette séquence justifie des questions. Elle ne démontre pas à elle seule que le même acteur est derrière tous les événements.

03Corrèle avec des clés explicites

Les clés possibles incluent:

asset_id
identity_id
source_id
session_id si la source en fournit un
adresse réseau avec précautions
event_id de référence

Dans ce lot, ID-ADMIN relie plusieurs observations d’hôte et d’application. Les événements réseau n’ont pas d’identité déclarée. Tu ne dois pas créer ce lien sans une donnée supplémentaire.

04Distingue fait, corrélation et hypothèse

Écris tes notes en trois colonnes:

Niveau Exemple Formulation
Fait EVT-A-003 existe dans l’original « un export est enregistré à 09:08 »
Corrélation deux événements partagent ID-ADMIN « ils concernent la même identité déclarée »
Hypothèse la connexion réseau est liée à l’export « relation possible, à confirmer »

Cette discipline prépare l’investigation du Lot 3.

05Teste la traçabilité

Le validateur compare chaque event_id normalisé à l’ensemble des identifiants source:

bash module1-telemetry-timeline-qualification.sh validate "$lab"

Une timeline qui invente ou perd une ligne échoue.

Tu peux vérifier manuellement un événement:

grep 'EVT-A-003' "$lab/output/timeline.csv"
grep -R 'EVT-A-003' "$lab/source/events"

06Mesure l’effet de l’horloge

Imagine que SRC-NET dérive de +8 minutes. La connexion sortante observée à 09:07 apparaîtrait après l’export à 09:08 alors qu’elle aurait peut-être eu lieu avant.

C’est pourquoi le Lot 1 bloque une dérive hors tolérance plutôt que de « corriger » silencieusement le timestamp.

Dans une vraie investigation, la correction d’horloge doit être documentée avec sa méthode et son incertitude.

07Ne transforme pas une timeline en verdict

Une timeline sert à:

  • ordonner les observations;
  • rechercher les trous;
  • comparer les sources;
  • construire des hypothèses;
  • identifier les moments où davantage de preuve est nécessaire.

Elle ne remplace pas le triage, l’investigation ni la décision de confinement.

Exercice

Annoter une chronologie

Pour cinq lignes du scénario, marque chacune comme fait, corrélation ou hypothèse. Pour toute hypothèse, écris la source supplémentaire qui permettrait de la confirmer ou de la réfuter.

✓À retenir

Une bonne chronologie est déterministe et traçable. Elle rapproche les observations sans confondre ordre temporel et causalité.

Ta progression

Chargement de l’état… Se connecter pour synchroniser.