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

Normalise des événements hétérogènes sans perdre les originaux

Construis un schéma commun dérivé tout en préservant identifiants, attribution de source et intégrité des événements d'origine.

Durée indicative · ~2 hNiveau avancéPrérequis conseillé · Leçon 2 — qualité et provenancePratique · TP
L’idée reçue

« Normaliser signifie réécrire les logs dans le format qu’on préfère. »

Une bonne normalisation crée un dérivé exploitable et garde un chemin vérifiable vers l’original.

01Sépare trois couches

Dans une chaîne d’analyse, distingue:

source originale
→ contrôle qualité
→ événement normalisé dérivé

Le fichier normalisé facilite la corrélation. Il ne remplace pas la source originale.

Dans le lab:

$lab/source/                 originaux synthétiques
$lab/.source-manifest.sha256 référence d'intégrité
$lab/output/normalized-events.csv dérivé

02Observe le schéma commun

head -n 4 "$lab/output/normalized-events.csv" | column -s, -t

Le Lot 1 conserve au minimum:

event_id
timestamp
source_id
source_type
asset_id
identity_id
event_kind
outcome
severity
detail
synthetic

Ce schéma est un choix pédagogique. Un SOC réel pourrait utiliser ECS, OCSF, un schéma propriétaire ou une autre convention. La compétence visée est la conservation du sens et de la provenance.

03Conserve ce qui permet de revenir à l’original

Deux champs ne doivent pas disparaître:

event_id
source_id

Si une timeline contient seulement:

09:05 login failed

sans pouvoir retrouver l’événement d’origine, tu as perdu une partie essentielle de la preuve.

Le validateur compare la liste des identifiants normalisés avec celle des quatre fichiers source. Un événement supprimé ou inventé fait échouer le lab.

04Normalise la forme, pas l’incertitude

Exemple réseau:

identity_id = -

Le normaliseur conserve -. Il n’essaie pas d’associer automatiquement l’adresse IP à ID-ALICE sans preuve.

Même règle pour un champ absent dans un vrai export: tu peux utiliser une valeur conventionnelle indiquant « non fourni » si le schéma le permet, mais tu dois préserver le fait que la source ne l’a pas démontré.

05Évite trois erreurs classiques

Écraser l’original

source/events/windows-security.csv

ne doit jamais devenir le fichier de sortie.

Perdre la source

Transformer tous les événements en lignes anonymes empêche de juger la qualité et le sens du champ.

Sur-enrichir

Ajouter user=admin parce qu’une IP « ressemble » à celle d’un administrateur transforme une hypothèse en fait.

L’enrichissement est utile seulement si sa source et son niveau de confiance restent identifiables.

06Vérifie l’immutabilité après transformation

sha256sum -c "$lab/.source-manifest.sha256" --quiet

Exécute cette commande depuis source/ si tu veux la reproduire manuellement. Le script le fait à chaque étape critique.

Puis compare:

cat "$lab/.source-manifest.sha256"
cat "$lab/output/source-integrity.sha256"

Les manifestes doivent être identiques.

07Comprends la limite du modèle

Les quatre fixtures d’événements utilisent volontairement une forme CSV compatible. Elles représentent des familles Windows, Linux, réseau et application; elles ne prétendent pas reproduire chaque format natif.

Les formats réels seront étudiés plus loin, notamment Suricata EVE. Le principe appris ici reste valable quel que soit le parseur: original préservé, dérivé traçable, transformation explicite.

Exercice

Conçois un schéma de normalisation minimal

Choisis une source d’authentification et une source réseau. Liste les champs communs, les champs spécifiques et les champs qui ne peuvent pas être inférés. Ajoute pour chaque champ enrichi la provenance attendue.

✓À retenir

Normaliser sert à comparer des événements, pas à réécrire l’histoire. Un bon dérivé reste traçable jusqu’à l’original.

Ta progression

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