Rédiger un rapport d'incident de sécurité : modèle et exemple

Un rapport d'incident de sécurité est le document qui raconte un incident une fois traité : ce qui s'est passé, quand, pourquoi, avec quelles conséquences, ce qui a été fait et ce qu'il faut changer. Il sert à la direction pour décider, à l'équipe technique pour corriger, au DPO et au juriste pour les obligations légales, à l'assureur pour indemniser. Ce chapitre distingue le rapport des autres écrits de l'incident, donne un plan type et des règles de rédaction, puis un exemple complet.

Main courante, compte rendu, rapport : trois écrits différents

Le compte rendu d'intervention du support (rédiger un compte rendu) suit la même logique, à plus petite échelle.

Un rapport, plusieurs lecteurs

Le directeur lira une page ; le prestataire, l'annexe technique ; le DPO, la partie sur les données personnelles. Un bon rapport est donc construit en couches : une synthèse lisible par un non-informaticien, puis des parties de plus en plus détaillées, et les éléments bruts en annexe.

Le plan type

1. En-tête : titre, référence, version, date, auteurs, niveau de diffusion (un rapport d'incident décrit vos failles : diffusion restreinte, ou TLP:AMBER+STRICT s'il est partagé).
2. Synthèse (cinq à dix lignes) : ce qui s'est passé, quand, l'impact, la cause, l'état actuel, les décisions attendues de la direction.
3. Contexte et périmètre : systèmes, services, données et personnes concernés.
4. Chronologie : une ligne par fait, avec l'heure, le fuseau et la source.
5. Analyse technique : vecteur d'entrée, actions de l'attaquant (avec les techniques MITRE ATT&CK si utile), cause racine.
6. Impacts : sur la disponibilité, l'intégrité, la confidentialité et la preuve ; impacts métier (heures d'arrêt, commandes perdues), financiers, juridiques, de réputation.
7. Actions menées : confinement, éradication, retour à la normale.
8. Notifications et démarches : registre, CNIL, personnes concernées, plainte, assureur, ANSSI.
9. Recommandations : priorisées, chacune avec un responsable, une échéance et une estimation de l'effort.
10. Retour d'expérience : ce qui a fonctionné, ce qui a manqué dans la réponse elle-même.
11. Annexes : main courante, indicateurs de compromission, extraits de journaux, empreintes et fiches de chaîne de possession.

Les règles de rédaction

Exemple : le rapport de l'incident de srv-web

Voici le rapport final rédigé par Claire Vasseur avec Mehdi et Léa, sans ses annexes.

Rapport d'incident de sécurité AM-SEC-2026-03, version 1.0 du 30 octobre 2026. Diffusion restreinte : direction, service informatique, DPO, prestataire, assureur.

1. Synthèse. Dans la nuit du 12 au 13 octobre 2026, un attaquant a deviné le mot de passe d'un compte technique du serveur du site de vente en ligne (srv-web) et en a pris le contrôle complet pendant environ cinq heures. Le site n'a pas été interrompu. La base des 18 400 comptes clients était accessible par cette intrusion, et peut-être aussi par une injection SQL sur le site le même matin ; l'analyse n'a trouvé aucune trace de copie, sans pouvoir l'exclure. La CNIL a été notifiée, les clients informés, une plainte déposée. La cause profonde est un accès d'administration ouvert sur Internet en 2024 et jamais refermé. Huit recommandations sont proposées ; trois demandent une décision de la direction (budget de double authentification, surveillance de nuit, revue trimestrielle des accès).

2. Périmètre. Serveur virtuel srv-web (Debian 13, Apache, PHP, MariaDB), qui héberge le site de vente en ligne et sa base. Données : identité, coordonnées, historique de commandes et mots de passe hachés (bcrypt) de 18 400 clients. Aucune donnée bancaire (paiement délégué à un prestataire).

3. Chronologie (heure de Paris).

Date et heure	Source	Fait
13/10 02:58:41	Journal SSH	Début d'une attaque par force brute depuis 203.0.113.45 : 38 essais sur 4 comptes
13/10 03:00:50	Journal SSH	Connexion réussie sur le compte deploy par mot de passe
13/10 03:01:30	Journal sudo	Lecture du fichier des empreintes de mots de passe système
13/10 03:02:45	Journal sudo	Téléchargement d'un programme depuis 198.51.100.23
13/10 03:03	Analyse du disque	Ajout d'une clé SSH et d'une tâche planifiée (persistance)
13/10 03:05	Prestataire de surveillance	Alerte envoyée par courriel
13/10 07:40	Main courante	Alerte prise en compte par le service informatique
13/10 07:52	Main courante	Accès SSH depuis Internet fermé, compte verrouillé
13/10 08:20	Main courante	Instantané de la machine (disque et mémoire), empreinte relevée
13/10 11:30	Main courante	Persistances supprimées, mots de passe et clés renouvelés
14/10	Main courante	Notification initiale à la CNIL, plainte, déclaration à l'assureur
15/10	Main courante	Remise de l'instantané au prestataire d'investigation
21/10	Rapport du prestataire	Pas de trace de copie de la base ; programme téléchargé : outil de minage de cryptomonnaie

