Détection et qualification

Bonne lecture et bon apprentissage ! Junior TSAFACK – 26/09/2026 ⏱️ Temps de lecture estimé : 10 minutes

D’où viennent les alertes ?

Source	Exemples
Outils de détection	SIEM (Wazuh, Splunk, Elastic), EDR, IDS/IPS, pare-feu, antivirus
Surveillance de l’intégrité	Alertes FIM (File Integrity Monitoring) sur des répertoires sensibles
Utilisateurs	« Mes fichiers ont une extension bizarre », courriel suspect signalé
Tiers	Client, CSIRT national, chercheur en sécurité, hébergeur
Supervision	Pic réseau inhabituel, service qui tombe, disque qui se remplit

💡 Une bonne partie des incidents graves est découverte par un tiers. Rendez votre adresse de signalement facile à trouver (par exemple un fichier security.txt sur votre site).

Le tri : les cinq questions de qualification

Face à chaque alerte, l’analyste répond à cinq questions, dans cet ordre :

Est-ce réel ? Faux positif, test planifié, maintenance ?
Qu’est-ce qui est touché ? Quel actif, quelle criticité (inventaire du chapitre 3) ?
Est-ce en cours ? L’activité suspecte continue-t-elle ?
Quelles données sont concernées ? Données personnelles, financières, secrets ?
Quelle gravité ? Application de la grille P1 à P4 du chapitre 2.

Application au scénario LogiTrans

Les alertes disponibles à 02 h 50

En consultant le SIEM, l’analyste du SOC retrouve plusieurs alertes liées sur les dernières heures, qui n’avaient pas été corrélées :

Heure (UTC)	Source	Alerte	Niveau SIEM
01 h 52	Pare-feu	Balayage de ports depuis une IP externe vers la zone serveurs	5
02 h 03	srv-erp01	Nombreux échecs d’authentification SSH depuis la même IP externe	10
02 h 11	srv-erp01	Connexion SSH réussie d’un compte technique depuis cette même IP	8
02 h 15	srv-erp01	Création d’un nouveau compte local ajouté au groupe d’administration	8
02 h 24	Pare-feu	Flux sortant inhabituel : 1,8 Go de srv-erp01 vers une IP externe	7
02 h 41	srv-erp01	FIM : modification massive de fichiers dans le répertoire des sauvegardes	12

🔎 Premier constat : chacune de ces alertes, prise isolément, pouvait passer pour du « bruit ». C’est leur enchaînement qui raconte une attaque. Ce sera un point majeur du RETEX (chapitre 7) : il manquait une règle de corrélation.

Les réponses aux cinq questions

Question	Réponse à 02 h 55
Réel ?	Oui. Aucune maintenance planifiée, IP externe inconnue, compte technique jamais utilisé la nuit
Qu’est-ce qui est touché ?	srv-erp01 (criticité 4), potentiellement ses sauvegardes locales
En cours ?	Oui, les modifications de fichiers continuent
Données ?	Base ERP : clients (dont données personnelles de contacts européens), factures
Gravité ?	P1 – Critique : système vital, données personnelles, activité en cours

Escalade

02 h 58 – Le SOC joint l’administrateur d’astreinte de LogiTrans.
03 h 05 – L’Incident Manager (responsable IT) déclare officiellement l’incident P1. C’est l’heure de référence pour les délais réglementaires.
03 h 10 – Le RSSI est prévenu et convoque la cellule de crise pour 07 h 00. Le DPO est informé.

La fiche de qualification

À remplir dès la déclaration. Voici celle de LogiTrans :

FICHE DE QUALIFICATION — INC-2026-0914-01
──────────────────────────────────────────────────────────────
Date/heure de détection   : 2026-09-14 02:41 UTC (alerte FIM)
Date/heure de déclaration : 2026-09-14 03:05 UTC
Déclaré par               : Responsable IT (Incident Manager)
Source de détection       : SIEM Wazuh (SOC externalisé)
Actif(s) concerné(s)      : srv-erp01 (criticité 4)
Type présumé              : Accès non autorisé + tentative de chiffrement
                            + possible exfiltration de données
Données concernées        : Base ERP (clients, factures, contacts UE)
Données personnelles ?    : OUI, probable → DPO informé 03:10
Gravité                   : P1 – Critique
Activité en cours ?       : OUI
Premières actions         : Préservation des preuves, préparation du
                            confinement (voir main courante)
──────────────────────────────────────────────────────────────

La main courante

La main courante (ou journal d’incident) est le document le plus important de toute la réponse. Elle sert à coordonner l’équipe, à justifier les décisions et à prouver la conformité. Règles :

tout y est noté : faits, hypothèses, décisions, actions, appels ;
chaque ligne est horodatée (toujours dans le même fuseau, idéalement UTC) ;
on distingue clairement un fait d’une hypothèse ;
on ne supprime jamais une ligne : on la corrige par une nouvelle ligne ;
elle est tenue hors du SI compromis (papier, outil externe).

Heure UTC	Auteur	Type	Entrée
02:41	SOC	Fait	Alerte FIM niveau 12 sur srv-erp01
02:55	SOC	Fait	Corrélation avec 5 alertes antérieures depuis 01:52, même IP externe
02:55	SOC	Hypothèse	Compromission via accès SSH exposé et compte faible
02:58	SOC	Action	Appel à l’astreinte LogiTrans
03:05	IM	Décision	Déclaration incident P1 INC-2026-0914-01
03:10	IM	Action	RSSI et DPO prévenus par téléphone
03:12	IM	Décision	Priorité : stopper le chiffrement tout en préservant les preuves

Pièges classiques de cette phase

Éteindre le serveur par réflexe : on détruit la mémoire vive, donc des preuves précieuses. Préférez l’isolation réseau (chapitre 6).
Se connecter au serveur compromis avec un compte à privilèges : l’attaquant pourrait récupérer vos identifiants.
Communiquer via la messagerie de l’entreprise : si l’annuaire est compromis, l’attaquant lit peut-être vos échanges. Utilisez un canal de secours.
Oublier de noter l’heure de déclaration : elle déclenche les délais légaux.

Prochaine étape : Analyse et prise de décision →