Un virement que personne n’a fait
Un vendredi à 17 h, la comptable d’une PME de Lille remarque un virement de 8 400 € qu’elle n’a jamais fait. Son poste est lent depuis le matin.
Elle hésite : éteindre l’ordinateur, tout effacer, ou attendre lundi.
Les premières minutes comptent beaucoup. Cette leçon donne les bons réflexes, dans le bon ordre.
À la fin de cette leçon
Remarque
Je peux dire les premiers gestes après un incident de sécurité.
Mots clés
| Mot | Ce que ça veut dire | Exemple |
|---|---|---|
| Incident | un événement qui menace les données ou le service | |
| Signaler | prévenir vite la bonne personne | |
| Contenir | empêcher l’incident de s’étendre | |
| Preuve | une trace qui montre ce qui s’est passé | |
| Journal | un fichier où un système note ce qui se passe | connexions.log |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
D’abord, on signale tout de suite
Le premier geste est de signaler. Prévenez votre responsable et le service informatique, ou la personne chargée de la sécurité.
Dites ce que vous avez vu, à quelle heure, sur quelle machine. N’attendez pas d’être sûr.
Si des données personnelles ont fui, l’entreprise doit en général prévenir la CNIL dans les 72 heures. Ce n’est pas à vous de le faire, mais votre alerte lance le compte.
Contenir sans détruire
Contenir, c’est empêcher l’incident de s’étendre. Débranchez le câble réseau ou coupez le Wi-Fi du poste touché.
Ne l’éteignez pas : la mémoire contient des preuves qui disparaîtraient. N’effacez rien non plus.
Changez les mots de passe concernés, mais depuis un autre poste sain.
Exemple : bon ou mauvais réflexe
| Geste | Bon réflexe ? | Pourquoi |
|---|---|---|
| Débrancher le câble réseau | Oui | L’attaquant perd l’accès au poste |
| Éteindre l’ordinateur | Non | Les traces en mémoire disparaissent |
| Supprimer le fichier suspect | Non | C’est une preuve |
| Changer le mot de passe depuis un autre poste | Oui | Le poste touché peut l’espionner |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Une erreur fréquente
Attention
Beaucoup pensent qu’il faut tout nettoyer seul, vite, avant que quelqu’un le remarque. On efface alors les preuves et l’incident continue ailleurs. Signalez d’abord et ne touchez à rien d’autre, car l’équipe a besoin des traces pour arrêter l’attaque.
Les journaux racontent ce qui s’est passé
Chaque serveur tient des journaux. Une ligne par événement : la date, l’heure, ce qui s’est passé, qui, depuis où.
Beaucoup de connexions refusées depuis la même adresse montrent souvent quelqu’un qui essaie des mots de passe.
La commande grep trouve vite ces lignes. Lancez le code pour lire un journal de connexions.
Essayez : fouiller un journal de connexions
mkdir -p incident && cd incident
printf '%s\n' \
"2026-10-16 08:02 SUCCES user=claire ip=10.0.0.12" \
"2026-10-16 08:15 ECHEC user=admin ip=203.0.113.9" \
"2026-10-16 08:15 ECHEC user=admin ip=203.0.113.9" \
"2026-10-16 08:16 ECHEC user=root ip=203.0.113.9" \
"2026-10-16 08:40 ECHEC user=claire ip=10.0.0.12" \
"2026-10-16 08:41 SUCCES user=claire ip=10.0.0.12" > connexions.log
# Toutes les connexions refusées
grep ECHEC connexions.log
# Combien en tout ?
grep -c ECHEC connexions.log
# Seulement celles de l'adresse suspecte
grep ECHEC connexions.log | grep 203.0.113.9
# Cherchez maintenant les connexions réussies de claire.