4. Analyse technique. Accès initial par force brute sur SSH (MITRE ATT&CK T1110), avec un compte valide (T1078) dont le mot de passe figurait dans les listes courantes. Élévation de privilèges par sudo, que le compte pouvait utiliser sans restriction. Transfert d'un outil (T1105) et persistance par clé SSH et tâche planifiée. Le programme installé exploitait le processeur du serveur pour miner de la cryptomonnaie ; il n'a pas été vu tenter d'accéder à la base. Le même jour, des attaques web distinctes (injection SQL sur produit.php, lecture de fichier sur facture.php) ont révélé deux failles du code du site, corrigées le 14 octobre.

Cause racine : en 2024, l'authentification SSH par mot de passe avait été ouverte depuis Internet pour un prestataire, sur un compte doté de sudo sans restriction ; aucune revue des accès n'a permis de la refermer. Facteur aggravant : l'alerte de 3 h 05 n'a été lue qu'à 7 h 40, faute de procédure de nuit.

5. Impacts. Disponibilité : aucune interruption du site. Intégrité : système modifié (outil installé, persistances), remis en état. Confidentialité : accès possible aux données de 18 400 clients par l'intrusion SSH et par l'injection SQL de produit.php, sans preuve de copie à ce stade (journaux de la base et tailles de réponses analysés par le prestataire) ; lecture de /etc/passwd par la faille de facture.php. Coûts : 3,5 jours de travail interne, intervention du prestataire.

6. Notifications. Violation inscrite au registre le 13/10. Notification initiale à la CNIL le 14/10, complémentaire le 23/10. Information des clients le 16/10, avec réinitialisation forcée des mots de passe. Plainte le 14/10. Déclaration à l'assureur le 14/10.

7. Recommandations.

N°	Recommandation	Responsable	Échéance	Effort
1	SSH par clé uniquement, connexion de root interdite, sur tous les serveurs	Mehdi Ouali	30/10/2026	2 h
2	Accès d'administration uniquement par VPN avec double authentification	Mehdi Ouali	30/11/2026	3 jours, budget à valider
3	Droits sudo limités aux commandes nécessaires pour les comptes techniques	Léa	15/11/2026	1 jour
4	Procédure de traitement des alertes critiques la nuit et le week-end (astreinte ou prestataire)	Claire Vasseur	31/12/2026	Décision de la direction
5	Revue trimestrielle des accès ouverts et des comptes techniques	Claire Vasseur	Dès janvier 2027	1/2 jour par trimestre
6	Requêtes préparées et contrôle d'accès sur tout le code du site, revue avant chaque mise en production	Hugo	31/01/2027	5 jours
7	Base de données sur un serveur distinct du serveur web	Mehdi Ouali, Hugo	31/03/2027	2 jours
8	Exercice de crise annuel sur un scénario de compromission	Claire Vasseur	Juin 2027	1/2 journée

8. Retour d'expérience. Ont bien fonctionné : la centralisation des journaux (aucune trace perdue), la règle de corrélation du prestataire, la main courante, la préservation des preuves avant tout nettoyage. Ont manqué : le traitement de l'alerte la nuit, l'inventaire des accès ouverts, une procédure écrite de notification (la décision de notifier la CNIL a pris une journée).

Le rapport et ton portfolio

Un incident traité pendant ton stage ou ton alternance peut devenir une réalisation professionnelle pour l'épreuve E5, au titre de la compétence « Répondre aux incidents et aux demandes d'assistance et d'évolution » (l'épreuve E5). Le rapport, anonymisé et validé par ton tuteur, en est la meilleure preuve : il montre la démarche, pas seulement le résultat. Retire les adresses, les noms, les identifiants et tout ce qui décrit une faille non corrigée.

À l'E7

À l'écrit, on ne te demande pas un rapport de huit pages, mais des écrits courts qui en ont les qualités.

• SISR, métropole 2023 (alors E6, U6), cas de la Ville du Parc : la question C1.1 demande de « rédiger un compte-rendu pour la phase d'investigation numéro 2 (identification) » avec la cause probable, la qualification de l'alerte et ses indicateurs de compromission, et la liste des autres machines qui ont pu être touchées.
• SLAM, Nouvelle-Calédonie 2023 (alors E6, U6), cas Yak : la question C2.1 fait émettre une hypothèse sur l'origine d'un événement suspect des journaux « dans une courte note à destination de votre responsable ».
• SISR, métropole 2025 (U7), cas SA Blanca : la responsable demande « un compte-rendu exposant la remédiation choisie et démontrant si cette dernière est opérationnelle ».

Pour ces questions : une phrase de conclusion d'abord, puis les faits tirés des documents (avec leur référence), puis la recommandation. Pas d'introduction générale sur la cybersécurité.

Exercices

Exercice 1 sur 4 Réécrire une synthèse Réussi À revoir

Voici la synthèse d'un rapport. Réécris-la pour la direction en six lignes au plus.

« Suite à des événements anormaux constatés sur l'infrastructure, nous avons investigué les logs du FW et de l'AD et constaté des 4625 en masse sur le RDP du TSE depuis une IP malveillante, puis un 4624 type 10 sur le compte d'un admin, qui a ensuite créé un compte et l'a ajouté aux admins locaux avant de clear le journal. Le serveur a été isolé et les comptes désactivés. Il faudrait voir pour améliorer la sécurité. »

Voir la réponseMasquer la réponse de l'exercice 1

Proposition :

« Le 20 octobre au soir, un attaquant a deviné le mot de passe d'un administrateur et s'est connecté à distance au serveur d'applications, ouvert sur Internet. Il s'y est créé un compte d'administration, puis a tenté d'effacer ses traces. Le serveur a été isolé et les comptes concernés désactivés le soir même ; aucune autre machine ne semble touchée, vérification en cours. La cause est l'ouverture du bureau à distance sur Internet sans double authentification. Nous demandons la validation de deux mesures : supprimer cet accès au profit d'un VPN avec double authentification, et revoir les mots de passe des comptes d'administration. »

Les sigles (FW, AD, TSE, RDP), les identifiants d'événements et le jargon (« clear », « investigué les logs ») restent dans l'analyse technique. La synthèse dit quoi, quand, l'impact, la cause, l'état et la décision attendue.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Fait, déduction ou hypothèse ? Réussi À revoir

Classe chaque phrase.

1. « Le journal du pare-feu montre 1,8 Go envoyés vers 198.51.100.23 à 02:12. »
2. « Les données envoyées sont probablement les documents du serveur de fichiers. »
3. « Le poste a donc communiqué avec un serveur connu de l'attaquant. »
4. « L'attaquant voulait sans doute revendre ces données. »
5. « 4 312 fichiers ont été ouverts avec le compte j.perrin entre 02:09 et 02:12. »

Voir la réponseMasquer la réponse de l'exercice 2

1. Fait (source citée : journal du pare-feu).
2. Hypothèse plausible (rapprochement des volumes et des heures), à confirmer par l'analyse du poste ou des flux.
3. Déduction : tirée du fait 1 et de l'indicateur de compromission connu (198.51.100.23 est déjà associée à l'attaquant).
4. Hypothèse sur l'intention, invérifiable en l'état : à éviter dans un rapport, ou à présenter comme telle.
5. Fait (journal du serveur de fichiers).

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Des constats aux recommandations Réussi À revoir

À partir de ces constats, rédige trois recommandations précises et priorisées (action, responsable, échéance).

• Le bureau à distance du serveur d'applications est ouvert sur Internet.
• Le compte compromis est un compte d'administration utilisé aussi pour la messagerie.
• Le journal Sécurité du serveur a été effacé, mais une copie existait sur le collecteur.

Voir la réponseMasquer la réponse de l'exercice 3

Priorité	Recommandation	Responsable	Échéance
1	Fermer le bureau à distance sur Internet ; accès par VPN avec double authentification uniquement	Administrateur réseau	Immédiat (fermeture), un mois (VPN)
2	Séparer les comptes : un compte nominatif sans privilège pour la bureautique et la messagerie, un compte d'administration distinct, utilisé seulement depuis un poste d'administration	Responsable informatique	Deux semaines
3	Ajouter une alerte critique du SIEM sur l'effacement d'un journal (événement 1102) et sur la création d'un compte suivie d'un ajout à un groupe d'administration	Administrateur systèmes	Une semaine

Le troisième constat est aussi un point positif à mentionner dans le retour d'expérience : la centralisation a sauvé les preuves.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Une note à ton responsable Réussi À revoir

Le journal de l'application de réservation d'une agence de voyages contient, pour le 10 mai, entre 14:02 et 14:04, 640 lignes RESERVATION_VIEW du même compte client c.dupont, avec des numéros de réservation qui se suivent de R-10001 à R-10640, depuis l'adresse 203.0.113.150. Ce client a d'habitude deux réservations. Rédige une note de cinq lignes à ton responsable.

Voir la réponseMasquer la réponse de l'exercice 4

Proposition :

« Le 10 mai entre 14:02 et 14:04, le compte client c.dupont a consulté 640 réservations aux numéros consécutifs (R-10001 à R-10640) depuis l'adresse 203.0.113.150 (journal applicatif). Ce client n'en possède que deux : il s'agit très probablement d'une énumération automatisée exploitant une absence de contrôle d'accès sur la consultation des réservations (accès aux objets d'autrui). Les réservations contiennent des données personnelles : une violation de confidentialité est probable, à inscrire au registre et à évaluer pour une notification à la CNIL sous 72 heures. Je propose de désactiver immédiatement la consultation par numéro, de bloquer l'adresse, puis de corriger le code pour vérifier que la réservation appartient au client connecté. »

Tu avais trouvé ?

Oui, j'avais bonPas encore